- 文档
- 提示工程
- 人工智能
【免费下载链接】claude-code-system-prompts
All parts of Claude Code's system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.
/code-review是 Claude Code 内置的代码审查斜杠命令，默认情况下它以"审查报告"收尾：产出经过验证的发现清单后停止。而当用户传入--fix标志时，命令的行为会发生质变——从"报告问题"转向"直接修复问题"。本文以开源仓库 claude-code-system-prompts 中维护的 Agent Prompt: /code-review part 9 fix application 为核心，结合仓库内与之配套的审查提示词（finder 阶段、验证阶段、ReportFindings 输出格式、--comment模式）与 CHANGELOG 中的演进记录，完整解析--fix模式的行为契约、跳过判据、收尾汇报方式及其在整条审查流水线中的位置，帮助读者理解 Claude Code 如何在一次命令中完成"发现—验证—修复—汇报"的闭环。
/code-review命令与--fix的定位
在深入--fix之前，先明确它隶属于哪一个命令体系。仓库中的 Tool Description: Code review command 给出了该命令的完整契约：
Review the current diff, or a PR number/branch/path target, for correctness bugs (plus reuse/simplification/efficiency cleanups where the model's review recipe covers them) at the given effort level... Pass
--commentto post findings as inline PR comments, or--fixto apply the findings to the working tree after the review.
从这段工具描述可以提炼出/code-review的三条关键能力：
- 审查对象：当前 diff，或显式传入的 PR 编号 / 分支名 / 路径目标；
- 审查范围：正确性缺陷（correctness bugs），以及复用（reuse）、简化（simplification）、效率（efficiency）等清理类问题；
- 三种收尾方式：默认输出审查报告；加
--comment把发现发布为 PR 内联评论；加--fix把发现直接应用到工作区。
--fix与--comment是互斥的两种"落地方式"：一个改代码，一个写评论。README 中对本文核心文档的定位也印证了这一点——"Optional /code-review instructions for applying findings to the working tree when--fixis passed"（见 README.md，该片段共 250 tokens）。
另外需要注意，--max-findings <n>与--max-findings all用于控制上报上限，且"最近一次的选择会持续生效，直到传入--max-findings default"——这意味着--fix之后仍可继续执行常规审查，选择状态是持久的。
--fix模式的核心行为契约
part 9 fix application 全文围绕一个前提展开："The--fixflag was passed."。它定义了审查在--fix下的完整行为，可拆解为以下四层契约：
1. 修复而非报告：审查的终点变成工作区
After producing the findings list, apply the findings to the working tree instead of stopping at the report: fix each one directly.
这是--fix与默认模式最根本的区别。默认模式在产出发现清单（findings list）后即停止，把"是否修复、如何修复"的决策交给开发者；--fix模式则要求审查代理在产出清单后立即动手，把每一项发现直接修复到工作区（working tree）中。也就是说，--fix模式下审查命令的交付物不是一份问题清单，而是一份已修复的 diff。
2. 修复范围：正确性缺陷与清理类问题一视同仁
correctness bugs and reuse/simplification/efficiency cleanups alike.
--fix的修复范围与/code-review的审查范围完全对齐，并不局限于严重缺陷：
- correctness bugs：如反转/错误的条件、off-by-one、空值/undefined 解引用、缺失的
await、被吞掉的异常、复制粘贴导致的错误变量引用等运行时正确性问题； - reuse / simplification / efficiency cleanups：复用已有 helper、简化重复逻辑、消除死代码、优化冗余计算等代码卫生问题。
这一点与命令描述中的 "plus reuse/simplification/efficiency cleanups where the model's review recipe covers them" 完全一致——--fix不是"只修高危 bug"的精简模式，而是"清单上有什么就修什么"的完整应用模式。
3. 三类必须跳过的判据
Skip any finding whose fix would change intended behavior, require changes well outside the reviewed diff, or that you judge to be a false positive — note the skip rather than arguing with it.
即使处于修复模式，也并非所有发现都会被应用。提示词明确给出了三类跳过判据：
| 跳过判据 | 含义 | 典型场景 |
|---|---|---|
| 修复会改变预期行为 | fix would change intended behavior | 该"问题"实为刻意设计（如业务要求的边界语义、兼容性兜底） |
| 需要改动远超审查 diff 的范围 | require changes well outside the reviewed diff | 修复牵一发动全身，涉及未在本次 diff 中的模块或接口 |
| 判定为误报 | judge to be a false positive | 验证阶段判为 REFUTED，或代码结构证明该场景不成立 |
其中"修复会改变预期行为"与"误报"两者在语义上存在重叠：若一个候选发现本质上是作者的有意行为，那么修复它就是改变预期行为，也等同于误报。提示词同时列出三者，意在覆盖"发现本身真实但修复代价不合理"（第二类）与"发现本身不成立"（第一、三类）两种不同的跳过动机。
4. 跳过要"记录"而非"争论"
note the skip rather than arguing with it.
这是--fix模式的一条纪律性要求：对于被跳过的发现，只需简明记录跳过理由，不要与"发现的提出者"展开辩论、也不要试图自我说服后强行修复。这条规则的目的在于让修复动作保持单向、高效——修复通过验证的发现，记录有合理理由的跳过，避免在单个发现上消耗过多轮次。
修复之后的收尾：条件化双分支
part 9 提示词的最后一部分是一个模板条件表达式，根据当前会话是否具备"报告发现"工具（ReportFindings）来决定收尾方式：
${HAS_REPORT_FINDINGS_TOOL?`Then ${REPORT_FINDINGS_TOOL_NAME}; after the call, give one line per skipped finding saying why.`:`Finish with a brief summary of what was fixed and what was skipped.`}其语义为：若会话中存在 ReportFindings 类工具，则调用它完成结构化上报，并在调用之后对每个被跳过的发现给出一行理由；若不存在此类工具，则以一段简要总结收尾，说明"修复了什么、跳过了什么"。
分支 A：具备 ReportFindings 工具
当HAS_REPORT_FINDINGS_TOOL为真时，修复完成后仍需调用ReportFindings工具做一次结构化汇报，随后逐条说明跳过原因。这套收尾与 part 10 ReportFindings output format 定义的输出契约衔接：一次调用{level, findings}，findings按严重度降序排列，每条包含file、line、summary、short_summary（压缩到 ≤60 字符、不含理由或后果）、failure_scenario、category（如correctness、simplification、efficiency、reuse、altitude、conventions、test-coverage），以及验证通过时产生的verdict。
值得说明的是，--fix模式下工具调用的角色与默认模式略有不同：默认模式下工具调用就是"报告本身"（"Do not also print the findings as text"）；而在--fix模式下，发现已经以"修复"的形式落地，工具调用更多承担"留痕"职责——汇报哪些被修复、哪些被跳过，且跳过的每条都要给一行理由。
分支 B：无 ReportFindings 工具
当工具不可用时，收尾退化为纯文本：简要总结本次修复覆盖了什么、跳过了什么及其原因。这与--fix的"应用优先"定位一致——工具不可用不应阻断修复动作，只需用更朴素的方式完成汇报。
值得一提的是，这套"简要总结修复与跳过内容"的模式并非孤例：仓库中/simplify斜杠命令的 Phase 2 — Apply the fixes 采用了几乎相同的语言（"Finish with a brief summary of what was fixed and what was skipped"），说明"修复 + 跳过记录 + 总结"是 Claude Code 中修复型提示词的通用范式。
--fix在整条审查流水线中的上下游关系
--fix不是孤立的一条指令，它作用于/code-review完整流水线的末端。理解它的前提，是弄清发现清单从何而来、如何被验证。从仓库中维护的配套提示词可以看出完整链路：
上游 1：发现阶段（finder angles）
在进入--fix之前，审查先要产出候选发现。基础模式是 part 1 base finder angles 中的 "Angle A — line-by-line diff scan"：逐行阅读 diff 的每个 hunk，并阅读每个 hunk 所在的外层函数——被改动函数中未改动行上的 bug 同样在审查范围内。该阶段明确寻找反转/错误条件、off-by-one、空值/undefined 解引用、缺失await、falsy-zero 检查、复制粘贴错误变量、catch 中吞掉错误、未转义的正则元字符等模式。
不同 effort 级别会扩展此阶段：medium/high 模式（part 6、part 7）运行 8 个独立 finder 角度（3 个正确性角度 + 3 个清理角度 + 1 个 altitude 角度 + 1 个 conventions 角度），每个角度最多产出 6 个候选；extra-high/max 模式（part 3）运行 10 个角度、每角度最多 8 个候选，并强调"recall 优先——漏掉真实 bug 的代价高于误报"。low effort 模式（part 2 low effort mode）则只做一遍 diff 阅读、不做子代理与全文件读取。
上游 2：验证阶段（verification）
候选发现经过验证后才会成为"可信发现"，--fix修复的正是验证幸存者。验证有两种口径：
- 三态验证（part 4）：将每个候选分为 CONFIRMED（能指出触发它的输入/状态及错误输出，需引用代码行）、PLAUSIBLE（机制真实但触发条件不确定，需说明何种条件可证实它）、REFUTED（事实错误或已被其他守卫覆盖，需引用证明行）；
- recall 偏向验证（part 5）：默认视为 PLAUSIBLE，除非能从代码构造出 REFUTED——如事实错误、类型/常量/不变量证明不可能、本次 diff 中已处理、或纯风格无可观察影响。
这一阶段直接决定了--fix的修复面：三态验证下 CONFIRMED 与 PLAUSIBLE 进入修复候选；recall 偏向下几乎全部非 REFUTED 候选进入修复候选。同时，验证结果（verdict）也会随 ReportFindings 输出保留，成为--fix后汇报的一部分。
下游：修复应用与收尾
经过验证的发现清单产出后，--fix接管：逐条修复到工作区 → 按跳过判据剔除三类发现 → 调用 ReportFindings 或输出总结 → 逐行说明跳过理由。至此，一条完整的"diff → 发现 → 验证 → 修复 → 汇报"链路闭环。
对照：--comment模式的分工
--fix与--comment覆盖了审查结果落地的两种形态，可以互为参照：
- part 8 GitHub comment posting：当目标为 GitHub PR 时，通过
mcp__github_inline_comment__create_inline_comment逐条发布内联评论（仅当建议块能完整修复问题时才附带 suggestion block）；工具不可用时回退到gh api repos/{owner}/{repo}/pulls/{pr}/comments；目标非 PR 时打印发现并注明--comment被忽略； - GitLab comment posting：当目标为 GitLab MR 时，通过
glab mr note ... -m "<body>"发布一条包含每个发现的 file:line、问题与建议修复的 MR 通用评论（glab 缺少行级评论的单命令动词，行内评论需走glab api的 discussions 接口）。
两者对比可见：--comment是"把发现写回代码评审平台"，--fix是"把发现直接写进代码"，且两者都遵循"目标不匹配则降级为终端打印并注明标志被忽略"的兜底策略。
--fix提示词的版本演进
CHANGELOG 记录了 part 9 提示词随 Claude Code 版本的演变，有助于理解--fix模式的设计取舍：
- 引入（约 2.1.195）：新增 part 9 fix application，定义
--fix行为——将已上报的审查发现应用到工作区，覆盖正确性缺陷及 reuse/simplification/efficiency 清理，跳过误报或超出审查 diff 的修复（见 CHANGELOG.md）； - 强化上报（约 2.1.199）：当发现上报工具可用时，要求
--fix运行将每个发现的结局上报为fixed/no_change_needed/skipped，避免以文本重复发现，且只解释被跳过的发现（见 CHANGELOG.md）； - 简化（2.1.206）：移除"逐条重报每个发现的结局"的显式要求，仅保留对被跳过发现的解释（见 CHANGELOG.md）。
结合本文核心文档（ccVersion: 2.1.235）可以看到最终形态：不再强制逐条上报fixed/no_change_needed/skipped结局，而是"有工具就调用一次结构化上报 + 逐行说明跳过原因，无工具就总结修复与跳过"。这一演进体现了提示词作者对"汇报成本 vs 留痕价值"的平衡——修复本身已是最充分的证据，逐条结局重报是冗余的。
实战建议：如何用好--fix
基于上述行为契约与流水线关系，归纳几条实操建议：
- 在改动较小的 diff 上使用
--fix：跳过判据之一就是"修复需要改动远超审查 diff 的范围"，因此--fix最适合自包含的改动（单文件或局部 hunk）；跨模块、牵涉未审查代码的发现会被跳过，属于预期行为而非缺陷。 - 理解 effort 级别对修复面的影响：low/medium 级别产出"更少但高置信"的发现，修复面窄而稳；high→max 级别覆盖更广、可能包含不确定发现（见 tool-description-code-review-command.md），此时
--fix需要更依赖验证阶段和跳过判据来过滤。 - 把
--fix与--max-findings配合使用：--max-findings <n>限制上报数量，间接也限制了修复面；--max-findings all则允许修复全部幸存发现（见 part 10）。 - 以"跳过理由"作为人工复核入口：
--fix的收尾明确要求逐行给出跳过原因，这些理由（"会改变预期行为 / 超出 diff 范围 / 误报"）正是开发者事后人工复核的最佳线索——被跳过的发现往往仍值得人工评估。 - 注意工作区状态：
--fix直接修改工作区文件，建议在干净或已提交的工作区上运行，避免修复结果与未提交改动混杂（这与 tool-description-bash-maintain-cwd.md 中"git 命令直接作用于当前工作树"的约束一致）。
小结
--fix是 Claude Code/code-review命令从"审查工具"走向"审查 + 修复工作流"的关键开关。以 part 9 fix application 为骨架，可以看到一整套严谨的工程设计：修复优先而非报告优先的行为转向、正确性缺陷与清理类问题同等的修复范围、三类明确的跳过判据（改变预期行为 / 超出 diff 范围 / 误报）、"记录跳过而非争论"的纪律，以及条件化的收尾汇报（工具可用则结构化上报 + 逐行跳过理由，否则简要总结）。配合仓库中维护的 finder 阶段、验证阶段与 ReportFindings 输出契约，--fix构成了一个完整、可审计的"发现—验证—修复—汇报"闭环，也为--comment（发布到 GitHub/GitLab）之外的审查结果落地提供了另一条高效路径。
- 文档
- 提示工程
- 人工智能
【免费下载链接】claude-code-system-prompts
All parts of Claude Code's system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.
相关推荐
基于 Claude Code 的多智能体 PR 自动审查：Code Review Plugin 工作流与置信度过滤机制深度解析
基于 Claude Code 的多智能体 PR 自动审查：Code Review Plugin 工作流与置信度过滤机制深度解析 本文以 Claude Code
AI 插件开发工具插件系统gsd-core 代码审查自动修复调度修复：`/gsd-code-review --fix` 标志从静默丢弃到完整链路
gsd core 代码审查自动修复调度修复： /gsd code review fix 标志从静默丢弃到完整链路 本篇技术文章以 gsd core 仓库中的 c
用 claude-task-master 自动化处理 PR Review Comments：从收集、分级到修复推送的完整 Claude Code 工作流
用 claude task master 自动化处理 PR Review Comments：从收集、分级到修复推送的完整 Claude Code 工作流 PR（
AI Agent开发工具CLIMCP
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
