Claude Code 团队约九成代码由模型编写，每日变更量从 5 月约 2500 次涨到 9 月超 3 万次，PR 数量翻倍而回滚比例反降四成。七层审查流程把验证前移，再按风险等级分配人工审批名额。

Claude Code 团队的代码库中，约 90% 的代码由 Claude 编写。2026 年 6 月到 9 月，合入 Claude Code 的 Pull Request 数量增长了一倍以上，但需要回滚的比例下降超过 40%。

这不是因为团队取消了 Code Review，而是把“逐行阅读”变成了多层自动化检查，把人类时间留给风险判断、架构方向和最终责任。

代码审查的目标变了

Agent 让每日变更量从 5 月约 2500 次增长到 9 月超过 3 万次。继续要求工程师逐行阅读每个 Diff，不仅难以扩展，也会把高级工程师从真正需要判断的任务中抽走。

代码审查仍然承担两个职责：发布前发现和修复问题，以及在团队内建立代码库上下文。但第一个职责不能只用“有没有人读过代码”衡量，更准确的问题是：这项变更有什么风险，哪道自动化或人工检查最适合拦截它？

审查因此从 PR 终点前移为持续运行的流程。大多数变更在提交给人类之前，已经经过 Agent 验证、审查和修复。

Claude Code 团队的七层审查流程

1. PR 创建前先验证

Agent 必须使用可运行的测试套件、构建流程、截图对比或端到端验证证明结果，而不是只汇报“已经完成”。随后，另一个全新上下文的 Subagent 读取 Diff，避免作者 Agent 的上下文偏差。

团队还使用专门找 Bug、精简 Diff、验证端到端行为和检查 UI 设计的 Skills。反复出现的审查意见会被固化进 Skill、Lint 规则、CLAUDE.md 或 REVIEW.md。

2. 每个 PR 先接受 AI Review

AI 审查结合整个仓库背景、PR 目标和代码 Diff，重点判断变更是否解决了承诺的问题，是否适配现有系统，是否破坏了其他模块。Bug 修复还要继续追查根因，而不是只确认表面测试通过。

研究预览阶段，产生有效审查意见的内部 PR 比例从 16% 提升到 54%。超过 1000 行的 PR 更容易发现问题，小型 PR 则更适合快速通过。

审查模式可以分为 Quick、Standard 和 Deep。漏掉错误代价高的变更，应选择更深的审查。

3. 多 Agent 验证审查意见

一个 Agent 发现的问题不会直接展示给人类。多个 Agent 并行检查，另一组独立验证 Agent 对意见投票，只有足够一致才发布。纯风格、日志或微小清理意见会被过滤。

每条意见按 Important、Nit 或 Pre-existing 分类，既有问题不会错误归因到当前 PR。意见必须修复或给出理由关闭，Agent 还可以在夜间自动完成修复和二次审查。

4. 安全审查拥有阻断权

只要 Bug 审查或安全审查存在未关闭意见，PR 就不能合并。后续提交修复问题后，审查项自动解除；团队也可以使用安全审查 GitHub Action 或 /security-review 搭建类似流程。

5. CI 检查必须全绿

Lint、类型检查、跨平台测试、构建编译都是基础门禁。PR 模板还要填写 Testing、Risk 和 How to revert。Agent 可以代填，但提交变更的人必须对内容负责。

6. 按风险等级决定人工审批

风险由代码变更决定，而不是由提交人决定。Agent 的批准不能抵消人类批准名额；批准只对特定 Commit 有效，一旦出现新 Commit，就必须重新审批。

7. 合并队列、灰度和快速回滚

Merge Queue 会把 PR 与最新主分支合并后重新运行检查，避免两个单独通过测试的变更组合后破坏主干。新功能先放在 Feature Flag 后交给内部员工使用，再从 latest 通道逐步推到 stable。

功能开关可以无需重新发布就关闭，On-call 轮值负责监控和快速回滚。每次事故复盘都要追问：这个问题本来应该在哪一层被拦截？

让审查器越来越聪明

所有线上事故都转化为 Eval：保留历史 PR、修复提交和回滚提交，由熟悉业务的工程师确认问题性质和位置，审查器每天对照评测集运行。

团队还通过观察人类如何处理意见衡量噪音：意见被修复、关闭、证明错误或被认为无关紧要，都要被统计。干净 PR 用来测试误报率，原则是优先捕捉真实 Bug，再减少审查轮数。

当作者也是 Agent 时，噪音成本更高。人可以忽略 Nit，Agent 却会认真修改，产生新提交并触发新一轮审查。因此流程必须收敛：最多三轮，后续只审新增 Diff，一次解决同类问题，禁止重复意见。

人类必须留在闭环里的地方

自动化审查可以检查很多代码，但以下判断仍需要人类：

• 是否应该做这个需求，方向与产品品味是否正确；
• 计费、自动更新、CI 和其他高危敏感路径；
• 会被多个模块复用的架构设计；
• 测试输出、实际命令、截图和审查证据是否可信；
• 合入后谁承担最终责任。

“谁上线，谁负责”并不等于把责任推给提交者，而是让拥有完整上下文的人负责后续排查。细粒度变更、功能开关、快速回滚、遥测和免责复盘共同保证这套机制可持续。

如果需要让 Claude Code 接入类似的自动审查、测试和回滚流程，可以使用兼容 API 配置环境；国内开发者可通过 Code80 设置 endpoint：

$env:ANTHROPIC_BASE_URL = “https://code.ai80.vip”

$env:ANTHROPIC_AUTH_TOKEN = “<你的 API Key>”

claude

常见问题

AI Code Review 能替代人工批准吗？

不能。AI 可以发现问题、验证 Diff 和过滤噪音，但高风险变更仍需人类批准，Agent 的批准不能抵消人类审批名额。

为什么要限制审查轮数？

Agent 作者和 Agent 审查器可能无限互相修改。限制轮数、只看增量 Diff 和禁止重复意见，可以让审查收敛。

如何判断自动审查是否有效？

用线上事故、回滚和历史 Bug 建立 Eval，同时统计真实问题召回、误报、PR 等待时间和人工审查次数。

低风险变更可以零人工合并吗？

在自动测试、安全检查和回滚机制成熟后，部分低风险变更可以只依赖自动门禁，但敏感代码、CI 和发布路径仍应保留人类审批。