lijianfei.com

如果 AI 帮你写作业，一天能写出一千份，老师批得过来吗？这正是当前所有软件工程组织在全面拥抱 Coding Agent 之后共同撞上的“工程之墙”：生成代码的边际成本已被大模型压缩殆尽，但代码审查（Code Review）的吞吐量却成了整个系统最致命的颈瓶。Anthropic 团队近期披露了一组震撼的数据——其 Monorepo 单日代码合并次数从 2026 年 5 月的 2,500 次狂飙至 9 月的超过 30,000 次；而 Claude Code 团队自身的代码库中，约 90% 的代码完全由 Claude 编写。面对排山倒海的 Pull Request，若仍依赖工程师逐行人工审阅，整个工程团队不仅会瞬间被拖垮，更会彻底失去交付敏捷度。

然而，更令人震惊的反直觉事实发生了：从 6 月到 9 月，Claude Code 团队的代码合并量翻了一倍多，但线上引发事故或需要紧急撤回（Revert）的比例，反而逆势暴跌了四成以上！在人肉审看越来越少的情况下，系统缺陷率为何不升反降？在深入拆解了 Anthropic 核心工程团队最新披露的代码审查体系后，我梳理出这套由“六层瑞士奶酪防御管线”与“底线回滚网”构成的现代质量工程实践。

范式转移：重新定义代码审查的真正目的

在传统的软件工程协作中，代码审查往往承载着两项核心职责：

1. 在代码上线前发现并拦截缺陷；
2. 在团队成员之间建立共享的代码认知与上下文理解。

以往的工程团队在讨论审查流程时，最常问的一句话往往是：“这段代码有没有被同事逐行读过？”

但在日常深度使用 Claude Code 之后，我愈发意识到：在 Agent 高并发产出代码的时代，这句话完全是一个提错了方向的伪命题。逐行肉眼扫视并不等同于质量保证，疲惫的工程师在面对成千上万行 AI 生成的 Diff 时，极易产生审查疲劳并漏掉深层边界隐患。

更本质的问题应当是：

“这一次代码修改到底可能出现什么类型的故障？在所有自动化工具和人工节点中，哪一道屏障最适合拦截它？”

一旦将思考重心转向“风险与防御的精准匹配”，整个代码审查的时空维度就会发生颠覆性的变化：

flowchart LR
    subgraph 传统单点审查模式
        A1[工程师编码] --> A2[开启 PR] --> A3[等待同事排期] --> A4[人工逐行硬看] --> A5[合入主干]
    end
    subgraph 现代持续验证模式
        B1[本地生成代码] --> B2[本地测试与自验证据] --> B3[全新上下文 Agent 预审] --> B4[自动化 CI 与多 Agent 投票] --> B5[风险分级审批]
    end

审查不再是代码生命周期末端的一道阻断式水坝（Gate at the end），而是转变为贯穿开发全流程、类似实时输入法拼写检查的持续验证流（Continuous Verification）。

在这一范式下，人类的注意力被重新定义为最稀缺的战略资源。工程师的时间投入存在两个核心消耗口：

• 前端：花费时间审阅代码；
• 后端：出了线上事故后花费时间排查与救火。

如果仅仅为了省事而在前端压缩审查流程，导致后端的故障频发与救火时间激增，整体工程效率实际上是负增长的。因此，Anthropic 设定了一对核心看门狗指标：每个 PR 的人工等待与审批耗时 vs 上线后的撤回率（Revert Rate）与事故率（Incident Rate）。后两者构成了不可逾越的硬红线——只有在事故与撤回率稳步下降的前提下，削减人工审查时间才算真正产生了工程价值。

六层“瑞士奶酪模型”：立体化防御管线

在航空安全与系统可靠性工程中，著名学者 James Reason 提出了经典的“瑞士奶酪模型”（Swiss Cheese Model）：没有任何单一的安全措施是万无一失的，每一层防御机制都像一片带有孔洞的瑞士奶酪。单片奶酪总会漏过缺陷，但只要将多片关注不同维度的奶酪纵向层层叠加，并确保各层的孔洞位置不发生共线重叠，绝大多数故障就会在下落过程中被某一特定层成功拦截。

Anthropic 将这一哲学深度融入了代码流转的全生命周期，构建起由六层奶酪与底层安全网组成的高可靠流水线：

flowchart TD
    In[代码修改提出] --> L1["第 1 层：提交前本地自验 (Self-Verification)"]
    L1 --> L2["第 2 层：强制 CI 门禁 (Required CI)"]
    L2 --> L3["第 3 层：多 Agent 并发与投票审查 (AI Review)"]
    L3 --> L4["第 4 层：自动化安全审查 (Security Review)"]
    L4 --> L5["第 5 层：基于风险分类器的人类审批 (Risk-tiered Approval)"]
    L5 --> L6["第 6 层：合并队列与基线重验 (Merge Queue)"]
    L6 --> L7["底层安全网：功能开关 + 渐进发布 + 极速回滚 (Safety Net)"]

    style L1 fill:#1e293b,stroke:#3b82f6,stroke-width:2px,color:#fff
    style L2 fill:#1e293b,stroke:#3b82f6,stroke-width:2px,color:#fff
    style L3 fill:#1e293b,stroke:#3b82f6,stroke-width:2px,color:#fff
    style L4 fill:#1e293b,stroke:#3b82f6,stroke-width:2px,color:#fff
    style L5 fill:#1e293b,stroke:#f59e0b,stroke-width:2px,color:#fff
    style L6 fill:#1e293b,stroke:#3b82f6,stroke-width:2px,color:#fff
    style L7 fill:#0f172a,stroke:#10b981,stroke-width:2px,color:#fff

1. 第一片奶酪：本地自验闭环与“新鲜视角”预审

大部分审查在 PR 产生之前就已经在本地完成。

在让 Claude Code 编写完一段功能后，绝不能仅凭它一句口头回复“我已经实现完成”就草率提交。工程师必须给它提供一个可实际运行并能验证结果的真实环境——这可以是一组单元测试、本地构建指令、API 请求脚本，甚至是移动端模拟器截图对比。必须要求 Agent 摆出实际运行的终端输出作为证据。

Claude Code 之父 Boris Cherny 曾指出：让模型拥有验证自身工作的能力，是获取高质量产出最关键的一步，能将最终效果提升 2 到 3 倍。

在本地跑通测试后，还会派生出一个拥有全新上下文窗口（Fresh Context）的第二 Subagent 对生成的 Diff 展开独立预审。这就像写完文章后，请一位完全没参与写作过程的同事进行交叉挑错，有效打破了编写者自身的认知惯性与幻觉偏差。

对于反复出现的同类规范毛病，直接从源头免疫，将其提炼下沉：

• CLAUDE.md：全局高层次的项目约定、技术栈架构与非目标（Non-goals）；
• REVIEW.md：各子模块负责人针对该目录专门编写的审查标准。它明确指出本模块最致命的故障特征（如对文档而言是“信息不实”，对路由网关而言是“错误分发”），规定哪些路径需要忽略，并要求任何审查意见必须附带确凿的文件名与行号证据。

2. 第二片奶酪：强类型 CI 持续集成硬性门禁

代码提交推流后，立即触发全自动 CI 流水线。包含静态代码规范检测（Linter）、严格类型系统校验（Type Checking）、全平台矩阵式测试、端到端集成测试以及构建打包。

在这道门禁上，任何一项任务亮红灯都会直接一票否决，阻断合入流程，绝不允许带病前行。

3. 第三片奶酪：多 Agent 并发猎虫与共识投票机制

当 PR 正式进入仓库后，将触发自动化 AI Code Review。它并非单次单模型的简单 Prompt 调用，而是一套严密的多智能体协同网络：

sequenceDiagram
    autonumber
    participant Diff as PR 变更与上下文
    participant Hunters as 并发猎虫智能体集群
    participant Verifiers as 独立仲裁投票集群
    participant Thread as PR 内联审查评论区

    Diff->>Hunters: 派发 Diff 与全局意图
    Note over Hunters: 多个 Agent 并行推演边界缺陷与根因
    Hunters->>Verifiers: 提交候选缺陷列表
    Note over Verifiers: 交叉核验：过滤风格/格式/琐碎噪音
    Verifiers->>Verifiers: 达标阈值投票共识
    Verifiers->>Thread: 挂载高置信度 Findings
    Note over Thread: 标明严重级 (Important / Nit / Pre-existing)<br>必须逐条显式解决方可合入

• 并行勘探与交叉投票：多个 Agent 同时从架构合理性、逻辑边界和潜在副作用等多角度寻找 Bug。随后，由另一组完全独立的验证 Agent 对提报的问题进行“共识投票（Voting）”。只有当足够多的验证者一致认定缺陷属实，且排除了无关紧要的代码风格、格式整理与诊断琐碎噪音后，才会正式贴出内联评论；
• 严重度分级：每一条沉淀下来的意见被清晰标记为 Important、Nit 或 Pre-existing（历史遗留老代码，不计入本次提交者的责任）；
• 100% 显式响应闭环：PR 的评论区强制要求“要么改代码修复，要么填写充分理由关闭”。只要有一条未决议的 Finding，PR 就绝对无法合入。

引入这一过滤与投票机制后，Anthropic 内部 PR 收到实质性技术意见的比例从最初的 16% 飙升至 54%，极大剔除了低价值口水噪音。

4. 第四片奶酪：独立的自动化安全特化网关

安全审查是一道完全解耦的独立自动化防线。针对敏感调用、鉴权逻辑、数据越权、凭证暴露与注入攻击展开深度专项审计。

与缺陷审查一样，安全网关具备一票否决权，任何未决议的安全风险都将死死锁住合入闸门。

5. 第五片奶酪：基于风险分类器的人类审查分级调度

AI 生成的代码量如此庞大，如果事事都要资深架构师逐行批准，团队必然陷入瘫痪；但如果彻底放开无人监管，系统脆弱性将不可估量。

Anthropic 的解决方案是：引入专属的模型分类器（Risk Classifier），按代码变动本身的潜在破坏力（Blast Radius）进行风险定级，实现差异化的人机分权：

在这一制度设计中，包含四条铁律：

1. 风险等级由变动本质决定，而非提交者的资历：哪怕是首席科学家提交的 PR，只要改动碰到了高危路径，同样必须经过双人审批；
2. 轻量路径只向受信任作者开放：仅仓库 Core Owner 团队享有低风险免审直通权限，外部贡献者一律需要至少一名人工介入；
3. AI 的 Approval 绝不能替代人类：自动化审查可以在低风险下放行，但只要该级别要求人工审批，AI 就绝不能代签；
4. 提示词驱动者承担第一连带责任：指派 Agent 编写代码的工程师，等同于手写代码的第一责任人；且任何后续新增 Commit 会立即令已有的人类 Approval 自动失效，必须重新签署。

6. 第六片奶酪：合并队列与基线重验（Merge Queue）

在日均合入数万次的高并发 Monorepo 中，经常出现隐蔽的“并发冲突幽灵”：开发者 A 的 PR 测试通过，开发者 B 的 PR 也测试通过，但二者先后合入主干后，由于隐藏的时序依赖或语义覆盖，导致主干瞬间构建炸裂。

为了彻底扑灭这类幽灵缺陷，所有通过审批的 PR 必须进入排队队列（Merge Queue）。在轮到合入的瞬间，系统会在最新的主干代码（main 分支 HEAD）基础上把该修改合入，从头重跑全套 CI 与构建验证。只有在最新基线完全健康的严苛条件下，代码才会被真正写入主干。

底层安全网：渐进交付与秒级极速回滚

即便六层奶酪层层设防，在数万次日吞吐量的冲击下，偶发缺陷依然可能穿透所有孔洞落入生产环境。之所以 Anthropic 敢于将大量低风险修改交给 0 人自动化合并，核心底气在于它们在最底层铺设了一张极其坚韧的安全救生网。

flowchart LR
    Bug[缺陷穿透六层奶酪] --> Gate1["功能开关 (Feature Flags)"]
    Gate1 -->|关停开关| UserSafe1[用户瞬间无感]
    Bug --> Gate2["微小步提交 (Small Diffs)"]
    Gate2 -->|秒级 Revert| UserSafe2[单键快速回滚]
    Bug --> Gate3["分层灰度阶梯"]
    Gate3 -->|拦截在内部| Dogfood[Anthropic 全员 Dogfooding]
    Gate3 -->|拦截在小范围| Canary[Latest 尝鲜通道]
    Gate3 -->|终极屏障| Stable[Stable 稳定生产通道]

这套兜底体系由三大支柱构成：

• 功能开关（Feature Flags）：新业务功能在上线之初默认置于开关背后。开关是一项纯配置项，若线上发生异动，值班工程师只需秒级关掉开关，用户端功能瞬间隐匿，既不需要改动代码，也不需要重新走发版推流流程；
• 三阶灰度递进发布：新版本首先在 Anthropic 内部全员展开高强度 Dogfooding（公司内部员工本身就是最高频的重度开发者），往往在到达真实外部用户前就已暴露绝大多数边缘 Bug；随后推送至外部 latest 尝鲜通道，最后才会沉淀推送给普通大众所用的 stable 稳定版；
• 微提交与快速撤回（Fast Revert）：每一个 PR 都被鼓励拆解为高内聚、小颗粒度的微提交（Small Diffs）。撤回一条改动不仅极其清晰简单，而且“撤回”本身也是一次走标准自动化流水线的常规 PR。打包、测试全由流水线自动化执行，数分钟即可秒级完成全网回滚。

正如他们团队一位工程师所言：放慢迭代节奏确实能降低表面出错率，但那主要是因为你什么都做得少了。现代工程的精髓不是靠裹足不前去防错，而是建立以秒为单位发现问题并修好问题的自愈能力。

突破 Agent Review 的工程死循环

在构建 AI 审查体系的实战过程中，Anthropic 也曾踩过巨大的工程深坑。最典型的一次事故是：一个 CLI 仓库的 PR 在夜间被审查 Agent 和修复 Agent 互相对垒、反复审查与修改了整整 50 轮以上，陷入了无限套娃的死循环，直到早晨工程师上班后手动强行叫停！

深度剖析 git blame 数据后，团队发现了一个令人啼笑皆非的根因：

审查 Agent 在反复挑刺的问题中，有高达 59% 是在第一轮审查前就早已存在于主干的历史老代码（Legacy Code）！

人类在审查代码时具备天然的上下文容错能力，看到细枝末节的非核心遗留格式往往直接略过；但 AI 审查者极具强迫症，会执着地把沿途看到的所有老毛病挨个揪出来，而负责修复的 AI 又会老老实实逐条修改，修改引入了新代码又触发新一轮挑刺，导致整个 PR 陷入无限迭代泥潭。

为了破除这种互殴死循环，工程团队落地了四项关键收敛规则：

1. 硬性轮次上限（Round Cap）：强制规定最多只允许自动化迭代 3 轮。如果 3 轮之后仍未收敛，系统直接终止自动循环，并提示作者：“请退后一步，审视当前架构思路是否出现根本偏差”；
2. 首轮后严格限定 Diff-only：在头一两轮全局扫视后，后续重新审查严格限定在本次新增改动的增量 Diff 之内，绝不允许向外发散翻旧账；
3. 按 Bug 类别反馈而非逐行报错：要求审查 Agent 提炼指出某一类缺陷的通用模式（Class of bug），推动编写端一次性全局修复，杜绝“改一行报一行”的拉锯战；
4. 去重与记忆抑制：已提出过的历史意见绝不重复提醒。

收敛治理上线后，审查效率呈现出了质的飞跃：

xychart-beta
    title "Agent 审查收敛治理前后指标对比 (%)"
    x-axis ["单轮通过率", "五轮以上率"]
    y-axis "占比百分比" 0 --> 100
    bar [65, 9]
    bar [78, 2]

事故驱动的评估集（Eval Suite）：让审查 Agent 像算法一样持续迭代

当审查 Agent 发生漏判导致线上 Bug 时，该如何让它变聪明？

团队的做法极具 ML 工程师的工程思维：将所有历史上引发过故障、被执行过 Revert 的真实 PR 变更全量收集起来，由最熟悉那块业务的资深工程师逐一复核并精准标注缺陷所在的具体代码行，沉淀为一套专属的“事故错题本（Eval Suite）”。

这本错题本成为了 Review Agent 的日常考卷：

• 审查 Agent 每天在后台将整本错题本上的历史案例全量重跑一遍，自动化打分；
• 无论是想要优化 Review Prompt、引入新的辅助工具，还是升级底层基础大模型，任何改动都必须在错题本上跑出更高的召回率与更低的噪音得分，才被允许合并上线；
• 跑分没有提升的优化构想，一律直接抛弃。

团队协作与文化演进：机器读代码，人类怎么学？

当代码审查的大部分审阅工作被机器接管，工程师之间该如何建立起对整个庞大代码库的直观理解？

在传统模式下，通过阅读队友的 PR Diff 是熟悉模块变迁的核心途径。但 Anthropic 团队的实践给出了截然不同的答案：在数万次合并的洪流中，试图让某个人把整个代码库的细节全部装进脑子里，既不可能，也毫无必要。

1. 按需交互式生成与可视化学习

当你即将需要修改某一个陌生模块（例如 Claude Code 的统一下发配置模块）时，传统的逐行 Diff 学习效率极其低下——一段修改文案的 Diff 无法教会你任何系统拓扑。

现在，工程师只需向 Claude 提出具象问题：

“请帮我讲解一下 Claude Code 目前是如何与远程服务器同步并获取统一下发设置的？”

Claude 会在几分钟内根据代码库当下的最新真实状态，生成一份高保真且切中要害的模块架构解析文档。一些工程师甚至会进一步让 Claude 生成一个小型交互式 Web 网页或动态时序图，以最适合个人习惯的可视化形态快速吸收上下文。

学习从过去的“被动接收全局海量碎片信息”，转变为“基于真实业务切片的按需精准建构”。

2. 免责复盘与“You Land It, You Own It”

在代码责任归属上，团队推行了一条看似严苛的准则：“谁合并，谁负责（You land it, you own it）”。中小改动一旦上线出现瑕疵，通常由执行合并操作的工程师亲自修复。

但我深入理解后发现，这里的“负责”绝非传统企业文化里的背锅惩处，而是出于极高工程效率的考量：因为执行合并的人对这次修改的业务意图和技术上下文最熟悉，由他介入定位和修剪止血速度最快。

在事故复盘会议（Postmortem）中，团队严格践行免责文化（Blameless Culture）：

• 绝不追问“这是谁写的错代码”；
• 而是集体探究：“这只 Bug 本该由哪一片奶酪拦截？为什么那一层奶酪漏过了？该如何修补那个孔洞，确保同类错误再也不会漏到下游？”

当犯错不再伴随恐慌与指责，所有人都不再隐匿边缘瑕疵，问题得以在最早期浮出水面。加之微小提交、Feature Flag 与秒级回滚将单次故障的爆炸半径压缩到微乎其微，工程师才敢于在极高吞吐的 Agent 协作网络中轻装上阵、极速迭代。

给个人与团队的落地实操清单

即便我日常开发的工程系统并没有 Anthropic 那样支撑日均三万次提交的庞大底层基础设施，这套瑞士奶酪工程学的核心思想在日常使用 Claude Code 或其他 Agent 编程工具时，同样可以即刻落地：

1. 构筑本地自验环境：
   在 CLAUDE.md 或自动化脚本中，为 Agent 明确指定测试运行指令、打包验证方法与设计对比标准。坚决不接受没有运行证据的完成声明；
2. 善用内置审查指令：
   在发起 PR 之前，在本地主动执行 /code-review 与 /security-review 命令，借助多 Agent 预检消除绝大部分中低级语法与边界疏漏；
3. 建立模块级 REVIEW.md：
   将团队反复提及的评审痛点（如空值处理、日志脱敏、配置规范）固化沉淀到目录级规范文件中，让 AI 审查者有法可依；
4. 为自动化审改设立 3 轮止损线：
   在配置 CI 自动化审改 Agent 时，硬性限制循环轮次（$\le 3$ 轮），首轮后严格锁定增量 Diff，坚决杜绝老代码翻旧账引发的审查雪崩；
5. 打造自己的事故错题本：
   将每一次生产 Bug 和回滚补丁整理为标准的自动化回归用例，用确定的测试集驱动 Agent 提示词与工具链的持续演进。

原文链接与参考资料

• Anthropic 官方工程博文：How the Claude Code team does code review - Addy Osmani, Morgan Westlee Lunt, Qing Wang
• 宝玉老师视频解读原推：@dotey: 如果 AI 帮你写作业，一天写一千份，老师批得过来吗？
• Anthropic Monorepo 版本控制架构分享：Redesigning Source Control for Agentic Coding at Scale
• Claude Code 自动化代码审查官方文档：Code Review for Claude Code Guide