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 从提交到合并,最多只需要一个真人参与,同时不让回滚率上涨。目前看,他们正在朝这个方向走。

##
分类