发生了什么

Anthropic（开发Claude的AI公司）在2026年10月15日发布文章，介绍Claude Code团队怎样检查AI写出的代码。公司说，Claude大约写出了Claude Code自身代码的90%。从6月到9月，已经合并的拉取请求增加了一倍以上，而需要回滚的比例下降了40%以上。在Anthropic更大的共享代码库中，每天的改动从5月的大约2500项，增加到9月的3万多项。这些数字来自公司自己的报告，不是外部审计结果。完整说明见Anthropic官方文章。

为什么要改变检查方法

AI代理可以快速制造大量改动。人很难再逐行读完所有内容。代码检查原本有两个作用。第一，是在发布前找出问题。第二，是帮助工程师理解代码怎样连接。Anthropic把问题换成了另一种问法：这次改动可能出什么错，应该由机器还是人来发现？

因此，检查不再只发生在最后。提交拉取请求以前，Claude可以运行测试、编译程序，或把画面和设计图比较。另一个拥有新上下文的AI会再看一次改动。每个拉取请求还会接受错误检查和安全检查。安全检查发现未解决的问题时，改动不能合并。多个AI会互相核对发现的问题，只有被认为确实存在的问题才会交给人处理。

人还要做什么

团队按风险等级决定需要多少人工检查。文档改动等低风险内容，在自动检查通过后，可能不需要人批准。中风险改动需要一人批准。高风险改动需要两人批准。风险等级由改动决定，不由写代码的人决定。即使自动判断为低风险，另一个判断器也可以要求再找一名人来检查。AI的批准不能代替人的批准。

人要决定更难的问题。这个功能是否应该做？整体设计是否合适？计费、自动更新、持续集成和系统提示等敏感位置，是否需要更深的检查？人还要阅读证据，包括测试结果、运行过的命令、画面截图和检查报告。谁让AI完成改动，谁就要对最后发布的结果负责。

怎样把失败控制住

团队使用合并队列、功能开关、分阶段发布和回滚。新功能可以先给Anthropic员工使用，再逐步给外部用户使用。新版本先进入较快的发布通道，稳定通道随后跟进。事故和回滚会被加入检查AI的评测材料。团队也会观察无用的警告，因为AI如果总是修理并不重要的问题，也会浪费时间。

检查本身也可能循环太久。有一个拉取请求一夜之间经历了50多轮检查和修改。团队查看反复出现的问题后发现，其中约59%涉及第一次检查时就已经存在的代码。于是团队设置了轮数上限，几轮以后只重新检查新改动。

已经知道什么，还有什么不知道

这篇文章清楚说明了Anthropic的内部办法：机器处理大量普通检查，人集中处理方向、证据、高风险代码和责任。公司还会记录每个拉取请求需要多少人工批准、留下多少评论、等待人多久，以及回滚和事故的比例。

但这篇文章不能独立证明这套办法在其他团队也有效。文章没有完整说明每个指标的计算范围，也没有比较事故严重程度。小公司是否有足够的模型、工具和资源采用同样流程，也还不清楚。机器读了大部分普通改动以后，工程师还能不能保持对代码的深入理解，同样需要继续观察。

Hacker News上的关注与下一步

这篇文章在Hacker News获得472个积分和468条评论。这些数字表示社区的关注程度，不表示原文一定正确。接下来要看的，是事故和回滚是否仍然受到控制，人工等待时间是否真的减少，以及低风险改动能否在不削弱责任的情况下更多自动合并。