Claude Code/code-review提示词深度解析:八视角候选发现与单票召回偏置验证的完整流水线
【免费下载链接】system_prompts_leaksExtracted system prompts from Anthropic - Claude Fable 5, Opus 5, Claude Design, Claude Code. OpenAI - ChatGPT GPT-5.6-Sol, Codex. Google - Gemini 3.5 Flash, 3.1 Pro, Antigravity. xAI - Grok, Cursor, Copilot, VS Code, Perplexity, and more. Updated regularly.项目地址: https://gitcode.com/GitHub_Trending/sy/system_prompts_leaks
本文以system_prompts_leaks仓库中提取的 Claude Code 内置代码审查技能提示词 SKILL.md 为核心,完整还原其「high effort」档审查流水线的三个阶段——Git diff 采集、8 个独立 Finder 视角、1 票召回偏置验证——并输出契约;同时结合同目录的 low.md、medium.md、xhigh.md、max.md 与 README.md,梳理五档 effort 的完整路由体系。读完本文,你将掌握一套可直接借鉴到自建 Agent 代码审查流程中的多视角候选发现 + 独立验证 + 结构化输出的工程范式。
一、技能定位:一个以 diff 为输入、以 JSON 为输出的审查协议
code-review是 Claude Code 编译进二进制、运行时以 user-message 块形式注入对话的内置 slash 命令提示词。其注册 frontmatter(SKILL.md#L1-L4)完整定义了命令的行为契约:
name: code-review description: Review the current diff, or a PR number/branch/path target, for correctness bugs and reuse/simplification/efficiency cleanups at the given effort level (low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings; ultra: deep multi-agent review in the cloud); with no level given, it reuses the level you typed last. Pass --comment to post findings as inline PR comments, or --fix to apply the findings to the working tree after the review. For ultra on a GitHub.com PR target, --post asks to post the finished review's findings to the PR as a single comment ... and --no-post hides that option.由此可以归纳出四个关键行为要素:
| 要素 | 取值 / 行为 |
|---|---|
| effort 档位 | low/medium/high(默认)/xhigh/max;另有ultra(云端多 Agent 审查) |
| 审查目标 | 当前 diff(默认),或传入的 PR 编号 / 分支名 / 文件路径 |
| 级别缺省策略 | 不传档位时,复用上一次输入的档位 |
| 后置动作 | --comment将 findings 以行内 PR 评论发布;--fix在审查后将修复应用到工作树;ultra 档对 GitHub.com PR 目标支持--post/--no-post控制结果回写 |
frontmatter 中「low/medium: fewer, high-confidence findings; high→max: broader coverage, may include uncertain findings」这句话是理解整套设计的钥匙:档位不只是控制工作量,而是切换 precision(精确率)与 recall(召回率)的权衡方向。这一点在正文第一行得到直接印证:
`high effort → 3+5 angles × 6 candidates → 1-vote verify (recall-biased) → ≤10 findings`即 high 档的流水线为:3 个正确性视角 + 5 个清理/深度视角,每个视角最多产出 6 个候选发现,经 1 票验证(召回偏置)后,最终输出不超过 10 条按严重度排序的 findings。
二、Phase 0 —— 采集 diff:审查范围的确定协议
流水线的第 0 阶段(SKILL.md#L12-L19)规定了审查范围的采集方式,这是一个可以直接照搬的实操细节:
- 优先执行
git diff @{upstream}...HEAD获取统一 diff; - 若当前分支没有 upstream,则退化为
git diff main...HEAD或git diff HEAD~1; - 若存在未提交更改,或范围 diff 为空,必须追加
git diff HEAD,把工作树变更纳入范围——因为「审查往往发生在提交之前」; - 若调用时传入了 PR 编号、分支名或文件路径,则改为审查该目标。
这段协议的工程含义在于:它显式承认了 pre-commit 审查场景(此时git diff main...HEAD可能为空,真正要审的是工作树),并用「追加而非替换」的方式把两类变更合并进同一审查范围。后文 low.md 与 medium.md 的 Phase 0 与此逐字一致,说明 diff 采集是所有档位共享的固定前置步骤。
三、Phase 1 —— 八个独立的 Finder 视角
Phase 1(SKILL.md#L21-L101)是整份提示词的核心:通过 Agent 工具并行运行8 个相互独立的 finder 视角,每个视角独立产出最多 6 个候选发现,每个候选必须携带file、line、一行summary和一个具体的failure_scenario(可命名失败场景)。若当前工具集中没有 Agent 工具,提示词明确要求「不要报错——在当前上下文中顺序地自行完成每个视角(和每次验证)」,即流水线降级为单进程串行模式而不中断。
8 个视角可分为三类:
3.1 正确性视角(Angle A/B/C):找真 bug
Angle A —— 逐行 diff 扫描。逐 hunk 阅读 diff 的每一行,然后读取每个 hunk 所在的外层函数——即使未改动的行只要在触及函数内,也属于审查范围(因为 PR 可能重新暴露或未能修复其中的 bug)。对每一行追问一个固定问题:「什么输入、状态、时序或平台会让这一行出错?」并给出八类高频缺陷清单:
- 反转 / 错误条件(inverted/wrong condition)
- 差一错误(off-by-one)
- null/undefined 解引用
- 缺失
await - falsy-zero 检查(把
0/""/false当作「不存在」处理) - 错误变量的复制粘贴
- catch 中吞掉本应传播的错误
- 未转义的正则元字符
Angle B —— 被删除行为的审计员。对 diff 中每一行被删除或替换的代码,先命名它所维护的不变量或行为,再在新代码中搜索该不变量在哪里被重新建立;找不到即构成候选——被移除的守卫、被丢弃的错误路径、被收窄的校验、被删掉且原本覆盖真实场景的测试,都属于此类。这个视角针对的是代码审查中最容易被逐行扫描遗漏的「回归型」缺陷。
Angle C —— 跨文件追踪器。对 diff 修改的每个函数,Grep 其符号找出所有调用方,检查变更是否破坏任何调用点:新增前置条件、返回形状改变、新异常、时序/顺序依赖;同时检查被调用方——同一 PR 中的并行修改是否使某个调用变得不安全。
3.2 清理视角(Reuse / Simplification / Efficiency):找技术债
这三个视角不找 bug,而是找「改动引入的清理机会」,且都要求给出替代方案:
- Reuse(复用):标记重新实现了代码库已有功能的新代码——要求 Grep 共享/工具模块与变更邻近文件,并点名应当改调用的既有 helper。
- Simplification(简化):标记 diff 引入的不必要复杂度:冗余或可推导的状态、略有差异的复制粘贴、深层嵌套、遗留死代码;要求点名能完成同样工作的更简形式。
- Efficiency(效率):标记浪费的工作:冗余计算或重复 I/O、本可并行的独立操作串行执行、启动或热路径上新增的阻塞工作。其中有一段颇具洞察力的规则:由闭包或捕获环境构造的长生命周期对象会让整个外层作用域在对象存活期间保持存活(当作用域持有大值时即为内存泄漏),应优先选择只拷贝所需字段的类/结构体。
3.3 深度视角(Altitude)与规范视角(Conventions)
Altitude(深度):检查每处修改是否实现在正确的抽象层,而不是脆弱的创可贴式修补。「在共享基础设施上叠加特例」是修复深度不够的信号——提示词要求优先泛化底层机制,而不是继续添加特例。
Conventions(CLAUDE.md 规范):定位管辖被改代码的 CLAUDE.md 文件——用户级~/.claude/CLAUDE.md、仓库根 CLAUDE.md,以及变更文件任意祖先目录下的 CLAUDE.md / CLAUDE.local.md(目录的 CLAUDE.md 只对其自身及以下文件生效)。读完每一份存在的文件后,检查 diff 是否存在明确违规。该视角有严格的证据门槛:
只有能逐字引用规则原文并指出被破坏的具体行时才能标记违规——不接受风格偏好,不接受对「文档精神」的模糊推断。finding 中必须写明 CLAUDE.md 的路径并引用规则原文,以便报告可被溯源;若没有适用的 CLAUDE.md,该视角返回空。
3.4 候选的准入与优先级规则
三个非正确性视角(cleanup / altitude / conventions)的候选与正确性候选共用同一file/line/summary形状,但failure_scenario里陈述的是具体代价(重复了什么、浪费了什么、为什么更难维护、或违反了哪条 CLAUDE.md 规则)而非崩溃。两条全局规则贯穿 Phase 1(SKILL.md#L93-L101):
- 正确性 bug 永远优先:当输出上限迫使裁剪时,正确性发现永远排在清理、深度与规范发现之前;
- 禁止 Finder 静默丢弃候选:凡能命名失败场景的候选一律放行——因为「finder 悄悄丢弃半信半疑的候选、从而绕过验证步骤,正是漏报的主要原因」。
第 2 条是整个流水线设计哲学的关键:与其让 finder 在不确定时自行裁掉候选,不如全部提交给下一阶段的独立验证者裁决。
四、Phase 2 —— 单票验证:召回偏置的三态裁决
Phase 2(SKILL.md#L103-L121)对候选先做去重——同一缺陷、同一位置、同一原因只保留一条——然后对每个剩余候选运行一个验证者(via Agent 工具),输入为 diff、相关文件与候选本身,输出恰好三态之一:CONFIRMED/PLAUSIBLE/REFUTED。
high 档与 xhigh.md / max.md 共用同一套三态定义,而 medium 档(medium.md#L97-L111)的裁决标准则更严格。high 档的验证规则有两点特别值得注意:
PLAUSIBLE 是默认出口——不得以「过于推测」或「依赖运行时状态」为由否决一个候选,只要该状态是现实可达的。提示词列举了六类必须判为 PLAUSIBLE 的场景:
- 并发竞态
- 稀有但可达路径上的 nil/undefined(错误处理器、冷缓存、缺失的可选字段)
- falsy-zero 被当作缺失处理
- 代码未排除的边界上的差一错误
- 重试风暴 / 部分失败
- 丢失锚点的正则 / 白名单
REFUTED 只在能从代码本身构造证明时成立,且必须属于四种情形之一:事实错误(引用实际行)、可证不可能(类型/常量/不变量——需展示)、本 diff 中已处理(引用守卫代码)、或纯风格且无可观测影响。
最终保留CONFIRMED 与 PLAUSIBLE,丢弃 REFUTED。对照 medium 档的表述——「You are reviewing forprecision... every finding you surface should be one a maintainer would act on」——high 档开头那句「You are reviewing forrecall... catching real bugs matters more than avoiding false positives. Err on the side of surfacing」形成清晰对照:档位切换的本质,是验证者裁决阈值在 precision 与 recall 之间的移动,而非简单地增减工作量。
五、输出契约:≤10 条的 JSON 数组
Output 阶段(SKILL.md#L123-L141)规定了本技能的输出契约——一个最多 10 个对象的 JSON 数组:
[ { "file": "path/to/file.ext", "line": 123, "summary": "one-sentence statement of the bug", "failure_scenario": "concrete inputs/state → wrong output/crash" } ]契约的完整规则为:按严重度降序排列;超过 10 条时只保留最严重的 10 条;若没有任何候选通过验证,返回[];即使ReportFindings工具可用也不得调用——本审查的输出契约就是上述 JSON 块。
这里存在一个值得注意的「双通道」设计:同目录的 report-findings-tool.md 给出了ReportFindings工具的完整 JSON Schema(level枚举五档、findings最多 32 项、每项必含file/summary/failure_scenario,另可选short_summary(≤60 字符,供紧凑 UI 渲染)、category(kebab-case 类型标签)、verdict(CONFIRMED/PLAUSIBLE)、outcome(fixed/skipped/no_change_needed,仅修复后重报时填写))。它是供宿主 UI 渲染类型化 findings 的替代输出通道;而本 SKILL 明确排除了它,说明「JSON 数组走文本」与「工具调用走 UI」是同一套 findings 模型的两种序列化方式。
六、五档 effort 全景:high 档在路由矩阵中的位置
README.md 提供了五档流水线与SKILL.md的关系,以及模型维度的路由规则。各档提示词文件均已提取在本仓库中,其头部流水线摘要可直接作为对照证据:
| 档位 | 流水线(各文件头部原文) | 上限 |
|---|---|---|
| low.md | 1 diff pass → no verify → ≤4 findings:单次读取 + 单次产出,跳过测试 hunk(test/、__tests__/、fixtures/等),只看 hunk 内即可判定的运行时正确性 bug,明确不标记风格/命名/性能/缺测试 | ≤4 条 |
| medium.md | 3+5 angles × 6 candidates → 1-vote verify → ≤8 findings:与 high 相同的 8 视角,但验证为precision-tuned(三态定义更严:REFUTED 含「事实错误或他处已守卫,需引用证明行」) | ≤8 条 |
| high.md / SKILL.md | 3+5 angles × 6 candidates → 1-vote verify (recall-biased) → ≤10 findings:默认档 | ≤10 条 |
| xhigh.md | 5+5 angles × 8 candidates → 1-vote verify → sweep → ≤15 findings:新增 Angle D(语言陷阱专家,如 JS falsy-zero /==强转、Python 可变默认参数 / 晚绑定闭包、Go nil-map 写入、浮点相等)与 Angle E(包装器/代理正确性,检查方法是否路由到被包装实例而非经 registry/session/全局回环),并在 Phase 2 后增加Phase 3 缺口清扫——由一名持有已验证清单的「新审查者」再扫一遍,只找清单外的缺陷,最多补 8 条 | ≤15 条 |
| max.md | 与 xhigh 相同的 10 视角 + 验证 + 清扫结构,README 说明「identical to xhigh except header wording」,仅 API 推理 effort 参数不同 | ≤15 条 |
几个结构性观察:
SKILL.md与high.md的关系:SKILL.md= 技能注册 frontmatter + 默认(high)档正文,high.md是去掉 frontmatter 的同一正文。- 视角集合是档位的显式变量:low 无子 Agent 无验证;medium/high 为 8 视角(A/B/C + Reuse/Simplification/Efficiency/Altitude/Conventions);xhigh/max 扩展为 10 视角(+D 语言陷阱、+E 包装器正确性),并且每个视角候选上限从 6 提到 8,xhigh/max 还额外要求「不要让一个视角的结论压制另一个——两个视角因不同原因标记同一行时,两条都记录」。
- 模型族是路由的另一半键:README 指出五档文件只是路由矩阵中的
default列。二进制中的矩阵还为特定模型族携带了差异化单元格:claude-sonnet-5:low档改用按min(files, 4)定数的变体,而非固定上限 4;claude-opus-4-8:low–xhigh 使用专属的o48-low/med/high/xhigh提示词,max共用共享版;claude-opus-5:medium与high合并收敛为单一「极简提示词 → 单次细致 diff 通读 → ≤15 findings」单元格,且经由ReportFindings上报;xhigh复用 opus-4-8 的 xhigh 单元格;low与max用共享版。- 此外每档都有无 Agent 工具的降级路径:Agent 工具缺席时,同样的视角在单进程内单遍运行,且没有子 Agent 验证。
- 二进制中还有未收录的兄弟变体:以
ReportFindings工具调用替代 JSON 数组的输出模式、工件发布步骤(findings 渲染为可分享 HTML 页)、以及启用 workflows 时 high/xhigh/max 采用的 workflow 编排(每个正确性视角一个 finder、一个合并的清理 finder、每个 distinct file:line 一个验证者、最后综合)。
这些说明该技能的生产形态是一个「effort × 模型族」二维路由矩阵,仓库中的六个文件是其中default列的完整快照。
七、设计启示:可复用的 Agent 审查工程模式
把 SKILL.md 从一份提示词抽象为一套工程方法,可以提炼出五条可迁移的模式:
- 候选发现与验证职责分离:finder 只负责「能命名失败场景就放行」,验证者独立裁决三态。这消除了单 Agent 自审时「先入为主、静默丢弃」的漏报主因,等价于把 review 与 re-review 做成两个不共享心智模型的 pass。
- 验证阈值参数化:同一套三态验证,仅靠改写裁决标准(medium 的 precision 表述 vs. high 的「PLAUSIBLE by default + 六类现实可达场景清单」)即可切换精确率/召回率取向,而无需改动视角定义——提示词本身就是配置。
- 视角正交化:逐行扫描、删除审计、跨文件追踪、语言陷阱、包装器正确性、复用、简化、效率、深度、规范——十个视角各自覆盖一类缺陷成因,且 xhigh/max 显式禁止视角间相互压制,最大化候选多样性。
- 证据门槛分级:正确性 bug 要求「具体输入/状态 → 错误输出/崩溃」;规范违规要求「规则原文 + 被破坏行」双引用;REFUTED 要求「从代码可构造证明」。每条发现都必须可被第三方复核。
- 上限 + 排序 + 空集约定:
≤N findings、严重度降序、无结果返回[]——为下游(PR 评论器、修复 Agent、UI 渲染器)提供稳定可解析的输出契约,而非自由文本。
适用前提与限制:本文内容基于该仓库对 Claude Code 2.1.245 捆绑包的提取与字节级核对(见 README.md 的提取说明),反映的是特定版本二进制的提示词内容;--comment/--fix/--post等运行行为以 Claude Code 官方实际版本为准,且ultra档为云端多 Agent 审查,本仓库未包含其提示词正文。
参考文件清单
| 文件 | 内容 |
|---|---|
| Anthropic/claude-code/skills/code-review/SKILL.md | 技能注册 frontmatter + high 档(默认档)正文,本文主分析对象 |
| Anthropic/claude-code/skills/code-review/high.md | high 档正文(无 frontmatter) |
| Anthropic/claude-code/skills/code-review/low.md / medium.md / xhigh.md / max.md | 其余四档提示词,档位对照依据 |
| Anthropic/claude-code/skills/code-review/report-findings-tool.md | ReportFindings工具描述 + JSON Schema(类型化输出通道) |
| Anthropic/claude-code/skills/code-review/README.md | 提取说明、五档路由表、模型族路由矩阵 |
【免费下载链接】system_prompts_leaksExtracted system prompts from Anthropic - Claude Fable 5, Opus 5, Claude Design, Claude Code. OpenAI - ChatGPT GPT-5.6-Sol, Codex. Google - Gemini 3.5 Flash, 3.1 Pro, Antigravity. xAI - Grok, Cursor, Copilot, VS Code, Perplexity, and more. Updated regularly.项目地址: https://gitcode.com/GitHub_Trending/sy/system_prompts_leaks
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考