你可能不敢相信，Claude Code 如今大约 90% 的代码是由 Claude 自行敲出的。既然代码是 AI 写的，那谁来审查？答案让人意外：大部分也是 AI。数据显示，6 月至 9 月间，Claude Code 合并的 PR 数量翻了一倍多，而回滚率却下降了 40%。期间还发生过一个有趣的插曲：两个 AI Agent 互相审查代码，一个挑刺一个改，整整吵了一夜，来回拉扯了 50 多轮，互不相让。
很多人可能会觉得，这就像学生自己批改自己的试卷，AI 写完 AI 审，人根本不看。这种想法不无道理，很多线上事故回溯起来，往往都是一眼就能看出的低级失误。Anthropic 近期发布的博客正是为了回应这一质疑，详细阐述了 Claude Code 是如何实现自动代码审查的。
其实，问题的切入点一开始就错了。5 月份，Anthropic 的大仓库每天合并约 2500 个改动，到了 9 月，这一数字飙升至每天 3 万多个。Claude Code 虽然不在主仓库，但势头同样迅猛。面对如此海量的代码变更，靠人眼逐行排查显然是不现实的，因此团队不再纠结“人有没有看”，而是转而关注“如果出事会怎么出”。
Anthropic 团队认为，“人是否查看”只是一个并不精准的替代指标。真正应该重视的，是评估这次改动潜在的风险，并让最合适的机制去拦截它——无论是测试、AI 还是人工，视情况而定。
审查的时间点也发生了根本性变化。传统的“写完-提 PR-等待同事”的流程已被打破。现在的模式是边写边查，类似于打字时的自动拼写检查，许多改动在提交人工审核前，Claude 已经自我检查并修复过一轮了。关于人力节省的计算，团队认为：看代码费时，烂代码上线后去救火更费时，两头一抵，省下来的就是净收益。最终的衡量标准只有两个：回滚率和事故率。只要这两个指标没有恶化，就说明方案有效。
原文提到了七层检查机制，这里重点介绍三层：
第一层是提交前的自我验证。在 PR 提交前，Claude 必须提供证据，例如测试结果、构建是否通过、界面截图是否与设计稿对齐。Claude Code 之父 Boris Cherny 曾表示，赋予 AI 自我验证的能力，效果可能会翻两三倍。
第二层是 AI 审查与投票。PR 提交后，首先由多个 AI Agent 分头寻找 Bug，收集到的意见再由另一组 Agent 投票决定。对于内容空洞或风格不合的修改，直接拒绝。预览版上线后，内部实质性审查意见的 PR 占比从 16% 飙升至 54%。此外，系统还会给意见打标签，其中一种叫“Pre-existing”，意为“已存在”，提醒作者这不是本次提交引入的问题，无需背锅。
第三层是人工审核。这一层有严格规定：AI 的批准不生效。无论 AI 审查得多么完美，都需要人工签字。而且，是谁让 AI 写的这段代码，谁就必须作为审批人，责任与亲手编写无异。至于需要几个人审核，取决于风险等级：低风险（自动检查和安全检查均通过）、普通风险（一人点头）、高风险（两人把关）。风险等级由分类器根据代码本身判定，与提交者无关。
这种层层叠加的审查机制，类似于航空和医疗领域的“瑞士奶酪模型”。每层都有漏洞，但位置各不相同，只要层级足够多，问题就很难从第一层一路漏到最后。即便真漏下去了，底层还有“功能开关”和“一键回滚”兜底。
前面提到的两个 AI 争吵 50 多轮并非孤例。这是一个 CLI 项目的 PR，写代码和审代码的都是 Agent。一个提意见，一个改，改完再审，形成了一个死循环。最终是 PR 的主人手动叫停了这场闹剧。原因在于，人看到“可选”的小毛病通常会忽略，但 Agent 却较真去改，导致产生新的 Commit，进而触发新一轮 Review。Git Blame 分析显示，Review 中揪出的问题，59% 其实早在第一轮就已经存在。团队后来调整了策略，将审查轮数限制在最多三轮，如果三轮过不去，就建议作者重新思考方案本身。这一改动后，PR 平均审查轮数从 2.08 降至 1.32，超过五轮的比例从 1/11 降至不到 2%。
代码大部分交给机器后，人类并没有闲下来，只是工作重心变了。最典型的转变是“决定做不做”，而不是“检查对不对”。有个团队曾宣称审查瓶颈已解决，但对外部提交的改动依然保留人工审核，目的就是让人去问一句：“这事儿真的有必要做吗？”至于计费、自动更新器、CI 等高风险代码，以及容易被抄袭的架构，依然需要人工死死盯着。目前来看，人类依然是 AI 大模型不可或缺的“守门人”。