Claude 编写了 Claude Code 约 90% 的代码。面对海量的代码产出，传统的代码审查模式难以为继：谁在阅读代码？如何发现并处理错误？

Anthropic 团队披露了其代码审查流程的演变。今年六月至九月，合并到 Claude Code 代码库的拉取请求（PR）数量翻倍，而需要回滚的比例下降超过 40%。团队并未取消审查，而是将大部分“阅读”工作转移给机器，优化人类注意力分配，并确保错误能被快速修正。

重新定义代码审查

随着 AI 代理（Agents）介入，变更数量激增。在 Anthropic 的单仓（monorepo）中，每日提交变更从五月的约 2,500 个增至九月的 30,000 多个。手动逐行审查已不可行。

代码审查的核心任务有二：发布前发现问题，以及建立团队共享上下文。新流程侧重于前者，将审查从“道路尽头的关卡”转变为“持续进行的拼写检查”。大多数变更在请求人类查看前，已由 Claude 审查并修复过一次，从而捕获常规错误，让人类专注于更高阶的问题。

稀缺资源：人类时间与注意力

团队的目标是：大多数 PR 合并时最多只有一名人类参与，且回滚或事故率不增加。衡量指标包括每个 PR 的人类批准数、评论数量及等待时间，并以回滚率和事故率为护栏。

变更生命周期：层层递进的过滤网

一次典型变更需经过多层审查：

1. PR 创建前的自动验证

在打开 PR 之前，Claude 需运行测试、构建或对比截图以验证输出。子代理会带着全新上下文审查差异（diff）。开发者还会运行内部技能查找 bug、简化差异或进行端到端检查。

Anthropic 工程师 Boris Cherny 指出，赋予 Claude 验证能力是关键，这使得最终结果质量提高两到三倍。同时，团队通过 CLAUDE.md（项目性质、约定）和 REVIEW.md（代码所有者指南）规范 AI 行为，并从源头修复自动审查员反复标记的问题。

2. AI 主导的 PR 审查

每个 PR 在人类查看前都会经过 Claude 审查，评估变更是否解决问题、符合系统规范或破坏其他功能。内部数据显示，获得实质性审查评论的 PR 比例从 16% 升至 54%。

审查发现由多个代理并行验证并投票，仅当足够多代理确认为真实问题时才发布，且按严重程度排序。风格或诊断类噪音被丢弃。每个发现必须得到回应：修复或用理由解决。通常，代理会在夜间接手修复，作者次日可见经过另一轮审查的 PR。

3. 可阻止的安全与自动化检查

若 Bug 或安全审查中存在未解决的开放问题，PR 禁止合并。常规操作包括 lint、类型检查、全平台测试及构建。PR 模板要求说明测试方法及回滚方案，由发起人签字确认。

4. 基于风险的人类批准

审查层级由变更风险决定，而非作者身份：

  • 低风险（文档、文案等）：自动化审查通过后无需人类批准。
  • 中风险（普通产品变更、敏感区域）：需一人批准。
  • 高风险（核心代码、特定路径）：需两人批准。

只有受信任的作者（如仓库所属团队）可享受较轻路径，但代理的批准永远不能替代人类。发起变更者对 PR 负责，新提交落地后需重新批准。

5. 合并队列与渐进式发布

合并队列会对主分支重新运行检查，防止冲突。新行为首先通过标志向内部员工发布，随后进入 latest 频道，最后推向 stable 频道。

6. 快速检测与回滚

对于漏网之鱼，团队依靠标志关闭、值班轮换及事故审查快速响应。工程师更倾向于提高发现和解决问题的速度，而非单纯降低开发速率。

优化审查员：减少噪音与收敛

团队将历史事故 PR 纳入评估集，每日运行审查员以检验效果。通过观察人类对评论的操作（修复、忽略、标记误报）来衡量噪音。

为避免 AI 作者与审查员陷入无限循环，团队设定了轮次上限（三轮后要求重新考虑方法），首次通过后仅重新审查差异，并标记 bug 类别以便批量修复。数据显示，约 59% 被审查员标记的代码在首次通过时已存在，表明审查员更多是在捕捉旧 bug 而非新 bug。

人类在循环中的位置

高级工程师的时间应从捕捉常规错误中解放出来，转向机器不擅长的决策：

  • 方向与范围：判断“是否应该构建此功能”。
  • 高风险代码：如计费、自动更新器、CI 工作流。
  • 架构规范：设定他人将复制的模式。
  • 证据审阅：检查测试输出、截图及审查员发现。
  • 结果问责：每个人对发布的变更负责，无论代码由谁输入。

共享上下文与所有权文化

为弥补机器阅读导致的上下文缺失，团队成员利用 Claude 生成代码解释器或可视化构件，以高效学习特定模块。这种按需获取知识的方式比逐行阅读琐碎差异更有效。

团队奉行“你落地，你拥有”原则。若变更出问题，发起人通常负责修复。这依赖于小变更、可逆操作（标志、回滚）、严格的爆炸半径控制及非指责性的事故审查。开放的 Slack 频道文化使得反馈来自不拥有代码的人，进一步保障了质量。

流程采纳建议

对于希望采用类似流程的团队，建议如下：

  • PR 前：提供可运行的检查列表（CLAUDE.md），本地运行 AI 审查与安全审查，添加 REVIEW.md。
  • PR 中：强制 CI，添加 AI 审查员并微调指南，实施自动化安全审查，根据风险匹配审查深度，限制审查轮次。
  • 批准：基于变更风险设定层级，保留轻量路径给受信任作者，关键路径始终需要人类批准，机器人批准不替代人类。
  • 合并后：使用合并队列、功能标志及分阶段发布，将事故转化为评估集，以回滚率和事故率监控人类时间投入。

未来，随着界限移动，更多低风险变更可能仅凭自动化检查即可合并。目标始终不变：减少每次变更的人类时间投入，同时保持甚至降低回滚率。