AI 写的代码谁审？把机器审查和人工审查的分工划清楚

一个正在普遍发生的事实：团队里 AI 生成的代码占到六七成，但 Code Review 的流程还是三年前那一套——人看 diff，点 approve。

问题在于，人看不动了。审查者面对的不再是同事写的、有思路可循的代码，而是量更大、结构更“正确”、但可能埋着语义错误的代码。同时，越来越多的团队用 AI 做第一轮 review，而 AI reviewer 有个致命倾向：它特别擅长放过“看起来正常”的错误。

AI Reviewer 擅长的和不擅长的

先说它真能干好的：

• 命名、格式、明显的空指针、未使用变量
• 有没有写测试、边界条件是否覆盖
• diff 与 PR 描述是否一致（这条人经常懒得查）
• 重复代码、可以抽出的公共逻辑

它干不好的，恰恰是最需要人的：

• 业务语义对不对——这个折扣该不该在退款时回滚，AI 不知道你们的规则。
• 架构是否被侵蚀——新增的这层耦合，半年后会不会让某个模块动不了。
• 安全边界——权限校验缺失时，AI 可能觉得“逻辑通顺”就通过了。
• 可运维性——这段重试会不会在高峰期把下游打挂。

结论很清楚：AI Reviewer 只适合做“事实层”的检查，不适合做“判断层”的决策。

三档审查模型

第一档：机器必查，人不看。 格式化、lint、类型检查、单测通过率、复杂度阈值、敏感信息扫描。这些没过就不该进人眼，否则是在浪费最贵的资源。

第二档：机器初筛，结果进 PR 评论但不阻塞。 由 AI reviewer 输出结构化清单，带严重度分级。关键是要求它标注置信度和依据：“第 42 行可能缺少空值判断，依据是上面 30 行的返回值可能为 null”。没有依据的意见一律不看。

第三档：人工必看，且只看这些地方。 边界定义清楚，人才能快：

1. 涉及钱、权限、数据删除的 diff；
2. 新增的跨模块调用；
3. 配置与开关变更；
4. 公共组件被改动时，调用方的兼容性；
5. AI reviewer 标记为“不确定”的段落。

一个反直觉的做法：让 AI 解释，不让人读

审查效率最低的环节是“陌生代码理解”。这里可以换一个用法：不要求人逐行读，而是让 AI 针对每个被改动的函数生成一段“改动意图 + 影响面 + 风险点”的说明，人只判断意图与影响面是否可接受。

判断意图比判断实现快一个数量级。审查者的角色从“读代码的人”变成“批准意图的人”，这是唯一能跟上代码供给速度的方式。

必须守住的三条底线

一、AI 不能批准自己写的代码。 这是最基本的隔离，道理和“不能自己给自己签字”一样。

二、任何 AI reviewer 的放行结论不可作为合并依据。 它可以说“我没发现问题”，不能说“可以合并”。

三、责任仍然在人。 PR 的 approve 人就是责任人。这条不能因为工具链升级而模糊——一旦模糊，团队的行为模式会迅速滑向“反正 AI 看过了”。

衡量这套流程有没有用

别只看审查速度，看两个指标：上线后 7 天内由本次 PR 引入的缺陷数，以及人工审查的驳回率。如果驳回率长期接近零，通常不是代码质量好，而是人已经不看了。