Claude Code `/code-review` 中等强度审查提示词全解：8 个查找角度、单票三态验证与 ≤8 条精确发现

system_prompts_leaks 仓库收录了从 Claude Code 二进制中逐字提取、并经 MITM 抓包字节校验的系统提示词。本文以 medium.md 为核心素材，完整拆解 Claude Code 内置 /code-review 命令在 medium（中等强度）档位下的审查流水线：Phase 0 如何圈定 diff 范围、Phase 1 用哪 8 个独立“查找角度”各产出至多 6 条候选、Phase 2 如何用一次三态投票（CONFIRMED / PLAUSIBLE / REFUTED）做精确调优的验证，以及最终 ≤8 条 JSON 发现的输出契约。读完本文，你能掌握一条可直接复用的“精确优先”代码审查提示工程范式，并理解它与 high 档“召回优先”范式的核心差异。

1. 这份提示词在 Claude Code 中的位置

SKILL.md 的 frontmatter 描述了该技能的注册信息：/code-review 用于审查当前 diff，或 PR 号 / 分支 / 路径目标，在给定强度档位（low/medium/high/xhigh/max/ultra）下查找正确性缺陷与复用、简化、效率类清理项；--comment 将发现以行内 PR 评论形式发出，--fix 在审查后把修复应用到工作区。

按 README 的说明，这些模板被编译进 Claude Code 二进制，命令执行时以 user-message 块的形式注入会话；有参数时，注入块会先带一行 Review target: <args> 再加空行，无参数时直接从强度头开始。五个档位对应的流水线在 README 中有汇总：

文件	流水线
low.md	1 次 diff 通读，无子代理、无验证 → ≤4 条发现
medium.md	8 个查找角度 × 6 条候选，单票验证（精确调优）→ ≤8 条发现
high.md	8 个查找角度 × 6 条候选，单票验证（召回偏置）→ ≤10 条发现，默认档
xhigh.md	10 个查找角度 × 8 条候选，验证 + 缺口扫查 → ≤15 条发现
max.md	与 xhigh 仅头部措辞不同，实际差异只在 API 推理 effort

需要指出的一个细节：README 提到实际注入哪个提示词由“强度档位 + 模型家族”两个键共同决定。上表是 default 列；从 README 的路由矩阵看，claude-opus-5 家族下 medium 与 high 会坍缩为同一个“最小提示词 → 单次仔细 diff 通读 → ≤15 条发现”的单元格，并通过 ReportFindings 上报；claude-sonnet-5 的 low 则改为目标 min(files, 4) 条。也就是说，本文分析的 medium 文本是“默认模型家族在 medium 档”收到的版本，特定模型家族可能拿到不同单元格。

medium.md 全文第一行就是它的自我定位：

`medium effort → 3+5 angles × 6 candidates → 1-vote verify → ≤8 findings`

并给出与 high 档截然不同的总纲——medium 追求的是精确（precision）：“你正在以中等强度做精确审查：你提出的每一条发现都应该是维护者会真正去处理的”；而 high.md 对应的是召回（recall）：“在这个档位，抓住真 bug 比避免误报更重要，宁可多报”。这是理解整份提示词所有设计决策的钥匙。

2. Phase 0：圈定审查范围（Gather the diff）

medium.md 的 Phase 0 给出了一段几乎可以原样搬进任何 CI 流程的 diff 收集规程：

1. 首选执行 git diff @{upstream}...HEAD 拿到统一 diff（unified diff）作为审查对象；
2. 若没有 upstream，退化为 git diff main...HEAD 或 git diff HEAD~1；
3. 若存在未提交改动、或范围 diff 为空，则额外执行 git diff HEAD，把工作区改动纳入范围——提示词明确解释了原因：“审查常常发生在 commit 之前”；
4. 若调用时传入了 PR 号、分支名或文件路径，则改为审查该目标；
5. 以上得到的 diff 即为审查边界（“Treat this diff as the review scope”）。

这段逻辑的关键工程点在于“已提交 + 未提交”的并集处理：只取 @{upstream}...HEAD 会漏掉尚未提交的工作区修改，而很多审查正是在本地改完、还没 push 时发起的。high、xhigh、max 三个档位的 Phase 0 文本与 medium 完全一致，说明范围圈定是档位无关的公共前置步骤，差异全部体现在候选查找与验证策略上。

3. Phase 1：8 个独立查找角度 × 至多 6 条候选

medium 的 Phase 1 标题即 3 correctness angles + 3 cleanup angles + 1 altitude angle + 1 conventions angle, up to 6 each，要求通过 Agent 工具运行 8 个独立查找角度（finder angles），每个角度产出至多 6 条候选发现，每条候选必须带四要素：file、line、一行 summary、以及具体的 failure_scenario。

提示词还内置了一个降级条款：如果当前工具集里没有 Agent 工具，“不要报错——由你自己在本上下文中顺序执行每个角度（以及每次验证）”。结合 README 中“每个档位都有无 Agent 工具的后备路径：同一组角度内联单遍执行，无子代理验证”的表述，可以推断这一设计让同一份提示词既能驱动多子代理编排，也能退化为单模型自洽执行，保证了行为下限。

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

规则是：逐行读取 diff 中每个 hunk，然后读出每个 hunk 所在的整个函数——被触碰函数内未改动行的 bug 同样在审查范围内，理由是“PR 要么重新暴露了它，要么本该修掉它却漏了”。对每一行都要自问：“什么输入、状态、时序或平台会让这行出错？”并给出了一份检查清单：条件写反、off-by-one、null/undefined 解引用、漏写 await、falsy-zero 判断（把 0 当空值）、复制粘贴错变量、catch 中吞掉本应向上抛的错误、未转义的正则元字符。

其中“把未改动行纳入范围”是一条容易被忽略但很实用的边界规则：它让审查的粒度从“diff 行”提升到“被触碰函数”，避免“我只改了三行，所以只看三行”的盲区。

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

对 diff 中每一行被删除或替换的代码，先说出它原本维护的不变量（invariant）或行为，再到新代码中搜索这个不变量在哪里被重新建立；如果找不到，就是候选。提示词列举的典型情形：被移除的守卫条件、被丢掉的错误处理路径、被收窄的输入校验、被删掉且原本覆盖真实用例的测试。

这个角度针对的是 diff 审查中最隐蔽的一类问题——删除行本身不“看起来错”，但它承载的约束可能悄悄消失。它把“审计删除”从凭感觉变成了有固定动作（命名不变量 → 搜索重建位置）的流程。

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

对 diff 改动的每个函数，用 Grep 找到它的调用方，检查本次改动是否破坏任何调用点：新增前置条件、返回值形状变化、新增异常、时序/顺序依赖；同时向下检查被调方——同一个 PR 里的并行改动是否让某个调用变得不安全。

这是三个正确性角度中唯一显式要求“离开当前文件”的角度，对应提示词中“Grep the symbol”这类工具级指令，说明该提示词是面向具备文件检索工具的执行环境编写的。

3.4 Reuse — 重复造轮子

“上面几个角度找的是 bug；这一个和接下来的两个找的是改动代码中的清理项。”规则：标记新代码中重新实现了代码库已有能力的部分——用 Grep 搜共享/工具模块和改动邻近文件，并指名应改调用的现有 helper。注意约束：只针对 diff 引入的新代码，不是全库审计。

3.5 Simplification — 冗余复杂度

标记 diff 引入的不必要复杂度：冗余或可推导的状态、带轻微变体的复制粘贴、深层嵌套、遗留的死代码，并要求“指名那个能完成同样工作的更简单形式”——即发现必须附带可操作的替代方案，而非一句“这里太复杂”。

3.6 Efficiency — 浪费的工作

标记 diff 引入的浪费：重复计算或重复 I/O、本可并行却被串行的独立操作、加到启动路径或热路径上的阻塞工作。还有一条专门针对闭包的规则值得单独看：由闭包或捕获环境构建的长生命周期对象会让整个外层作用域在整个对象生命周期内保持存活——当外层作用域持有大值时这就是内存泄漏，建议改为只拷贝所需字段的 class/struct。最后同样要求“指名更便宜的替代方案”。

3.7 Altitude — 修复深度是否合适

检查每处改动是否实现在正确的抽象深度上，而不是脆弱的创可贴（bandaid）。判据很具体：“在共享基础设施上叠加特殊分支，是修复深度不够的信号”——正确做法是泛化底层机制，而不是继续加特例。这是 8 个角度中唯一不指向具体代码缺陷、而指向“设计层面是否选对位置”的角度。

3.8 Conventions — CLAUDE.md 规约检查

这个角度的规则最有“可验证性”设计，值得完整继承：

• 查找管辖改动代码的 CLAUDE.md 文件：用户级 ~/.claude/CLAUDE.md、仓库根 CLAUDE.md，以及改动文件所在目录链上每个祖先目录中的 CLAUDE.md 或 CLAUDE.local.md（某目录的 CLAUDE.md 只作用于该目录下及更深的文件）；
• 逐份读取存在的文件，再对照 diff 找明确违反其规则之处；
• 只有能同时引用确切的规则原文和违规的确切行号时才标记——不接受风格偏好、不接受对“文档精神”的模糊推断；
• 发现中必须写明 CLAUDE.md 路径并引用规则原文，让报告可以出处化；若没有任何 CLAUDE.md 适用，该角度返回空。

这套“可引用才成立”的门槛与第 4 节验证阶段的引用要求一脉相承，是精确调优在规约维度上的落地。

3.9 候选的传递规则与优先级

三个清理类角度（Reuse / Simplification / Efficiency）加上 Altitude 和 Conventions，产出的是与 bug 相同的 file/line/summary 形状，但 failure_scenario 字段的内容定义不同：不写崩溃，而是写具体代价——重复了什么、浪费了什么、维护上难在哪，或违反了哪条 CLAUDE.md 规则。

两条全局规则：

1. 优先级：当输出上限（8 条）迫使裁剪时，正确性 bug 永远排在清理、altitude、conventions 类发现之前；
2. 禁止静默丢弃：“所有能说出可命名 failure scenario 的候选都必须传递下去——静默丢弃半信半疑候选的 finder 会绕过验证步骤，是漏报的主要原因（the dominant cause of misses）。”

第二条是整份提示词中最反直觉的设计：它明令禁止 finder 阶段自我过滤。因为 medium 是精确档，若允许 finder 凭感觉丢候选，被丢掉的半信候选就永远不会进入验证器，精确性反而被自我审查破坏；正确做法是“宽进”候选、靠 Phase 2 的验证做“严出”。

4. Phase 2：单票三态验证（1-vote, 3-state）

Phase 2 分两步。

去重：对指向同一行/同一机制的候选去重，保留 failure_scenario 最具体的那一条。

验证：对每条剩余候选，通过 Agent 工具运行一个验证器（one verifier），给它 diff、相关文件、候选本身，要求它恰好返回三者之一：

判定	含义	必须附带的证据
CONFIRMED	能说出触发它的输入/状态以及错误的输出或崩溃	引用（Quote）相关代码行
PLAUSIBLE	机制真实存在，但触发条件不确定（时序、环境、配置）	说明什么证据能把它坐实
REFUTED	事实错误（代码并非如此）或他处已有防护	引用能证明这一点的那一行

规则是保留 CONFIRMED 与 PLAUSIBLE，丢弃 REFUTED。

这里的三态设计比常见的“真/假”二分类更细：PLAUSIBLE 单独成态，且每个态都强制要求引用代码行作为证据锚点（CONFIRMED 引触发行、REFUTED 引反证行、PLAUSIBLE 说明坐实条件）。这让“验证”这个动作本身变得可审计——验证结论不是自由文本判断，而是绑定到具体行号的。

4.1 与 high 档验证策略的关键差异

对照 high.md 的 Phase 2 可以看到精确/召回的分野：

• high 的验证器是召回偏置的：默认 PLAUSIBLE，明确列出“不得以‘过于推测’或‘依赖运行时状态’为由拒绝”的情形——并发竞态、稀有但可达路径上的 nil/undefined、falsy-zero 被当缺失、代码未排除边界上的 off-by-one、重试风暴/部分失败、丢失锚点的正则/白名单——这些都是 PLAUSIBLE；REFUTED 仅限于“可从代码构造出来”的反证（引用实际行、类型/常量/不变量证明不可能、本 diff 已处理、或无可观察效果的纯风格问题）；
• medium 的验证器则是中性的三态：没有“默认 PLAUSIBLE”的偏置条款，PLAUSIBLE 的定义收紧为“机制真实、触发不确定”，且 REFUTED 分支更宽（“事实错误或他处已有防护即拒绝”）。

也就是说，medium 档验证器被允许以“他处已防护”为由拒绝候选，而 high 档要求引用本 diff 内的守卫才算处理过；medium 不兜底“半信”候选，high 明确“单个非 REFUTED 票即带出该发现，不因不确定而丢弃（Do NOT drop on uncertainty）”。这就是“1-vote verify”在两个档位上参数化的含义：投票机制相同，判定阈值不同。

5. Output：≤8 条 JSON 发现与输出契约

medium 档的最终输出契约是至多 8 个对象的 JSON 数组，按严重度从高到低排序；超过 8 条时保留最严重的 8 条；若没有任何候选通过验证，返回 []。对象形状：

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

四个字段各有约束：file 定位到文件，line 锚定到行（与验证阶段的引用要求呼应），summary 限定为一句缺陷陈述，failure_scenario 必须是“具体输入/状态 → 错误输出/崩溃”的形式——这与 Phase 1 “能说出可命名 failure scenario 才传递”的规则形成闭环：没有具体失败场景的候选在入口就被拦下，有场景的候选在出口仍以场景形式交付。

契约中最后有一句硬性约束：“即使 ReportFindings 工具可用，也不要调用它——本次审查的输出契约就是上面的 JSON 块。”对照 report-findings-tool.md 可以看到，ReportFindings 是该技能体系里的另一条上报通道：类型化发现列表（含 level、short_summary、category、verdict、outcome 等字段，findings 上限 32 条），供宿主 UI 渲染结构化审查结果，且描述中写明“仅当当前 code-review 指令要求用它上报时才使用”。medium 档明确选择 JSON 数组通道，说明两个通道的启用与否由具体档位提示词单方决定，提示词之间靠这种显式互斥条款避免双通道同时输出。

6. 从这份提示词能提炼的提示工程范式

把 medium.md 通读下来，它本质上是一份“单模型 + 可选多子代理”的精确型审查协议，几个设计决策可以独立借鉴：

1. 档位化流水线参数：angles × candidates → verify → cap 这一行头部（3+5 angles × 6 candidates → 1-vote verify → ≤8 findings）把整条流水线的量化参数压缩成一行，让不同档位（low 的 1 遍无验证 ≤4、high 的 ≤10、xhigh/max 的 10 角度 ×8 候选 + 缺口扫查 ≤15）共享同一套 Phase 结构、只调参数和判定阈值。对比 low.md 的“两轮式”（Turn 1 读、Turn 2 出）与 xhigh.md 多出的 Angle D（语言陷阱专家）、Angle E（包装/代理正确性）和 Phase 3（对已验证清单之外的缺口再扫一遍），可以看到强度档位是通过增减角度、候选上限和验证阶段来实现的，而非另写一套流程；
2. finder / verifier 职责分离 + 宽进严出：finder 被明令禁止自我过滤（防漏报），verifier 承担全部过滤职责，且投票附行号引用（防幻觉）；
3. 精确与召回是两个可调方向：medium 与 high 的 Phase 0/1 几乎逐字相同，真正的差异集中在验证阈值（是否默认 PLAUSIBLE、REFUTED 的宽严）和输出上限（8 对 10）——这说明“召回优先”可以通过放宽验证端实现，而不必增加查找开销；
4. 降级条款保证可移植性：无 Agent 工具时内联顺序执行，让提示词在“多子代理编排”和“单模型自洽”两种运行形态下都有明确行为。

7. 复现与延伸阅读

想在本地对照这份提示词做实验，可用的路径都在当前仓库内：

• 档位全文对照：low.md、medium.md、high.md、xhigh.md、max.md；
• 技能注册信息与默认档（high）正文：SKILL.md；
• 目录 README 中的提取方法、档位矩阵与模型家族路由说明：README；
• 结构化上报通道的完整 JSON Schema：report-findings-tool.md；
• Claude Code 各模型的系统提示词上下文：Anthropic/claude-code 目录。

适用前提需要说明：这些文本是从 Claude Code 二进制提取并对照 2.1.245 包（2026-08-25 复核）字节校验的结果，描述的是该版本命令注入提示词的实际内容；具体会话实际收到哪一份文本，还取决于当时的模型家族路由（见第 1 节），且仓库中的文本随 Claude Code 版本更新可能变化，引用时应以仓库当前内容为准。