Anthropic 怎样让 AI 审查 AI 代码

AI 写代码越来越快，谁来检查它写得对不对？

这套方案的关键，是把“找问题、核实问题、决定合并”分成不同环节。 读懂这三个环节，就能抓住 Claude Code 团队审查流程的主线。

背景：人的注意力跟不上代码产量

团队希望减少人工审查时间，同时不增加回滚和事故。为此，他们把验证前移，并把人工审批与变更风险绑定。原文

这里的难点是：每一份修改都需要有人理解需求、核对行为、处理疑点。如果代码生成加速，而这些工作仍全部排在提交之后等待人工完成，审查就会成为瓶颈。自动化要真正省时间，还得减少误报和反复修改，否则只是把“读代码”变成了“处理评论”。

flowchart LR
  A[提交前验证] --> B[AI 找问题并复核]
  B --> C[按风险审批]
  C --> D[发布与反馈]

给编码 Agent 可运行的测试、构建或界面检查，让它执行、读取结果并修正，再交付实际输出。官方最佳实践

这一步需要把“做完了”变成可检查的条件。例如，修改一个接口后，除了描述改了什么，还应提供执行过的验证命令、输入和结果。审查者可以据此知道哪些行为已验证、哪些仍需检查，不必重新猜测作者是否真的运行过代码。

测试通过的含义有范围。 它证明已覆盖场景符合预期，不能保证所有调用方式都正确。因此，后面仍需要结合需求和周边代码审查。

公开 Code Review 服务采用四步处理：多个 Agent 并行阅读 diff 和周边代码，形成候选问题；验证阶段对照代码筛掉误报；随后去重、按严重度排序；最后写成行内评论和摘要。工作流程

例如，某个 Agent 怀疑“接口缺少权限检查”，验证阶段就需要核对调用路径：检查是否已经在上层中间件完成，以及当前请求能否绕过它。如果已有有效检查，局部代码没有重复校验就未必是漏洞。这个例子说明，一条疑点需要经过上下文核实，才能成为值得作者处理的意见。

这里的核实基于读代码，服务本身不运行测试。因此，“代码分析支持这个判断”和“已执行测试复现”是两种证据，不能混为一谈。服务边界

审查还需要知道项目特有的约定。公开服务用 CLAUDE.md 获取通用规则，用 REVIEW.md 定义审查重点、严重度和忽略范围。规则说明对自己的团队而言，规则最好描述具体的失败条件，例如“什么情况下数据可能越权”，而不是笼统要求“关注安全”。

内部流程结合安全审查和 CI，并要求发现的问题被修复或说明关闭理由；风险分类决定 0、1、2 人的审批要求，另一个分类器判断是否还需额外人工。轻量路径限受信任作者，敏感路径另有强制要求，Agent 不能占人工名额。原文

理解这一步，要分清三个状态：检查有没有运行完、发现有没有处理完、审批条件有没有满足。它们分别回答执行、问题处理和授权的问题。一个审查任务成功结束，不代表它发现的问题已修复，更不代表这项修改已经获得合并资格。

风险分级也不能孤立使用。即使某项修改被判为低风险，仍要满足适用的自动检查、作者资格和路径规则。借鉴时应该把这些条件写成可检查的流程，避免只用一个风险标签决定放行。

内部使用合并队列重跑检查，以渐进发布和回滚控制上线风险；事故进入评测集，用来检验后续审查能力。原文

合并队列解决的是“单独正确，组合出错”：两个 PR 各自通过测试，合在一起可能改变接口约定或状态行为，所以需要验证合并后的结果。渐进发布则缩小首次暴露范围，避免一个漏检问题立刻影响所有用户。

事故进入评测集后，过去漏掉的缺陷就成为可以再次检查的案例。由此可以比较新的审查方式是否识别了原来的问题，而不只凭评论看起来更详细来判断进步。对自己的评测，还应加入正常修改，观察是否引入更多误报。

从工程角度看，这套分工让不同检查互相补充：测试验证已定义的行为，AI 扩大代码分析的范围，人工判断变更风险，发布机制限制漏检后的影响。每一层都有局限，组合起来才有意义。

另一个关键问题是审查能否结束。AI 作者和 AI 审查者可能不停地互相改代码。 团队在三轮后要求重新评估方案，并使用增量复查、问题去重和同类缺陷一起修复来控制循环。原文

为什么这很重要？每条意见都可能触发新提交，新提交又触发审查。如果同一个问题反复出现，或者每轮只指出同类问题中的一个位置，评论越多，返工也越多。因此，评价审查工具时既要看它抓住了什么，也要看作者为它花了多少时间。轮次上限是重新判断方案的信号，不能变成自动放行的理由。

以下是结合上述机制的落地建议：

先让修改可验证。 在 PR 说明中记录预期行为、验证命令和实际结果。这样，作者和审查者围绕同一份证据讨论，而不是反复确认“到底测过没有”。
让意见有证据、有处理结果。 要求指出代码位置、触发条件和影响；修复或关闭时留下理由，后续复查据此识别重复问题。检查超时或失败也要单独记录，不能当成“没有发现”。
观察效果，再调整人工审批。 先在熟悉的模块试用，同时记录漏报、误报、修改轮次和人工耗时。只有确认整体负担下降、风险可控后，才考虑扩大自动化范围。

接入补充：审查规则从哪里加载

REVIEW.md 读取 base branch 或默认分支的版本，不采用待审 PR 自己修改后的规则。本地 /code-review 不读取 REVIEW.md，接入前需确认实际使用的工具。规则加载说明