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