Claude Code 团队的 Addy Osmani 写了一篇文章，介绍他们在约 90% 代码由 Claude 写的情况下，怎么做 code review？

莉月奶奶

Claude Code 团队的 Addy Osmani 写了一篇文章，介绍他们在约 90% 代码由 Claude 写的情况下，怎么做 code review？


Anthropic 最近分享了一个数据：他们团队 90% 的代码都是 Claude 写的，但今年 6 月到 9 月，合并的 PR 数量翻了一倍多，需要回滚的比例却下降了 40%。

他们是怎么做到的？

先说一下情况，从 5 月到 9 月，代码仓库每天合并的改动从 2500 个涨到了 3 万个。这个量级，靠人工一行行审根本不现实。

所以他们搭了六层检查，把大部分工作交给机器，人只盯最关键的部分。

先说提交之前。写完代码，先让 Claude 跑测试、截图对比设计稿，再让另一个 AI 用全新视角扫一遍，把大多数常规 bug 过滤掉。据 Claude Code 的创始人 Boris Cherny 估计，加了验证流程之后，输出质量能提升两到三倍。

然后说提交之后。每个 PR 都有一轮 AI 自动审查，看改动有没有搞坏别的地方，有没有真正解决问题。审查结果分“重要问题”和“小毛病”，还会标注哪些是这次改动新引入的，哪些是原本就有的老问题，不让作者背锅。接下来是安全审查，只要有未解决的安全问题，PR 就不能合并。再然后是自动化测试，lint、类型检查、多平台构建，一个 PR 提交上去，可能要过几十项检测才轮到真人看。

真人审查这一关，不是每个改动都需要人来盯。系统根据风险高低来决定：改文档可以自动通过，碰计费系统就必须有真人批准。而且明确规定，AI 的批准不算数，关键路径上只认人类。

最后是分阶段发布。新功能先给内部员工用，发现问题再修，然后才逐步放出去。

当然也踩过坑。AI 审查和 AI 作者有时候会陷入死循环，一个 PR 一晚上来回循环了五十多次。后来他们设了上限，最多跑三轮，超过了就让作者重新评估方向。

还有个有意思的问题。以前大家靠看同事的代码改动来学习项目，但现在大部分代码都是 AI 写的，还有多少人会认真看那些改动？他们的做法是：谁想了解某块代码，就让 Claude 现场生成一份讲解文档，几分钟内就能拿到一份永远最新的说明。

他们的目标是：一个 PR 从提交到合并，最多只需要一个真人参与，同时不让回滚率上涨。目前看，他们正在朝这个方向走。

##