三层体系：先分清你在用哪层
| 层 | 跑在哪 | 谁能用 | 特点 |
|---|---|---|---|
| /code-review | 本地会话（子智能体） | 所有用户 | 审当前 diff，发现直接回会话，走套餐额度 |
| /code-review ultra | 云端沙箱（智能体舰队） | claude.ai 登录用户（研究预览） | 更大舰队 + 逐发现独立验证，不占本机资源 |
| 托管 Code Review | Anthropic 基础设施 | Team / Enterprise（ZDR 除外） | PR 自动触发、行内评论、管理后台管控与计费 |
想在自己的 CI 里跑审查（而不是托管服务），走 GitHub Actions / GitLab CI 的 claude-code-action 路线——见我们的无头 CI 一文，两条路线互为替代。
托管审查怎么工作
多个专职智能体并行分析 diff 与周边代码，各盯一类问题（逻辑错误、安全漏洞、边界情况、隐性回归）；验证步骤把候选发现对照实际代码行为过滤假阳性；去重、按严重度排序后以行内评论落在具体代码行上， 平均 20 分钟完成。严重度三档：
- 🔴 Important：合并前该修的 bug。
- 🟡 Nit：值得修但不阻塞的小问题。
- 🟣 Pre-existing：存量 bug，不是这个 PR 引入的。
每条发现自带 👍👎 按钮——点评有用没用，Anthropic 在 PR 合并后收集用于调校审查器（不会触发重审）。 每条发现还有可展开的推理过程，讲它为什么这么判、怎么验证的。
永不阻塞，但可以自建门禁
check run「Claude Code Review」恒以中性结论完成，分支保护规则卡不住它——这是有意设计，保证现有审查流程不被打断。 要按发现数卡合并，解析 check run 输出末尾的机器可读注释：
gh api repos/OWNER/REPO/check-runs/CHECK_RUN_ID \
--jq '.output.text | split("bughunter-severity: ")[1] | split(" -->")[0] | fromjson'
# 返回 {"normal": 2, "nit": 1, "pre_existing": 0}
# normal 非零 = 有合并前该修的问题，自己的 CI 里判失败即可触发策略与成本
| 策略 | 行为 | 成本特征 |
|---|---|---|
| 每 PR 一次 | PR 打开或转正式时审一次 | 可预算，基线选择 |
| 每次 push | 每次推送都审，自动解决已修复线程 | 成本 × push 数，最贵 |
| Manual | 只认 @claude review 评论 | 高流量仓库按需付费 |
均价 $15-25 / 次（随 PR 规模与验证量浮动），走 usage credits 单独计费、不占套餐内额度；管理后台可设月度上限、看每仓库均价。手动命令三个：@claude review（单次）、@claude review always（并订阅后续 push）、@claude review once（同单次）。 触发失败最隐蔽的原因：GitHub 组织成员身份默认私有，Claude 看不到你的 write 权限——公开成员身份或让管理员直接加你为 collaborator。fork 来的 PR 任何模式都只认手动评论。
REVIEW.md：七种调校模式
CLAUDE.md 会被当作项目上下文读（新引入的违规按 nit 报），而 REVIEW.md 是 review 专用指令——直达查找、验证、定级、写报告的每个智能体，落地更可靠。官方总结的高价值模式：
- 重定义严重度：明说你的仓库里什么算 Important（默认标定面向生产代码；文档仓、配置仓该收窄）。
- 限制 nit 音量：「最多报 5 条 nit，其余在摘要里给个数」。
- 跳过规则：生成代码、lockfile、vendor 目录、CI 已有 lint 覆盖的类别。
- 仓库专属检查：「新 API 路由必须有集成测试」这类每 PR 必查项。
- 验证门槛：「行为断言必须带 file:line 引用，不接受按命名推断」——直接砍假阳性。
- 复审收敛：「首轮之后只报 Important，不再出新 nit」——防一行修复审到第七轮。
- 摘要形状：要求评审正文开头给一行统计（如「2 事实问题、4 风格」）。
注意 REVIEW.md 按纯文本读取：@import 语法不展开、引用的文件不会被跟读，规则要直接写在文件里。
/code-review ultra：云端深审
本地 /code-review 之上的重型选项：把仓库状态打包上传到远程沙箱（审 PR 时则什么都不上传）， 云端舰队并行探索，每个报告的发现都被独立复现验证——产出聚焦真 bug 而不是风格建议。 启动前有确认弹窗：审查范围、剩余免费次数、预估成本，确认后后台跑、终端照常用。
/code-review ultra # 当前分支 vs 默认分支（含未提交改动）
/code-review ultra develop # 指定对比基线边界：需 claude.ai 登录（API key 先 /login）；Bedrock / Vertex / Foundry 与 ZDR 组织不可用——不可用时 自动降级为本地审查；只有你显式敲命令才会跑，Claude 不会自作主张。上传遵循云端会话的凭证排除规则（.env、*.pem 类未提交改动不上传）。
落地清单
- 个人：把 /code-review 纳入合并前习惯；大改动加一层 ultra。
- 团队：从「每 PR 一次」起步，观察两周均价再决定是否上 push 模式。
- 第一周就写 REVIEW.md：先只写严重度定义 + 跳过规则两节，按噪音逐步加。
- 要门禁就解析 bughunter-severity JSON 自建，别指望 check run 本身卡人。
- 用 👍👎 反馈喂调校，噪音大的仓库优先调 REVIEW.md 而不是关审查。
这套体系的定位不是替代人审，而是把人审的注意力从「找 bug」解放到「判设计」——机器先把逻辑错误、 安全漏洞、边界情况筛一遍并验证过，人只对严重度表和设计取舍表态。