制：從審查發(fā)現(xiàn)到自動修復(fù)工作區(qū)的完整流程解析)
文檔提示工程人工智能【免費(fèi)下載鏈接】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點(diǎn)擊查看免費(fèi)下載/code-review是 Claude Code 內(nèi)置的代碼審查斜杠命令默認(rèn)情況下它以審查報告收尾產(chǎn)出經(jīng)過驗證的發(fā)現(xiàn)清單后停止。而當(dāng)用戶傳入--fix標(biāo)志時命令的行為會發(fā)生質(zhì)變——從報告問題轉(zhuǎn)向直接修復(fù)問題。本文以開源倉庫 claude-code-system-prompts 中維護(hù)的 Agent Prompt: /code-review part 9 fix application 為核心結(jié)合倉庫內(nèi)與之配套的審查提示詞finder 階段、驗證階段、ReportFindings 輸出格式、--comment模式與 CHANGELOG 中的演進(jìn)記錄完整解析--fix模式的行為契約、跳過判據(jù)、收尾匯報方式及其在整條審查流水線中的位置幫助讀者理解 Claude Code 如何在一次命令中完成發(fā)現(xiàn)—驗證—修復(fù)—匯報的閉環(huán)。/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的三條關(guān)鍵能力審查對象當(dāng)前 diff或顯式傳入的 PR 編號 / 分支名 / 路徑目標(biāo)審查范圍正確性缺陷correctness bugs以及復(fù)用reuse、簡化simplification、效率efficiency等清理類問題三種收尾方式默認(rèn)輸出審查報告加--comment把發(fā)現(xiàn)發(fā)布為 PR 內(nèi)聯(lián)評論加--fix把發(fā)現(xiàn)直接應(yīng)用到工作區(qū)。--fix與--comment是互斥的兩種落地方式一個改代碼一個寫評論。README 中對本文核心文檔的定位也印證了這一點(diǎn)——Optional /code-review instructions for applying findings to the working tree when--fixis passed見 README.md該片段共 250 tokens。另外需要注意--max-findings n與--max-findings all用于控制上報上限且最近一次的選擇會持續(xù)生效直到傳入--max-findings default——這意味著--fix之后仍可繼續(xù)執(zhí)行常規(guī)審查選擇狀態(tài)是持久的。--fix模式的核心行為契約part 9 fix application 全文圍繞一個前提展開The--fixflag was passed.。它定義了審查在--fix下的完整行為可拆解為以下四層契約1. 修復(fù)而非報告審查的終點(diǎn)變成工作區(qū)After producing the findings list, apply the findings to the working tree instead of stopping at the report: fix each one directly.這是--fix與默認(rèn)模式最根本的區(qū)別。默認(rèn)模式在產(chǎn)出發(fā)現(xiàn)清單findings list后即停止把是否修復(fù)、如何修復(fù)的決策交給開發(fā)者--fix模式則要求審查代理在產(chǎn)出清單后立即動手把每一項發(fā)現(xiàn)直接修復(fù)到工作區(qū)working tree中。也就是說--fix模式下審查命令的交付物不是一份問題清單而是一份已修復(fù)的 diff。2. 修復(fù)范圍正確性缺陷與清理類問題一視同仁correctness bugs and reuse/simplification/efficiency cleanups alike.--fix的修復(fù)范圍與/code-review的審查范圍完全對齊并不局限于嚴(yán)重缺陷correctness bugs如反轉(zhuǎn)/錯誤的條件、off-by-one、空值/undefined 解引用、缺失的await、被吞掉的異常、復(fù)制粘貼導(dǎo)致的錯誤變量引用等運(yùn)行時正確性問題reuse / simplification / efficiency cleanups復(fù)用已有 helper、簡化重復(fù)邏輯、消除死代碼、優(yōu)化冗余計算等代碼衛(wèi)生問題。這一點(diǎn)與命令描述中的 plus reuse/simplification/efficiency cleanups where the models review recipe covers them 完全一致——--fix不是只修高危 bug的精簡模式而是清單上有什么就修什么的完整應(yīng)用模式。3. 三類必須跳過的判據(jù)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.即使處于修復(fù)模式也并非所有發(fā)現(xiàn)都會被應(yīng)用。提示詞明確給出了三類跳過判據(jù)跳過判據(jù)含義典型場景修復(fù)會改變預(yù)期行為fix would change intended behavior該問題實為刻意設(shè)計如業(yè)務(wù)要求的邊界語義、兼容性兜底需要改動遠(yuǎn)超審查 diff 的范圍require changes well outside the reviewed diff修復(fù)牽一發(fā)動全身涉及未在本次 diff 中的模塊或接口判定為誤報judge to be a false positive驗證階段判為 REFUTED或代碼結(jié)構(gòu)證明該場景不成立其中修復(fù)會改變預(yù)期行為與誤報兩者在語義上存在重疊若一個候選發(fā)現(xiàn)本質(zhì)上是作者的有意行為那么修復(fù)它就是改變預(yù)期行為也等同于誤報。提示詞同時列出三者意在覆蓋發(fā)現(xiàn)本身真實但修復(fù)代價不合理第二類與發(fā)現(xiàn)本身不成立第一、三類兩種不同的跳過動機(jī)。4. 跳過要記錄而非爭論note the skip rather than arguing with it.這是--fix模式的一條紀(jì)律性要求對于被跳過的發(fā)現(xiàn)只需簡明記錄跳過理由不要與發(fā)現(xiàn)的提出者展開辯論、也不要試圖自我說服后強(qiáng)行修復(fù)。這條規(guī)則的目的在于讓修復(fù)動作保持單向、高效——修復(fù)通過驗證的發(fā)現(xiàn)記錄有合理理由的跳過避免在單個發(fā)現(xiàn)上消耗過多輪次。修復(fù)之后的收尾條件化雙分支part 9 提示詞的最后一部分是一個模板條件表達(dá)式根據(jù)當(dāng)前會話是否具備報告發(fā)現(xiàn)工具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 類工具則調(diào)用它完成結(jié)構(gòu)化上報并在調(diào)用之后對每個被跳過的發(fā)現(xiàn)給出一行理由若不存在此類工具則以一段簡要總結(jié)收尾說明修復(fù)了什么、跳過了什么。分支 A具備 ReportFindings 工具當(dāng)HAS_REPORT_FINDINGS_TOOL為真時修復(fù)完成后仍需調(diào)用ReportFindings工具做一次結(jié)構(gòu)化匯報隨后逐條說明跳過原因。這套收尾與 part 10 ReportFindings output format 定義的輸出契約銜接一次調(diào)用{level, findings}findings按嚴(yán)重度降序排列每條包含file、line、summary、short_summary壓縮到 ≤60 字符、不含理由或后果、failure_scenario、category如correctness、simplification、efficiency、reuse、altitude、conventions、test-coverage以及驗證通過時產(chǎn)生的verdict。值得說明的是--fix模式下工具調(diào)用的角色與默認(rèn)模式略有不同默認(rèn)模式下工具調(diào)用就是報告本身Do not also print the findings as text而在--fix模式下發(fā)現(xiàn)已經(jīng)以修復(fù)的形式落地工具調(diào)用更多承擔(dān)留痕職責(zé)——匯報哪些被修復(fù)、哪些被跳過且跳過的每條都要給一行理由。分支 B無 ReportFindings 工具當(dāng)工具不可用時收尾退化為純文本簡要總結(jié)本次修復(fù)覆蓋了什么、跳過了什么及其原因。這與--fix的應(yīng)用優(yōu)先定位一致——工具不可用不應(yīng)阻斷修復(fù)動作只需用更樸素的方式完成匯報。值得一提的是這套簡要總結(jié)修復(fù)與跳過內(nèi)容的模式并非孤例倉庫中/simplify斜杠命令的 Phase 2 — Apply the fixes 采用了幾乎相同的語言Finish with a brief summary of what was fixed and what was skipped說明修復(fù) 跳過記錄 總結(jié)是 Claude Code 中修復(fù)型提示詞的通用范式。--fix在整條審查流水線中的上下游關(guān)系--fix不是孤立的一條指令它作用于/code-review完整流水線的末端。理解它的前提是弄清發(fā)現(xiàn)清單從何而來、如何被驗證。從倉庫中維護(hù)的配套提示詞可以看出完整鏈路上游 1發(fā)現(xiàn)階段finder angles在進(jìn)入--fix之前審查先要產(chǎn)出候選發(fā)現(xiàn)。基礎(chǔ)模式是 part 1 base finder angles 中的 Angle A — line-by-line diff scan逐行閱讀 diff 的每個 hunk并閱讀每個 hunk 所在的外層函數(shù)——被改動函數(shù)中未改動行上的 bug 同樣在審查范圍內(nèi)。該階段明確尋找反轉(zhuǎn)/錯誤條件、off-by-one、空值/undefined 解引用、缺失await、falsy-zero 檢查、復(fù)制粘貼錯誤變量、catch 中吞掉錯誤、未轉(zhuǎn)義的正則元字符等模式。不同 effort 級別會擴(kuò)展此階段medium/high 模式part 6、part 7運(yùn)行 8 個獨(dú)立 finder 角度3 個正確性角度 3 個清理角度 1 個 altitude 角度 1 個 conventions 角度每個角度最多產(chǎn)出 6 個候選extra-high/max 模式part 3運(yùn)行 10 個角度、每角度最多 8 個候選并強(qiáng)調(diào)recall 優(yōu)先——漏掉真實 bug 的代價高于誤報。low effort 模式part 2 low effort mode則只做一遍 diff 閱讀、不做子代理與全文件讀取。上游 2驗證階段verification候選發(fā)現(xiàn)經(jīng)過驗證后才會成為可信發(fā)現(xiàn)--fix修復(fù)的正是驗證幸存者。驗證有兩種口徑三態(tài)驗證part 4將每個候選分為 CONFIRMED能指出觸發(fā)它的輸入/狀態(tài)及錯誤輸出需引用代碼行、PLAUSIBLE機(jī)制真實但觸發(fā)條件不確定需說明何種條件可證實它、REFUTED事實錯誤或已被其他守衛(wèi)覆蓋需引用證明行recall 偏向驗證part 5默認(rèn)視為 PLAUSIBLE除非能從代碼構(gòu)造出 REFUTED——如事實錯誤、類型/常量/不變量證明不可能、本次 diff 中已處理、或純風(fēng)格無可觀察影響。這一階段直接決定了--fix的修復(fù)面三態(tài)驗證下 CONFIRMED 與 PLAUSIBLE 進(jìn)入修復(fù)候選recall 偏向下幾乎全部非 REFUTED 候選進(jìn)入修復(fù)候選。同時驗證結(jié)果verdict也會隨 ReportFindings 輸出保留成為--fix后匯報的一部分。下游修復(fù)應(yīng)用與收尾經(jīng)過驗證的發(fā)現(xiàn)清單產(chǎn)出后--fix接管逐條修復(fù)到工作區(qū) → 按跳過判據(jù)剔除三類發(fā)現(xiàn) → 調(diào)用 ReportFindings 或輸出總結(jié) → 逐行說明跳過理由。至此一條完整的diff → 發(fā)現(xiàn) → 驗證 → 修復(fù) → 匯報鏈路閉環(huán)。對照--comment模式的分工--fix與--comment覆蓋了審查結(jié)果落地的兩種形態(tài)可以互為參照part 8 GitHub comment posting當(dāng)目標(biāo)為 GitHub PR 時通過mcp__github_inline_comment__create_inline_comment逐條發(fā)布內(nèi)聯(lián)評論僅當(dāng)建議塊能完整修復(fù)問題時才附帶 suggestion block工具不可用時回退到gh api repos/{owner}/{repo}/pulls/{pr}/comments目標(biāo)非 PR 時打印發(fā)現(xiàn)并注明--comment被忽略GitLab comment posting當(dāng)目標(biāo)為 GitLab MR 時通過glab mr note ... -m body發(fā)布一條包含每個發(fā)現(xiàn)的 file:line、問題與建議修復(fù)的 MR 通用評論glab 缺少行級評論的單命令動詞行內(nèi)評論需走glab api的 discussions 接口。兩者對比可見--comment是把發(fā)現(xiàn)寫回代碼評審平臺--fix是把發(fā)現(xiàn)直接寫進(jìn)代碼且兩者都遵循目標(biāo)不匹配則降級為終端打印并注明標(biāo)志被忽略的兜底策略。--fix提示詞的版本演進(jìn)CHANGELOG 記錄了 part 9 提示詞隨 Claude Code 版本的演變有助于理解--fix模式的設(shè)計取舍引入約 2.1.195新增 part 9 fix application定義--fix行為——將已上報的審查發(fā)現(xiàn)應(yīng)用到工作區(qū)覆蓋正確性缺陷及 reuse/simplification/efficiency 清理跳過誤報或超出審查 diff 的修復(fù)見 CHANGELOG.md強(qiáng)化上報約 2.1.199當(dāng)發(fā)現(xiàn)上報工具可用時要求--fix運(yùn)行將每個發(fā)現(xiàn)的結(jié)局上報為fixed/no_change_needed/skipped避免以文本重復(fù)發(fā)現(xiàn)且只解釋被跳過的發(fā)現(xiàn)見 CHANGELOG.md簡化2.1.206移除逐條重報每個發(fā)現(xiàn)的結(jié)局的顯式要求僅保留對被跳過發(fā)現(xiàn)的解釋見 CHANGELOG.md。結(jié)合本文核心文檔ccVersion: 2.1.235可以看到最終形態(tài)不再強(qiáng)制逐條上報fixed/no_change_needed/skipped結(jié)局而是有工具就調(diào)用一次結(jié)構(gòu)化上報 逐行說明跳過原因無工具就總結(jié)修復(fù)與跳過。這一演進(jìn)體現(xiàn)了提示詞作者對匯報成本 vs 留痕價值的平衡——修復(fù)本身已是最充分的證據(jù)逐條結(jié)局重報是冗余的。實戰(zhàn)建議如何用好--fix基于上述行為契約與流水線關(guān)系歸納幾條實操建議在改動較小的 diff 上使用--fix跳過判據(jù)之一就是修復(fù)需要改動遠(yuǎn)超審查 diff 的范圍因此--fix最適合自包含的改動單文件或局部 hunk跨模塊、牽涉未審查代碼的發(fā)現(xiàn)會被跳過屬于預(yù)期行為而非缺陷。理解 effort 級別對修復(fù)面的影響low/medium 級別產(chǎn)出更少但高置信的發(fā)現(xiàn)修復(fù)面窄而穩(wěn)high→max 級別覆蓋更廣、可能包含不確定發(fā)現(xiàn)見 tool-description-code-review-command.md此時--fix需要更依賴驗證階段和跳過判據(jù)來過濾。把--fix與--max-findings配合使用--max-findings n限制上報數(shù)量間接也限制了修復(fù)面--max-findings all則允許修復(fù)全部幸存發(fā)現(xiàn)見 part 10。以跳過理由作為人工復(fù)核入口--fix的收尾明確要求逐行給出跳過原因這些理由會改變預(yù)期行為 / 超出 diff 范圍 / 誤報正是開發(fā)者事后人工復(fù)核的最佳線索——被跳過的發(fā)現(xiàn)往往仍值得人工評估。注意工作區(qū)狀態(tài)--fix直接修改工作區(qū)文件建議在干凈或已提交的工作區(qū)上運(yùn)行避免修復(fù)結(jié)果與未提交改動混雜這與 tool-description-bash-maintain-cwd.md 中g(shù)it 命令直接作用于當(dāng)前工作樹的約束一致。小結(jié)--fix是 Claude Code/code-review命令從審查工具走向?qū)彶? 修復(fù)工作流的關(guān)鍵開關(guān)。以 part 9 fix application 為骨架可以看到一整套嚴(yán)謹(jǐn)?shù)墓こ淘O(shè)計修復(fù)優(yōu)先而非報告優(yōu)先的行為轉(zhuǎn)向、正確性缺陷與清理類問題同等的修復(fù)范圍、三類明確的跳過判據(jù)改變預(yù)期行為 / 超出 diff 范圍 / 誤報、記錄跳過而非爭論的紀(jì)律以及條件化的收尾匯報工具可用則結(jié)構(gòu)化上報 逐行跳過理由否則簡要總結(jié)。配合倉庫中維護(hù)的 finder 階段、驗證階段與 ReportFindings 輸出契約--fix構(gòu)成了一個完整、可審計的發(fā)現(xiàn)—驗證—修復(fù)—匯報閉環(huán)也為--comment發(fā)布到 GitHub/GitLab之外的審查結(jié)果落地提供了另一條高效路徑。贊分享文檔提示工程人工智能【免費(fèi)下載鏈接】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點(diǎn)擊查看免費(fèi)下載相關(guān)推薦基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機(jī)制深度解析基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機(jī)制深度解析 本文以 Claude CodeAI 插件開發(fā)工具插件系統(tǒng)gsd-core 代碼審查自動修復(fù)調(diào)度修復(fù)/gsd-code-review --fix 標(biāo)志從靜默丟棄到完整鏈路gsd core 代碼審查自動修復(fù)調(diào)度修復(fù) /gsd code review fix 標(biāo)志從靜默丟棄到完整鏈路 本篇技術(shù)文章以 gsd core 倉庫中的 c用 claude-task-master 自動化處理 PR Review Comments從收集、分級到修復(fù)推送的完整 Claude Code 工作流用 claude task master 自動化處理 PR Review Comments從收集、分級到修復(fù)推送的完整 Claude Code 工作流 PRAI Agent開發(fā)工具CLIMCP上一篇從零到一部署LMFlow推理服務(wù)高性能本地Chatbot搭建指南下一篇3步實現(xiàn)AI模型自動化部署GitLab CI/CD配置cog項目全流程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Claude Code `/code-review` 的 `--fix` 機(jī)制：從審查發(fā)現(xiàn)到自動修復(fù)工作區(qū)的完整流程解析
文檔提示工程人工智能【免費(fèi)下載鏈接】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點(diǎn)擊查看免費(fèi)下載/code-review是 Claude Code 內(nèi)置的代碼審查斜杠命令默認(rèn)情況下它以審查報告收尾產(chǎn)出經(jīng)過驗證的發(fā)現(xiàn)清單后停止。而當(dāng)用戶傳入--fix標(biāo)志時命令的行為會發(fā)生質(zhì)變——從報告問題轉(zhuǎn)向直接修復(fù)問題。本文以開源倉庫 claude-code-system-prompts 中維護(hù)的 Agent Prompt: /code-review part 9 fix application 為核心結(jié)合倉庫內(nèi)與之配套的審查提示詞finder 階段、驗證階段、ReportFindings 輸出格式、--comment模式與 CHANGELOG 中的演進(jìn)記錄完整解析--fix模式的行為契約、跳過判據(jù)、收尾匯報方式及其在整條審查流水線中的位置幫助讀者理解 Claude Code 如何在一次命令中完成發(fā)現(xiàn)—驗證—修復(fù)—匯報的閉環(huán)。/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的三條關(guān)鍵能力審查對象當(dāng)前 diff或顯式傳入的 PR 編號 / 分支名 / 路徑目標(biāo)審查范圍正確性缺陷correctness bugs以及復(fù)用reuse、簡化simplification、效率efficiency等清理類問題三種收尾方式默認(rèn)輸出審查報告加--comment把發(fā)現(xiàn)發(fā)布為 PR 內(nèi)聯(lián)評論加--fix把發(fā)現(xiàn)直接應(yīng)用到工作區(qū)。--fix與--comment是互斥的兩種落地方式一個改代碼一個寫評論。README 中對本文核心文檔的定位也印證了這一點(diǎn)——Optional /code-review instructions for applying findings to the working tree when--fixis passed見 README.md該片段共 250 tokens。另外需要注意--max-findings n與--max-findings all用于控制上報上限且最近一次的選擇會持續(xù)生效直到傳入--max-findings default——這意味著--fix之后仍可繼續(xù)執(zhí)行常規(guī)審查選擇狀態(tài)是持久的。--fix模式的核心行為契約part 9 fix application 全文圍繞一個前提展開The--fixflag was passed.。它定義了審查在--fix下的完整行為可拆解為以下四層契約1. 修復(fù)而非報告審查的終點(diǎn)變成工作區(qū)After producing the findings list, apply the findings to the working tree instead of stopping at the report: fix each one directly.這是--fix與默認(rèn)模式最根本的區(qū)別。默認(rèn)模式在產(chǎn)出發(fā)現(xiàn)清單findings list后即停止把是否修復(fù)、如何修復(fù)的決策交給開發(fā)者--fix模式則要求審查代理在產(chǎn)出清單后立即動手把每一項發(fā)現(xiàn)直接修復(fù)到工作區(qū)working tree中。也就是說--fix模式下審查命令的交付物不是一份問題清單而是一份已修復(fù)的 diff。2. 修復(fù)范圍正確性缺陷與清理類問題一視同仁correctness bugs and reuse/simplification/efficiency cleanups alike.--fix的修復(fù)范圍與/code-review的審查范圍完全對齊并不局限于嚴(yán)重缺陷correctness bugs如反轉(zhuǎn)/錯誤的條件、off-by-one、空值/undefined 解引用、缺失的await、被吞掉的異常、復(fù)制粘貼導(dǎo)致的錯誤變量引用等運(yùn)行時正確性問題reuse / simplification / efficiency cleanups復(fù)用已有 helper、簡化重復(fù)邏輯、消除死代碼、優(yōu)化冗余計算等代碼衛(wèi)生問題。這一點(diǎn)與命令描述中的 plus reuse/simplification/efficiency cleanups where the models review recipe covers them 完全一致——--fix不是只修高危 bug的精簡模式而是清單上有什么就修什么的完整應(yīng)用模式。3. 三類必須跳過的判據(jù)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.即使處于修復(fù)模式也并非所有發(fā)現(xiàn)都會被應(yīng)用。提示詞明確給出了三類跳過判據(jù)跳過判據(jù)含義典型場景修復(fù)會改變預(yù)期行為fix would change intended behavior該問題實為刻意設(shè)計如業(yè)務(wù)要求的邊界語義、兼容性兜底需要改動遠(yuǎn)超審查 diff 的范圍require changes well outside the reviewed diff修復(fù)牽一發(fā)動全身涉及未在本次 diff 中的模塊或接口判定為誤報judge to be a false positive驗證階段判為 REFUTED或代碼結(jié)構(gòu)證明該場景不成立其中修復(fù)會改變預(yù)期行為與誤報兩者在語義上存在重疊若一個候選發(fā)現(xiàn)本質(zhì)上是作者的有意行為那么修復(fù)它就是改變預(yù)期行為也等同于誤報。提示詞同時列出三者意在覆蓋發(fā)現(xiàn)本身真實但修復(fù)代價不合理第二類與發(fā)現(xiàn)本身不成立第一、三類兩種不同的跳過動機(jī)。4. 跳過要記錄而非爭論note the skip rather than arguing with it.這是--fix模式的一條紀(jì)律性要求對于被跳過的發(fā)現(xiàn)只需簡明記錄跳過理由不要與發(fā)現(xiàn)的提出者展開辯論、也不要試圖自我說服后強(qiáng)行修復(fù)。這條規(guī)則的目的在于讓修復(fù)動作保持單向、高效——修復(fù)通過驗證的發(fā)現(xiàn)記錄有合理理由的跳過避免在單個發(fā)現(xiàn)上消耗過多輪次。修復(fù)之后的收尾條件化雙分支part 9 提示詞的最后一部分是一個模板條件表達(dá)式根據(jù)當(dāng)前會話是否具備報告發(fā)現(xiàn)工具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 類工具則調(diào)用它完成結(jié)構(gòu)化上報并在調(diào)用之后對每個被跳過的發(fā)現(xiàn)給出一行理由若不存在此類工具則以一段簡要總結(jié)收尾說明修復(fù)了什么、跳過了什么。分支 A具備 ReportFindings 工具當(dāng)HAS_REPORT_FINDINGS_TOOL為真時修復(fù)完成后仍需調(diào)用ReportFindings工具做一次結(jié)構(gòu)化匯報隨后逐條說明跳過原因。這套收尾與 part 10 ReportFindings output format 定義的輸出契約銜接一次調(diào)用{level, findings}findings按嚴(yán)重度降序排列每條包含file、line、summary、short_summary壓縮到 ≤60 字符、不含理由或后果、failure_scenario、category如correctness、simplification、efficiency、reuse、altitude、conventions、test-coverage以及驗證通過時產(chǎn)生的verdict。值得說明的是--fix模式下工具調(diào)用的角色與默認(rèn)模式略有不同默認(rèn)模式下工具調(diào)用就是報告本身Do not also print the findings as text而在--fix模式下發(fā)現(xiàn)已經(jīng)以修復(fù)的形式落地工具調(diào)用更多承擔(dān)留痕職責(zé)——匯報哪些被修復(fù)、哪些被跳過且跳過的每條都要給一行理由。分支 B無 ReportFindings 工具當(dāng)工具不可用時收尾退化為純文本簡要總結(jié)本次修復(fù)覆蓋了什么、跳過了什么及其原因。這與--fix的應(yīng)用優(yōu)先定位一致——工具不可用不應(yīng)阻斷修復(fù)動作只需用更樸素的方式完成匯報。值得一提的是這套簡要總結(jié)修復(fù)與跳過內(nèi)容的模式并非孤例倉庫中/simplify斜杠命令的 Phase 2 — Apply the fixes 采用了幾乎相同的語言Finish with a brief summary of what was fixed and what was skipped說明修復(fù) 跳過記錄 總結(jié)是 Claude Code 中修復(fù)型提示詞的通用范式。--fix在整條審查流水線中的上下游關(guān)系--fix不是孤立的一條指令它作用于/code-review完整流水線的末端。理解它的前提是弄清發(fā)現(xiàn)清單從何而來、如何被驗證。從倉庫中維護(hù)的配套提示詞可以看出完整鏈路上游 1發(fā)現(xiàn)階段finder angles在進(jìn)入--fix之前審查先要產(chǎn)出候選發(fā)現(xiàn)。基礎(chǔ)模式是 part 1 base finder angles 中的 Angle A — line-by-line diff scan逐行閱讀 diff 的每個 hunk并閱讀每個 hunk 所在的外層函數(shù)——被改動函數(shù)中未改動行上的 bug 同樣在審查范圍內(nèi)。該階段明確尋找反轉(zhuǎn)/錯誤條件、off-by-one、空值/undefined 解引用、缺失await、falsy-zero 檢查、復(fù)制粘貼錯誤變量、catch 中吞掉錯誤、未轉(zhuǎn)義的正則元字符等模式。不同 effort 級別會擴(kuò)展此階段medium/high 模式part 6、part 7運(yùn)行 8 個獨(dú)立 finder 角度3 個正確性角度 3 個清理角度 1 個 altitude 角度 1 個 conventions 角度每個角度最多產(chǎn)出 6 個候選extra-high/max 模式part 3運(yùn)行 10 個角度、每角度最多 8 個候選并強(qiáng)調(diào)recall 優(yōu)先——漏掉真實 bug 的代價高于誤報。low effort 模式part 2 low effort mode則只做一遍 diff 閱讀、不做子代理與全文件讀取。上游 2驗證階段verification候選發(fā)現(xiàn)經(jīng)過驗證后才會成為可信發(fā)現(xiàn)--fix修復(fù)的正是驗證幸存者。驗證有兩種口徑三態(tài)驗證part 4將每個候選分為 CONFIRMED能指出觸發(fā)它的輸入/狀態(tài)及錯誤輸出需引用代碼行、PLAUSIBLE機(jī)制真實但觸發(fā)條件不確定需說明何種條件可證實它、REFUTED事實錯誤或已被其他守衛(wèi)覆蓋需引用證明行recall 偏向驗證part 5默認(rèn)視為 PLAUSIBLE除非能從代碼構(gòu)造出 REFUTED——如事實錯誤、類型/常量/不變量證明不可能、本次 diff 中已處理、或純風(fēng)格無可觀察影響。這一階段直接決定了--fix的修復(fù)面三態(tài)驗證下 CONFIRMED 與 PLAUSIBLE 進(jìn)入修復(fù)候選recall 偏向下幾乎全部非 REFUTED 候選進(jìn)入修復(fù)候選。同時驗證結(jié)果verdict也會隨 ReportFindings 輸出保留成為--fix后匯報的一部分。下游修復(fù)應(yīng)用與收尾經(jīng)過驗證的發(fā)現(xiàn)清單產(chǎn)出后--fix接管逐條修復(fù)到工作區(qū) → 按跳過判據(jù)剔除三類發(fā)現(xiàn) → 調(diào)用 ReportFindings 或輸出總結(jié) → 逐行說明跳過理由。至此一條完整的diff → 發(fā)現(xiàn) → 驗證 → 修復(fù) → 匯報鏈路閉環(huán)。對照--comment模式的分工--fix與--comment覆蓋了審查結(jié)果落地的兩種形態(tài)可以互為參照part 8 GitHub comment posting當(dāng)目標(biāo)為 GitHub PR 時通過mcp__github_inline_comment__create_inline_comment逐條發(fā)布內(nèi)聯(lián)評論僅當(dāng)建議塊能完整修復(fù)問題時才附帶 suggestion block工具不可用時回退到gh api repos/{owner}/{repo}/pulls/{pr}/comments目標(biāo)非 PR 時打印發(fā)現(xiàn)并注明--comment被忽略GitLab comment posting當(dāng)目標(biāo)為 GitLab MR 時通過glab mr note ... -m body發(fā)布一條包含每個發(fā)現(xiàn)的 file:line、問題與建議修復(fù)的 MR 通用評論glab 缺少行級評論的單命令動詞行內(nèi)評論需走glab api的 discussions 接口。兩者對比可見--comment是把發(fā)現(xiàn)寫回代碼評審平臺--fix是把發(fā)現(xiàn)直接寫進(jìn)代碼且兩者都遵循目標(biāo)不匹配則降級為終端打印并注明標(biāo)志被忽略的兜底策略。--fix提示詞的版本演進(jìn)CHANGELOG 記錄了 part 9 提示詞隨 Claude Code 版本的演變有助于理解--fix模式的設(shè)計取舍引入約 2.1.195新增 part 9 fix application定義--fix行為——將已上報的審查發(fā)現(xiàn)應(yīng)用到工作區(qū)覆蓋正確性缺陷及 reuse/simplification/efficiency 清理跳過誤報或超出審查 diff 的修復(fù)見 CHANGELOG.md強(qiáng)化上報約 2.1.199當(dāng)發(fā)現(xiàn)上報工具可用時要求--fix運(yùn)行將每個發(fā)現(xiàn)的結(jié)局上報為fixed/no_change_needed/skipped避免以文本重復(fù)發(fā)現(xiàn)且只解釋被跳過的發(fā)現(xiàn)見 CHANGELOG.md簡化2.1.206移除逐條重報每個發(fā)現(xiàn)的結(jié)局的顯式要求僅保留對被跳過發(fā)現(xiàn)的解釋見 CHANGELOG.md。結(jié)合本文核心文檔ccVersion: 2.1.235可以看到最終形態(tài)不再強(qiáng)制逐條上報fixed/no_change_needed/skipped結(jié)局而是有工具就調(diào)用一次結(jié)構(gòu)化上報 逐行說明跳過原因無工具就總結(jié)修復(fù)與跳過。這一演進(jìn)體現(xiàn)了提示詞作者對匯報成本 vs 留痕價值的平衡——修復(fù)本身已是最充分的證據(jù)逐條結(jié)局重報是冗余的。實戰(zhàn)建議如何用好--fix基于上述行為契約與流水線關(guān)系歸納幾條實操建議在改動較小的 diff 上使用--fix跳過判據(jù)之一就是修復(fù)需要改動遠(yuǎn)超審查 diff 的范圍因此--fix最適合自包含的改動單文件或局部 hunk跨模塊、牽涉未審查代碼的發(fā)現(xiàn)會被跳過屬于預(yù)期行為而非缺陷。理解 effort 級別對修復(fù)面的影響low/medium 級別產(chǎn)出更少但高置信的發(fā)現(xiàn)修復(fù)面窄而穩(wěn)high→max 級別覆蓋更廣、可能包含不確定發(fā)現(xiàn)見 tool-description-code-review-command.md此時--fix需要更依賴驗證階段和跳過判據(jù)來過濾。把--fix與--max-findings配合使用--max-findings n限制上報數(shù)量間接也限制了修復(fù)面--max-findings all則允許修復(fù)全部幸存發(fā)現(xiàn)見 part 10。以跳過理由作為人工復(fù)核入口--fix的收尾明確要求逐行給出跳過原因這些理由會改變預(yù)期行為 / 超出 diff 范圍 / 誤報正是開發(fā)者事后人工復(fù)核的最佳線索——被跳過的發(fā)現(xiàn)往往仍值得人工評估。注意工作區(qū)狀態(tài)--fix直接修改工作區(qū)文件建議在干凈或已提交的工作區(qū)上運(yùn)行避免修復(fù)結(jié)果與未提交改動混雜這與 tool-description-bash-maintain-cwd.md 中g(shù)it 命令直接作用于當(dāng)前工作樹的約束一致。小結(jié)--fix是 Claude Code/code-review命令從審查工具走向?qū)彶? 修復(fù)工作流的關(guān)鍵開關(guān)。以 part 9 fix application 為骨架可以看到一整套嚴(yán)謹(jǐn)?shù)墓こ淘O(shè)計修復(fù)優(yōu)先而非報告優(yōu)先的行為轉(zhuǎn)向、正確性缺陷與清理類問題同等的修復(fù)范圍、三類明確的跳過判據(jù)改變預(yù)期行為 / 超出 diff 范圍 / 誤報、記錄跳過而非爭論的紀(jì)律以及條件化的收尾匯報工具可用則結(jié)構(gòu)化上報 逐行跳過理由否則簡要總結(jié)。配合倉庫中維護(hù)的 finder 階段、驗證階段與 ReportFindings 輸出契約--fix構(gòu)成了一個完整、可審計的發(fā)現(xiàn)—驗證—修復(fù)—匯報閉環(huán)也為--comment發(fā)布到 GitHub/GitLab之外的審查結(jié)果落地提供了另一條高效路徑。贊分享文檔提示工程人工智能【免費(fèi)下載鏈接】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點(diǎn)擊查看免費(fèi)下載相關(guān)推薦基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機(jī)制深度解析基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機(jī)制深度解析 本文以 Claude CodeAI 插件開發(fā)工具插件系統(tǒng)gsd-core 代碼審查自動修復(fù)調(diào)度修復(fù)/gsd-code-review --fix 標(biāo)志從靜默丟棄到完整鏈路gsd core 代碼審查自動修復(fù)調(diào)度修復(fù) /gsd code review fix 標(biāo)志從靜默丟棄到完整鏈路 本篇技術(shù)文章以 gsd core 倉庫中的 c用 claude-task-master 自動化處理 PR Review Comments從收集、分級到修復(fù)推送的完整 Claude Code 工作流用 claude task master 自動化處理 PR Review Comments從收集、分級到修復(fù)推送的完整 Claude Code 工作流 PRAI Agent開發(fā)工具CLIMCP上一篇從零到一部署LMFlow推理服務(wù)高性能本地Chatbot搭建指南下一篇3步實現(xiàn)AI模型自動化部署GitLab CI/CD配置cog項目全流程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考