AI 时代 Code Review 面试：怎么点评生成代码而不显得刻薄

AI 产代码的速度，已经超过团队安全接收代码的速度。所以 code review 面试会越来越重要。

现在的问题不只是“你会不会写代码”，还包括“你会不会判断代码”。

这类面试真正考什么

Code review 面试不是让你证明自己比作者聪明，而是看你能不能保护系统，同时保持协作。

面试官通常在听五件事：

• 你能不能发现正确性问题
• 你能不能指出缺失测试
• 你能不能解释运行风险或安全风险
• 你能不能区分阻塞问题和个人偏好
• 你的反馈方式团队能不能真的使用

AI 时代还有一个额外信号：你能不能 review 看起来很合理的生成代码。

AI 生成代码常常表面干净，真正风险藏在假设、上下文缺失、过时 API、薄弱错误处理和未覆盖边界里。

分层 review

不要一上来挑命名。先看风险。

意图

这个改动想解决什么？实现是否匹配需求？

正确性

什么输入会打破它？什么状态转换不安全？依赖失败时会怎样？

测试

关键路径有没有覆盖？边界有没有覆盖？这个测试在修复前会不会失败？

可维护性

代码是否容易理解？是否符合本项目模式？有没有引入不必要抽象？

安全和运行风险

会不会泄露数据、重复计费、制造 race condition，或隐藏失败？

这些之后，再谈风格问题。

强 reviewer 的表达方式

弱 reviewer 会说："这代码不行。"

强 reviewer 会说："主思路是合理的，但我会在合并前阻塞两个点：空输入路径和 retry 行为。如果 retry 会再次调用这个函数，可能导致重复记录或重复计数。"

区别很明显。强表达指出风险、说明触发条件，并给出验证方式。

另一个好用句式是：

"我会把这个作为 blocking comment，因为它会影响用户数据。命名问题是 non-blocking，可以单独处理。"

这种优先级判断会让你听起来更成熟。

如何 review AI 生成代码

如果面试官说这段代码是 AI 生成的，不要把回答变成 AI 立场演讲。还是按正常代码 review，但更关注隐藏假设。

你可以问：

• 代码是否推断了需求里没有说的东西
• 它选择的库或 API 在这个项目里真的存在吗
• 错误处理方式是否符合当前代码库
• 它是否为简单任务引入了不必要复杂度
• 测试是在验证行为，还是只是在迎合生成实现

这些问题说明你理解 AI coding 的真实风险：不是代码一定很差，而是它可能非常自信地偏离上下文。

示例回答

"我会先确认预期行为。这个实现的 happy path 看起来合理，但合并前我会看三个风险。

第一，空输入会直接返回成功，但这里不清楚这是不是预期行为。我会补一个测试来定义它。

第二，retry 路径似乎会再次调用写操作。如果这个 action 不是幂等的，可能会产生重复记录。

第三，错误处理记录了原始 payload。如果 payload 里包含用户内容，就可能暴露敏感数据。

我会阻塞 retry 和日志问题，因为它们影响数据完整性和隐私。命名问题我会作为 non-blocking 留下。"

Interview AiBox 能帮什么

Code review 面试难，是因为你要一边想，一边把判断说清楚。Interview AiBox 可以帮助你练习这种表达节奏：观察、排序、解释、提出验证。

不要只说“这里可能会坏”，而是练成“这个假设在空输入时不成立，我会在合并前用一个回归测试验证”。

这就是发现问题和像队友一样 review 的区别。

FAQ

Code review 面试是不是要表现得很挑剔？

要具体，不要刻薄。你的目标是保护系统，并帮助作者改好这个变更。过度负面会让你看起来难合作。

如果我找不到严重 bug 怎么办？

可以直接说。然后 review 测试覆盖、边界条件、可维护性和运行风险。好的 review 不是硬编问题。

主观风格问题怎么处理？

除非违反项目约定，否则标成 non-blocking。强 reviewer 会区分正确性、安全性和个人偏好。

下一步

• 阅读 真实工作型技术面
• 查看 Coding Agent 之后的初级工程师面试
• 了解 Interview AiBox 功能全景
• 下载 Interview AiBox