---

description: Claude Code Review 用多个 Agent 并行搜索、验证并排序 PR 中的缺陷，能够补足人类快速浏览留下的空白；但“不到 1% 的发现被标错”不是误报率，默认中性检查也不会阻止合并。本文结合官方演示视频拆解其审查机制、指标边界、成本模型，以及如何把 REVIEW.md、CI 和人工审批组成可信门禁。
tags: [Claude Code, 代码审查, Agentic Coding, 软件质量, CI/CD]

---

Claude Code Review 的误报标记不到 1%，为什么仍不能直接当合并门禁？

Anthropic 发布 Claude Code Review 时给了一个很容易改变决策的案例：某个生产服务只有一行代码发生变化，看起来足以快速批准，深度审查却发现它会破坏身份认证。内部数据同样醒目——工程师标记为“不正确”的发现不到 1%。

如果把后一个数字读成“准确率超过 99%”，下一步似乎就该让 Code Review 直接阻止有问题的 PR。可官方产品并没有这样设计：它不会批准 PR，GitHub Check 默认始终以中性结论结束；即使审查失败或超时，也不会挡住合并。

这不是产品缺少最后一个自动化开关。Code Review 擅长扩大缺陷搜索范围，却没有自动获得完整召回率，也不知道一条评论未被点踩究竟代表正确、无人核对，还是没有人在意。把它用好，需要把“发现问题的第二视角”和“有权放行的门禁”分开。

45 秒演示里的严重漏洞，藏在 PR 目标旁边

官方公告嵌入的 45 秒演示先在管理设置中启用 Code Review，然后展示一个名为“Fix: filter out API Error sessions from /resume command”的 PR。开发任务只是过滤失败的 API 会话，防止用户看到或恢复这些会话，表面上与权限系统没有直接关系。

Code Review 留下的评论却追到了相邻的会话详情接口。画面显示，GET /api/sessions/:id 只确认调用者已经登录，没有验证目标会话是否属于当前用户，还会把 accessToken 和 refreshToken 返回给客户端。若会话 ID 可以顺序枚举或猜测，一个已登录用户就可能取得其他用户的有效凭据。审查结果将其判断为 IDOR，给出 CVSS 9.1，并说明影响可能是任意账户接管。

演示随后把两项修复交给 Claude：增加会话所有权校验，并从响应中移除两类令牌。代码修改完成后，PR 上的对应线程显示为已验证并解决。

这段视频展示了深度审查最有价值的一面：它没有只问“过滤逻辑写对了吗”，而是沿着 PR 触及的会话数据继续追问“谁有权读取这些数据”。发现来自更宽的代码库上下文，而不是差异行的表面语法。

不过，这是一个被选来介绍产品的成功案例，只能证明系统具备发现此类漏洞的能力，不能单独给出所有 PR 上的平均召回率。演示也没有展示无发现、误报或审查失败时会发生什么，这些边界需要从数据和当前文档补齐。

多 Agent 增加搜索宽度，验证步骤负责压低噪声

按 2026 年 9 月 3 日核对的 Claude Code Review 文档，托管服务会让多个专门 Agent 并行读取差异及完整代码库。不同 Agent 寻找不同类别的问题，候选发现还要经过验证、去重和严重程度排序，最后才作为行内评论与汇总发布。

并行搜索解决的是注意力覆盖问题。一个人快速浏览大型 PR 时，很难同时保持对鉴权、并发、边界值、回滚与历史约束的深度关注；多个 Agent 可以把这些方向拆开，再共享代码库上下文。

验证步骤解决的是另一个问题：候选缺陷不等于真实缺陷。Agent 必须回到实际代码行为寻找证据，再过滤无法成立的猜测。当前产品还把发现分为 Important、Nit 和 Pre-existing，让“合并前应修复的问题”“轻微建议”与“PR 没有引入但附近原本存在的问题”分开。

这种结构比单次提示模型“帮我看看代码”更系统，但它仍是多个模型判断组成的审查管线。验证 Agent 可以减少同类误报，不能保证搜索 Agent 从未遗漏某个完全没被提出的失败路径。

四组发布数字，没有一组直接测量召回率

Anthropic 公布的数据回答了不同问题，放在一起很有说服力，却不能合并成一个“审查准确率”。

数据	实际测量	不能推出
实质性评论覆盖从 16% 升到 54%	更多 PR 收到了有内容的反馈	其余 46% 没有缺陷
大型 PR 中 84% 有发现，平均 7.5 项	大变更触发发现的频率与数量	每千行缺陷率或发现比例
小于 50 行的 PR 中 31% 有发现，平均 0.5 项	小变更也并非天然安全	工具对小 PR 的召回率
不到 1% 的发现被标记为不正确	显式负反馈非常少	误报率低于 1% 或准确率超过 99%

最后一项最容易被误读。当前文档说明，每条评论附有点赞和点踩，Anthropic 会在 PR 合并后收集反应，用于调整审查器。工程师没有点击“不正确”，可能是认可，也可能是没有验证、没有反馈或直接忽略。因此，分母是所有发现，而分子只是被显式标错的发现；它不是经过逐条标注得到的混淆矩阵。

召回率更难测量，因为团队通常不知道工具和人类共同漏掉了多少真实缺陷。可以用历史事故回放、预先植入且不告知审查器的缺陷集，或上线后的逃逸缺陷做近似评估，但官方并没有提供这类结果。

这些数字足以证明 Code Review 提高了审查覆盖，并且用户主动报告的噪声不多。它们不足以证明“无发现”就是安全，也不足以独立决定是否合并。

中性检查不是门禁，失败时更不能被误读成通过

当前文档明确说明，Code Review 的 Check Run 始终以 neutral 结论结束，因此不会通过 GitHub 分支保护自动阻止合并。它是尽力而为的审查：内部错误或超时同样返回中性状态，不会自动重试，也不会发布发现。

这个设计保留了现有评审流程。人类可以利用 Important 发现集中检查高风险位置，而不会因为模型的一条错误评论让所有开发停摆。代价是团队必须区分三种完全不同的状态：

“没有发现”表示已执行的审查没有报告问题；“失败或超时”表示没有得到有效审查；“Important 为零”也没有覆盖缺失测试。官方默认关注会破坏生产的正确性问题，而不检查格式偏好，也不默认把测试覆盖不足当作发现。

如果团队确实希望 Important 阻塞合并，可以从 Check Run 中读取机器可解析的严重程度统计，再用自己的 CI 创建阻塞规则。但这一步同时引入新的可靠性要求：审查服务失败时应当 fail closed、降级为人工审批，还是允许继续，必须由仓库风险决定，不能把 neutral 当作 success。

这与自动合并的边界是同一个判断：自动化只会执行已有门禁的决定，不会替团队补出门禁没有表达的质量标准。

REVIEW.md 决定它是否理解本仓库真正危险的地方

通用审查器能识别常见逻辑、安全和回归问题，却不知道某个团队最怕什么。多租户服务关心查询有没有限定租户，支付系统关心金额与幂等，数据平台关心迁移能否回滚；这些规则如果只存在资深工程师脑中，Agent 无法稳定检查。

当前产品会读取两类文件。CLAUDE.md 提供所有 Claude Code 任务共享的项目背景，新引入的违反项默认只作为 Nit；仓库根目录的 REVIEW.md 专门指导审查管线，内容会直接送给寻找、验证、排序和报告发现的 Agent。

一份有效的 REVIEW.md 不需要重新描述整个架构，应集中改变审查行为：

• 定义什么问题必须标成 Important，例如跨租户查询、PII 写入日志或不可向后兼容的迁移；
• 跳过生成文件、锁文件和 CI 已经严格检查的格式问题；
• 要求新增 API 路由必须带集成测试，关键行为判断必须引用 file:line 证据；
• 限制 Nit 数量，并在二次审查时只报告新的 Important，避免一行修复触发多轮风格争论。

规则越长，关键约束越容易被稀释。更好的做法是把事故复盘里已经证明重要、又能从代码验证的条件逐条沉淀进去。这样，Code Review 才是在执行团队的风险模型，而不是给所有仓库套同一份通用偏好。

每次审查 15～25 美元，触发时机本身就是架构决策

一次托管审查平均约 20 分钟，费用通常为 15～25 美元，并随 PR 大小、代码库复杂度和需要验证的问题数量变化。费用通过单独的使用额度结算，不计入方案自带用量。若仓库选择每次 Push 都审查，一个 PR 的总成本会随推送次数成倍增加。

因此，“所有仓库、每次推送、全部深审”并不是天然稳妥的默认值。三种触发方式适合不同阶段：

触发方式	更适合	主要代价
手动 @claude review	高频仓库、WIP 阶段、选择高风险 PR 深审	依赖开发者主动触发
PR 就绪时审查一次	普通功能改动，在稳定检查点获得第二视角	后续新增改动不会自动覆盖
每次 Push 后审查	高风险且持续变化的 PR，需要反复验证新提交	成本、等待与评论轮次最高

经济性不该只拿 15～25 美元与人工审查时薪比较。一条认证漏洞若被提前发现，避免的损失可能远高于审查费；大量低风险机械 PR 若每次推送都深审，费用和等待则可能超过收益。可以用一条简单关系约束试点：

审查净价值
= 被提前发现问题的预期损失
- 模型费用
- 人工确认评论的成本
- 审查等待对交付的影响

最实用的路由依据是变更风险和可验证性，而不是代码行数本身。大型 PR 通常值得更深检查，但一行鉴权改动同样可能具有极高影响；官方案例已经证明，规模只能调整审查预算，不能代替风险分类。

试点要记录确认结果，不能只看评论数量

要判断 Code Review 是否适合一个团队，至少需要同时记录四类结果：每条发现最终是否被确认和修复、Important 的发现成本、人工评审时间是否下降，以及上线后仍逃逸了哪些缺陷。点赞和点踩可以作为反馈入口，但不能代替结构化标注。

一轮可信试点可以先选择几个风险清楚的仓库，用 REVIEW.md 固定严重程度和证据标准，再对历史事故对应的改动做回放。对每条发现保留“真实缺陷、误报、重复、既有问题、无法判断”五类结果，并记录人类确认所花时间。这样才能算出可行动发现的比例，而不是把无人回应当作正确。

还要单独统计审查失败、超时和因费用上限被跳过的次数。只有成功运行的样本进入准确性报表，会高估日常可靠性；失败不阻塞合并时，这类缺口尤其重要。

Claude Code Review 的价值不在于替人类点击批准，而在于把原本没有时间展开的深读变成稳定的第二视角。多 Agent 搜索和候选验证可以提高覆盖、降低噪声，REVIEW.md 可以把团队经验变成可重复检查的规则。最终合并仍应由独立 CI、代码所有者和风险分级共同决定。

看到“不到 1% 被标错”时，先问清分子来自主动反馈还是完整标注，再看系统对无发现、失败和超时分别如何处理。能准确读懂这些缺口，才知道 Code Review 应该放在审查链路的哪一层，也能避免把一个很强的缺陷发现器误装成未经校准的放行开关。