AI 代码审查如何从逐行阅读转向证据核验

AI 写代码越来越快，人工审查却很难跟着提速。Aviator 的做法是把审查拆开：机器检查反复出现的规则，人来判断变更意图、验收标准、不能破坏的约束、设计决策，以及运行证据，不再要求每个 PR 都逐行读完。

作者称，同样 9 名工程师每周合并的 PR 增至 4 倍，合并耗时中位数从 2.1 天降到 3.4 小时，回滚率下降 40%，每个 PR 仍由人签字。这套方法值得看，但数据能否支持一般团队照搬，需要分开判断。

为什么增加审查工具，反而没解决瓶颈

他们团队每周合并的 PR 从约 100 个增加到超过 400 个，AI 生成 PR 的代码行数中位数达到 640 行。作者引用的常见判断是，超过 400 行后，人工发现缺陷的效果会下降；原文没有展开这个阈值的依据。

团队先后试过三种办法，问题都没有消失。

AI reviewer 在作者的一个 PR 中开启了 18 个讨论线程中的 16 个，多数是细枝末节，淹没了两条重要的人工意见。把首次审查 SLA 设成 4 小时，虽然让响应更快，却让审批变成赶时间的扫读。按团队规范调整自审 skill，发现的问题更有用了，但它依然是在代码写完后读取 diff，推理过程也留在聊天窗口里。

三种尝试都在改善「怎么读差异」，没有解决「哪些事情需要人判断」。

作者还引用 Microsoft 在 2013 年的 Bacchelli & Bird 研究：只有 14% 的审查评论涉及缺陷。这不能证明审查不必找 bug，但提醒了一个容易被忽略的作用：审查也是团队共享知识、更新系统认知的过程。

把重复意见写成规则，把分歧提前暴露

这套方法的关键，是让规则有固定的检查方式，让决策留下可追溯的理由。

他们从一年的 11,400 条审查评论中提炼出 212 条候选规则，最终批准 64 条不变量（invariants）。这里的不变量，就是系统必须持续满足的约束，例如「每次配置变更都要写审计日志，而且只有实际发生变化时才写」。

每条约束都有适用范围、验证方法、来源和负责人。能转换成静态检查的，就由 agent 编译成 ast-grep 规则，先与模型并行运行、比对结果，再交给确定性的检查程序。目前有 19 条采用这种方式，总耗时 0.3 秒。

这个过程比单纯维护一份提示词更具体：规则不仅告诉 AI 应该怎么写，还规定由什么机制检查、出了问题谁负责维护。

设计分歧则提前到 PR 创建之前处理。审查 agent 会质询作者的 agent，两者使用不同模型，所有分歧都被记录。能解决的要写明理由，无法解决的交给人。PR 最后列出每项决策的来源和裁定者，审查者可以略读已解决事项、处理剩余争议，也可以重新打开自己不认同的决定。

不同模型不保证判断正确，但留下争论过程，至少让人能检查结论是怎么来的。

验收证据从哪里来，为什么 CI 绿灯还不够

他们没有要求先写一份完整规格，而是从编码会话里提取意图和验收标准。工程师纠正 agent、回答问题时，往往已经表达了具体要求；过去这些信息会随会话结束而丢失，现在被保存下来。

随后，每条验收标准都转成一个场景。agent 启动预览环境，像用户一样操作，记录截图、请求和日志。

对于页面或接口改动，这些材料能帮助审查者判断：要求有没有被执行，实际行为是否符合预期。CI 绿灯只能证明已编写的测试通过，不能证明测试覆盖了全部要求；场景验证同样存在覆盖边界，只是多提供了一层可检查的证据。

作者报告，每个 PR 的人工讨论线程从 6.2 个降到 1.3 个，每 100 个 PR 的回滚率下降 40%。审查劳动并没有消失，而是转向维护规则、讨论决策和改进验证。按他们的经验，第 1 个月是双份工作，第 2 个月规则开始缩短审查，第 3 个月才逐渐转向阅读意图和证据。

我的判断

我认同把重复评论转成自动检查。与每次靠审查者记住规范相比，这种做法更稳定，也能把注意力留给权限边界、异常处理和跨模块影响等具体判断。

但「不用逐行读」有前提：验收标准足够完整，规则覆盖了重要约束，证据确实对应当前变更。若编码会话遗漏了需求，后续场景可能只是认真验证了一份不完整的要求。

这些数字也应当按团队自报结果看待。原文没有给出统计周期、PR 拆分变化、改动复杂度或对照组，因此无法确认 4 倍吞吐量有多少来自这套审查流程。回滚率下降比单看 PR 数更有参考价值，但回滚也不能代表全部线上缺陷。

多 agent 辩论优于单 agent 自审、三个月能完成转型，目前都属于作者的经验之谈。对于风险高、影响面大的改动，我仍会保留针对关键实现的人工细读。

能拿来做什么

• 从最近 1,000 条审查评论中找出重复最多的 20 类，优先把其中可客观判断的要求写成检查，并注明适用范围和负责人。
• 在日常 AI 编程中，把你纠正 agent 的要求补进 PR 验收标准，让审查者能看见代码之外的约束。
• 对有预览环境的前端改动，为关键验收场景附上截图、请求和日志，并说明每份证据对应哪条要求。
• 在 PR 中记录重要决策、理由和未解决分歧，再根据改动风险决定哪些代码需要人工细读。