90% 代码由 AI 写，Claude Code 团队怎么做 Code Review

最近读到 Claude Code 团队 Addy Osmani 的一篇文章，讲他们在 90% 代码都由 Claude 写的情况下，是怎么做代码审查的。

读完有点感触，倒不是因为有什么颠覆性的结论，而是里头不少处理问题的思路，放到日常开发里也很有参考价值。

先抛一个数字，可能会让人惊一跳。

他们的代码仓库，每天合并的代码改动量，从今年 5 月的 2500 个，飙到了 9 月的 3 万个，涨了将近 12 倍。这种量级，靠人工一行行看，物理上根本做不到。

所以团队换了一套打法：搭了六层检查机制，把大部分审查工作交给机器，人只去盯真正重要的部分。

结果怎么样？从 6 月到 9 月，合并的 PR 数量翻了一倍多，但需要回滚的比例反而下降了 40% 以上。

量上去了，质量反而更稳了。

一、提交代码之前，就已经审完一遍了

这六层检查里，有几个地方让我印象比较深。

先说第一个：他们把审查这件事，直接提前到了写代码的过程中。

很多人的习惯是写完代码、提交 PR，然后等别人来 review。他们的做法是，在提交 PR 之前就已经做了一轮检查：让 Claude 跑测试、把截图和设计稿做对比，再让另一个 AI 用全新的角度重新扫一遍。

Claude Code 的创始人 Boris Cherny 说，加了这个验证流程之后，输出质量能提升两到三倍。

这个道理其实挺朴素的。把检查变成一件随时都在做的事，而不是等全部写完之后才想起来。就像写文章，边写边顺一遍，和写完再从头校对，效果差得不是一星半点。

然后是第二个：每个 PR 提交后，AI 会先看一遍，才轮到真人。

AI 会把这次改动跟整个代码库做比对，看有没有把别的地方搞坏，有没有真正解决问题。发现的问题被分成两类：重要问题和小毛病。而且会标注清楚哪些是这次改动新引入的，哪些是原本就有的老问题。

标注“老问题”这个设计挺细心的。代码库里本来就堆着不少历史遗留的 bug，如果 AI 审查每次都把这些统统翻出来归到作者身上，作者就很冤。所以他们把这类问题单独打标签，不让人背不是自己造成的锅。

二、不是每件事都值得同样认真

接下来是人工审查这一关。

他们做了一个设计，叫按风险分级。

不是每个 PR 都需要真人来看。系统根据改动的内容判断风险高低：改一篇文档的，可以自动通过；碰到计费系统、权限系统这些地方，就必须有真人批准。而且规定很明确——AI 的批准不算数，这些关键地方只认人类点头。

这背后有个思路挺有意思：把“谁来看这件事”这个问题，变成了“这件事的风险有多高”。

我们在日常工作里经常遇到类似的困境。一堆事情堆在面前，不知道从哪里开始，也没有判断标准，只能一视同仁地慢慢熬。如果能先想清楚哪些事情出了问题代价最大，哪些事情随便搞一搞问题也不大，注意力就会好用得多。

三、AI 和 AI 之间，会陷入死循环

这套机制跑起来也踩过坑。有个案例让我印象很深。

AI 审查员发现问题，AI 作者去改。改完之后，AI 审查员又发现新问题，AI 作者再改。然后再发现，再改……

他们发现有一个 PR，一晚上来回循环了五十多次，最后是被人手动停掉的。

更有意思的是，他们去翻了一下，AI 审查员一直在盯着的那些地方，约 59% 的代码其实从项目最开始就在那里了。AI 审查员基本上没在发现新 bug，只是每次循环都多翻出几个老 bug 而已。

后来他们设了一个规矩：最多跑三轮，超过了就让作者自己重新判断方向，不再继续让 AI 来回折腾。

这件事本身挺有意思的。两个 AI 都在“认真工作”，一个认真审，一个认真改，但整件事根本没有在推进，只是在原地消耗。没有人出来说停，它们就可以一直循环下去。

有时候，知道什么时候该喊停，比一直往前冲更重要。

四、学东西的方式，悄悄变了

还有一个问题，文章里提到，读的时候觉得挺值得琢磨的。

以前大家是怎么学习一个项目的代码库的？很多人靠的是看同事提交的代码改动，一点一点摸清楚整个项目的结构和逻辑。

但现在，90% 的代码是 AI 写的，还有多少人会认真去看那些改动？

他们的解法是：谁想了解某一块代码，就让 Claude 现场生成一份专门针对那块代码的讲解文档。几分钟内就能拿到，而且永远是最新的。

他们说，这样比一行行看代码改动，能学到更多东西。特别是那种改一个字的小改动，看了基本等于没看。

这个点我挺认同的。很多时候我们以为自己在“学习”，其实只是在完成一个动作。换一种更直接、更针对自己真实需求的方式，反而能省很多力气。

五、人还是不可缺少的

文章最后也说了，有几件事是机器替代不了的。

先说第一件：要不要做这个功能，这个方向对不对，得是人来拍板。他们提到，有一个团队虽然已经解决了代码审查的效率问题，但外部团队提交的改动，他们还是坚持人工审查，因为他们要确认这个东西该不该做。

然后说第二件：架构设计。架构决策会影响整个团队后面很长时间的工作方式，这种事情，得有人认真想，认真担着。

还有一件，就是责任。不管这行代码是谁写的，只要上线了，必须有一个真人来负责。AI 写了代码，操作这个 AI 的人，就是那个要负责的人。

他们的目标是，一个 PR 从提交到合并，最多只需要一个真人参与（包括作者自己），同时不让回滚率上涨。

目前看，他们正在朝这个方向走。

读完这篇文章，我觉得他们做的这套东西，核心思路其实很简单：把机器能做的事情尽量交给机器，把人的时间留给只有人才能做的那部分。

但这件事说起来容易，做起来很难。你得知道哪些事情机器能做好，哪些不行；哪些地方省人力是真省，哪些只是把问题挪了个地方。

他们花了几个月摸索，踩了不少坑，才把这套东西跑顺了。如果你也在实践 AI 辅助开发，云栈社区上有不少同行在讨论类似的话题，互相交流能少走一些弯路。