90%代码由AI写，Claude Code团队怎么审？

Claude Code团队自己透露过一个数字：Claude写了Claude Code自身约90%的代码。代码量暴涨之后，谁来读这些代码？如果出了问题，又是谁发现的？

他们给出的答案不是"取消审查"，而是把大部分阅读工作交给机器，把人的时间留给只有人能解决的问题，同时把"犯错后能快速撤销"这件事做扎实。

先看两组数字

从6月到9月，合并进Claude Code代码库的PR数量翻了一倍多，而被回滚的比例下降了超过40%。

在Anthropic的monorepo里，每天落地的变更从5月的约2,500次，涨到今年9月的超过30,000次。Claude Code有自己的独立仓库，不在monorepo里，但同样承受着压力。以这样的速度交付，逐行人工审查即便不是不可能，也极其困难。

审查到底在解决什么

代码审查做两件事：一是在代码上线前发现并修复问题；二是在团队内建立共享的上下文和对代码库的理解。这套流程主要针对第一件事。

团队认为，"有没有人读过这段代码"是一个不精确的替代指标。更该问的是：这个变更可能出什么问题，该由哪道检查——自动的还是人工的——来抓住它？

这个问题也改变了审查发生的时机。过去审查是终点前的一道闸门：写完代码，开PR，等同事。现在审查是持续运行的，更像写作时的拼写检查。大多数变更在被要求人工查看之前，已经被Claude至少审查并修复过一次。

目标：最多一个人经手

人的时间包含审查成本的两面：花在审查上的时间，以及花在修复坏代码造成的后果上的时间。只砍掉前者，如果时间转移到后者，等于没省。

所以团队的目标是：Claude Code各仓库（CLI、桌面端、Web应用和移动端）的大多数PR，合并时最多经过一个人，这个人可以是作者本人，同时回滚率和事故率不上升。

衡量人的时间，他们看每个PR的人工批准数（中位数和第95百分位）、人工评论数，以及PR等待某个人的时长。回滚率和事故率是护栏：一旦上升，说明人的时间没有被省下，只是被挪走了。

审查发生在PR之前

现在大部分审查在PR存在之前就完成了。做法是给Claude一个可以运行的东西——测试、构建，或一张可与设计稿对比的截图——要求它展示输出，而不是口头说"做完了"。随后由一个子代理带着全新上下文审查diff。这两个习惯都来自他们的最佳实践指南。

开PR之前，很多人还会跑几个内部技能：一个找bug，一个简化diff，一个做端到端的行为检查。UI变更还要对照设计规范检查。

Claude Code的创造者Boris Cherny称，给Claude一个验证自己工作的方式，可能是拿到好结果最重要的一件事。他估计这能让最终结果好上两到三倍。他写道："验证在每个领域看起来都不一样。它可能简单到跑一条bash命令，或跑一套测试，或在浏览器或手机模拟器里测试应用。"

反复被标记，就从源头修

当自动审查器反复标记同一个问题，团队会在源头修复：改技能、加lint规则，或更新指导性文件，比如CLAUDE.md和REVIEW.md。

CLAUDE.md告诉Claude这个项目是什么：技术栈、约定、目标和非目标。每次审查都会加载它，所以在大型代码库里要写得短，再从那里指向其他文档。审查器也会标记违反其中约定的代码，以及让其中某一行过时的变更。

REVIEW.md由代码所有者撰写，告诉审查器在他们负责的部分什么才重要。团队会单独检查审查器是否真的遵守了它。写得好的都很短：说清在那个仓库里失败长什么样（文档是"它在说谎"，配置是"它路由错了"），限制琐碎意见的数量，列出要跳过的路径，要求以文件和行号作为证据，而不是凭名字猜测。它们还要求摘要以计数开头，并在没有需要修复的问题时直说。

每个PR都先过Claude

每个PR在被人看到之前都会先经过一次Claude审查。它对照整个仓库和PR声明的意图来读diff，问的是：这个变更解决了它要解决的问题吗，契合系统吗，会不会弄坏别的东西？在bug修复上，它会去找根因。

公开版本Code Review for Claude Code已在Team和Enterprise套餐上正式可用，/code-review可以在本地跑一个更轻量的版本。

研究预览版上线时，内部PR中获得实质性审查评论的比例从16%升到了54%。超过1,000行的大多数PR会得到发现项，而大多数小PR回来是干净的。管理员可以把每个仓库设为Quick、Standard或Deep。在漏掉一个bug的代价高于额外审查时间的地方，Deep是值得的。

发现项在交给人审查之前，会先由其他代理验证：多个代理同时找bug，然后另一组代理进行投票。