現(xiàn)到自動修復(fù)工作區(qū)的完整流程解析)
文檔提示工程人工智能【免費下載鏈接】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 內(nèi)置的代碼審查斜杠命令默認情況下它以審查報告收尾產(chǎn)出經(jīng)過驗證的發(fā)現(xiàn)清單后停止。而當用戶傳入--fix標志時命令的行為會發(fā)生質(zhì)變——從報告問題轉(zhuǎn)向直接修復(fù)問題。本文以開源倉庫 claude-code-system-prompts 中維護的 Agent Prompt: /code-review part 9 fix application 為核心結(jié)合倉庫內(nèi)與之配套的審查提示詞finder 階段、驗證階段、ReportFindings 輸出格式、--comment模式與 CHANGELOG 中的演進記錄完整解析--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)鍵能力審查對象當前 diff或顯式傳入的 PR 編號 / 分支名 / 路徑目標審查范圍正確性缺陷correctness bugs以及復(fù)用reuse、簡化simplification、效率efficiency等清理類問題三種收尾方式默認輸出審查報告加--comment把發(fā)現(xiàn)發(fā)布為 PR 內(nèi)聯(lián)評論加--fix把發(fā)現(xiàn)直接應(yīng)用到工作區(qū)。--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用于控制上報上限且最近一次的選擇會持續(xù)生效直到傳入--max-findings default——這意味著--fix之后仍可繼續(xù)執(zhí)行常規(guī)審查選擇狀態(tài)是持久的。--fix模式的核心行為契約part 9 fix application 全文圍繞一個前提展開The--fixflag was passed.。它定義了審查在--fix下的完整行為可拆解為以下四層契約1. 修復(fù)而非報告審查的終點變成工作區(qū)After producing the findings list, apply the findings to the working tree instead of stopping at the report: fix each one directly.這是--fix與默認模式最根本的區(qū)別。默認模式在產(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的審查范圍完全對齊并不局限于嚴重缺陷correctness bugs如反轉(zhuǎn)/錯誤的條件、off-by-one、空值/undefined 解引用、缺失的await、被吞掉的異常、復(fù)制粘貼導(dǎo)致的錯誤變量引用等運行時正確性問題reuse / simplification / efficiency cleanups復(fù)用已有 helper、簡化重復(fù)邏輯、消除死代碼、優(yōu)化冗余計算等代碼衛(wèi)生問題。這一點與命令描述中的 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ù)要求的邊界語義、兼容性兜底需要改動遠超審查 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)本身不成立第一、三類兩種不同的跳過動機。4. 跳過要記錄而非爭論note the skip rather than arguing with it.這是--fix模式的一條紀律性要求對于被跳過的發(fā)現(xiàn)只需簡明記錄跳過理由不要與發(fā)現(xiàn)的提出者展開辯論、也不要試圖自我說服后強行修復(fù)。這條規(guī)則的目的在于讓修復(fù)動作保持單向、高效——修復(fù)通過驗證的發(fā)現(xiàn)記錄有合理理由的跳過避免在單個發(fā)現(xiàn)上消耗過多輪次。修復(fù)之后的收尾條件化雙分支part 9 提示詞的最后一部分是一個模板條件表達式根據(jù)當前會話是否具備報告發(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 工具當HAS_REPORT_FINDINGS_TOOL為真時修復(fù)完成后仍需調(diào)用ReportFindings工具做一次結(jié)構(gòu)化匯報隨后逐條說明跳過原因。這套收尾與 part 10 ReportFindings output format 定義的輸出契約銜接一次調(diào)用{level, findings}findings按嚴重度降序排列每條包含file、line、summary、short_summary壓縮到 ≤60 字符、不含理由或后果、failure_scenario、category如correctness、simplification、efficiency、reuse、altitude、conventions、test-coverage以及驗證通過時產(chǎn)生的verdict。值得說明的是--fix模式下工具調(diào)用的角色與默認模式略有不同默認模式下工具調(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 工具當工具不可用時收尾退化為純文本簡要總結(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)清單從何而來、如何被驗證。從倉庫中維護的配套提示詞可以看出完整鏈路上游 1發(fā)現(xiàn)階段finder angles在進入--fix之前審查先要產(chǎn)出候選發(fā)現(xiàn)?；A(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 級別會擴展此階段medium/high 模式part 6、part 7運行 8 個獨立 finder 角度3 個正確性角度 3 個清理角度 1 個 altitude 角度 1 個 conventions 角度每個角度最多產(chǎn)出 6 個候選extra-high/max 模式part 3運行 10 個角度、每角度最多 8 個候選并強調(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機制真實但觸發(fā)條件不確定需說明何種條件可證實它、REFUTED事實錯誤或已被其他守衛(wèi)覆蓋需引用證明行recall 偏向驗證part 5默認視為 PLAUSIBLE除非能從代碼構(gòu)造出 REFUTED——如事實錯誤、類型/常量/不變量證明不可能、本次 diff 中已處理、或純風(fēng)格無可觀察影響。這一階段直接決定了--fix的修復(fù)面三態(tài)驗證下 CONFIRMED 與 PLAUSIBLE 進入修復(fù)候選recall 偏向下幾乎全部非 REFUTED 候選進入修復(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當目標為 GitHub PR 時通過mcp__github_inline_comment__create_inline_comment逐條發(fā)布內(nèi)聯(lián)評論僅當建議塊能完整修復(fù)問題時才附帶 suggestion block工具不可用時回退到gh api repos/{owner}/{repo}/pulls/{pr}/comments目標非 PR 時打印發(fā)現(xiàn)并注明--comment被忽略GitLab comment posting當目標為 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)直接寫進代碼且兩者都遵循目標不匹配則降級為終端打印并注明標志被忽略的兜底策略。--fix提示詞的版本演進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強化上報約 2.1.199當發(fā)現(xiàn)上報工具可用時要求--fix運行將每個發(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)不再強制逐條上報fixed/no_change_needed/skipped結(jié)局而是有工具就調(diào)用一次結(jié)構(gòu)化上報 逐行說明跳過原因無工具就總結(jié)修復(fù)與跳過。這一演進體現(xiàn)了提示詞作者對匯報成本 vs 留痕價值的平衡——修復(fù)本身已是最充分的證據(jù)逐條結(jié)局重報是冗余的。實戰(zhàn)建議如何用好--fix基于上述行為契約與流水線關(guān)系歸納幾條實操建議在改動較小的 diff 上使用--fix跳過判據(jù)之一就是修復(fù)需要改動遠超審查 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ū)上運行避免修復(fù)結(jié)果與未提交改動混雜這與 tool-description-bash-maintain-cwd.md 中g(shù)it 命令直接作用于當前工作樹的約束一致。小結(jié)--fix是 Claude Code/code-review命令從審查工具走向?qū)彶? 修復(fù)工作流的關(guān)鍵開關(guān)。以 part 9 fix application 為骨架可以看到一整套嚴謹?shù)墓こ淘O(shè)計修復(fù)優(yōu)先而非報告優(yōu)先的行為轉(zhuǎn)向、正確性缺陷與清理類問題同等的修復(fù)范圍、三類明確的跳過判據(jù)改變預(yù)期行為 / 超出 diff 范圍 / 誤報、記錄跳過而非爭論的紀律以及條件化的收尾匯報工具可用則結(jié)構(gòu)化上報 逐行跳過理由否則簡要總結(jié)。配合倉庫中維護的 finder 階段、驗證階段與 ReportFindings 輸出契約--fix構(gòu)成了一個完整、可審計的發(fā)現(xiàn)—驗證—修復(fù)—匯報閉環(huán)也為--comment發(fā)布到 GitHub/GitLab之外的審查結(jié)果落地提供了另一條高效路徑。贊分享文檔提示工程人工智能【免費下載鏈接】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點擊查看免費下載相關(guān)推薦基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機制深度解析基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機制深度解析 本文以 Claude CodeAI 插件開發(fā)工具插件系統(tǒng)gsd-core 代碼審查自動修復(fù)調(diào)度修復(fù)/gsd-code-review --fix 標志從靜默丟棄到完整鏈路gsd core 代碼審查自動修復(fù)調(diào)度修復(fù) /gsd code review fix 標志從靜默丟棄到完整鏈路 本篇技術(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` 機制：從審查發(fā)現(xiàn)到自動修復(fù)工作區(qū)的完整流程解析
文檔提示工程人工智能【免費下載鏈接】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 內(nèi)置的代碼審查斜杠命令默認情況下它以審查報告收尾產(chǎn)出經(jīng)過驗證的發(fā)現(xiàn)清單后停止。而當用戶傳入--fix標志時命令的行為會發(fā)生質(zhì)變——從報告問題轉(zhuǎn)向直接修復(fù)問題。本文以開源倉庫 claude-code-system-prompts 中維護的 Agent Prompt: /code-review part 9 fix application 為核心結(jié)合倉庫內(nèi)與之配套的審查提示詞finder 階段、驗證階段、ReportFindings 輸出格式、--comment模式與 CHANGELOG 中的演進記錄完整解析--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)鍵能力審查對象當前 diff或顯式傳入的 PR 編號 / 分支名 / 路徑目標審查范圍正確性缺陷correctness bugs以及復(fù)用reuse、簡化simplification、效率efficiency等清理類問題三種收尾方式默認輸出審查報告加--comment把發(fā)現(xiàn)發(fā)布為 PR 內(nèi)聯(lián)評論加--fix把發(fā)現(xiàn)直接應(yīng)用到工作區(qū)。--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用于控制上報上限且最近一次的選擇會持續(xù)生效直到傳入--max-findings default——這意味著--fix之后仍可繼續(xù)執(zhí)行常規(guī)審查選擇狀態(tài)是持久的。--fix模式的核心行為契約part 9 fix application 全文圍繞一個前提展開The--fixflag was passed.。它定義了審查在--fix下的完整行為可拆解為以下四層契約1. 修復(fù)而非報告審查的終點變成工作區(qū)After producing the findings list, apply the findings to the working tree instead of stopping at the report: fix each one directly.這是--fix與默認模式最根本的區(qū)別。默認模式在產(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的審查范圍完全對齊并不局限于嚴重缺陷correctness bugs如反轉(zhuǎn)/錯誤的條件、off-by-one、空值/undefined 解引用、缺失的await、被吞掉的異常、復(fù)制粘貼導(dǎo)致的錯誤變量引用等運行時正確性問題reuse / simplification / efficiency cleanups復(fù)用已有 helper、簡化重復(fù)邏輯、消除死代碼、優(yōu)化冗余計算等代碼衛(wèi)生問題。這一點與命令描述中的 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ù)要求的邊界語義、兼容性兜底需要改動遠超審查 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)本身不成立第一、三類兩種不同的跳過動機。4. 跳過要記錄而非爭論note the skip rather than arguing with it.這是--fix模式的一條紀律性要求對于被跳過的發(fā)現(xiàn)只需簡明記錄跳過理由不要與發(fā)現(xiàn)的提出者展開辯論、也不要試圖自我說服后強行修復(fù)。這條規(guī)則的目的在于讓修復(fù)動作保持單向、高效——修復(fù)通過驗證的發(fā)現(xiàn)記錄有合理理由的跳過避免在單個發(fā)現(xiàn)上消耗過多輪次。修復(fù)之后的收尾條件化雙分支part 9 提示詞的最后一部分是一個模板條件表達式根據(jù)當前會話是否具備報告發(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 工具當HAS_REPORT_FINDINGS_TOOL為真時修復(fù)完成后仍需調(diào)用ReportFindings工具做一次結(jié)構(gòu)化匯報隨后逐條說明跳過原因。這套收尾與 part 10 ReportFindings output format 定義的輸出契約銜接一次調(diào)用{level, findings}findings按嚴重度降序排列每條包含file、line、summary、short_summary壓縮到 ≤60 字符、不含理由或后果、failure_scenario、category如correctness、simplification、efficiency、reuse、altitude、conventions、test-coverage以及驗證通過時產(chǎn)生的verdict。值得說明的是--fix模式下工具調(diào)用的角色與默認模式略有不同默認模式下工具調(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 工具當工具不可用時收尾退化為純文本簡要總結(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)清單從何而來、如何被驗證。從倉庫中維護的配套提示詞可以看出完整鏈路上游 1發(fā)現(xiàn)階段finder angles在進入--fix之前審查先要產(chǎn)出候選發(fā)現(xiàn)?；A(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 級別會擴展此階段medium/high 模式part 6、part 7運行 8 個獨立 finder 角度3 個正確性角度 3 個清理角度 1 個 altitude 角度 1 個 conventions 角度每個角度最多產(chǎn)出 6 個候選extra-high/max 模式part 3運行 10 個角度、每角度最多 8 個候選并強調(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機制真實但觸發(fā)條件不確定需說明何種條件可證實它、REFUTED事實錯誤或已被其他守衛(wèi)覆蓋需引用證明行recall 偏向驗證part 5默認視為 PLAUSIBLE除非能從代碼構(gòu)造出 REFUTED——如事實錯誤、類型/常量/不變量證明不可能、本次 diff 中已處理、或純風(fēng)格無可觀察影響。這一階段直接決定了--fix的修復(fù)面三態(tài)驗證下 CONFIRMED 與 PLAUSIBLE 進入修復(fù)候選recall 偏向下幾乎全部非 REFUTED 候選進入修復(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當目標為 GitHub PR 時通過mcp__github_inline_comment__create_inline_comment逐條發(fā)布內(nèi)聯(lián)評論僅當建議塊能完整修復(fù)問題時才附帶 suggestion block工具不可用時回退到gh api repos/{owner}/{repo}/pulls/{pr}/comments目標非 PR 時打印發(fā)現(xiàn)并注明--comment被忽略GitLab comment posting當目標為 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)直接寫進代碼且兩者都遵循目標不匹配則降級為終端打印并注明標志被忽略的兜底策略。--fix提示詞的版本演進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強化上報約 2.1.199當發(fā)現(xiàn)上報工具可用時要求--fix運行將每個發(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)不再強制逐條上報fixed/no_change_needed/skipped結(jié)局而是有工具就調(diào)用一次結(jié)構(gòu)化上報 逐行說明跳過原因無工具就總結(jié)修復(fù)與跳過。這一演進體現(xiàn)了提示詞作者對匯報成本 vs 留痕價值的平衡——修復(fù)本身已是最充分的證據(jù)逐條結(jié)局重報是冗余的。實戰(zhàn)建議如何用好--fix基于上述行為契約與流水線關(guān)系歸納幾條實操建議在改動較小的 diff 上使用--fix跳過判據(jù)之一就是修復(fù)需要改動遠超審查 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ū)上運行避免修復(fù)結(jié)果與未提交改動混雜這與 tool-description-bash-maintain-cwd.md 中g(shù)it 命令直接作用于當前工作樹的約束一致。小結(jié)--fix是 Claude Code/code-review命令從審查工具走向?qū)彶? 修復(fù)工作流的關(guān)鍵開關(guān)。以 part 9 fix application 為骨架可以看到一整套嚴謹?shù)墓こ淘O(shè)計修復(fù)優(yōu)先而非報告優(yōu)先的行為轉(zhuǎn)向、正確性缺陷與清理類問題同等的修復(fù)范圍、三類明確的跳過判據(jù)改變預(yù)期行為 / 超出 diff 范圍 / 誤報、記錄跳過而非爭論的紀律以及條件化的收尾匯報工具可用則結(jié)構(gòu)化上報 逐行跳過理由否則簡要總結(jié)。配合倉庫中維護的 finder 階段、驗證階段與 ReportFindings 輸出契約--fix構(gòu)成了一個完整、可審計的發(fā)現(xiàn)—驗證—修復(fù)—匯報閉環(huán)也為--comment發(fā)布到 GitHub/GitLab之外的審查結(jié)果落地提供了另一條高效路徑。贊分享文檔提示工程人工智能【免費下載鏈接】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點擊查看免費下載相關(guān)推薦基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機制深度解析基于 Claude Code 的多智能體 PR 自動審查Code Review Plugin 工作流與置信度過濾機制深度解析 本文以 Claude CodeAI 插件開發(fā)工具插件系統(tǒng)gsd-core 代碼審查自動修復(fù)調(diào)度修復(fù)/gsd-code-review --fix 標志從靜默丟棄到完整鏈路gsd core 代碼審查自動修復(fù)調(diào)度修復(fù) /gsd code review fix 標志從靜默丟棄到完整鏈路 本篇技術(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），僅供參考