文章摘要
Claude Code目前近九成代码由AI自身生成，大部分审核工作也由AI完成。开发团队披露其多层审核流程：提交前AI自验证，提交后多AI投票审核，最终按改动风险等级配置人工审核。实施后合并代码量翻倍，回滚改动减少超四成，人类主要负责必要性判断与高风险改动把关。

你可能难以置信，Claude Code 目前有近九成的代码都是由 Claude 自身生成的。

如果你是一名开发者，第一反应或许和多数人一样：那谁来审核这些代码？

答案是，大部分审核工作同样由 AI 完成。

更有意思的是，从6月到9月，Claude Code 合并的代码请求数量翻了一倍还多，需要回滚的改动则减少了四成以上。

此前还发生过一件趣事：两个 AI 代理互相审核代码，一个挑错一个修改，一夜之间来回了50多轮，谁也不肯让步。

你或许会觉得，AI 写代码、AI 审核，人根本不看，这不就和学生自己批改自己的试卷一样吗？

这么想完全没问题，很多线上事故事后查起来，都是一眼就能发现的低级错误。

最近有篇技术博客正是为了回应这个疑问，详细说明了 Claude Code 是如何实现自动化代码审核的。

从一开始，人们问的问题就错了

5月时，某团队的主仓库每天合并约2500个改动，到了9月，这个数字飙升到每天3万多个。Claude Code 虽然不在那个主仓库，但也呈现出类似的增长势头。

面对这么多改动，靠人一行行审核的话，就算不眠不休也看不完，所以团队不再纠结人类是否已经审核了代码。

开发团队在博客中表示，人类是否审核过代码只是一个不太准确的替代指标。

真正需要考虑的是：如果这个改动出了问题，会以什么方式发生，然后让最合适的检查环节把它拦住，至于这个检查是测试、AI还是人，都可以灵活调整。

审核的时间点也跟着变了。以前的流程大家都很熟悉：写完代码、提交代码请求、坐等同事有空。

现在的情况是，Claude 在编写代码时就同步检查，有点像打字时自动标红的拼写检查。等到有人来看的时候，Claude 早就自己检查修改过一遍了。

省下来的人力该怎么衡量？他们的逻辑是：审核代码费时间，代码上线后出问题再救火也费时间，在前者省的时间如果被后者抵消，就是白忙活。

所以他们只看两个指标：回滚率和事故率。只要这两个指标没有上升，就算没白干。

多层审核机制，重点介绍三层

博客里一共列了七层审核，内容太多，我们挑三层重点说。

提交代码请求前，Claude 需要先提供可验证的成果

光说“搞定了”不算数，必须有测试运行结果、构建是否通过的证明，修改界面的改动还要拿截图和设计稿做对比。

Claude Code 的创始人曾提到，给 Claude 一套能自我验证结果的方法，是让它把工作做好最关键的一步，他估计这样做能让效果提升两三倍。

代码请求提交后，首先要通过 AI 审核

这个环节不是单个 Claude 说了算，而是多个 AI 代理分头查找代码问题，找出的问题再交给另一组 AI 代理投票，票数不足就不通过，纯粹修改代码风格的无意义改动也会被驳回。

这个功能刚推出预览版时，收到实质性审核意见的代码请求占比从16%一下子涨到了54%。

还有个贴心的设计：每条审核意见会打上标签，其中一种叫“原有问题”，意思是这个问题早就在代码里存在了，不是这次改动带来的，这样改动的作者就不用为此负责。

最后一步才是人工审核

这一层有个硬性规定：哪怕 AI 代理给出了批准意见，也不算有效。不管 AI 审核得多好，需要人工签字确认的环节，AI 都无法替代。

另外，发起 AI 代理编写这段代码的人，必须算在审批人里，和自己手动写代码的审批要求一样。

是否需要人工参与、需要几个人参与，取决于改动的风险等级。修改文档和修改自动更新器，风险等级显然天差地别。

风险低的改动，只要自动检查和安全检查都通过就能合并；普通改动需要一个人批准；涉及核心功能的高风险改动则需要两个人批准。

风险等级由分类器根据改动本身的性质判定，和提交者无关。这种层层叠加的审核机制，和航空、医疗安全领域常用的瑞士奶酪模型很像。

每一片奶酪都有漏洞，但漏洞的位置各不相同，把它们摞起来后，很少有问题能从第一层一路漏到最后一层。就算真有问题漏过去了，还有功能开关和一键回滚机制兜底。

纯人工手动审核虽然慢，但确实能减少错误，不过这主要是因为手动审核时改动的范围和数量都更少。

两个 AI 代理的“拉锯战”

之前提到过，两个 AI 代理来回拉扯了50多轮。那是一个命令行界面相关的代码请求，编写代码的是 AI 代理，审核代码的也是 AI 代理。

一个提修改意见，另一个调整代码，调整完再审核，审核完再提意见，一个晚上就这么来回拉扯了50多轮。最后还是代码请求的负责人发现了问题，手动终止了这次循环。

为什么会出现这种情况？原文的解释是，人看到一条可改可不改的小问题，扫一眼就过去了，但 AI 代理偏偏较真我去修改，每次修改都会产生新的提交，新提交又会触发新一轮审核，审核又会挑出更多问题。

后来他们用代码回溯工具发现，审核代理一轮轮挑出的问题中，约59%在第一轮审核时就已经存在了。也就是说，AI 代理不是在找新的错误，而是每轮都在重复翻出之前就存在的老问题。

原文也很坦诚地提到，这也有团队自身的原因：之前习惯了默认多审核几轮，觉得每多一轮总能多发现一些问题。现在他们改成最多只允许三轮审核，如果三轮都没通过，就让改动的作者停止修改，转而考虑方案本身是否存在问题。

调整之后，单个代码请求平均的审核轮数从2.08降到了1.32；需要审核五轮以上的请求，从原来的每11个里有1个，降到了现在的不到2%。

人类现在的角色

大部分代码审核工作交给了 AI，人类并没有闲下来，只是工作内容变了。最典型的变化是，人类现在负责判断一个改动到底是否有必要做。

原文提到，有个团队已经宣布解决了审核瓶颈，但对于外部人员提交的改动，还是保留了人工审核环节，就是为了有人能问一句：这个改动真的有必要吗？

涉及计费、自动更新器、持续集成等一旦出问题会造成重大事故的代码，仍然需要人工审核；那些会被其他团队当作模板参考的架构改动，也需要人工把关。现阶段，人类仍然是 AI 审核体系中不可或缺的一环。

以上内容不代表本平台立场，仅供读者参考