Claude Code `/code-review` 的 `--fix` 机制：从审查发现到自动修复工作区的完整流程解析

文档提示工程人工智能【免费下载链接】claude-code-system-promptsAll parts of Claude Codes 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.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载/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 models 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 models 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-promptsAll parts of Claude Codes 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.项目地址https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts点击查看免费下载相关推荐基于 Claude Code 的多智能体 PR 自动审查Code Review Plugin 工作流与置信度过滤机制深度解析基于 Claude Code 的多智能体 PR 自动审查Code Review Plugin 工作流与置信度过滤机制深度解析 本文以 Claude CodeAI 插件开发工具插件系统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 工作流 PRAI Agent开发工具CLIMCP上一篇从零到一部署LMFlow推理服务高性能本地Chatbot搭建指南下一篇3步实现AI模型自动化部署GitLab CI/CD配置cog项目全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考