当 AI 编写了 90% 的代码：Anthropic 是如何重塑代码审查的？

By Gemini 3.8 flash

导读：当 AI Agent 成为研发主力，代码产出呈指数级爆发时，传统的代码审查（Code Review）机制会最先崩溃。在 Anthropic，Claude 编写了 Claude Code 项目本身约 90% 的代码；其 Monorepo 的每日合并量在短短数月内从 2,500 次暴增至 30,000+ 次。面对海量变更，工程师还读不读代码？出了线上事故谁负责？

本文深度解析 Anthropic 官方技术博客 How the Claude Code team does code review，探讨他们在 AI 原生软件工程（AI-Native SDLC）时代给出的答卷：放弃逐行人工审代码，以“瑞士奶酪”多层防御与极低成本回滚，换取研发吞吐量与代码质量的双重提升。

一、瓶颈与剧变：AI 编码时代的“审查危机”

在过去几个月中，Anthropic 内部经历了一场前所未有的工程吞吐量爆发：

代码生成主体易位：在 Claude Code 团队内部，大约 90% 的代码已由 Claude 编写。
合并吞吐量暴涨：Anthropic 整个 Monorepo 每天合入的变更量，从 2026 年 5 月的约 2,500 次飙升至 9 月的 30,000+ 次。
审查与回滚成效：从 6 月到 9 月，Claude Code 代码库合并的 PR 数量翻了一倍以上，而需要回滚（Revert）的比例反而下降了 40% 以上。

在如此恐怖的交付节奏下，传统的 “写完代码 $\rightarrow$ 提 PR $\rightarrow$ 等同事逐行审查（Line-by-line review）” 模式已经完全不可持续。

这引发了三个最尖锐的问题：

还有人看代码吗？
如果机器看大部分代码，它真能抓出关键 Bug 吗？
如果出了事故，谁来背锅？

二、认知重构：代码审查的真正目的是什么？

Anthropic 团队首先重新审视了代码审查的本质。传统研发流程中，Code Review 承担着两项核心职责：

在代码上线前发现并修复缺陷；
在团队中建立代码共识与对系统的共同理解。

团队指出：“是否有真人读过这段代码”并不是衡量代码可靠性的准确指标。真正科学的追问应当是：

“这项改动可能带来什么风险？哪种检查手段——无论是自动化的还是人工的——最适合捕获它？”

这一底层思维的转变彻底打破了传统流程：

审查时机的前移：以往审查是流水线末端的硬门槛（Gate）；现在审查变成了开发全流程的“实时拼写检查”。大部分代码在人类工程师看到之前，已经被 Claude 审查并自动修复过多轮。
以“稀缺注意力”为优化目标：工程师的时间和注意力是极度稀缺的资源。优化目标是——绝大多数 PR 在合并时，最多只需要 1 个人类在循环中（甚至可以就是发起人自己），且回滚率和线上事故率不上升。

三、瑞士奶酪模型：一次代码变更的 7 层防御旅程

为了在极少人工干预的前提下控制质量，团队建立了一套纵深防御体系。单层检查难免存在疏漏（如同瑞士奶酪上的孔洞），但当 7 层机制叠加，且底部配备快速回滚机制时，漏网之鱼将变得极少。

flowchart TD
    subgraph S1["第 1 层：PR 之前的前置自验 (Verification)"]
        A["开发/生成代码"] --> B["自动化自测: 运行测试 / 构建 / UI截屏对比"]
        B --> C["子 Agent 在全新上下文独立审查 Diff"]
        C --> D["加载 CLAUDE.md 与 REVIEW.md 规范"]
    end

    subgraph S2["第 2-4 层：PR 提交后的自动化阻断检查"]
        D --> E["第 2 层：Claude AI 代码审查<br/>(多 Agent 并发捕获 + Verifiers 投票)"]
        E --> F["第 3 层：独立自动化安全审查 (Security Review)"]
        F --> G["第 4 层：严格阻断级 CI<br/>(Lint / Types / 跨平台构建与测试)"]
    end

    subgraph S3["第 5 层：基于风险的人工分级审批 (Risk-based Approval)"]
        G --> H{"风险分类器判定"}
        H -- "低风险: 文档/文案/Flag 后功能" --> I["免人工审批直接合入 (限信任作者)"]
        H -- "中风险: 一般功能/敏感配置" --> J["需 1 名工程师审批"]
        H -- "高风险: 核心链路/鉴权/CI 脚本" --> K["强制 2 名工程师审批"]
    end

    subgraph S4["第 6-7 层：合并后防线与兜底恢复"]
        I & J & K --> L["第 6 层：Merge Queue 最新主干再验证"]
        L --> M["Feature Flag 内部员工灰度先行 (Dogfooding)"]
        M --> N["渐进式发布: Latest 渠道 -> Stable 渠道"]
        N --> O["第 7 层：实时监控 + 秒级一键回滚 (Fast Rollback)"]
    end

1. 提交 PR 之前的自动化自验（Verification）

大多数审查在 PR 创建前就已经完成：

必须展示执行结果：Claude Code 创始人 Boris Cherny 强调，给 Agent 提供自验手段是获取优质结果最关键的一步，能让结果质量提升 2~3 倍。无论是运行一段 shell 脚本、跑单元测试，还是在无头浏览器中渲染页面截图并与设计图比对，Claude 必须展示实际运行输出，而不是仅仅宣称“我做完了”。
独立上下文的 Subagent 复查：由另一个独立的子 Agent 在全新的上下文（Fresh Context）中独立审查 diff。
指令规范文件的沉淀：
- CLAUDE.md：全局项目规范、技术栈、架构约定。
- REVIEW.md：各子模块代码所有者（Code Owner）编写的微型审查指南。声明该模块最关心的故障模式（例如“文档不能说谎”、“路由配置不能错配”），要求审查器必须给出具体代码行号证据，而非凭函数名臆测。

2. 每个 PR 都有 AI 审查（AI Review）

每个 PR 都会在人类介入前接受 Claude 的深度审查：

多 Agent 找 Bug + Verifiers 投票：多个 Agent 并行查找 Bug，随后由另一组验证 Agent 对找出的 Finding 进行投票。只有被公认真实的实质性问题才会被发表，无意义的代码风格（nits）和诊断清理会被自动过滤。
强制闭环处理：所有 Finding 必须被解决——要么提交代码修复，要么填写原因关闭议题（如标记为 False Positive）。这一闭环机制经常在夜间由 Agent 自动完成，作者第二天上线时已是修复后的最新状态。

3. 独立的自动化安全审查（Security Review）

安全审查作为独立的流水线运行。只要 AI 审查或安全审查中存在任何未关闭的 Finding，PR 就被强制阻断合并。

4. 严格的阻断级自动化 CI

包含类型检查、Lint、跨平台测试以及打包构建。PR 模板中必须清晰注明“如何测试”以及“出现问题如何回滚”。

5. 基于风险的人工审批分级（Risk-based Approval）

彻底抛弃了“所有改动一律需要 Peer Review”的死板规定，改由分类器根据变更内容本身自动评估风险级别：

风险级别	典型场景	人工审批要求
低风险 (Low)	文档更新、UI 文案、纯内部特性、受 Feature Flag 保护的增量改动	0 人（AI 审查与 CI 全绿后自动合入，限受信作者）
中风险 (Medium)	常规业务功能，以及敏感模块（如缓存逻辑、自动更新器、系统 Prompt）	1 人审批
高风险 (High)	计费系统、鉴权逻辑、CI 工作流脚本及团队核心路径	2 人强制审批

重要

审批铁律：

Bot 的审批绝不能计入人类配额；
指派 Agent 编写代码的工程师视同该 PR 的作者，算作审查者之一，负首要责任；
审批绑定特定 commit：一旦有新代码提交（包括 Agent 自动修复的 push），之前的人工审批立即作废，必须重新确认。

6. Merge Queue、Feature Flags 与渐进式放量

Merge Queue：在合入前将变更与最新 main 分支预合并测试，杜绝两个单独测试通过的 PR 合并后破坏主干的问题。
吃自己的狗粮（Dogfooding）：新功能首先通过 Feature Flag 向 Anthropic 全体内部员工开放，通过高频自用提前暴露边缘缺陷。
双通道发布：外部发布走双层缓冲，先推向 latest 预览通道，平稳后再推进到 stable 正式通道。

7. 快速检测与秒级回滚（Fast Rollback）

体系的最后一道防线是承认“即便千锤百炼，也一定会有疏漏”。因此团队将重注押在降低撤销错误的成本上：

Feature Flag 无需重新部署即可秒级热关停；
发生缺陷时坚决执行快速回滚（Revert），而不是在主干上慌乱地“向前热修复（Fix forward）”；
每次事故复盘，核心议题都是追问：“前面的哪一层机制本该捕获这个问题？”

四、关键工程治理：如何避免“AI 互博死循环”？

在推行全自动审查时，Anthropic 遇到了一个极其典型的 AI 原生工程陷阱：AI 编写者与 AI 审查者陷入无限循环（Convergence Issue）。

曾经有一个 CLI 的 PR，由 Agent 编写并由 Agent 审查，双方在夜间不知疲倦地“找茬-修改-再找茬-再修改”，足足迭代了 50 多轮。
进一步排查发现：审查器反复提出的批评中，约 59% 是在第一轮就已存在的老代码！ 审查器并不是在不断发现新 Bug，而是在每一轮随机把代码库里的陈旧异味再挑出来几条。

为此，团队制定了严格的收敛机制：

硬性轮次上限（Round Cap）：如果 3 轮审查后仍未通过，强制终止循环，要求人工介入重新审视方案方向；
前几轮后仅审查增量（Diff-only Re-review）：后续轮次仅针对最新修复的代码 diff 进行审查，不再全盘扫描老代码；
指出“一类缺陷”而非“单行缺陷”：要求 AI 审查器一次性归纳出问题类别，促使 Agent 作者全量整改，杜绝挤牙膏式修改；
禁止重复报障：已标记或讨论过的问题，不允许再次弹出。

提示

线上事故即评测集（Eval-Driven Improvement）：
团队将历史上引发事故或导致 Revert 的 PR 全部收集整理成基准 Eval 集。AI 审查器本身的 Prompt、工具链或模型发生任何变动，都必须先在这一 Eval 集上跑分跑通，确保 Bug 拦截率只增不减。

五、人类工程师的角色重塑

当机器接管了语法、类型、常规逻辑和边界条件的逐行检查后，人类工程师在研发循环中究竟该做什么？

Anthropic 团队给出的回答是：人类精力从“挑语法毛病”全面撤离，集中投射到机器最不擅长的五大高阶决策中：

                    ┌──────────────────────────────┐
                    │  人类工程师的核心高阶职责   │
                    └──────────────┬───────────────┘
                                   │
      ┌────────────────────────────┼────────────────────────────┐
      │                            │                            │
┌─────┴───────────────┐  ┌─────────┴─────────────┐  ┌───────────┴──────────┐
│ 1. 必要性与品味判断 │  │ 2. 关键架构模式制定   │  │ 3. 审查真实运行证据  │
│ Should we build it? │  │ 设计将来被 AI 复用的  │  │ 检查命令输出/截屏/日志│
│ 决定需求是否值得做   │  │ 核心模式与架构范式    │  │ 而非脑内跑代码       │
└─────────────────────┘  └───────────────────────┘  └──────────────────────┘
              │                                                 │
              └────────────────────┬────────────────────────────┘
                                   │
                    ┌──────────────┴───────────────┐
                    │ 4. "You land it, you own it" │
                    │ 最终责任归属：谁发起谁负责   │
                    └──────────────────────────────┘

审视必要性与品味（Should we build this at all?）：AI 让写代码的成本几乎归零，这导致了大量不必要、设计拙劣的功能被轻易提出来。人类最首要的任务是说“不”，把握功能方向与软件品味。
掌控高危与核心架构：涉及计费结算、安全鉴权、系统架构演进等关键设计，必须由人类深度思考。
审视客观证据，而非脑内模拟：人类不应在脑子里肉眼反编译代码，而应直接审视客观证据——测试日志通过了吗？性能 Benchmark 变好了吗？UI 截图是否还原？
终极责任归属（"You land it, you own it"）：不管一行代码是手写的还是 Prompt 让 Claude 写的，由点击合入的那个人承担所有线上运维和故障恢复的全部责任。

六、知识传递重构：不逐行看 Diff，如何掌握代码库？

在传统观念中，“读同事的代码”是工程师学习系统架构、了解全局变化的主要途径。如果大家都不读 diff 了，怎么理解系统？

Anthropic 团队给出了一个出人意料的答案：放弃“每个工程师脑子里都必须维持一个完整代码库心智模型”的执念。

在当今瞬息万变的巨型代码库中，要求人脑记住全部细节不仅是不可能的，而且是极度低效的。一个改动了一行文字样式的 PR，通读它对你的技术成长没有任何收益。

现在的做法是：按需实时切片学习（On-demand Slice Learning）：

当你需要修改某个陌生模块时，直接让 Claude 生成针对该切片的深度解析（Explainer）；
让 Claude 自动生成定制化的交互式 Artifacts 或架构可视化流程图，按照你最习惯的认知方式即时授课；
这种学习只需要几分钟，而且得到的信息永远是最新的，远比几个月前在某个 PR 里粗粗扫过几眼记忆深刻得多。

七、团队实践落地清单

对于希望拥抱 AI 辅助编码、正在面临 PR 积压的团队，Anthropic 给出的落地节奏十分明确：

Phase 1: PR 提交前
  ├─ 维护简短清晰的 CLAUDE.md（全局规范）
  ├─ 各模块配置 REVIEW.md（模块期望与关注点）
  └─ 本地运行自动化检验命令并输出实测证据

Phase 2: PR 审查中
  ├─ 引入 AI 审查流水线，开启并发审查与验证投票
  ├─ 设立严格的审查轮次上限（建议最多 3 轮）
  └─ 阻断性 CI + 自动化安全检查，未解决 Finding 不得合并

Phase 3: 审批分级
  ├─ 制定基于风险等级的审批矩阵（低/中/高风险）
  ├─ 敏感关键路径强制 2 人审批 + CODEOWNERS 锁定
  └─ 任何新 commit 自动重置人工审批状态

Phase 4: 合并与线上保障
  ├─ 强制使用 Merge Queue
  ├─ 全面普及 Feature Flag，内部员工灰度先行
  └─ 建设秒级回滚体系，将每次线上事故固化为 AI 审查 Eval 集

结语：软件工程范式的跃迁

当研发速度提升 10 倍，想要维持软件质量，答案绝不是把刹车踩死、强求工程师加班做更多的人工审查。

Anthropic 的经验表明，AI 原生软件工程的核心不是用 AI 替代流程中的某一个动作，而是重塑整个工程闭环：

把细枝末节的验证交还给自动化的算力；
把宝贵的人类直觉留给方向判断与架构决策；
用极低成本的试错与回滚机制替代笨重的前置门禁。

正如团队在文中所述：“放慢速度确实能降低错误率，但那主要是因为你什么事都少做了。我们宁可跑得更快，同时变得更快地去发现和修复问题。”

当 AI 编写了 90% 的代码：Anthropic 是如何重塑代码审查的？

一、 瓶颈与剧变：AI 编码时代的“审查危机”

二、 认知重构：代码审查的真正目的是什么？

三、 瑞士奶酪模型：一次代码变更的 7 层防御旅程