当 AI 生成 90% 代码：Claude Code 团队如何重构审查流程
Anthropic 的 Claude Code 团队此前披露，其内部工具约 90% 的代码由 Claude 自身编写。随着自动化代码生成量的激增，传统的逐行人工审查模式面临巨大挑战：谁在真正阅读这些代码？错误由谁拦截？
从 6 月到 9 月，Claude Code 代码库的合并请求（PR）数量增加了一倍以上。面对这一变化，团队并未减少审查环节，而是将大部分初筛工作转移给机器，旨在优化人类工程师的时间与注意力分配，并建立更高效的纠错机制。
重新定义代码审查的目标
智能体介入编码后，变更规模迅速扩大。在 Anthropic 的单体仓库中，每日落地的变更数从 5 月的约 2,500 次飙升至今年 9 月的超过 30,000 次。这种高频、海量的手动逐行检查已不再具备可行性。
代码审查本质上承担两项职能：
- 在发布前发现并修复问题；
- 在团队内部建立共享上下文及对代码库的共同理解。
本文重点阐述第一项职能的实现方式，即如何通过自动化手段捕获常规错误，从而释放人力专注于更复杂的问题。
“是否有人读过代码”这一质疑本身可能并不准确。审查的性质已从“终点大门”转变为“实时拼写检查”。在提交给人工审核之前，Claude 至少会对大多数变更进行初步检查与修复。这一前置步骤捕获了绝大多数常规错误，使团队能将注意力集中在更高阶的逻辑问题上。
核心资源：人类时间与注意力的稀缺性
策略的核心在于让自动化检查处理剩余问题，而让人类专注于只有人才能解决的决策。即便在当前速度下，人类仍需投入大量精力，团队几乎每天都会遇到新挑战。
人类时间成本包含两部分：审查耗时与修复坏代码的耗时。若仅缩短前者而后者未减，则整体效率并未提升。因此，团队追踪每位 PR 作者的批准耗时（中位数及第 95 百分位数），以衡量是否真正节省了人力，而非仅仅转移了负担。
目标是在 Claude Code 仓库（涵盖 CLI、桌面端、Web 应用及移动端）中，实现大多数提取请求仅需一人参与循环即可合并。
变更的生命周期：多层防御体系
一个典型的代码变更从工程师本地或 Slack 中的 Claude 会话出发，需经过多层审查才能最终上线。
审查并非单一关卡，而是分为六层检查，辅以回滚机制。每一层捕获特定类型的问题，极少有错误能穿透所有防线。
1. 提交前的自我验证
目前多数审查发生在创建 PR 之前。开发者赋予 Claude 可执行的验证手段（如测试、构建或与截图比对），随后由另一个子代理基于新上下文审查差异。这源于团队的最佳实践指南。
在正式开 PR 前，许多工程师还会运行内部技能：一项用于查找 Bug，另一项用于简化差异。UI 变更还需对照设计准则进行检查。
Claude Code 创建者 Boris Cherny 指出，赋予 Claude 验证自身工作的能力是获得高质量结果的关键。他估计此举可将最终质量提升两到三倍。不同领域的验证方式各异，例如在浏览器或手机模拟器中测试应用。
当自动审查器反复标记同一类问题时，团队会在源头（即技能配置）中进行修正：
- CLAUDE.md：告知 Claude 项目背景，包括技术栈、惯例、目标与非目标。每次审查均加载此文件，因此在大型代码库中保持精简至关重要。审查者会依据规范标记违规代码及过时更改。
- REVIEW.md：由代码所有者编写，明确代码中的关键约束。团队单独检查审查者是否遵循此文件。优秀的 REVIEW.md 简短明了，具体说明失败形态（如文档“撒谎”，配置“路由错误”），列出跳过的路径，并要求提供文件行号作为证据而非猜测名称。同时要求总结，明确指出何时无需修复。
2. 每个人工智能审查
每个提取请求在人工查看前，都会获得一条来自 Claude 的评论。审查核心问题包括：变更是否解决了既定问题？是否符合系统架构？是否破坏了其他功能？
在修复错误时，重点在于寻找根本原因。公开版本《Code Review for Claude Code》已在团队和企业计划中普遍可用，本地可通过 /code-review 命令运行轻量版。
推出研究预览版后，内部 PR 获得实质性审查评论的比例从 16% 升至 54%。大多数超过 1,000 行的 PR 会被发现问题，而小型 PR 通常顺利通过。管理员可为每个仓库设置 Quick、Standard 或 Deep 模式。在漏掉 Bug 代价高于额外审查时间的场景下，Deep 模式值得采用。
在人工审核前，其他代理商会验证结果。多个代理同时寻找 Bug，只有足够多代理同意确认为真实问题时才会发布。仅涉及风格、诊断或清理的发现会被丢弃。保留前需对公关人员进行 A/B 测试。剩余内容按严重程度排序，并标记为“重要”、“无用”或“已存在”，确保引入的错误看起来不像作者的个人失误。
每一个发现都必须得到回应：要么修复，要么给出理由关闭线程。代理往往在一夜之间完成排查，作者次日面对的已是经过多轮处理的 PR。
3. 强制性安全审查
安全部门执行自动检查。若 Bug 审查或安全审查仍有未解决项，PR 禁止合并。开发者需修复或以简短理由关闭相关线程。
若后续提交解决了问题，结果会自动清除。团队使用开源安全审查 GitHub Action 或 /security-review 命令配置此流程。
4. 阻断式自动检查
在所有平台上进行测试与构建。一个典型的 CLI 提取请求在任何人查看前，可能已运行数十次检查。公共关系模板询问变更的测试方法及取消方式。Claude 可填写相关内容，但要求变更人员签字确认。
5. 基于风险缩放的人工批准
文件修复与自动更新器的风险等级不同，审查要求亦不同。
| 风险等级 | 示例 | 人工批准要求 |
|---|---|---|
| 低 | 文件、副本、内部特征、标志后的添加更改 | 自动审查和安全检查通过后，无需人工批准 |
| 中 | 常规产品更改，以及缓存、自动更新器或系统提示等敏感区域的更改 | 需要一人批准 |
| 高 | 最危险的代码，加上一组始终需要两人审查的路径 | 需要两人批准 |
分类器读取变更内容以选择风险级别，第二个分类器判断是否需要额外人员，即使层级规则未强制要求。某些路径（如所有者列为敏感的文件、任何 CI 工作流程文件）始终需要人工介入。
只有受信任的作者（通常是拥有者）才能获得更轻松的路径。其他人均需第二人认可。代理人的认可不计入个人认可。自动审查可清除低风险变更，但不能替代必须的人工空缺。
无论谁促成变更，都需为此负责。在代理编写的 PR 中，指导代理的人被视为必要审稿人之一。批准仅针对特定承诺，若有新提交且系统无法保证一致性，批准必须重新给予。
6. 合并队列与逐步发布
合并队列会对 main 分支重新运行所有检查，防止两个单独通过的 PR 组合后导致主分支破碎。大规模使用往往能在用户感知前暴露回归问题。公共发行先推送至最新频道，稳定频道随后跟进。
7. 快速检测与回滚
最后一层旨在快速发现漏网之鱼。通过关闭标志（Flag）在不部署的情况下隔离问题。Claude Code 设有每周值班轮换，事件审查会追问哪一层应捕获该问题。
尽管电路断路器尚未完全收紧审批流程，但发现错误的合并仍依赖作者、值班人员及仪表板反馈。一位同事表示，放慢速度虽降低错误率，但团队更倾向于快速发现并解决问题。
优化审查者性能
代码审查流程处于持续改进的闭环中。
事故转化为评估集。团队收集了过去引发事故的 PR 及其修复和回滚记录，由熟悉代码的工程师确认每个 Bug 及其位置。审查者每日在此集合上运行。
通过用户行为监测噪音。若不介意标记大量非 Bug，捕获更多 Bug 很容易，因此需控制噪音。团队根据 PR 作者对评论的反应进行分类：修复、反驳、声明有意为之或忽略。此外，在已知干净的 PR 上运行审查者，统计其报告可能导致有害变更的频率。优先级明确：首先捕获真实 Bug，其次减少审查轮次。
当作者是代理时，噪音成本更高。人可以瞬间忽略小瑕疵，而代理会尝试修复，导致新的提交和新一轮审查。
审查必须收敛。代理作者与代理审查者可能无限期互相忙碌。曾有一个 CLI PR 在夜间经历了超过五十轮审查与修复，直到作者主动停止。
通过 git blame 分析审查者反复标记的内容，发现约 59% 是首次通过时就存在的代码。审查者很少发现新 Bug，而是在每轮重复发现旧 Bug。
团队曾习惯默认运行多轮审查，因为每轮都能发现新东西。这在高风险变更中值得，但不适用于每个 PR。现在团队跟踪“通过所需轮次” alongside 召回率，并调整重审策略：
- 轮次上限。三轮后，审查者要求作者退一步重新考虑方案。
- 仅差异重审。前几轮之后，仅审查差异部分。
- 标记 Bug 类别。促使作者修复所有实例，而非单行代码。
- 禁止重复。不重复发布已提交的发现。
审查代理还每晚扫描现有代码，帮助在旧 Bug 显现于其他地方之前将其捕获。
人类保留的决策权
将资深工程师从深度工作中抽出以捕捉常规错误，成本远高于自动审查。在 Anthropic，人类的工作重心已从阅读每个差异转向机器不擅长的决策领域：
- 方向与范围。是否应该构建此功能？即使某团队声称解决了审查瓶颈，对外部团队的变更仍保留人工审查，以回答“我们真的要做这个吗？”
- 高风险代码。如计费、自动更新器和 CI 工作流程。
- 架构模式。设定他人将复制的模式。
- 阅读证据。测试输出、运行的命令及返回结果、截图、审查者的发现。若无法说明检查遗漏了什么，应请求真正的审查而非快速批准。
- 结果所有权。无论谁输入代码，人都要对发布的变更负责。
团队上下文的共享
代码审查的第二项职能是传播代码库理解。阅读队友的差异是了解变化及组件契合度的传统方式。若机器完成大部分阅读，人如何学习代码？
团队没有正式流程。无人需要在脑海中保持 Claude Code 的完整模型，团队认为也无此必要。当某人想理解代码库的某一部分时，他们直接询问 Claude 生成针对该切片的解释。这只需几分钟，且反映的是当前代码状态。
部分成员更进一步，让 Claude 构建小型可视化工件，以个人喜欢的学习方式教授代码片段。
若目标是高效利用人类注意力，这种方法优于逐行阅读琐碎差异。一行文案修改几乎不传授知识，而关于即将修改模块的解释则极具价值。团队默认在开放的 Slack 频道工作，这也促进了协作，成员可在构建过程中看到他人的工作。
“你落地，你负责”
若落地的小型或中型变更出现问题，团队规范通常由负责人修复。以下机制防止情况恶化：
- 变更粒度小。易于审查、调试和回滚。
- 一切可逆。标志、回滚和分阶段发布可在几分钟内撤销大多数错误。
- 爆炸半径决定标准。昂贵代码获得更多人员和检查。
- 回归快速浮现。通过遥测和内部使用发现。
- 非指责文化。拥有修复意味着拥有最多上下文；事件审查关注系统而非个人。
所有权也是共享的。团队多在开放频道工作，任何人都可见证构建过程、接管线程或引导 Claude 填补空白。反馈也来自不拥有代码的人。这种开放性是维持高质量而无需逐行设卡的关键。
方向调整
由于代理使启动项目变得廉价，部分工作不应落地。通常频道中有人会询问原因，指出早期决策或建议更简单路径，作者随即关闭或重塑 PR。
鉴于代码编写速度快，关闭 PR 并不会带来沉重的心理负担。
