Claude Code团队七层审查法：AI写代码，人管什么？

Anthropic 开发者博客近期披露了 Claude Code 团队如何应对 AI 生成代码带来的审查挑战。核心转变在于：当九成代码由 Claude 编写，传统的人工逐行审查已不再可行，团队将审查拆解为七层自动化与人工结合的防线，把人的注意力留给真正需要判断的难题。

审查量翻倍，回滚率反降四成

从六月到九月，合并进 Claude Code 代码库的 PR 数量翻了一倍多，但需要回滚的比例下降了四成以上。这组数据来自 Anthropic 官方开发者博客，作者 Eddie Osmani 等三人详细拆解了背后的机制。

更宏观的背景是，Anthropic 主代码库每天落地的改动从五月的约 2500 次涨到九月的 3 万多次。文章直言：主行人工审查已经做不到。团队没有取消审查，而是重新定义了审查的目标——不是“有没有人读过这段代码”，而是“这次改动可能出什么问题，哪一道检查能拦住它最合适”。

审查从终点前的一道闸门，变成了写代码时持续运行的拼写检查。大多数改动在请人看之前，已经被 Claude 审过、修过至少一轮。团队的目标是大部分 PR 最多只需要一个人参与，这个人可以就是作者本人，同时回滚和事故不增加。

七层防线：每一层拦下什么，漏掉什么

一次改动从工程师的电脑出发，要经过七层审查。每一层拦下一部分问题，也漏掉一部分，能穿过所有层的很少，剩下的交给回滚。

第一层：PR 出现之前，先让 Claude 自证

团队给 Claude 一个能运行的检验手段，比如测试、构建，或者和设计稿对比的截图，要求它拿出运行结果。再由一个子 Agent 在全新的上下文里审查 Diff。Claude Code 的创建者 Boris Cherney 估计，这能让最终结果好上两到三倍。自动审查反复指出的问题，会从源头修改 Skill、加 Lint 规则，或者写进 CLAUDE.md 和 REVIEW.md。

第二层：每个 PR 先过 Claude 审查

在人看之前，PR 先经过一次 Claude 的审查，对照整个仓库和 PR 的意图来读 Diff。这项能力的研究预览上线时，内部 PR 收到实质性审查意见的比例从 16% 升到了 54%。审查意见在给人看之前还要经过核验：几个 Agent 同时找 bug，再由另一组 Agent 对每条发现投票，足够多的认为是真问题才会发出来，留下的按严重程度排序，标注 Important、Nit 或 Pre-Existing。每条意见都必须回应——要么修，要么写明理由关掉。

CLAUDE.md 与 REVIEW.md 是 Claude Code 读取的项目级指令文件。CLAUDE.md 放在仓库中，用来告诉 Claude 这个项目的构建方式、测试命令、代码风格和禁止事项；REVIEW.md 则专门约定审查偏好，比如哪些模式必须拦截、意见如何分级。两者都随代码一起版本化，团队每次发现自动审查反复漏掉或误报的问题，就把规则补进去，相当于把人的经验沉淀成可复用的审查上下文。

第三层到第四层：安全审查与自动化检查

第三层是安全审查，还有没关闭的意见，PR 就不能合并。第四层是 Lint、类型检查、各平台测试和构建检查。一个普通的命令行 PR 在有人看之前，可能已经跑了几十项检查。

Lint 与类型检查 属于静态分析：Lint 在不运行代码的情况下扫描风格问题和常见缺陷模式，类型检查则验证变量、函数签名之间的类型是否一致。它们能在几秒内拦下整类低级错误，成本远低于人工阅读。构建检查 验证代码能否在各目标平台上成功编译打包，跨平台测试 则在多个操作系统和运行环境里执行测试用例，避免“在我机器上能跑”的问题流到主干。这些检查全部自动化、可重复，是七层防线里最廉价也最稳定的一层。

第五层：人工批准按风险分级

文档、文案、放在开关后面的新增改动属于低风险，自动检查通过后不需要人批准。普通产品改动，以及缓存、自动更新、系统提示词这类敏感区域需要一个人。风险最高的代码需要两个人，等级由改动本身决定，和作者是谁无关，由分类器来判断。Agent 的批准永远不能顶替人的批准。Agent 写的 PR，发出指令的那个人就算作必须的审查人之一。批准只对应一个具体的提交，之后有系统无法担保的新提交就要重新批准。

功能开关（Feature Flag） 是一种在不大规模改代码的前提下控制功能是否对用户可见的机制。新代码可以先合并、部署，但开关关闭时对用户不生效，等验证通过再逐步打开。它让“合并”和“上线”解耦，也使高风险改动的爆炸半径可控。配合合并队列——把待合并的 PR 排成一列，在最新主干上逐个重跑检查后再合入——可以避免多个 PR 各自通过检查、合到一起却互相冲突的情况。

第六层到第七层：合并队列与快速回滚

合并前在最新的主干上再跑一遍检查，新功能先给 Anthropic 员工用，再逐步发布。最后一道是快速回滚开关，不用部署就能关掉事故。复盘会追问：这个问题本该有哪一层拦住？

审查者本身也在改进：从 65% 到 78%

团队把过去引发事故的 PR 做成评测集，审查者每天跑一遍，每次改提示词、工具或模型，分数上去才保留。

作者是 Agent 时，噪声的代价更高——人几秒钟就能略过一条小意见，Agent 会去修它，于是又多一轮审查。审查还必须收敛。有一个命令行 PR 一夜之间来回审了 50 多轮，直到作者叫停。用 Git Blame 一查，审查者反复指出的内容大约 59% 是第一轮时就已经存在的代码，它很少发现新 bug，只是每一轮多找出几个旧的。团队于是改了规则：最多三轮之后请作者重新考虑方案，前几轮以后只审新的 Diff，指出一类 bug 让作者把同类的地方一起修掉，发过的意见不再重复。

改完以后，一轮就通过的内部 PR 从 65% 升到 78%，需要五轮以上的从 8.9% 降到 1.5%。

Git Blame 能逐行显示某段代码最后一次是由哪个提交、哪次改动引入的。团队用它来判定审查意见是否真的针对本次 Diff：如果被指出的行来自很早以前的提交，说明这是历史遗留问题而非新引入的 bug。这一手段揭示出审查者反复翻炒旧代码、制造无效轮次的现象，也成为后续“只审新 Diff、同类问题一次性修掉”规则的数据依据。

人的工作转向哪里

人的工作从读每一份 Diff，转向机器不擅长的决定：这个东西该不该做；计费、自动更新、CI 这类高风险代码会被别人罩着写的架构；读懂测试输出和截图这些证据；以及为结果负责。每一次上线的改动都有一个人对它负责。

机器读了大部分代码，人怎么理解代码库？团队里没有人装着 Claude Code 的完整模型，想了解哪一块就让 Claude 针对这一块写一份讲解，几分钟就好，内容和当前代码一致。团队的规范是：谁合并谁负责，改动要小，一切都能撤回，影响范围越大检查越多。回归问题很快暴露，复盘看的是系统，不追究个人。Agent 让开始一件事变得很便宜，方向不对的 PR 关掉也不可惜，关键是尽早在讨论里提出来。

给团队的一份清单

文章最后列出了一份可直接参考的清单：给 Agent 能运行的检查；写好 CLAUDE.md 和 REVIEW.md；每个 PR 都过 CI、AI 审查和安全审查；审查深度按风险匹配；限制审查轮数；写下风险等级；从严开始；用合并队列、功能开关和一步回滚；把事故变成评测集。

值得一提的是，Code Review 这个产品只发审查意见，不发批准，批准 PR 仍然由人决定。而团队自己的仓库走得更远，允许低风险改动只靠自动检查合并。目标始终没变：每次改动花更少的人工时间，回滚不比以前多。