2026 年 6 月到 9 月，Claude Code 团队合并的 Pull Request 数量增长到两倍以上，需要回滚的比例同时下降超过 40%。这组数据真正值得复用的地方，并非 AI 可以替代人工审查，而是团队把审查发现持续转成了可复用控制，让同一类错误无需在未来的每个 PR 里重新消耗人工注意力。
这里需要先区分两层验证。Anthropic 托管的 Code Review 会只读检查 diff 和仓库上下文，验证候选发现，去重、排序并发布评论。它不会构建或运行代码，返回的 GitHub Check 也不会阻止合并。审查系统验证的是这条发现是否成立；回归系统验证的是同类行为以后能否再次被自动检测。
审查意见是一条关于潜在缺陷的主张。回归控制则是一种可重复运行的检测机制。
Claude Code 团队公开的并不是一个万能审查器
官方工程文章描述的是一套分层系统：
- 提交 PR 前，开发者先给 Coding Agent 可执行的测试、构建或截图检查。
- 使用全新上下文的 Agent 复核 diff。
- 每个 PR 接受自动缺陷审查，候选发现经过其他 Agent 验证后才发布。
- 安全审查和常规 CI 提供阻断性检查。
- 人工审批数量由变更风险决定。
- 合并队列、Feature Flag、分阶段发布、监控和快速回滚覆盖漏网错误。
这套系统解决的是规模问题。Anthropic monorepo 的日变更量从 2026 年 5 月约 2500 个增长到 9 月超过 3 万个。Code Review 上线后，Claude Code PR 获得实质性自动评论的比例从 16% 增加到 54%。如果只扩大评论产量，审查队列会继续膨胀，所以团队同时观察人工审批数、人工评论数、等待时间、回滚、事故、噪声和审查轮次。
其中有两个反馈闭环特别重要：
- 反复出现的发现被前移到
CLAUDE.md、REVIEW.md、Skill、lint 规则或其他自动检查中。 - 引发过事故或回滚的历史 PR 被整理成评测集，每天重新评估审查器。
这比把每条评论都写成测试更准确。不同失败类型需要进入不同控制层。
把发现路由到成本最低的持久控制
审查评论适合作为诊断输入，不能直接充当完整规格。
| 发现类型 | 持久控制 | 原因 |
|---|---|---|
| 有稳定输入、可以复现的行为错误 | 单元、集成、契约或端到端测试 | 预期行为可以反复执行 |
| 机械语法或局部代码模式 | linter、类型检查、格式化或静态规则 | 确定性工具比 Agent 更便宜，噪声也更低 |
| 仓库特有约定 | 精简的 REVIEW.md、CLAUDE.md 或按需 Skill |
规则需要上下文，但未必对应运行时行为 |
| 安全或授权不变量 | 阻断性策略检查加负向测试 | 高影响不变量应该失败关闭 |
| 带有生产证据的事故或回滚 | 版本化评测样本与生产回放 | 原始失败应同时评估审查器和系统 |
| 架构、范围、审美或产品方向 | 人工审查、设计记录或 CODEOWNERS 门禁 | 判断依赖组织意图和取舍 |
| 误报或低价值 nit | 审查反馈标签或抑制规则 | 把噪声永久化会增加维护与 Agent 返工 |
路由时只需要回答一个问题：下一次要稳定检测这类失败，成本最低且足够可靠的接口是什么？
先把评论还原成行为合同
一条有价值的审查意见通常只描述了症状。写测试前，至少把五类信息显式化：前置条件、触发动作、期望结果、禁止结果和原始证据。
finding_id: CR-2026-1042
failure_class: stale-cache-after-account-switch
precondition: 用户 A 的数据已缓存，随后会话切换到用户 B
action: 不完整刷新，直接打开仪表盘
expected: 页面只呈现用户 B 的数据
forbidden: 任何用户 A 的记录出现
evidence: PR 链接、文件与行号、审查轨迹
接下来建立能保留原始失败的最小复现，冻结输入、环境、依赖版本、Feature Flag 和预期结果。只在当前实现上通过的测试证据很弱。真正的回归测试应该在有缺陷的版本上失败，在修复后通过。
当补丁和测试都由 AI 编写时，先红后绿尤其重要。模型可能把当前实现当成期望答案，也可能测试了错误路径，或者写出从未真正观察缺陷的断言。应在隔离分支中恢复缺陷，确认新测试变红；再重新应用修复，确认测试转绿。
不要把发现成立等同于修复完成
可以用六级证据状态管理审查线程：
- 已发现：审查器报告了候选问题。
- 已复现：人或独立 Agent 在记录完整的条件下重现失败。
- 已修复：实现针对已确认的根因发生变更。
- 已回归保护：控制在缺陷状态下失败，在修复状态下通过。
- 已集成：相关 CI 或策略门禁会覆盖未来变更。
- 已线上观察：分阶段发布或生产监控在约定窗口内没有发现复发。
这套状态能避免把已验证的审查发现误写成已验证的修复。Anthropic 的公开文档明确指出，没有发现问题并不代表代码没有错误或安全缺陷。Code Review 本身也不执行代码。测试、构建、截图、合并队列、Canary 和线上监控分别补齐不同证据层。
优化收敛，而不是最大化评论数量
作者 Agent 和审查 Agent 可以无限制造彼此的工作。Anthropic 记录过一个内部 PR 在一夜之间经历 50 多轮审查与修改。进一步分析发现，反复被标记的代码约有 59% 在第一轮时就已经存在。团队随后增加了三轮上限，在前几轮之后只复审新增 diff，标记整类缺陷，并禁止重复发布已有发现。
这给出了四组更有用的运营指标：
- 按严重度拆分的真实缺陷召回率；
- 误报率与错误修复率；
- 通过所需轮次的中位数和 p95；
- 每个合并变更消耗的人工分钟数，以及对应的事故率和回滚率。
评论数量不应该成为目标。噪声较高的审查器看起来覆盖全面，实际会制造更多提交、重跑和等待。真实缺陷捕获优先，减少审查轮次其次；回滚率和事故率负责判断人工时间究竟被节省，还是被转移到了下游。
在行为合同模糊的地方保留人工责任
Claude Code 团队按照变更风险分配审批，而非按照代码作者分配。低风险变更通过自动检查后可以走轻量路径；中风险变更需要一人审批；最高风险区域和指定敏感路径需要两人审批。Agent 的批准不能占用人工审批名额，指挥 Agent 编写变更的人仍然对结果负责。
回归自动化也应沿用这一边界。测试擅长验证可明确描述、可重复执行的行为。以下问题仍需人工判断：
- 这个功能是否值得做？
- 这个抽象是否会形成团队愿意长期维护的模式？
- 变更爆炸半径是否可以接受？
- 测试 oracle 漏掉了什么重要行为？
- 产品应该选择哪组取舍？
自动化的目标是压缩重复验证，让人的注意力集中到这些机器难以替代的决定上。
一套可以落地的四周流程
先选一个仓库，使用四周真实审查数据启动：
- 导出实质性评论、已解决线程、回滚和事故。
- 为每项标记失败类别、严重度、根因、处置方式和证据状态。
- 选择高频或高影响、且行为合同稳定的失败类型。
- 建立最小复现，证明测试先红后绿。
- 将每类失败路由到测试、静态规则、指令、评测集或人工门禁。
- 把新控制关联回原始 PR 或事故。
- 每次变更运行最小相关检查，合并或发布前运行更广的检查集。
- 同时观察审查噪声、收敛轮次、人工时间、回滚和事故。
- 把新的线上漏网错误加入回归集或审查器评测集。
- 定期删除行为合同已失效，或维护成本超过风险收益的控制。
最终形成的是一套可复利的审查系统。每个重要错误都会改善下一轮审查，而不是只留在一个已经关闭的 PR 线程里。
常见问题
Claude Code Review 会运行测试吗？
Anthropic 托管的 Code Review 会读取 diff 和仓库上下文，但不会构建或运行代码。需要自行增加可执行测试、构建、静态检查，以及真正具有阻断能力的 CI。
Claude Code Review 没有发现问题，是否代表 PR 安全？
不代表。Anthropic 将它定义为 best-effort，也明确说明没有发现问题无法证明代码正确或安全。它适合作为多层验证系统中的一层。
每条审查评论都应该变成回归测试吗？
行为可复现的缺陷适合写测试。机械模式适合静态工具，仓库约定可以进入精简指令，架构与产品方向继续保留人工判断，误报则应该用于改进或抑制审查器。
怎样避免 AI 编写的测试验证了错误行为？
先写行为合同，冻结测试夹具，并证明测试在缺陷版本上确实失败。高影响场景使用独立复核者，并在线上另行验证实际结果。
REVIEW.md 里应该写什么？
保持简短且贴合仓库。说明什么算失败、哪些区域敏感、哪些路径应该跳过、发现需要什么证据，以及低价值 nit 的数量限制。可执行不变量应进入测试或静态检查，避免只依赖文本指令。