你可能不信，Claude Code 现在差不多 90% 的代码，是 Claude 自己敲的。
写代码的人第一反应多半是：那谁审？答案是，大部分也是 AI。而且从 6 月到 9 月，Claude Code 合进去的 PR 翻了一倍多，要回滚的反而少了四成多。
中间还闹过一出：两个 AI 互相 Review，一个挑刺一个改，一宿干了 50 多轮，谁也不服谁，最后还是 PR 的主人发现了，手动给停的。
AI 写完 AI 审，人看都不看，这不就是学生自己批自己卷子？这个质疑站得住脚。Anthropic 最近这篇博客，讲的就是 Claude Code 到底怎么自动审代码。
问题从一开始就问错了
5 月的时候，Anthropic 大仓库一天合进去 2500 个左右的改动，到 9 月，一天 3 万多个。Claude Code 不在那个大仓库里，但势头差不多。
这么多东西靠人一行行看，看到明年也看不完。所以开发团队干脆不纠结人到底看没看了。他们在博客里说，人看没看过，只是个不太准的替代指标。
真正该琢磨的，是这次改动万一出事会怎么出，然后让最合适的那道检查去拦它。至于那道检查是测试、是 AI 还是人，看情况。
时间点也跟着变了。以前是写完、提 PR、干等同事有空；现在 Claude 边写边查，有点像打字时自动标红的拼写检查，很多改动等到有人来看的时候，早就自己查过改过一遍了。
省下来的人力怎么算？他们的账是：看代码费时间，烂代码上线后救火也费时间，前一头省了后一头冒出来，就是白折腾。所以只看两个数——回滚率和事故率，这俩没往上走，就算没白干。
七层检查，挑三层说
PR 提之前，Claude 得先拿出证据。光一句搞定了不算数，测试跑出什么结果、Build 有没有过，改界面的还得拿截图跟设计稿对一对。
Claude Code 之父 Boris Cherny 讲过，给 Claude 一个能自己检验结果的办法，大概是让它把活干好最要紧的一件事，他估计效果能好上两三倍。
PR 提上去以后，先过 AI 这一关。不是一个 Claude 自己说了算，几个 Agent 分头找 Bug，找出来的东西再交给另一拨 Agent 投票，票不够就不发，纯属改代码风格灌水的也不发。这功能刚推出预览版那会儿，内部有实质性审查意见的 PR，占比从 16% 一下子涨到了 54%。
每条意见会打标签，其中一种叫 Pre-existing，意思是这毛病早就在了，不是这次 PR 搞出来的，作者不用背这个锅。
最后才是人。这一层有条死规矩：Agent 点的 Approve，不算数。哪怕 AI 审得再好，需要人签字的那一栏，它也填不进去。另外，谁让 Agent 写的这段代码，谁就得算进审批人里头，跟自己亲手写的没两样。
人要不要上、上几个，看风险。改个文档跟改自动更新器显然不是一回事：风险低的，自动检查和安全检查都绿了就能合并；普通改动得一个人点头；最要命的那几块要两个人。风险等级是分类器看改动本身判定的，跟谁提交的没关系。
这么一层一层摞起来，有点像航空和医疗安全里常提的瑞士奶酪模型。每片奶酪都有洞，可洞的位置各不一样，摞够了，很少有问题能从第一片一路漏到最后一片。就算真漏下去了，底下还有 Feature Flag 和一键回滚兜着。
两个 AI 吵了一整晚
那个吵了 50 多轮的 PR，其实是个 CLI 的改动，写代码的是 Agent，审代码的也是 Agent。一个提意见，一个改，改完再审，审完又提，一个晚上就这么来回拉扯。
为什么会这样？人看到一条可改可不改的小毛病，扫一眼也就算了，Agent 偏偏较真，真去改，一改就多一个 Commit，新 Commit 又把 Review 叫起来，Review 又挑出点新东西。
他们后来拿 Git Blame 回头查，Reviewer 一轮一轮揪出来的问题，差不多 59% 在第一轮审的时候就已经存在了。等于它不是在找新 Bug，是每轮多翻出几个老的 Bug。
团队也认了自己的锅：之前习惯了默认多审几轮，觉得每多一轮总能多抓点东西。现在改成最多三轮，三轮过不去，就让作者别改了，退一步想想方案本身是不是有问题。
这么一改，一个 PR 平均要审的轮数从 2.08 降到 1.32；要审五轮以上的，原来差不多每 11 个里有 1 个，现在不到 2%。
人现在干点啥
代码大部分交给机器看了，人也没闲下来，只是活变了。最典型的是判断这东西到底该不该做。
有个团队都已经宣布审查瓶颈解决了，团队外面的人提的改动，还是留着人工审，就是为了有人能问一句：这事真有必要做吗？
计费、自动更新器、CI 这些出了事会造成重大事故的代码，照样要人盯着；会被别人当模板抄的架构也是一样。
现阶段，人还是被 AI 大人所需要的。
热门跟贴