84條Claude Code最佳實踐，我挑了10條最值得用的
整理版優先睇
10條最好用嘅Claude Code最佳實踐，由84條精選出嚟
呢篇文係由魯工整理，佢係一個Claude Code老玩家，見到GitHub上有個叫claude-code-best-practice嘅倉庫衝到Trending前排，有20k+ Star。作者將Claude Code嘅最佳實踐整理咗84條，魯工逐條睇曬，揀咗10條佢自己用過或者驗證過最實用嘅出嚟。
整體結論係：Claude Code要玩得好，關鍵係精簡配置、規劃先行、善用工具嘅特性（例如Plan Mode、子代理），同埋注意上下文管理。作者分享咗自己踩過嘅坑，例如CLAUDE.md塞到500行導致Claude忽略規則，或者硬撐到上下文用盡先compact。
魯工嘅整理角度係實戰派，每條都附帶個人經驗，例如點樣用AskUserQuestion工具幫手發現邊界情況，或者用「scrap this and implement the elegant solution」呢句咒語。文章希望讀者可以避開常見誤區，直接套用最有效嘅方法。
- CLAUDE.md要精簡到60行以內，只寫Claude容易忽略嘅內容，必要時用.claude/rules/拆分文件。
- 複雜任務先進入Plan Mode做調研規劃，確認方向先執行，唔好一嚟就寫Code。
- 讓Claude用AskUserQuestion工具採訪你，問清楚細節，然後開新會話執行，避免上下文污染。
- 對平庸方案直接要求重寫「Knowing everything you know now, scrap this and implement the elegant solution」，效果好過修修補補。
- 上下文使用率到50%就要手動/compact，唔好等系統自動，否則Claude會入agent dumb zone表現下降。
精簡CLAUDE.md，複雜任務唔好一嚟就寫Code
CLAUDE.md要精簡到60行以內
呢條係魯工踩過最大嘅坑。佢以前塞咗500行入CLAUDE.md，結果Claude經常忽略後面嘅規則。根據Boris Cherny（Claude Code之父）解釋，前沿LLM可靠跟隨約150-200條指令，但系統提示已經佔咗50條，所以剩低嘅空間唔多。HumanLayer團隊建議控制在60行以內，300行係硬上限。
另外，複雜任務一定要先用Plan Mode。按Shift+Tab兩次進入，Claude只做調研唔寫Code，確認計劃先切返Normal Mode。Anthropic官方推薦四步：Explore → Plan → Implement → Commit。
先Plan再動手，效率高好多
採訪後重開會話，平庸方案直接重寫
將簡單需求描述俾Claude，佢會用AskUserQuestion工具採訪你，問清楚細節。魯工做API嘅時候，Claude問咗「併發請求點處理」、「超時策略係咩」呢啲佢一開始冇諗到嘅問題。關鍵係採訪完要開新會話，唔好留喺同一上下文入面。
採訪過程嘅對話會污染上下文，所以一定要開新會話執行
Claude俾咗個「用得但唔優雅」嘅方案時，唔好喺上面修修補補。直接話「Knowing everything you know now, scrap this and implement the elegant solution」，Claude會基於全部理解重新設計。魯工試咗幾次，重寫版確實比修補版好。
Bug貼fix就夠，用subagents分工
遇到bug，簡單貼錯誤信息然後話「fix」，唔好指導點修、唔好猜原因。Claude定位問題嘅能力比想像中強，越微操越容易帶偏。魯工體驗係直接fix成功率超過80%，兩次搞唔掂就/clear清上下文重來。
直接話「fix」就得，唔好微操
另外，喺Prompt入面直接話「use subagents」，Claude會拆任務俾多個子代理並行處理。尤其係代碼審查同大規模重構時好用。有人用9個並行子代理做code review，每個聚焦一個質量維度。魯工建議：子代理要功能特定（例如「前端組件agent」），唔好做通用「QA agent」。
Skills用文件夾結構，建Gotchas部分
好多人創建Skill就寫一個SKILL.md，但倉庫強調應該用完整文件夾結構：SKILL.md主文件加上references/、scripts/、examples/子目錄。咁樣Claude只喺需要時先讀子目錄內容，唔會所有嘢塞入上下文。魯工將自己嘅論文寫作Skill改成呢種結構後，效果提升好明顯。
漸進式披露係Skills嘅關鍵
仲有一條長期有用嘅技巧：喺每個Skill入面建一個Gotchas部分，每次Claude犯錯就將失敗模式記低。時間一長，呢部分會變成信噪比最高嘅內容。魯工記錄咗十幾種AI味模式，初稿質量提升一個檔次。
上下文用到50%就compact，走偏就兩下Esc回滾
Claude Code有個agent dumb zone，上下文使用率超過60-70%時表現明顯下降，容易忽略指令、出低級錯誤。倉庫建議到50%就手動執行/compact，唔好等系統自動。魯工之前成日一個會話幹到底，而家50%就compact或/clear換新會話，效果好唔少。可以用/statusline監控使用率，顏色編碼提醒。
到50%就手動/compact，唔好等到系統自動
Claude走偏咗點算？唔好喺當前會話糾正，按兩下Esc（或/rewind）直接回滾到上一個checkpoint。因為前面嘅錯誤推理仲留喺上下文，會越改越偏。魯工習慣：走偏就Esc Esc回滾，偏兩次就/clear重來。
- 小任務（例如改變量名）直接用原生Claude Code，唔好行完整工作流，原生最快。
- 複雜工作流係為多文件多步驟嘅大任務設計，三五分鐘做完嘅事，原生Claude Code已經夠快。
大家好，我係魯工。
前排喺GitHub Trending上，見到一個叫claude-code-best-practice嘅倉庫衝到咗前幾名。20k+Star，撳入去睇，作者整理咗84條Claude Code最佳實踐，由Prompting到CLAUDE.md到Skills到除錯，好全面。
倉庫地址：
https://github.com/shanraisshan/claude-code-best-practice
作為一個Claude Code老玩家，我週末用咗兩個幾鐘逐條睇曬。有啲技巧我早就用緊，有啲睇完覺得好精妙，仲有啲令我發現自己一路以嚟行錯路。我由裏面揀咗10條最實用嘅，每條都係我之前用過或者驗證過效果嘅最佳實踐。
1 CLAUDE.md要精簡，60行就夠用啦
呢個係我踩過最大嘅坑。
舊年我啱開始玩CC嗰陣，我喺CLAUDE.md入面塞咗差唔多500行，項目說明、代碼規範、API文檔全部堆曬入去。結果Claude成日揀嚟忽略規則，尤其係後面嘅內容。
後來睇到Boris Cherny（Claude Code之父）嘅解釋先至明：前沿LLM可以可靠噉跟隨大概150到200條指令，而Claude Code嘅系統提示已經佔咗50條左右。留俾你嘅空間其實冇咁多。根據公開資料，HumanLayer團隊嘅做法係控制在60行之內，300行係硬上限。
我後來嘅做法係淨係寫Claude容易忽略嘅內容：構建命令、測試命令、分支命名規範、項目特有嘅架構決策。Claude睇代碼就推斷到嘅資訊，唔使寫喺裏面。如果規則真係太多，就用.claude/rules/目錄拆做多個小文件，按需要載入。關鍵規則可以用<important if="...">標籤包住，防止被忽略。
2 複雜任務先入Plan Mode
呢條Boris本人講過唔止一次。而且而家都應該係大家玩CC嘅共識。
複雜任務開始之前，先撳Shift+Tab兩次進入Plan Mode。呢個模式下Claude淨係做調研同規劃，唔寫代碼。等計劃確認咗之後再切返Normal Mode執行。
我初期都習慣直接開工，結果成日Claude寫咗一大堆代碼方向錯曬，要推倒重來。而家先Plan先動手，效率會高好多。Anthropic官方推薦嘅流程係四步：Explore → Plan → Implement → Commit小任務可以直接開工，但係稍微複雜啲嘅功能一定要行Plan。
3 叫Claude先訪問你先動手
先俾Claude一個簡單嘅需求描述，叫佢用AskUserQuestion工具來訪問你，問清楚啲細節。訪問完之後，新開一個會話執行。
我整一個API嘅時候，Claude問咗我「併發請求點處理」、「超時策略係咩」，呢啲我一開始根本都冇諗到。佢提出嘅問題往往可以幫你發現冇諗到嘅邊界情況。
關鍵係訪問完要開新會話。訪問過程產生嘅大量對話留喺上下文裏面，反而影響後續執行質量。
4 對平庸方案直接要求重寫
呢條係Boris團隊Tips入面我最鍾意嘅。
Claude俾咗一個用得但唔優雅嘅方案嗰陣，唔好喺上面修修補補。直接講「knowing everything you know now, scrap this and implement the elegant solution」。Claude會根據佢對問題嘅全部理解重新設計方案，我試咗好幾次，重寫版真係比修補版好好多。
類似嘅仲有「prove to me this works」，叫Claude自己diff當前分支同main嚟證明改動正確。
5 貼bug講fix，唔好玩微操
呢條可能係84條入面最反直覺嘅。
遇到bug，將錯誤信息貼俾Claude，講一個字「fix」。唔好指導點樣修，唔好估原因，唔好規定方案。Claude定位問題嘅能力比大多數人想像嘅強，你越微操越容易帶偏佢。我自己嘅體驗係，直接叫Claude修嘅成功率喺80%以上。
修咗兩次搞唔掂就唔好死磕，/clear 清上下文換個角度重來。Anthropic官方都建議糾正超過2次就應該重啓。
呢條其實我之前都鍾意用力過猛，修bug嘅時候仲補充描述一大堆，而家睇返係多此一舉。
6 直接喺提示詞入面講use subagents
喺prompt入面直接講「use subagents」，Claude會將任務拆俾多個子代理並行處理。
代碼審查同大規模重構嗰陣特別好用。根據公開資料，有人用9個並行子代理做code review，每個專注一個質量維度。我喺做跨文件重命名嘅時候用過，Claude開咗3個子代理分頭做，比單線程快唔少，主上下文都冇被搜索結果污染。
呢度有個小技巧：開subagents嗰陣，整功能特定嘅（例如「前端組件agent」），唔好整通用嘅「QA agent」。功能越具體，攜帶嘅上下文越精準，效果越好。
7 Skills整成文件夾，開Gotchas部分
好多人（包括之前嘅我）開Skill就寫一個SKILL.md就算。
倉庫強調Skills應該係完整嘅文件夾結構：SKILL.md主文件再加上 references/、scripts/、examples/子目錄。呢種漸進式披露先係Skills嘅關鍵，Claude淨係喺需要嘅時候先讀子目錄內容，唔會將所有嘢一次過塞入上下文。
我將自己嘅論文寫作Skill改成文件夾結構之後，效果提升好明顯。之前所有規範塞一個文件入面，Claude成日漏細節。而家主文件淨係放核心規則同索引，語料庫、檢查清單放references/下面。
仲有一條長期特別有用嘅技巧：喺每個Skill入面開一個Gotchas（踩坑記錄）部分，每次Claude犯錯就將失敗模式記入去。時間一長，呢部分會變成信噪比最高嘅內容。我嘅論文寫作Skill入面記錄咗十幾種AI味模式，加咗之後初稿質量提升咗一個檔次。
8 上下文到50%就手動compact
呢條係工作流層面最關鍵嘅。
Claude Code有個所謂嘅agent dumb zone，上下文使用超過60%到70%嗰陣表現會明顯下降，容易忽略指令，代碼出低級錯誤。倉庫建議到50%就手動執行/compact，唔好等系統自動compact，嗰陣往往已經太遲。
我之前成日一個會話做到尾，或者到10%左右先至手動compact，我嘗試50%就compact或者/clear換新會話，效果好好多。可以用/statusline 實時監控使用率，Boris團隊嘅腳本仲會用顏色編碼提醒：綠色安全、黃色注意、紅色危險。
9 走偏咗撳Esc Esc回滾
Claude走偏咗點算？大多數人嘅本能係喺當前會話入面糾正。
倉庫建議撳兩下Esc（或者 /rewind）直接回滾到上一個checkpoint。喺同一個上下文入面修偏差，往往越改越偏，因為前面嘅錯誤推理仲喺上下文入面，Claude會被自己嘅錯誤思路帶住走。
我而家嘅習慣係：走偏咗Esc Esc回滾，同一個問題偏咗兩次就 /clear重來。
10 小任務唔好用複雜工作流
倉庫入面有條特別清醒嘅建議：原生Claude Code處理小任務，比任何複雜工作流都好。
我之前犯過呢個錯，改個變量名都行完整嘅Plan → Execute → Review流程。其實直接講一句話就得。嗰啲複雜工作流（Superpowers、Spec Kit、BMAD-METHOD之類）係為多文件多步驟嘅大任務設計嘅，三五分鐘做得完嘅事，原生Claude Code最快。
以上10條係我從84條入面揀出嚟嘅，完整版喺倉庫入面，值得由頭睇一次。作者仲整理咗8個主流工作流嘅橫向對比同Boris Cherny嘅全部訪談連結，資訊密度相當高。
如果覺得有用，撳個讚或者睇嚇，方便更多朋友睇到。我係魯工，九年AI算法老兵，AI全棧開發者，深耕AI編程賽道。有興趣嘅朋友都可以加我微信（louwill26_）交個朋友。
大家好，我是魯工。
前段時間在GitHub Trending上，看到一個叫claude-code-best-practice的倉庫衝到了前幾名。20k+Star，點進去一看，作者把Claude Code的最佳實踐整理了84條，從Prompting到CLAUDE.md到Skills到調試，相當全面。
倉庫地址：
https://github.com/shanraisshan/claude-code-best-practice
作為一個Claude Code老玩家，我週末花了兩個多小時逐條看完。有些技巧我早就在用，有些看完覺得非常精妙，還有些讓我發現自己一直在走彎路。我從裏面挑了10條最實用的，每條都是我之前用過或者是驗證過效果的最佳實踐。
1 CLAUDE.md要精簡，60行夠用了
這是我踩過最大的坑。
去年我剛開始玩CC的時候，我往CLAUDE.md裏塞了快500行，項目說明、代碼規範、API文檔全往裏堆。結果Claude經常選擇性忽略規則，尤其是靠後面的內容。
後來看到Boris Cherny（Claude Code之父）的解釋才明白：前沿LLM能可靠跟隨大約150到200條指令，而Claude Code的系統提示已經佔了50條左右。留給你的空間其實沒那麼多。根據公開信息，HumanLayer團隊的實踐是控制在60行以內，300行是硬上限。
我後來的做法是隻寫Claude容易忽略的內容：構建命令、測試命令、分支命名規範、項目特有的架構決策。Claude讀代碼就能推斷的信息，不用寫在裏面。如果規則實在多，就用.claude/rules/目錄拆分成多個小文件，按需加載。關鍵規則可以用<important if="...">標籤包裹，防止被忽視。
2 複雜任務先進Plan Mode
這條Boris本人說過不止一次。並且現在也應該是大家玩CC的共識了。
複雜任務開始前，先按Shift+Tab切兩次進入Plan Mode。這個模式下Claude只做調研和規劃，不寫代碼。等計劃確認了再切回Normal Mode執行。
我早期也習慣直接上手幹，結果經常Claude寫了一堆代碼方向不對，推倒重來。現在先Plan再動手，效率會高很多。Anthropic官方的推薦流程是四步：Explore → Plan → Implement → Commit。小任務可以直接開幹，單稍微複雜點的功能一定要走Plan。
3 讓Claude先採訪你再動手
先給Claude一個簡單的需求描述，讓它用AskUserQuestion工具來採訪你，把細節問清楚。採訪完了，新開一個會話執行。
我做一個API的時候，Claude問了我"併發請求怎麼處理"、"超時策略是什麼"，這些我一開始壓根都沒想到。它提的問題往往能幫你發現沒想到的邊界情況。
關鍵是採訪完要開新會話。採訪過程產生的大量對話留在上下文裏，反而影響後續執行質量。
4 對平庸方案直接要求重寫
這條是Boris團隊Tips裏我最喜歡的。
Claude給了一個能用但不優雅的方案時，別在上面修修補補。直接說"knowing everything you know now, scrap this and implement the elegant solution"。Claude會基於它對問題的全部理解重新設計方案，我試了好幾次，重寫版確實比修補版好很多。
類似的還有"prove to me this works"，讓Claude自己diff當前分支和main來證明改動正確。
5 貼bug說fix，別玩微操
這條可能是84條裏最反直覺的。
遇到bug，把錯誤信息貼給Claude，說一個字"fix"。不要指導怎麼修，不要猜原因，不要規定方案。Claude定位問題的能力比大多數人想象的強，你越微操越容易把它帶偏。我自己的體驗是，直接讓Claude修的成功率在80%以上。
修了兩次沒搞定就別死磕，/clear 清上下文換個角度重來。Anthropic官方也建議糾正超過2次就該重啓。
這條其實我之前也喜歡用力過猛，修bug的時候也補充描述一大堆，現在來看是多此一舉了。
6 直接在提示詞裏說use subagents
在prompt裏直接說"use subagents"，Claude會把任務拆給多個子代理並行處理。
代碼審查和大規模重構時特別好用。根據公開資料，有人用9個並行子代理做code review，每個聚焦一個質量維度。我在做跨文件重命名時用過，Claude開了3個子代理分頭幹，比單線程快不少，主上下文也沒被搜索結果污染。
這裏有個小技巧：建subagents的時候，做功能特定的（比如"前端組件agent"），別做通用的"QA agent"。功能越具體，攜帶的上下文越精準，效果越好。
7 Skills做成文件夾，建Gotchas部分
很多人（包括之前的我）創建Skill就寫一個SKILL.md完事。
倉庫強調Skills應該是完整的文件夾結構：SKILL.md主文件加上 references/、scripts/、examples/子目錄。這種漸進式披露才是Skills的關鍵，Claude只在需要時才讀子目錄內容，不會把所有東西一次性塞進上下文。
我把自己的論文寫作Skill改成文件夾結構後，效果提升很明顯。之前所有規範塞一個文件裏，Claude經常漏細節。現在主文件只放核心規則和索引，語料庫、檢查清單放references/下。
還有一條長期特別有用的技巧：在每個Skill裏建一個Gotchas（踩坑記錄）部分，每次Claude犯錯就把失敗模式記進去。時間一長，這部分會變成信噪比最高的內容。我的論文寫作Skill裏記錄了十幾種AI味模式，加了之後初稿質量提升了一個檔次。
8 上下文到50%就手動compact
這條是工作流層面最關鍵的。
Claude Code有個所謂的agent dumb zone，上下文使用超過60%到70%時表現會明顯下降，容易忽略指令，代碼出低級錯誤。倉庫建議到50%就手動執行/compact，別等系統自動compact，那時候往往已經晚了。
我之前經常一個會話幹到底，或者到10%左右才會手動compact，我嘗試50%就compact或者/clear換新會話，效果好很多。可以用/statusline 實時監控使用率，Boris團隊的腳本還會用顏色編碼提醒：綠色安全、黃色注意、紅色危險。
9 走偏了按Esc Esc回滾
Claude走偏了怎麼辦？大多數人的本能是在當前會話裏糾正。
倉庫建議按兩下Esc（或 /rewind）直接回滾到上一個checkpoint。在同一個上下文裏修偏差，往往越改越偏，因為前面的錯誤推理還在上下文裏，Claude會被自己的錯誤思路帶着跑。
我現在的習慣是：走偏了Esc Esc回滾，同一個問題偏了兩次就 /clear重來。
10 小任務別用複雜工作流
倉庫裏有條特別清醒的建議：原生Claude Code處理小任務，比任何複雜工作流都好。
我之前犯過這個錯，改個變量名都走完整的Plan → Execute → Review流程。其實直接說一句話就行了。那些複雜工作流（Superpowers、Spec Kit、BMAD-METHOD之類）是為多文件多步驟的大任務設計的，三五分鐘能做完的事，原生Claude Code最快。
以上10條是我從84條裏篩出來的，完整版在倉庫裏，值得通讀一遍。作者還整理了8個主流工作流的橫向對比和Boris Cherny的全部訪談連結，信息密度相當高。
如果覺得有用，點個贊或者在看，也方便更多朋友看到。我是魯工，九年AI算法老兵，AI全棧開發者，深耕AI編程賽道。感興趣的朋友也可以加我微信（louwill26_）交個朋友。