Claude Code 六层代码审查系统全解析：REVIEW.md 与 AI 审查实践

Anthropic 的工程团队正在用一种激进的方式重写软件开发的协作流程。据 B 站 UP 主对多源信息的整合分析，Claude Code 目前已经能写出自身约 90% 的代码，合并的 PR 数量在几个月内翻了一倍多，而回滚或返工的代码比例反而下降了 40%。在"代码产量暴增"和"质量不降"之间，他们靠的不是更努力地人工审查，而是一套由六层检查构成的自动化审查体系，以及一个关键文件：REVIEW.md。

这篇文章将拆解这套系统的设计逻辑，并给出普通团队可以立刻借鉴的落地建议。

为什么代码审查必须被重新设计

Anthropic 官方博文披露了一个数字：其 monorepo 每日落地的变更量从约 2500 次涨到了超过 3 万次。在这种规模下，逐行人肉审查已经"极其困难甚至不可能"。UP 主在视频中特别强调，这是他走访多家公司后听到的共性痛点——跑 100 个 agent 并不难，难的是大量代码涌入后如何审查和合入。

Anthropic 的做法是回到第一性原理，重新定义审查的目的：一是上线前发现问题，二是让团队理解代码库。他们把一个习惯性问题"有人审过这段代码吗"换成了"这段代码可能出什么问题，应该由哪种检查来兜底"。审查的位置也变了——从合并前的一次性关卡，变成从第一个 prompt 开始就持续运行的"边写边查"。

他们设定的目标很明确：大多数 PR 最多只需要一个人类参与，而这个人类可以是作者本人。这打破了"审查必须由第二双眼睛完成"的传统假设。

六层检查：从验证到合并队列

这套系统可以概括为"六层检查 + 底层的回滚能力"。核心思路是让 agent 在受限范围内放手干活，一旦出问题，能在影响客户之前回滚。

第一层：人类看到之前先自我验证

大部分审查其实发生在 PR 被创建之前。Claude 必须跑测试、构建、截图、做端到端测试，用输出证明"确实做完了"，而不是口头声称完成。随后一个子 agent 会用全新的上下文窗口审查 diff。Claude Code 的创作者 Boris Cherny 估计，仅验证这一步就能让最终结果好两到三倍。

当同一个问题反复出现时，团队会选择在源头修复：claude.md 或 agents.md 描述项目技术栈、约定和目标，而 CODEOWNERS 则编写 REVIEW.md，告诉审查者这段代码里什么才是真正重要的。UP 主特别提到，这一步还能抑制"挑刺型"误报——包括对本次改动之外的历史代码指指点点，这类噪音在生产工作流中非常常见。

CODEOWNERS 是 GitHub 等代码托管平台支持的一种配置文件（通常位于仓库根目录或 .github/ 下），用通配模式把仓库中的路径映射到具体的团队或个人。当 PR 修改了某个路径时，平台会自动把对应负责人加为必选审查者，从而在制度上保证「懂这块代码的人一定会被拉进来」。在 Anthropic 的实践中，CODEOWNERS 还承担了另一重职责：它不仅是审批人的声明，也是 REVIEW.md 的编写者与维护者——因为只有真正拥有该模块上下文的人，才知道哪些约束、边界条件和历史包袱值得写进审查清单。这种「所有权即审查知识所有权」的绑定，避免了 REVIEW.md 沦为一份无人维护、放之四海而皆准的空洞文档。

第二层：每个 PR 上的 AI 审查

AI 审查会通读 diff 与整个仓库的关系，以及 PR 声明的意图。多个 agent 并行找 bug，再由另一组 agent 对每个发现投票，只有足够多 agent 认同的问题才会被发布。这正是 Claude Code Review 产品的公开版本，官方称审查速度约提升 3 倍，从约 20 分钟降到 6 到 10 分钟。

「多个 agent 并行找 bug，再由另一组 agent 投票」属于一种**集成式多智能体评审（ensemble review）**思路，其价值在于压制单模型的随机性幻觉。单个 LLM 审查时容易对某些模式过度敏感、对另一些则系统性失明；让多个独立上下文的 agent 各自扫描，再用投票阈值过滤，可以把「一个模型觉得有问题」和「这个问题确实稳定复现」区分开。投票机制同时是一种廉价的可信度校准：它不需要训练奖励模型，也不需要人工标注，仅靠一致性就把误报率压下来。代价是推理成本随 agent 数量线性上升，因此这类方案通常只对高风险路径或大 diff 全量启用，普通改动则走单 agent 通道。

第三层：独立的安全审查

在 Anthropic 自己的仓库里，只要 bug 审查或安全审查还有未关闭的发现，PR 就无法合入。这是一道硬性闸门。

第四层：枯燥但必须的检查

lint、类型检查、多平台测试、构建测试，以及 PR 模板中强制填写的"如何测试"和"如何撤销"。

第五层：按风险分级的审批

低风险改动（文档、文案、flag 后的增量改动）在自动检查通过后无需人工审批；普通产品改动需要一人；高风险代码需要两人。这里有五条规则值得记住：变更本身而非作者决定风险等级；只有可信作者走轻量通道；agent 的批准永远不能顶替人类的名额；发起 prompt 的人对 agent 写的 PR 负责；一次批准只覆盖一个特定 commit。UP 主指出，这与 Adi Osmani 关于 blast radius 与审批层级的观点一脉相承。

第六层：合并队列与新行为的分级放量

合并队列会针对主分支重跑全部检查，避免两个各自通过的 PR 合在一起后互相破坏。新行为先在 flag 后面对内部团队开放，再进入约千人规模的 latest 频道，最后才进入 stable。

合并队列（merge queue） 解决的是「语义冲突」这一经典问题：两个 PR 各自基于旧主分支测试通过，但合并后彼此叠加可能编译失败或逻辑互斥。合并队列的做法是把待合并的 PR 组成临时批次，在真实的合并结果上重跑全部 CI，只有整批通过才真正落地；若批次中某个 PR 失败，则将其剔除并对剩余部分重试。它把「通过检查」的定义从「相对我的基线通过」改成「相对将要成为主分支的那个状态通过」，是高频合并场景下维持主分支绿色的关键基础设施。当每日合并量达到数万次时，合并队列的调度策略本身也会成为吞吐瓶颈。

50 轮 AI 审查暴露的陷阱

UP 主分享了一个极具警示意义的案例：一个 Claude Code CLI 的 PR 在一夜之间经历了 50 多轮 AI 审查与修复，直到作者亲自叫停。用 git blame 做根因分析后发现，约 59% 被反复标记的问题其实来自第一轮就存在的旧代码——审查器不是在发现新 bug，而是在每一轮多挖出几个老问题。

这正是 agent 时代的典型陷阱：人类几秒钟就能忽略一个挑刺，而主动型 agent 会去"修"它，于是产生新 commit、新审查、新回合，陷入循环。Anthropic 的修复方式是：三轮之后要求作者停下来重新思考方案；后续轮次只复审新的 diff；把问题按"类别"而非"单行"上报；以及永不重复已报告的发现。

blast radius（爆炸半径） 是软件发布与 SRE 领域的常用概念，指一次变更失败时可能波及的用户、服务与数据的范围。它决定了团队应该为一次改动投入多少审查与验证成本：改动一个内部文档或 flag 后的灰度功能，爆炸半径接近于零，可以全自动放行；而改动认证、计费或数据迁移路径，失败可能影响全部用户且难以回滚，就必须叠加多重人工把关。把审批门槛与 blast radius 而非作者职级挂钩，本质上是让控制强度与真实风险对齐——这也解释了为什么 Anthropic 允许低风险改动零人工审批，却在安全审查上设置不可绕过的硬闸门。

普通团队可以照搬的五件事

据这位 UP 主与 Anthropic 官方博文的交叉印证，即便你没有海量推理资源，也能立刻落地以下做法：

1. 给 agent 提供它能自己运行的检查，让它用输出自证完成。
2. 新增一份 REVIEW.md，并让 AI 审查器在一个仓库上先调优几周。
3. 按变更的风险等级而非作者身份设定审批门槛。
4. 永远不允许 agent 的批准替代人类批准。
5. 把回滚率和事故率作为核心指标，而不是只看合并速度。

此外，Anthropic 还透露他们用自研系统 Cyan 替换了 monorepo 上的 Git（主分支历史近 100GB，CI 每天检出 2500 万次），由 7 人团队约 5 个月完成迁移，体积比旧方案小约 200 倍。这套方案目前没有外部验证，但它揭示了当代码产量提升一个数量级后，基础设施本身也会成为瓶颈。

值得注意的还有 Anthropic 坦然承认的缺口：他们还没有"断路器"，也就是当回滚率异常上升时自动降速的机制。他们更倾向于更快地发现并修复问题，而不是减少总量。这个取舍是否适合你的团队，取决于你的 blast radius 有多大。

对开发者而言，角色正在从"写代码的人"转向"设计和维护一套持续运转的软件工厂的人"。REVIEW.md 只是这套工厂里一个很小的零件，但它标志着一种转变：审查知识本身也需要被工程化、被显式地写下来。