随着 AI 编程代理大量参与开发，代码审查面对的最大问题已经从“如何审查一份代码”变成了“如何在代码数量快速增长时，合理分配有限的人类注意力”。

Claude Code 团队在官方博客中分享了他们的实践：不取消代码审查，而是把大部分机械性检查交给机器，把人类时间留给架构、风险和产品方向等更需要判断力的问题。

本文是对原文的中文整理与总结，并非官方翻译。原文：How the Claude Code team does code review。

一、代码审查的目标需要重新定义

传统流程通常是：开发者写完代码、提交 PR、等待同事逐行检查。但当 AI 代理能够快速生成大量代码时，人工逐行阅读很难继续作为唯一审查方式。

Claude Code 团队认为，代码审查主要承担两项职责：

  1. 在代码上线前发现问题；
  2. 帮助团队建立对代码库的共同理解。

其中，第一项可以大量交给自动化系统完成；第二项则不一定要通过阅读每一份普通 diff 来实现。对于需要理解某个模块的工程师，让 Claude 针对目标模块生成解释或可视化，往往比阅读大量低风险改动更有效。

团队的目标不是“每行代码都必须由人看过”，而是回答：

这次改动可能出什么问题？哪个检查层最适合发现它？

二、数据说明：代码增长，但回滚率下降

文章提到，Claude Code 团队在 2026 年 6 月到 9 月期间，合并到 Claude Code 代码库的 PR 数量增长超过一倍，但需要回滚的改动比例下降了超过 40%。

Anthropic 内部主仓库每天落地的改动，也从 5 月的大约 2,500 个增长到 9 月的 30,000 个以上。

这说明高吞吐开发并不必然意味着质量下降，前提是审查流程、自动化验证和回滚机制能够一起升级。

三、一份改动要经过多层检查

Claude Code 团队采用的是“多层防线”，而不是单一的人工审批门禁。

1. 在创建 PR 之前完成验证

开发者会先给 Claude 提供可以实际运行的验证手段，例如：

  • 测试命令；
  • 构建命令；
  • 截图或界面比对；
  • 端到端行为检查；
  • 针对特定领域的内部技能。

要求代理展示实际执行结果，而不是只口头说明“已经完成”。完成初步实现后，再使用一个具有新上下文的子代理重新检查 diff，避免作者代理只按照自己的思路确认结果。

重复出现的问题，则应该沉淀到源头：

  • 写入 CLAUDE.md；
  • 增加 lint 规则；
  • 增加自动化测试；
  • 更新项目技能或检查脚本；
  • 用 REVIEW.md 记录代码所有者最关心的风险。

2. 每个 PR 都进行 AI 代码审查

每个 PR 都会先经过 Claude 审查。审查不只看 diff，还会结合整个代码库和 PR 的目标，判断：

  • 这次改动是否真正解决了问题；
  • 是否符合现有系统设计；
  • 是否破坏了其他功能；
  • 修复是否触及根因；
  • 是否引入了安全问题。

审查结果还会经过其他代理复核，只有多个检查者认为问题真实存在时，才会提交给开发者。这样可以减少风格建议、无关清理和误报。

3. 安全审查单独运行

安全审查与普通 bug 审查分开进行，而且可以阻塞合并。

当普通审查或安全审查仍有未解决的问题时，PR 不能合并。开发者必须修复问题，或者明确说明原因并关闭对应讨论。

这类检查尤其适合覆盖：

  • 权限变更；
  • 自动更新器；
  • CI 工作流；
  • 系统提示词；
  • 凭据处理；
  • 网络和数据访问。

4. CI 检查继续发挥作用

lint、类型检查、多平台测试和构建仍然是基础门槛。AI 审查不能替代确定性的自动化检查。

PR 模板还应要求说明：

  • 做了哪些测试；
  • 这次变更的风险是什么；
  • 出问题后如何回滚。

5. 根据风险决定人工审批数量

不是所有改动都需要相同程度的人工审查。团队按改动风险分级：

风险等级 典型改动 人工审批
低 文档、文案、内部功能、特性开关后的增量改动 自动检查通过后可不要求额外审批
中 普通产品功能、缓存、自动更新器、系统提示词 至少 1 人
高 高风险代码、CI 工作流、关键路径 至少 2 人

审批数量由改动内容决定，而不是由提交者身份决定。代理的批准不能替代必须由人完成的审批。

6. 合并队列、灰度发布和快速回滚

合并队列会在最新主分支上重新运行检查，避免两个分别通过测试的 PR 合并后产生组合问题。

新功能通常先通过特性开关向内部员工开放，再逐步推向用户。发布渠道也采用渐进策略，让新版本先进入较快的渠道，稳定版本稍后跟进。

如果问题最终仍然漏过前面的检查，就依靠监控、值班响应、特性开关和一键回滚快速止损。

四、如何减少 AI 审查中的重复和噪声

AI 作者和 AI 审查者可能互相推动，导致一份 PR 不断修改、不断重新审查。Claude Code 团队发现，某些 PR 甚至经历了几十轮审查。

为避免审查失控，他们采用了几项措施：

  • 限制审查轮数，超过三轮就重新考虑整体方案；
  • 首轮之后主要只审查新增 diff；
  • 同类问题一次性修复，而不是逐行修补；
  • 不重复报告已经解决的问题；
  • 每晚对已有代码进行审查，提前发现历史问题。

此外，团队会把过去造成事故或回滚的 PR 收集成评测集，每次修改审查器后都重新测试。这样，真实事故会反过来改善下一轮自动审查。

五、人类应该把时间用在哪里

AI 负责大量重复性审查后，人类并不是退出流程，而是把注意力集中到更高价值的判断上：

  • 这个功能是否值得构建；
  • 产品方向和范围是否正确；
  • 架构是否会成为未来的坏范例；
  • 高风险代码是否需要额外审批；
  • 自动化检查的证据是否可信；
  • 发生问题后谁负责修复和恢复。

团队强调“谁推动改动落地，谁就对结果负责”。无论代码是人写的还是代理写的，最终让它进入生产环境的人都需要承担结果责任。

六、普通团队如何借鉴

不需要一次性复制完整体系，可以从一个仓库开始逐步实施：

提交 PR 前

  • 在 CLAUDE.md 中写清楚项目结构、验证命令和边界；
  • 给代理提供可以实际运行的测试、构建和截图检查；
  • 使用新上下文的子代理检查 diff；
  • 建立简短的 REVIEW.md，记录真实的高频问题；
  • 将重复出现的意见转化为 lint 规则或自动化测试。

PR 阶段

  • 为每个 PR 接入 AI 审查；
  • 单独增加安全审查；
  • 要求所有审查线程都得到处理；
  • 在 PR 模板中记录测试、风险和回滚方式；
  • 先从低风险仓库或低风险路径开始试运行。

合并和发布阶段

  • 对 CI、认证、计费、安装器和自动更新器设置强制人工审批；
  • 使用 CODEOWNERS 和分支保护；
  • 使用合并队列；
  • 新功能优先通过特性开关灰度发布；
  • 将事故和回滚案例加入持续评测；
  • 用回滚率和事故率衡量自动化是否真的提升了效率。

七、总结

Claude Code 团队的核心经验不是“让 AI 代替人类审查所有代码”，而是重新安排不同类型检查的职责：

  • 机器负责高频、确定性和重复性的检查；
  • AI 负责理解上下文、发现潜在缺陷和辅助修复；
  • 人类负责方向、架构、风险和最终责任；
  • 发布系统负责灰度、监控和快速回滚。

在 AI 生成代码越来越多的情况下，最重要的指标也不应只是“人工审批了多少次”，而应该关注：

  • 真实问题是否被提前发现；
  • 回滚率和事故率是否上升；
  • 人类审查时间是否下降；
  • 自动化检查是否持续减少误报；
  • 出错后是否能够快速恢复。

真正成熟的 AI 开发流程，不是取消人类判断，而是让人类判断出现在最值得出现的地方。