解析 Claude Code /code-review 的 high 档评审提示词：system_prompts_leaks 中的多视角代码审查流水线

本篇以 high.md 为核心，逐段拆解 Claude Code 内置 /code-review 命令在 high（默认）努力级别下的完整提示词：从 Phase 0 的 diff 采集、Phase 1 的 8 个独立查找视角（finder angles）、Phase 2 的“单票 + 召回偏向”验证，到最终最多 10 条的 JSON 输出契约。读完本文，你既能理解这个提示词为什么能把一次评审组织成“多 Agent 并行找候选 → 单票去偏验证 → 排序截断”的工程化流水线，也能把其中“视角分工、失败场景命名、CONFIRMED/PLAUSIBLE/REFUTED 三态判定”等技巧借鉴到自己设计代码审查类 Agent 时。以下内容依据 system_prompts_leaks 仓库中从 Claude Code 二进制提取并对照线上 API 抓取逐字节校验过的原文（见 code-review 目录 README），并结合同级目录中 low.md、medium.md、max.md、xhigh.md、report-findings-tool.md 等文件做交叉印证。

总体流水线：一行公式定下 high 档的全部参数

high.md 全文第一行就是一句话流水线公式，它也是理解整个文档的骨架：

`high effort → 3+5 angles × 6 candidates → 1-vote verify (recall-biased) → ≤10 findings`

展开成中文即：

• 3+5 视角：3 个正确性（correctness）角度 + 3 个清理（cleanup）角度 + 1 个“实现深度”（altitude）角度 + 1 个“规范”（conventions）角度，共 8 个独立 finder；
• 每视角至多 6 条候选：每条候选必须带 file、line、一句话 summary 和一个具体的 failure_scenario；
• 单票验证、召回偏向：每条候选只派一个验证者（1-vote verify），且判定时偏向“宁可放出、不可漏报”（recall-biased）；
• 最终最多 10 条 finding，按严重程度排序输出。

文档开头紧接着用三行定义了 high 档的评审哲学：

You are reviewing for recall at high effort: catch every real bug a careful reviewer would catch in one sitting. At this level, catching real bugs matters more than avoiding false positives. Err on the side of surfacing.

注意一个关键设计：high 档追求的是召回率（recall）——目标是“一个仔细的评审者坐在那里看一遍能抓到的每一个真实 bug 都要抓到”。在这一档，抓真 bug 的优先级高于排除误报，规则上明确指示模型“倾向于把疑点放出来”。这与 medium 档形成鲜明对照：medium.md 开头写的是 "You are reviewing for precision at medium effort: every finding you surface should be one a maintainer would act on."（medium 追求精确率：每条 finding 都应是维护者会实际去处理的）。同一个 8 视角、1-vote verify 的骨架，仅通过改变“recall 优先还是 precision 优先”这句话，就把两个档位的输出风格区分开了。

命令入口与努力级别：high 是如何被路由到的

在 system_prompts_leaks 仓库中，high.md 属于 Claude Code /code-review slash 命令的提示词模板集。code-review 目录 README 说明了使用方式与五个努力档位的完整矩阵：

/code-review [level] [target]

• level 取值 low、medium、high（默认）、xhigh、max；target 可选，可为 PR 编号、分支、ref 区间或文件路径；
• --comment 把 findings 作为行内 PR 评论发出；--fix 在评审后把 findings 应用到工作区；
• ultra 走的是另一条云端多 Agent 评审通道，不在这五份本地模板之内。

README 给出的五档流水线对照表如下（原文为英文，此处按原意翻译并保留关键数字）：

文件	流水线
low.md	1 次 diff 通读，无子 Agent，无验证 → ≤4 条 findings
medium.md	8 个 finder 视角 × 6 条候选，1-vote verify（precision 调校）→ ≤8 条
high.md	8 个 finder 视角 × 6 条候选，1-vote verify（recall 偏向）→ ≤10 条 —— 默认档
xhigh.md	10 个 finder 视角 × 8 条候选，验证 + 缺口扫描（sweep）→ ≤15 条
max.md	与 xhigh 相同，仅头部措辞不同；只有 API reasoning effort 有差异

从源码结构看（即从仓库中各文件的正文比对看），medium 与 high 的 Phase 0/1/输出部分几乎逐字相同，差异集中在两点：开头的 recall/precision 定位句，以及 Phase 2 验证规则——medium 要求验证者按“CONFIRMED 必须能报出触发输入与错误输出、PLAUSIBLE 需说明什么情况能确认、REFUTED 需引用证明行”的三态细则给出；high 则采用更粗粒度的“PLAUSIBLE by default”规则（下文详述）。这解释了为什么两个档位共享同一套 8 视角骨架：视角集是常量，档位差异主要体现在验证松紧与输出上限（≤8 vs ≤10）上。

另外，README 指出当命令带参数时，注入的提示词块会在开头加上 Review target: <args> 前缀与一个空行；不带参数时直接从档位头部开始。SKILL.md 则是该 skill 的注册文件：frontmatter 中 name: code-review 加一段 description 说明各档语义，正文与 high.md 完全一致——因为 high 就是默认档。

Phase 0 — Gather the diff：先把“评审范围”钉死

high.md 的 Phase 0 给出 diff 采集的完整规则，原文要点如下（含全部命令）：

1. 首选运行 git diff @{upstream}...HEAD 拿到统一 diff；
2. 若没有 upstream，退化为 git diff main...HEAD 或 git diff HEAD~1；
3. 若存在未提交改动，或者上述范围 diff 为空，还要再跑 git diff HEAD，并把工作区改动一并纳入评审范围——原文解释理由是 “the review often runs before the commit”（评审常常发生在提交之前）；
4. 如果调用方以参数传入了 PR 编号、分支名或文件路径，则改以该目标为评审对象；
5. 最终把这份 diff 当作评审范围（review scope）来对待。

这一段看似平淡，实际解决的是 Agent 化代码审查中一个非常实际的问题：评审对象（review scope）的边界定义。@{upstream}...HEAD 的三点 diff 只覆盖“本分支领先于上游”的提交；但开发者更常见的场景是“刚改完还没 commit”，此时三点 diff 可能是空的——如果不补 git diff HEAD，整条流水线就会在空输入上跑完并输出 []，一次本应捕获 bug 的评审静默作废。把两种 diff 取并集作为 scope，是这个提示词里第一处“面向真实工作流”的设计。

Phase 1 — Find candidates：8 个视角、每个至多 6 条候选

Phase 1 的执行方式是：通过 Agent 工具运行 8 个相互独立的 finder 视角，每个视角最多产出 6 条候选 finding，每条候选包含 file、line、一句话 summary 与一个具体的 failure_scenario。原文还给出了降级路径：

If the Agent tool is not available in your current tool set, do not error — perform each angle (and each verification) yourself, sequentially, in this context.

即：当前工具集里没有 Agent（子 Agent）工具时不要报错，而是在当前上下文里按顺序逐个视角、逐个验证自己执行。code-review 目录 README 也印证了这一点：每个档位都附带一个 no-Agent-tool 的 fallback——没有 Agent 工具时，同样的视角以单路、无子 Agent 验证的方式 inline 执行。这是一个典型的“提示词级优雅降级”设计：能力缺失时不中断流程，而是缩小并行度。

下面按原文顺序逐视角拆解。

正确性视角 A/B/C：三个抓 bug 的角度

三个正确性视角分别盯住 diff 的“新增行、删除行、跨文件影响面”，形成互补：

Angle A — line-by-line diff scan（逐行 diff 扫描）

• 逐行读 diff 的每一个 hunk；然后对每个 hunk，把其所在的整个函数读进来——这是原文特别强调的：被触碰函数中未改动行上的 bug 也在评审范围内（“the PR re-exposes or fails to fix them”：这次 PR 要么重新暴露了它们，要么本应修复却漏掉了）；
• 对每一行问同一个问题：什么输入、什么状态、什么时机、什么平台会让这一行出错？
• 原文给出了一张具体缺陷清单，逐项列举：倒置/写错的条件（inverted/wrong conditions）、差一错误（off-by-one）、null/undefined 解引用（null/undefined deref）、漏掉 await、把 falsy-zero 当缺失值（falsy-zero checks）、复制粘贴时拿错变量（wrong-variable copy-paste）、catch 中吞掉错误（error swallowed in catch）、未转义的正则元字符（unescaped regex metachars）。

Angle B — removed-behavior auditor（被删除行为的审计员）

这是三个角度中独辟蹊径的一个：它不看新增代码，而是看被删除或被替换的每一行——先问“这一行原来在维护什么不变量/行为”，再到新代码里搜索这个不变量在哪里被重新建立；如果找不到，那本身就是一个候选。原文列举的典型形态：被移除的 guard（防御检查）、被丢掉的错误处理路径（dropped error path）、被收窄的输入校验（narrowed validation）、以及“删掉的测试本来覆盖了一个真实场景”。这类“回归风险”在只看 + 行的常规 diff 审查中最容易被漏掉，把它单独设成一个视角，正是该提示词区别于人工 review 的结构性优势。

Angle C — cross-file tracer（跨文件追踪器）

对 diff 中每个被改动的函数：用 Grep 找到它的调用方（callers），检查本次变更是否破坏任何调用点——新的前置条件（new precondition）、返回结构变化（changed return shape）、新增异常（new exception）、时序/顺序依赖（timing/ordering dependency）；同时检查被调方（callees）：同一个 PR 里的并行修改，是否让这次调用变得不安全？

清理视角：Reuse / Simplification / Efficiency

原文用一句话区分了两组视角：“The angles above hunt for bugs; this one and the next two hunt for cleanup in the changed code.”（上面那些视角找 bug；这三个找改动代码里的清理点。）

Reuse（复用）

标记“重新实现代码库已有东西”的新代码——用 Grep 搜索共享/工具模块以及改动文件相邻的文件，并点名应该改调用的现有 helper。注意这个视角的产出不是模糊的“这里可能有重复”，而是要求给出可执行的替代目标。

Simplification（简化）

标记 diff 引入的不必要复杂度：冗余或可由别处推导的状态（redundant or derivable state）、带细微差异的复制粘贴（copy-paste with slight variation）、深层嵌套、遗留的死代码（dead code left behind），并且要指出能完成同样工作的更简形式。

Efficiency（效率）

标记 diff 引入的浪费性工作：冗余计算或重复 I/O、本可并行却被顺序执行的独立操作、加在启动路径或热路径上的阻塞工作。原文还包含一条颇有经验深度的规则：

由闭包或捕获环境构造的长生命周期对象——会让整个外层作用域在该对象存活期内保持存活（当该作用域持有大值时就是内存泄漏）；优先改为只拷贝所需字段的 class/struct。

最后同样要求“点名更便宜的替代方案”（Name the cheaper alternative）。

Altitude：检查修改是否在正确的深度

Altitude（实现深度/高度） 视角问的是：每处改动是否实现在了正确的层次，而不是贴了一块脆弱的“创可贴”（fragile bandaid）。原文的判断信号很具体：在共享基础设施上叠加特例（special cases）是“修得不够深”的标志——应优先泛化底层机制，而不是继续加特例。

这个视角管的是“结构性正确”而非“行为性正确”：即使行为完全正确，用特例补丁污染共享层，也会在未来所有走该层的代码上持续制造隐患。它与 Reuse/Simplification/Efficiency 一起构成清理组，但关注点从“这行代码”上升到“这一层架构”。

Conventions：CLAUDE.md 规范视角

Conventions (CLAUDE.md) 视角负责检查改动是否违反项目规范文件，原文给出了完整的 CLAUDE.md 发现规则：

1. 找出管辖被改动代码的所有 CLAUDE.md：用户级 ~/.claude/CLAUDE.md、仓库根目录的 CLAUDE.md，以及任何“位于某个被改文件的祖先目录”里的 CLAUDE.md 或 CLAUDE.local.md——并注明作用域规则：某目录的 CLAUDE.md 只作用于该目录下及更深层的文件；
2. 逐个读取存在的文件，然后检查 diff 是否明显违反其中明文写出的规则。

原文对违规判定设了很高的门槛：

Only flag a violation when you can quote the exact rule and the exact line that breaks it — no style preferences, no vague "spirit of the doc" inferences.

只有当你能同时引用出确切的规则原文和确切违反它的行时才允许报——不接受风格偏好，也不接受对“文档精神”的模糊推断。finding 中必须写明 CLAUDE.md 的路径并引用该规则，以便报告可以引用溯源。如果没有任何 CLAUDE.md 适用于本次改动，该视角返回空。

这一段把“规范检查”从常见 AI 评审的“自由发挥式挑刺”约束成了可引用、可复核的硬检查，与全文“每个候选都要有可引用证据”的一贯风格一致。

候选流转规则：宁过勿漏

Phase 1 末尾有两条对整条流水线至关重要的规则：

1. 三类非 bug 候选的写法约束：清理、altitude、conventions 候选使用同样的 file/line/summary 结构；但 failure_scenario 里写的不是崩溃，而是具体代价——重复了什么、浪费了什么、哪里更难维护、或违反了哪条 CLAUDE.md 规则。并且：当输出上限迫使截断时，正确性 bug 永远排在清理、altitude、conventions 之前（Correctness bugs always outrank cleanup, altitude, and conventions findings when the output cap forces a cut）。
2. 禁止 finder 自行丢弃候选：

Pass every candidate with a nameable failure scenario through — finders that silently drop half-believed candidates bypass the verify step and are the dominant cause of misses.

凡是能给出可命名失败场景的候选，一律放行给 Phase 2。原文明确指出：finder 悄悄丢弃“半信半疑”的候选，会绕过验证环节，是漏报（misses）的首要原因。这句话透露了该提示词对自身失效模式的判断——漏报不来自验证环节，而来自查找环节的自我审查。因此设计上把“筛”的职责完全后移给 Phase 2 的独立验证者，finder 只负责“捞”。

Phase 2 — Verify：单票验证与 recall-biased 判定

Phase 2 的标题是 Verify (1-vote, recall-biased)，流程为：

1. 去重：近重复（same defect, same location, same reason → 保留一个）合并；
2. 对每条剩余候选，通过 Agent 工具运行一个验证者（one verifier），把 diff、相关文件、该候选一起给它；它必须恰好返回三态之一：CONFIRMED / PLAUSIBLE / REFUTED；
3. 保留 CONFIRMED 与 PLAUSIBLE，丢弃 REFUTED。

与 medium.md 的三态细则不同，high 档对判定边界给出了方向性极强的两条规则：

PLAUSIBLE by default（默认按 PLAUSIBLE 处理）——当状态现实可达时，不得以“推测性”或“依赖运行时状态”为由否决候选。原文逐一举出应判为 PLAUSIBLE 的典型情形：

• 并发竞争（concurrency races）；
• 罕见但可达路径上的 nil/undefined（错误处理器、冷缓存、缺失的可选字段）；
• falsy-zero 被当成缺失值；
• 边界处的差一错误（代码并未排除该边界）；
• 重试风暴 / 部分失败（retry storms / partial failures）；
• 丢失了锚点的正则 / 白名单（regex/allowlist that lost an anchor）。

REFUTED 的判定必须能从代码中构造出来，且仅限四种情形：

1. 事实性错误（factually wrong）——引用实际的行证明；
2. 可证明不可能（provably impossible）——用类型/常量/不变量证明；
3. 本次 diff 中已处理（already handled in this diff）——引用那道 guard；
4. 纯风格、无任何可观测影响（pure style with no observable effect）。

对比之下，medium 档的 REFUTED 定义是“factually wrong (code doesn't say that) or guarded elsewhere”，判定口径明显更严。也就是说，high 与 medium 共用同一套“finder → 单票验证”机器，high 档通过放宽 REFUTED 门槛（必须能从代码中证明其不可能）+ 降低输出上限的松紧（≤10 vs ≤8），实现了从 precision 到 recall 的档位切换。

Output：JSON 数组是 high 档的输出契约

Phase 2 之后是 Output 段，high 档的输出契约原文如下：

[
  {
    "file": "path/to/file.ext",
    "line": 123,
    "summary": "one-sentence statement of the bug",
    "failure_scenario": "concrete inputs/state → wrong output/crash"
  }
]

配套规则：

• 返回至多 10 个对象的 JSON 数组；
• 按严重程度从高到低排序；超过 10 条时保留最严重的 10 条；
• 若没有候选通过验证，返回空数组 []；
• 即使 ReportFindings 工具可用，也不要调用它——本次评审的输出契约就是上面的 JSON 块。

最后一条值得展开。同一目录下的 report-findings-tool.md 定义了 ReportFindings 工具：它把 findings 作为带类型的列表上报，供宿主 UI 渲染（schema 中含 level、file、line、summary、short_summary（≤60 字符的紧凑标签）、failure_scenario、category、verdict（CONFIRMED/PLAUSIBLE）、outcome（fixed/skipped/no_change_needed）等字段，findings 上限 32 条）。从 code-review 目录 README 可见，ReportFindings 是“宿主 UI 能渲染带类型 findings”的会话才挂载的另一条输出通道，与 JSON 数组二选一。high 档提示词明确把自己钉死在 JSON 通道上，意味着该档位的设计目标是可被脚本/上层编排消费的结构化输出，而不是面向人直接阅读的散文。

high 档在五个档位中的位置：一组对照实验

把五个档位文件放在一起读，system_prompts_leaks 仓库提供的其实是一份“同一任务、五组超参”的对照实验。以 high 为中心对照：

维度	low	medium	high（本文）	xhigh / max
评审取向	—（仅抓 hunk 内可见 bug）	precision：每条都值得维护者处理	recall：一轮能抓到的都要抓到	recall，且“漏掉的 bug 会随版本发布（a missed bug ships）”
结构	1 次 diff 通读，无子 Agent、无验证	8 视角 × 6 候选 + 1-vote verify	8 视角 × 6 候选 + 1-vote verify（recall 偏向）	10 视角 × 8 候选 + 1-vote verify + 缺口扫描（sweep）
视角数	0（单 pass）	8	8	10（多出 D 语言陷阱专家、E 包装/代理正确性）
额外机制	跳过测试文件 hunk	三态验证细则	PLAUSIBLE by default 规则	多跑一个“只找未列出的缺陷”的 sweep finder（≤8 条新增）
输出上限	≤4，单行文本格式	≤8，JSON	≤10，JSON	≤15，JSON

几个值得注意的工程细节：

1. low 档连测试文件都不看——low.md 明确要求跳过 test/、spec/、__tests__/、*_test.*、*.test.*、fixtures/、testdata/ 下的 hunk，并且输出是 path:123 — 问题与具体失败 的单行文本而非 JSON。这展示了同一个 skill 如何在低档把 token 预算压到最低。
2. medium 与 high 共享全部 8 个视角，唯一实质性差异是开头的 recall/precision 宣言与 Phase 2 的判定口径（如前文所述）；换言之，“档位”在这套体系里是验证策略 + 输出上限的旋钮，而不是流程结构的旋钮。
3. **xhigh/max 的 10 视角在 high 的 8 视角之上只加了 D（language-pitfall specialist：JS falsy-zero、== 强转、闭包捕获循环变量；Python 可变默认参数、晚绑定闭包；Go nil-map 写入、range 变量捕获；SQL 注入；时区/DST 漂移；浮点相等）与 E（wrapper/proxy correctness：检查包装类型的每个方法都路由到被包装实例，而不是绕回 registry/session/global，例如缓存 provider 持有 delegate 字段却用 session.get(...) 解析 ID 会重入缓存或递归）。high 档不含这两个视角，这是它与 xhigh 在查找能力上的唯一差距。
4. max 与 xhigh 的正文完全相同，README 说明“only the API reasoning effort differs”（只有 API 层的 reasoning effort 不同）——即 max 档用同一份提示词换取更大的推理预算，而不是更长的提示词。

模型家族路由：high.md 只是 default 列

SKILL.md 的 frontmatter 描述中还有一句路由逻辑：“For ultra on a GitHub.com PR target, --post asks to post the finished review's findings to the PR as a single comment … while non-interactive mode posts on the flag alone”（ultra 档针对 GitHub PR 时 --post 的行为细节），说明 effort 之外的 flag 也会改变注入块。而 code-review 目录 README 指出：努力级别只是路由键的一半，模型家族是另一半。这五份文件（含 high.md）是矩阵中的 default 列——没有专属单元格的模型家族拿到的就是它们。二进制里还存在差异化单元格，例如：

• claude-sonnet-5 的 low 档使用一个变体，目标是 min(files, 4) 条 findings 而非固定上限 4；
• claude-opus-4-8 在 low–xhigh 各有自己的 o48-* 提示词，max 用共享版；
• claude-opus-5 的 medium 与 high 坍缩为同一个“最小提示词 → 单次仔细 diff 通读 → ≤15 findings、经 ReportFindings 上报”的单元格。

这解释了为什么仓库要同时保存 SKILL.md（frontmatter + default 正文）与独立的 high.md（同一正文、去掉 frontmatter）：前者是注册元数据，后者是注入用的纯正文。对读者的启示是：阅读这类提取出的提示词时，应同时确认它属于路由矩阵的哪一格——同一产品命令在不同模型上实际执行的提示词可能完全不同。

小结：这份 high 档提示词值得借鉴的四个设计

1. 把评审组织成流水线而非自由发挥：gather diff → 多视角并行找候选 → 单票三态验证 → 排序截断 → 固定 JSON 契约。每一阶段输入输出形状固定，便于审计和复现。
2. 视角分工覆盖 diff 的三种证据面：新增行（Angle A 逐行 + 全函数上下文）、删除行（Angle B 不变量审计）、影响面（Angle C 调用方/被调方追踪），再叠加清理与结构性视角。三者合起来接近“一个仔细的人工评审者会做的事”的上界。
3. 把筛选职责后移、禁止 finder 自我删减：finder 只需“能命名失败场景就放行”，是否成立交给独立验证者；而验证者的 REFUTED 门槛被刻意抬高（必须能从代码证明不可能），在 recall 档实现“PLAUSIBLE by default”。
4. 输出契约与工具解耦：明确“即使 ReportFindings 可用也不要调用”，把本档的输出钉死为 ≤10 条的 JSON 数组——提示词层面直接约束了工具选择，避免同一会话里两条输出通道互相干扰。

以上所有原文措辞与数字均可在 high.md 中逐行核对，档位间差异可对照 low.md、medium.md、xhigh.md、max.md 及 report-findings-tool.md，路由与提取背景见 code-review 目录 README。