03 - 代码审查¶

AI 编程时代，代码审查的重要性不是降低了，而是提高了。因为现在问题不再只是“人写错”，还包括“模型自信地写错、写旧、写过度、写得不可维护”。

这章解决什么问题¶

很多人把 AI 代码审查看成“再问一次模型”。这远远不够。

真正的代码审查要回答：

• 逻辑对不对
• 风险大不大
• 是否破坏了旧行为
• 是否真的通过了验证
• 是否值得长期维护

所以这章要把“代码审查”从简单点评，升级为 AI 产出治理。

学习目标¶

• 建立一套适用于 AI 代码产出的审查框架
• 学会区分正确性、风险、性能和可维护性问题
• 学会识别 AI 特有的错误模式
• 能把审查结果转成 PR 级别的改进动作

为什么 AI 时代更需要 review¶

因为 AI 代码有几个典型特征：

• 生成速度快
• 表面上通常很像对的
• 容易包含隐藏风险
• 容易做过度抽象
• 容易和现有仓库风格错位

也就是说，AI 让“产出速度”提升了，但把“判断质量”的责任更集中地压回给开发者。

代码审查的 4 层框架¶

建议把 review 固定成下面 4 层。

大部分低质量 review 只停留在 L1。

AI 代码最常见的 8 类问题¶

先把常见错误模式认出来，review 才不会退化成只看“能不能跑”的表面检查。

1. 幻觉 API¶

表现：

• 调用了不存在的函数
• 参数名错误
• 引用了过时 API

这类问题经常“看起来像能跑”，但实际上不成立。

2. 只修表象，不修根因¶

表现：

• 通过加 if 绕过报错
• catch 一切异常后直接吞掉
• 没有真正找到根因

这是修 bug 场景里最常见的问题。

3. Happy Path 偏置¶

表现：

• 正常输入能跑
• 空值、异常、超时、并发场景没考虑

如果 review 不看边界，线上很容易出问题。

4. 过度设计¶

表现：

• 简单逻辑引入复杂抽象层
• 平白增加 class / interface / helper
• 重构幅度远超任务需要

AI 很喜欢“写得像架构”，但未必适合当前仓库。

5. 风格不一致¶

表现：

• 命名、错误处理、日志格式和仓库既有规范不一致
• 引入不同风格的测试结构

这会直接提高后续维护成本。

6. 不必要的依赖和改动范围膨胀¶

表现：

• 顺手引入新库
• 多改了无关文件
• 为了一个功能改了多个层级

复杂仓库里这类问题很危险。

7. 缺失测试或测试无效¶

表现：

• 没补测试
• 只补 happy path 测试
• 测试无法真正覆盖变更风险

AI 产出的代码如果没有验证，可信度会显著下降。

8. 注释和说明“像对的”，但与真实行为不一致¶

这类问题会污染文档和团队认知，也很常见。

一套可复用的 AI 代码审查清单¶

建议你固定用下面这套 checklist。

一、需求对齐¶

• 这段代码是否真的满足任务目标
• 是否超出了本次任务边界
• 是否遗漏了关键验收条件

二、逻辑正确性¶

• 正常输入是否正确
• 空输入/异常输入是否正确
• 是否有空指针、越界、状态错误
• 是否引入竞态或并发问题

三、安全与风险¶

• 是否有注入风险
• 是否错误处理过宽
• 是否泄露敏感信息
• 是否破坏权限边界

四、性能与资源¶

• 是否引入明显低效路径
• 是否有不必要的重复计算
• 是否影响热点接口时延
• 是否增加了资源占用

五、可维护性¶

• 命名是否清晰
• 抽象是否必要
• 代码是否容易读懂
• 是否和现有风格一致

六、验证闭环¶

• 是否补了必要测试
• 测试是否真正覆盖风险点
• lint / build / test 是否明确执行
• 是否有回滚或降级思路

代码审查时最有效的 4 个动作¶

下面这 4 个动作的核心价值，是让审查过程更像结构化排雷，而不是随缘看 diff。

动作 1：先回到 spec¶

review 之前先看：

• 本次任务目标是什么
• non-goals 是什么
• 验收标准是什么

很多 review 失败，是因为 reviewer 自己都没按任务边界看代码。

动作 2：只看关键 diff，不要先看全文¶

重点看：

• 改了哪些文件
• 哪些逻辑分支变化了
• 哪些接口行为变化了
• 有没有新增依赖或配置

AI 时代 review 的首要任务是识别“范围是否失控”。

动作 3：追问边界和失败场景¶

至少问自己：

• 空值怎么办
• 超时怎么办
• 老配置怎么办
• 测试失败怎么办
• 回滚怎么办

动作 4：把发现的问题分类¶

建议固定成这 4 类：

• bug
• risk
• style
• follow-up

这样 review 更容易落地成明确动作。

一个高质量审查模板¶

下面这版适合你让 AI 做第一轮 review，也适合你自己人工参考：

请从以下角度审查这次改动：

1. 需求是否实现完整
2. 是否存在逻辑错误或边界遗漏
3. 是否引入安全或兼容性风险
4. 是否有不必要的复杂度
5. 是否补了足够测试

输出格式：
- Findings: 发现的问题，按严重程度排序
- Risks: 仍需关注的风险
- Tests: 建议补充的测试
- Summary: 改动是否建议合并

代码审查不是让 AI 自审一次就结束¶

可以让 AI 做：

• 第一轮静态审查
• 找边界 case
• 总结潜在风险
• 生成测试建议

但最后仍然要有人看：

• 逻辑是否和业务一致
• 是否符合当前仓库约束
• 是否值得以当前形态合并

如果让 AI 自己写、自己审、自己通过，那只是把风险包进流水线。

面向不同任务，review 重点不同¶

不同任务的风险来源不同，所以 review 关注点也必须跟着变。

1. 缺陷修复¶

重点看：

• 根因是否真被修掉
• 是否只是打补丁
• 是否补了防回归测试

2. 新功能开发¶

重点看：

• 需求是否完整
• 行为是否和旧系统兼容
• 接口/文档是否同步

3. 重构¶

重点看：

• 外部行为是否未变
• 改动范围是否过大
• 是否有隐藏回归风险

4. 测试生成¶

重点看：

• 测试是否真的覆盖关键路径
• 是否只是机械复制函数名
• 是否覆盖边界和失败场景

2028 面试里怎么讲代码审查能力¶

不要只说：

我会用 AI review code。

更好的表达是：

我把 AI 代码审查分成正确性、风险、工程性和系统一致性四层。
复杂改动除了让模型做初审，我还会结合 spec、测试门禁和关键 diff 做人工确认，重点防止 AI 产出中的幻觉 API、边界遗漏和过度设计。

这会比“会用审查工具”有说服力得多。

一份适合写进项目里的 review 流程¶

1. 生成 patch
2. 输出改动摘要
3. 跑 lint/test/build
4. AI 初审
5. 人工审关键 diff 和风险点
6. 决定合并 / 回退 / 继续修复

如果你在项目里能把这条流程做成模板或平台能力，价值会更高。

最容易犯的 5 个错误¶

1. 只审风格，不审逻辑¶

这是最低效的 review 方式。

2. 看到测试绿就直接过¶

测试覆盖不足时，这个结论并不成立。

3. 不看任务边界¶

不知道本次任务目标，review 就会失焦。

4. 不区分严重程度¶

所有问题都一样写，会降低执行效率。

5. 没有形成复用清单¶

如果每次 review 都从零开始，团队很难积累。

本章小结¶

• AI 时代的代码审查，本质上是 AI 产出治理
• 高质量 review 至少覆盖正确性、风险、工程性和系统一致性
• 你真正要练的是“识别高风险错误模式并把它变成流程”

下一步¶

• 继续看 04-代码优化
• 再看 05-测试生成
• 配合 08-AI协作开发方法论 把 review 纳入完整工作流