Claude Code 團隊的 10 個內部技巧，但你不一定都要學
整理版優先睇
Claude Code 團隊嘅10個內部技巧：揀啱自己嘅先用，唔使全部學
呢篇文章係作者根據 Claude Code 團隊分享嘅10條內部技巧，再加上自己嘅實戰經驗同解讀，按難度分層整理出嚟。作者想解決嘅問題係：點樣有效率咁用 Claude Code 嚟提升開發效率，同時避免盲目跟從。整體結論係：冇唯一正確嘅使用方式，每個人都要按自己嘅情況去揀技巧，唔好照單全收。
團隊公認最有效嘅技巧係並行運行，用 git worktrees 同時開幾個會話，但呢個方法需要好高嘅注意力管理能力，唔係個個適合。Plan Mode 就啱複雜任務，強迫你先諗清楚再做，減少後續改錯。另外，投資喺 CLAUDE.md 同自定義 Skills 係性價比最高嘅做法，可以累積經驗，產生複利效應。
作者特別提醒，技巧只係起點，唔係終點。例如 CLAUDE.md 唔好塞太多內容，要精簡；Skill 唔好濫用，淨係將每日做兩次以上嘅嘢自動化。最緊要係透過實踐揾到自己嘅 workflow，先係最有效嘅用法。
- 團隊最推薦並行運行（git worktrees），但需要高注意力管理，初學者唔一定要跟。
- Plan Mode 喺複雜任務前先用，強迫釐清需求，確保 Claude 理解意圖，減少後續改錯。
- CLAUDE.md 係性價比最高嘅投資，每次糾正完錯誤就叫 Claude 自己更新規則，累積經驗。
- 自定義 Skills 將每日做兩次以上嘅任務自動化，例如 /commit-push-pr，可以跨項目複用。
- 開啓 Explantory 輸出風格，用 Claude 學新嘢，例如叫佢生成 HTML 幻燈片解釋唔熟嘅代碼。
自動更新 CLAUDE.md
每次糾正 Claude 錯誤後，用呢句 prompt 叫佢自己寫規則：「Update your CLAUDE.md so you don't make that mistake again.」
推倒重來 prompt
當 Claude 方案唔夠好，直接講：「Knowing everything you know now, scrap this and implement the elegant solution.」記住先回滾代碼，再開新會話。
AI 審核 prompt
叫 Claude 反過來考你：「Grill me on these changes and don't make a PR until I pass your test.」或者「Prove to me this works.」
/commit-push-pr
一鍵完成提交、推送、創建 PR 嘅整個流程，Boris 每日用幾十次。可以寫成 skill 放喺項目度。
並行運行同 Plan Mode：改變工作模式嘅兩個核心技巧
團隊公認最大效率提升係 並行運行，做法係用 git worktrees 同時檢出 3-5 個工作目錄，每個目錄開一個獨立 Claude Code 會話。例如目錄 A 重構，目錄 B 寫測試，目錄 C 改文檔，三件事同步推。
瓶頸從「等 AI 生成」變咗做「注意力點樣分配」
呢個技巧改變咗成個工作模式，但唔適合所有人。因為 git worktrees 操作有啲麻煩，同埋並行任務會令你頻繁切換大腦線程，對編程呢類需要專注嘅工作係挑戰。作者自己就偏好簡單啲嘅方法：直接 checkout 幾份倉庫（clawbot-1、clawbot-2...），邊個空閒用邊個。
團隊有人更進一步：叫一個 Claude 寫計劃，另一個以「高級工程師」身份審核計劃，即係 AI 審 AI。重要補充：如果做做嚇走歪咗，要即刻返 Plan Mode 重新規劃，唔好硬推。
CLAUDE.md 同 Skills：性價比最高嘅複利投資
CLAUDE.md 係放喺項目根目錄嘅檔案，Claude Code 每次啟動都會讀。你可以喺入面寫代碼規範、設計原則、PR 模板、常見錯誤提醒——任何你想 Claude 記住嘅嘢。團隊最關鍵嘅做法：每次糾正 Claude 錯誤之後，叫佢自己更新 CLAUDE.md，用嘅 prompt 係「Update your CLAUDE.md so you don't make that mistake again. 」
至於 Skills，如果你有一件事每日做兩次以上，就值得整成 skill 或者 slash command。例如 /commit-push-pr 可以一鍵完成提交、推送、創建 PR。Boris 話佢每日用呢個 command 幾十次。Skill 可以提交到 git，跨項目複用，將一個項目積累嘅自動化帶到下一個項目。
- 將常用工作流程自動化，例如 /commit-push-pr、/code-review-sweep（清理重複代碼）。
- 進階用法：用 skill 整合 Slack、Google Drive、Asana、GitHub 活動，一鍵獲取「呢個星期發生咗乜」嘅全景視圖。
- 亦有人用 skill 整咗「數據分析工程師」agent，自動寫 dbt 模型、審核代碼、測試變更。
Bug 修復同 Prompting 技巧：俾多啲信任，收窄要求
團隊經驗係：大部分 bug，Claude 自己就可以修好。你只需要俾夠上下文同權限，然後信任佢。例如將 Slack 上嘅 bug 貼過去，淨係講一句「fix」，Claude 就會自己睇代碼、理解問題、修復。或者 CI 測試失敗，直接講「Go fix the failing CI tests.」唔好微管理。
提升 Prompting 有幾招：第一，叫 Claude 反過來考你，例如「Grill me on these changes and don't make a PR until I pass your test.」第二，如果方案唔夠好，直接推倒重來：「Knowing everything you know now, scrap this and implement the elegant solution.」記得先回滾代碼，再開新會話。
喺當前會話繼續改，之前嘅錯誤信息可能幹擾 Claude 判斷
第三，減少歧義：spec 寫得越詳細越好。人係懶嘅，但 Plan Mode 可以幫你確認 Claude 聽明你講乜。
終端環境配置同 Subagents：進階玩家嘅提升工具
團隊好多人用 Ghostty 終端，因為有同步渲染、24 位真彩色、完善 unicode 支持，對開多個 Claude 會話好重要。亦有人用 tmux 管理會話，每個 tab 上色命名，一個 tab 對應一個 task 或 worktree。
用 /statusline 自定義狀態欄，顯示 context 用量同 git 分支
另外一個易忽略嘅建議：用 語音輸入。講嘢速度係打字嘅三倍，而且用語音時你會不自覺講得更詳細，prompt 質量反而更高。macOS 按兩下 fn 鍵就啟動。
進階玩法：用 hook 將權限請求路由俾 Opus 4.5，讓最強模型判斷邊啲操作可以自動批准，邊啲需要人手確認，相當於加咗個「安全審核員」。
數據分析同學習：Claude Code 嘅另類用法
Anthropic 團隊將 BigQuery 封裝成一個 skill，所有人可以直接喺 Claude Code 用 bq 命令行查數據。Boris 話佢已經六個月冇寫過一行 SQL。呢個唔限於 BigQuery，任何有 CLI、MCP 或 API 嘅數據庫都可以咁用，例如 PostgreSQL、MySQL、MongoDB。
團隊嘅數據科學家都開始用 Claude Code 寫查詢、做可視化
至於用 Claude Code 學習，首先喺 /config 開啟「Explanatory」或「Learning」輸出風格，令 Claude 解釋點解咁改，而唔係淨係改完就算。另外，可以叫 Claude 生成 HTML 幻燈片 嚟解釋唔熟嘅代碼，或者畫 ASCII 圖 解釋協議、架構、數據流。
Claude Code 團隊分享嘅 10 條內部技巧，已經好多人分享過，大部份我都係結合自己經驗解讀嚇。
其中最重要嘅一句話係：「冇唯一正確嘅使用方式，每個人嘅設置都唔一樣。」
我按難度分咗層，再加上自己嘅理解同背景資料。
【1】並行運行：團隊公認嘅第一大效率提升，但您唔一定要學
呢個係團隊最推薦嘅技巧，但唔一定係你要學嘅技巧。
做法係用 git worktrees 同時 checkout 3-5 個工作目錄，每個目錄行一個獨立嘅 Claude Code 會話。例如目錄 A 重構模塊，目錄 B 寫測試，目錄 C 改文檔。三件事並行推進。
Git worktree 係乜嘢？ 等你可以喺同一個倉庫入面同時打開多個分支嘅工作目錄，唔使來回切換。命令大概係 git worktree add ../feature-a feature-a。
相關文檔：https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees
團隊入面有人俾 worktree 目錄配 shell 快捷鍵（za、zb、zc），一鍵跳轉。仲有人專門留一個「分析專用」嘅 worktree，只用嚟睇日誌、行查詢，唔寫代碼。
Boris 本人用多個 git checkout 而唔係 worktree，但團隊大多數人更鍾意 worktree。Claude Desktop 應用為此專門加咗原生支援。
點解佢哋將呢個排第一？ 因為佢改變嘅係成個工作模式。由「一次做一件事」變成「同時推進多件事」。瓶頸由「等 AI 生成」變咗做「我嘅注意力點樣分配」。
呢個用法唔一定適合所有人。
首先 git worktree 操作比較麻煩（可以俾 Claude Code 幫你做）。我個人更鍾意 ClawdBot（一個開源嘅 Claude 客戶端）作者 Peter 嘅方式，分幾個目錄，比 worktree 簡單：
佢就簡單咁 checkout 幾份倉庫：clawbot-1、clawbot-2、clawbot-3、clawbot-4、clawbot-5。邊個空閒就用邊個，做完測試、推到 main 分支、同步。
然後並行任務會令你不斷切換大腦線程，對於編程呢啲需要注意力嘅事都幾麻煩。需要一段時間練習。
我估計佢哋團隊有唔少簡單嘅 Bug 修復任務，呢類任務描述清楚之後，基本上複製貼上過去等就得。
如果係多個複雜任務並行我就唔太推薦，當然想試嚇都冇問題。
【2】Plan Mode：複雜任務先規劃再開工
Plan Mode 嘅價值唔止係「計劃」本身，而係強迫你喺開工前諗清楚到底要啲乜，同埋確保 Claude 明你想要啲乜。
好多時候我哋自己做一件事時，一開始只有模糊嘅想法，唔知咩係最優解，呢個時候直接開始寫代碼唔一定係好事，如果透過 plan 模式反覆傾嚇，可能就幫你梳理清楚，有時 Claude Code 仲有你意想不到嘅提議。
好多時候 Claude 寫出嚟嘅嘢唔啱，唔係佢唔得，係佢冇理解清楚你真正想要嘅係乜就開始寫代碼。透過 Plan Mode 反覆傾偈確認，可以確保佢理解你嘅意圖。
基本原則： 遇到複雜任務，先用 Plan Mode 同 Claude 討論方案。反覆迭代，直到你對計劃滿意，再切換到自動編輯模式俾 Claude 執行。一個好嘅計劃通常意味住 Claude 可以一次到位，唔使來回改。
團隊有人嘅做法更進一步：俾一個 Claude 寫計劃，另開一個 Claude 以「高級工程師」嘅身份審核呢個計劃。俾 AI 審 AI。
仲有一條重要嘅補充：事情一旦走偏，即刻返去 Plan Mode 重新規劃。唔好硬來，唔好俾 Claude 喺錯誤嘅方向越行越遠。有人甚至會喺驗證步驟時都切換到 Plan Mode，唔止喺「做」嘅階段。
【3】投資你嘅 CLAUDE.md
呢個可能係性價比最高嘅一個技巧。
CLAUDE.md 係放喺項目根目錄嘅文件，Claude Code 每次啟動都會讀取佢。你可以喺裏面寫代碼規範、設計原則、PR 模板、常見錯誤提醒——任何你希望 Claude 記住嘅嘢。
關鍵在於點樣維護呢個文件。團隊嘅做法係：每次糾正 Claude 嘅錯誤之後，俾佢自己更新 CLAUDE.md。
具體 prompt 可以係：「Update your CLAUDE.md so you don't make that mistake again.」
Boris 嘅原話係：「Claude is eerily good at writing rules for itself.」（Claude 非常擅長俾自己寫規則。）
團隊裏面有個工程師嘅做法更系統：佢為每個項目/任務維護一個 notes 目錄，每次 PR 後更新。然後喺 CLAUDE.md 入面指向呢啲 notes，相當於俾 Claude 建立一個持續更新嘅知識庫。
呢個思路同我成日提到嘅 Skills 迭代思路類似。通常一開始規則唔夠完善，每次遇到問題，基於當前上下文俾 Agent 自己去完善係效果最好嘅。一方面你唔需要從頭描述問題，另一方面 Agent 好善於歸納總結。
至於維護一個 notes 目錄，係一個幾好嘅積累經驗嘅做法。呢件事你唔需要自己寫，可以做一個 Skill，每次俾 Claude Code 從當前會話中覆盤，提煉成 Note。甚至可以連上 hook，每次會話結束自動執行。不過呢條我個人唔推薦，太多冇意義嘅信息唔見得係好事。
呢個技巧嘅核心係將人腦入面嘅經驗變成系統知識。時間越長，CLAUDE.md 越完善，Claude 犯嘅錯越少，你需要糾正嘅次數都越少。呢種係一種複利。
呢度需要補充一個注意事項，CLAUDE.md 唔建議放太多內容，只會適得其反，只放最重要嘅 AI 未訓練過嘅內容，更多嘅內容作為文件連結按需讀取。
好多人將設計模式、規範、最佳實踐之類嘅都放進去，先唔講呢啲 AI 都訓練過，你最多講個名就夠，就算係你需要嘅，都唔係每次都要，不如放一個連結或者移到 Skills 按需加載。
Claude Code 官方項目中 CLAUDE.md 文件都係大約 2.5k tokens：
• 常用 Bash 指令：俾 AI 知道點樣好似開發者咁操作命令行。 • 代碼風格規範 (Code Style Conventions)：確保 AI 寫嘅代碼符合團隊編碼標準。 • UI 與內容設計準則：指導 AI 點樣設計界面同編寫文案。 • 核心技術實現流程：教 AI 點樣處理狀態管理 (State Management)、日誌記錄 (Logging)、錯誤處理 (Error Handling)、功能門控 (Gating，即控制特定功能嘅開啓與關閉) 以及調試 (Debugging)。 • 代碼合併請求 (Pull Request) 模板：規範提交代碼時嘅文檔格式。
【4】建立自定義技能（Skills）
如果某件事你一日要做兩次以上，就值得將佢變成一個 skill 或者 slash command。
Skill 係一組可複用嘅指令，放喺項目裏面，用斜槓命令調用。例如 /commit-push-pr 可以一鍵完成提交、推送、建立 PR 嘅整個流程。Boris 話佢每日會用呢個命令幾十次。
團隊分享咗幾個在用嘅 skill：
• ：喺每次 session 結束時運行，俾 Claude 檢查並清理重複代碼。
仲有人建立咗一個 slash command，可以將過去 7 日嘅 Slack 消息、Google Drive 文檔、Asana 任務、GitHub 活動同步到一個上下文入面，相當於一鍵獲取「呢個星期發生咗啲乜」嘅全景視圖。
更高級嘅用法：有人用 skill 構建咗「數據分析工程師」類型嘅 agent，可以自動寫 dbt 模型、審核代碼、喺開發環境測試變更。
Skill 嘅好處係可以提交到 git，跨項目複用。你喺一個項目入面積累嘅自動化，可以帶到下一個項目。
Skill 文檔：https://code.claude.com/docs/en/skills#extend-claude-with-skills
【5】俾 Claude 自己修 Bug
團隊嘅經驗係：大多數 bug，Claude 自己就修得好。
一個常見場景：啟用 Slack MCP，將 Slack 上面嘅 bug 反饋帖子直接貼俾 Claude，然後只講一個字：「fix」。唔需要解釋上下文，唔需要手動定位問題。Claude 會自己去睇代碼、理解問題、修復。
另一個場景：CI 測試死咗。直接話俾 Claude：「Go fix the failing CI tests.」唔好微管理佢點做，等佢自己去睇日誌、揾原因、改代碼。
更複雜嘅場景：分佈式系統出問題，將 docker logs 指俾 Claude，等佢幫你排查。Boris 話 Claude 喺呢方面「surprisingly capable」（能力出乎意料地強）。
Boris 冇講嘅係，描述 Bug 嘅時候要清楚：
• 點樣重現問題 • 預期嘅結果 • 實際嘅問題，例如錯誤日誌、截圖等等
換個角度講，假設係個程式員，睇咗你嘅 Bug 描述都知係咩一回事。有咗呢啲基本資訊，AI 先有足夠嘅上下文去定位同驗證問題。
呢個技巧嘅核心係俾 Claude 足夠嘅上下文同權限，然後信任佢。唔需要一步步指揮，等佢自己閉環。
所以你睇，呢個先係佢哋能夠多任務嘅重要原因——好多 Bug 都係 Claude Code 自己修得到嘅。
【6】提升你嘅 Prompting 技巧
呢一部分有幾個具體嘅招數。
第一招：俾 Claude 嚟考你
Prompt 示例：「Grill me on these changes and don't make a PR until I pass your test.」（針對呢啲改動考我，直到我通過測試先可以提 PR。）
或者：「Prove to me this works.」（向我證明呢個 work 到。）俾 Claude 對比 main 分支同你嘅 feature 分支嘅行為差異。
呢個相當於將 Claude 由「執行者」變咗做「審核者」。等佢反過來 review 你。
第二招：推倒重來
當 Claude 俾出嘅方案唔夠好，唔好喺上面打補丁。直接講：「Knowing everything you know now, scrap this and implement the elegant solution.」（基於你而家知道嘅所有資訊，掉咗呢個方案，實現一個更優雅嘅版本。）
我通常會用 git 將代碼回滾到修改前，然後新開會話、調整提示詞再嚟過。喺當前會話繼續嘅話，之前嘅錯誤信息可能會干擾 Claude 嘅判斷。
第三招：減少歧義
交代任務時，spec 寫得越詳細越好。你越具體，Claude 嘅輸出越準確。呢個聽落似廢話，但好多人（包括我）都係習慣性咁寫模糊嘅需求，然後抱怨 AI 唔明。
其實人都懶，可以一句話講清楚就一定懶得講第二句。用 Plan 模式相對好啲，你可以知佢聽明咗未。
【7】終端同環境配置
團隊入面好多人用 Ghostty 終端，理由是佢有同步渲染、24 位真彩色、完善嘅 unicode 支援。呢啲對於同時開多個 Claude 會話好重要。
另一個實用技巧：用 /statusline 自定義狀態欄，始終顯示當前嘅 context 用量同 git 分支。咁樣你一眼就可以知道每個會話嘅狀態。
仲有人用 tmux 管理多個會話，俾每個 tab 上色、命名，一個 tab 對應一個 task 或 worktree。
Optimize your terminal setup 文檔：https://code.claude.com/docs/en/terminal-config
最後一個容易俾人忽視嘅建議：用語音輸入。
Boris 話你講嘢嘅速度係打字速度嘅三倍。更重要嘅係，用語音嘅時候你會不自覺咁講得更詳細，prompt 質量反而更高。
macOS 上面按兩下 fn 鍵就可以啟動語音輸入。試嚇？
【8】使用 Subagents
呢個係一個進階技巧，用得好好強大。
最簡單嘅用法： 喺任何請求後面加上「use subagents」。Claude 會自動將任務拆分俾多個 Subagents 並行處理，相當於等佢「開更多嘅線程」嚟解決問題。
另一個用法係用 Subagents 保持主會話嘅上下文乾淨。將一啲獨立嘅子任務分派出去，主會話只負責整體協調。咁樣主會話嘅 context window 唔會俾中間過程塞滿。
Subagents 可以令任務並行，大大節約時間。例如我之前俾文章生成插圖嘅時候，就會叫佢行 4 個 Subagents，將提示詞文件路徑傳俾每個 Subagent。不過實際上用落穩定性仲未夠，成日有 Subagent 死咗嘅情況，期待後續版本改進。
更高級嘅玩法：用 hook 將權限請求路由俾 Opus 4.5（Anthropic 最強嘅模型），等佢判斷邊啲操作係安全可以自動批准，邊啲需要人工確認。相當於俾 Claude 加咗一個「安全審核員」。
參考文檔：https://code.claude.com/docs/en/hooks#permissionrequest
【9】用 Claude Code 做數據分析
呢個用法可能出乎好多人意料。
Anthropic 團隊將 BigQuery 嘅使用封裝成一個 skill，所有人都可以喺 Claude Code 入面直接 bq 命令行查詢數據。Boris 話佢已經六個月冇寫過一行 SQL。
呢個唔限於 BigQuery。任何有 CLI、MCP 或 API 嘅數據庫都可以咁樣用。PostgreSQL、MySQL、MongoDB，都可以叫 Claude 幫你寫查詢、行分析、生成報告。
對於非工程師嚟講呢個可能更有價值。團隊入面嘅數據科學家而家都喺用 Claude Code 寫查詢、做可視化。工具嘅邊界正在模糊。
【10】用 Claude Code 學習
最後呢個技巧係關於點樣用 Claude Code 嚟學習新嘢。
首先，喺 /config 入面開啟「Explanatory」或「Learning」輸出風格。咁樣 Claude 喺改代碼嘅時候會解釋「點解」咁樣改，而唔係改完就算。
第二個用法：叫 Claude 生成 HTML 投影片嚟解釋唔熟悉嘅代碼。Boris 話效果出奇地好。你可以直接喺瀏覽器睇一個圖文並茂嘅代碼講解。
第三個用法：叫 Claude 畫 ASCII 圖嚟解釋協議、架構、數據流。純文字嘅圖表意外地有助理解複雜系統。
最後一個高級玩法：有人建立咗一個「間隔重複學習」（spaced repetition，一種基於遺忘曲線嘅學習方法）skill。你先向 Claude 解釋你對某個概念嘅理解，Claude 會追問嚟填補你嘅知識漏洞，然後將結果存低。下次複習時再叫出嚟。
Boris 喺推文開頭強調「冇唯一正確嘅使用方式」，呢個係最重要嘅一條。佢嘅團隊內部使用方式都各不相同。呢啲技巧係起點，唔係終點。揾到適合你自己嘅方式，比起照搬人哋嘅設置更加重要。
Claude Code 團隊分享的 10 條內部技巧，已經很多人分享過了，大部分我還是結合自己經驗解讀一下。
其中最重要的一句話是：“沒有唯一正確的使用方式，每個人的設置都不一樣。”
我按難度分了層，加上自己的理解和背景信息。
【1】並行運行：團隊公認的第一大效率提升，但你不一定要學
這是團隊最推薦的技巧，但不一定是你要學的技巧。
做法是用 git worktrees 同時檢出 3-5 個工作目錄，每個目錄跑一個獨立的 Claude Code 會話。比如目錄 A 在重構模塊，目錄 B 在寫測試，目錄 C 在改文檔。三件事並行推進。
Git worktree 是什麼？ 讓你在同一個倉庫裏同時打開多個分支的工作目錄，不用來回切換。命令大概是 git worktree add ../feature-a feature-a。
相關文檔：https://code.claude.com/docs/en/common-workflows#run-parallel-claude-code-sessions-with-git-worktrees
團隊裏有人給 worktree 目錄配上 shell 快捷鍵（za、zb、zc），一鍵跳轉。還有人專門留一個“分析專用”的 worktree，只用來看日誌、跑查詢，不寫代碼。
Boris 本人用的是多個 git checkout 而不是 worktree，但團隊大多數人更喜歡 worktree。Claude Desktop 應用為此專門加了原生支持。
為什麼他們把這排第一？ 因為它改變的是整個工作模式。從“一次做一件事”變成“同時推進多件事”。瓶頸從“等 AI 生成”變成了“我的注意力怎麼分配”。
這個用法不一定適合所有人。
首先 git worktree 操作比較麻煩（可以讓 Claude Code 幫你做）。我個人更喜歡 ClawdBot（一個開源的 Claude 客戶端）作者 Peter 的方式，分幾個目錄，比 worktree 簡單：
他就簡單地 checkout 好幾份倉庫：clawbot-1、clawbot-2、clawbot-3、clawbot-4、clawbot-5。哪個空閒就用哪個，做完測試、推到主分支、同步。
然後並行任務會讓你頻繁切換大腦線程，對於編程這種需要注意力的事情還是挺麻煩的。需要一段時間練習。
我估計他們團隊有不少簡單的 Bug 修復任務，這類任務描述清楚後，基本上覆制粘貼過去等着就行。
如果是多個複雜任務並行我不太推薦，當然想試試還是沒問題。
【2】Plan Mode：複雜任務先規劃再動手
Plan Mode 的價值不只是“計劃”本身，而是強迫你在動手前想清楚到底要什麼，以及確保 Claude 懂你想要什麼。
很多時候我們自己想做一件事時，一開始只有模糊的想法，不知道什麼是最優解，這時候直接開始寫代碼不見得是好事，如果通過 plan 模式反覆聊一下，可能就幫你梳理清楚了，有時候 Claude Code 還能有你意想不到的提議。
很多時候 Claude 寫出來的東西不對，不是它不行，是它沒理解清楚你真正想要的是什麼就開始寫代碼了。通過 Plan Mode 反覆聊天確認，可以確保它理解你的意圖。
基本原則： 遇到複雜任務，先用 Plan Mode 和 Claude 討論方案。反覆迭代，直到你對計劃滿意，再切換到自動編輯模式讓 Claude 執行。一個好的計劃通常意味着 Claude 可以一次到位，不用來回改。
團隊有人的做法更進一步：讓一個 Claude 寫計劃，另開一個 Claude 以“高級工程師”的身份審核這個計劃。讓 AI 審 AI。
還有一條重要的補充：事情一旦跑偏，立刻回到 Plan Mode 重新規劃。不要硬推，不要讓 Claude 在錯誤的方向上越走越遠。有人甚至會在驗證步驟時也切換到 Plan Mode，不只是在“做”的階段。
【3】投資你的 CLAUDE.md
這可能是性價比最高的一個技巧。
CLAUDE.md 是放在項目根目錄的文件，Claude Code 每次啓動都會讀取它。你可以在裏面寫代碼規範、設計原則、PR 模板、常見錯誤提醒——任何你希望 Claude 記住的東西。
關鍵在於怎麼維護這個文件。團隊的做法是：每次糾正 Claude 的錯誤後，讓它自己更新 CLAUDE.md。
具體 prompt 可以是：“Update your CLAUDE.md so you don't make that mistake again.”
Boris 的原話是：“Claude is eerily good at writing rules for itself.”（Claude 非常擅長給自己寫規則。）
團隊裏有個工程師的做法更系統：他為每個項目/任務維護一個 notes 目錄，每次 PR 後更新。然後在 CLAUDE.md 裏指向這些 notes，相當於給 Claude 建了一個持續更新的知識庫。
這個思路跟我經常提到的 Skills 迭代思路類似。通常一開始規則不夠完善，每次遇到問題，基於當前上下文讓 Agent 自己去完善是效果最好的。一方面你不需要從頭描述問題，另一方面 Agent 很善於歸納總結。
至於維護一個 notes 目錄，是個蠻好的積累經驗的實踐。這事你不需要自己寫，可以做一個 Skill，每次讓 Claude Code 從當前會話中覆盤，提煉成 Note。甚至可以連上 hook，每次會話結束自動執行。不過這條我個人不推薦，太多沒意義的信息不見得是好事。
這個技巧的核心是把人腦裏的經驗變成系統知識。時間越長，CLAUDE.md 越完善，Claude 犯的錯越少，你需要糾正的次數也越少。這是一種複利。
這裏需要補充一個注意事項，CLAUDE MD 不建議放太多內容，只會適得其反，只放最重要的 AI 沒訓練過的內容，更多的內容作為文件連結按需讀取。
很多人把設計模式、規範、最佳實踐之類的都放進去，先不說這些 AI 都訓練過，你最多說個名字就夠了，就算是你需要的，也不是每次都要，不如放一個連結或者移到 Skills 按需加載。
Claude Code 官方項目中 CLAUDE md 文件也就大約 2.5k tokens：
• 常用 Bash 指令：讓 AI 知道如何像開發者一樣操作命令行。 • 代碼風格規範 (Code Style Conventions)：確保 AI 寫的代碼符合團隊編碼標準。 • UI 與內容設計準則：指導 AI 如何設計界面和編寫文案。 • 核心技術實現流程：教 AI 如何處理狀態管理 (State Management)、日誌記錄 (Logging)、錯誤處理 (Error Handling)、功能門控 (Gating，即控制特定功能的開啓與關閉) 以及調試 (Debugging)。 • 代碼合併請求 (Pull Request) 模板：規範提交代碼時的文檔格式。
【4】創建自定義技能（Skills）
如果某件事你一天要做兩次以上，就值得把它變成一個 skill 或者 slash command。
Skill 是一組可複用的指令，放在項目裏，用斜槓命令調用。比如 /commit-push-pr 可以一鍵完成提交、推送、創建 PR 的整個流程。Boris 說他每天會用這個命令幾十次。
團隊分享了幾個在用的 skill：
• ：在每次 session 結束時運行，讓 Claude 檢查並清理重複代碼。
還有人搭建了一個 slash command，可以把過去 7 天的 Slack 消息、Google Drive 文檔、Asana 任務、GitHub 活動同步到一個上下文裏，相當於一鍵獲取“這周發生了什麼”的全景視圖。
更高級的用法：有人用 skill 構建了“數據分析工程師”類型的 agent，可以自動寫 dbt 模型、審核代碼、在開發環境測試變更。
Skill 的好處是可以提交到 git，跨項目複用。你在一個項目裏積累的自動化，可以帶到下一個項目。
Skill 文檔：https://code.claude.com/docs/en/skills#extend-claude-with-skills
【5】讓 Claude 自己修 Bug
團隊的經驗是：大多數 bug，Claude 自己就能修好。
一個常見場景：啓用 Slack MCP，把 Slack 上的 bug 反饋帖子直接粘貼給 Claude，然後只說一個詞：“fix”。不需要解釋上下文，不需要手動定位問題。Claude 會自己去看代碼、理解問題、修復。
另一個場景：CI 測試掛了。直接告訴 Claude：“Go fix the failing CI tests.”不要微管理它怎麼做，讓它自己去看日誌、找原因、改代碼。
更復雜的場景：分佈式系統出問題，把 docker logs 指給 Claude，讓它幫你排查。Boris 說 Claude 在這方面“surprisingly capable”（能力出乎意料地強）。
Boris 沒說的是，描述 Bug 的時候要清楚：
• 如何復現問題 • 期望的結果 • 實際的問題，比如錯誤日誌、截圖等等
換個角度說，假設是個程序員，看了你的 Bug 描述也能知道是怎麼回事。有了這些基本信息，AI 才能有足夠的上下文去定位和驗證問題。
這個技巧的核心是給 Claude 足夠的上下文和權限，然後信任它。不需要一步步指揮，讓它自己閉環。
所以你看，這才是他們能多任務的重要原因——好多 Bug 都是 Claude Code 自己能修的。
【6】提升你的 Prompting 技巧
這一部分有幾個具體的招數。
第一招：讓 Claude 來考你
Prompt 示例：“Grill me on these changes and don't make a PR until I pass your test.”（針對這些改動考我，直到我通過測試才能提 PR。）
或者：“Prove to me this works.”（向我證明這個能 work。）讓 Claude 對比 main 分支和你的 feature 分支的行為差異。
這相當於把 Claude 從“執行者”變成了“審核者”。讓它反過來 review 你。
第二招：推倒重來
當 Claude 給出的方案不夠好，不要在上面打補丁。直接說：“Knowing everything you know now, scrap this and implement the elegant solution.”（基於你現在知道的所有信息，扔掉這個方案，實現一個更優雅的版本。）
我通常會用 git 把代碼回滾到修改前，然後新開會話、調整提示詞重來。在當前會話繼續的話，之前的錯誤信息可能會干擾 Claude 的判斷。
第三招：減少歧義
交代任務時，spec 寫得越詳細越好。你越具體，Claude 的輸出越準確。這聽起來像廢話，但很多人（包括我）還是習慣性地寫模糊的需求，然後抱怨 AI 不懂。
其實人都懶，能一句話說清楚肯定懶得說第二句。用 Plan 模式相對好一點，你能知道它聽懂了沒有。
【7】終端和環境配置
團隊裏很多人用 Ghostty 終端，理由是它有同步渲染、24 位真彩色、完善的 unicode 支持。這些對於同時開多個 Claude 會話很重要。
另一個實用技巧：用 /statusline 自定義狀態欄，始終顯示當前的 context 用量和 git 分支。這樣你一眼就能知道每個會話的狀態。
還有人用 tmux 管理多個會話，給每個 tab 上色、命名，一個 tab 對應一個 task 或 worktree。
Optimize your terminal setup 文檔：https://code.claude.com/docs/en/terminal-config
最後一個容易被忽視的建議：用語音輸入。
Boris 說你的說話速度是打字速度的三倍。更重要的是，用語音的時候你會不自覺地說得更詳細，prompt 質量反而更高。
macOS 上按兩下 fn 鍵就能啓動語音輸入。試試看？
【8】使用 Subagents
這是一個進階技巧，用好了很強大。
最簡單的用法： 在任何請求後面加上“use subagents”。Claude 會自動把任務拆分給多個 Subagents 並行處理，相當於讓它“開更多的線程”來解決問題。
另一個用法是用 Subagents 保持主會話的上下文乾淨。把一些獨立的子任務分派出去，主會話只負責整體協調。這樣主會話的 context window 不會被塞滿中間過程。
Subagents 可以讓任務並行，大大節約時間。比如我之前給文章生成插圖的時候，就會讓它跑 4 個 Subagents，把提示詞文件路徑傳給每個 Subagent。不過實際用下來穩定性還不夠，經常會有 Subagent 掛掉的情況，期待後續版本改進。
更高級的玩法：用 hook 把權限請求路由給 Opus 4.5（Anthropic 最強的模型），讓它判斷哪些操作是安全的可以自動批准，哪些需要人工確認。相當於給 Claude 加了一個“安全審核員”。
參考文檔：https://code.claude.com/docs/en/hooks#permissionrequest
【9】用 Claude Code 做數據分析
這個用法可能出乎很多人意料。
Anthropic 團隊把 BigQuery 的使用封裝成了一個 skill，所有人都可以在 Claude Code 裏直接用 bq 命令行查詢數據。Boris 說他已經六個月沒寫過一行 SQL 了。
這不限於 BigQuery。任何有 CLI、MCP 或 API 的數據庫都可以這樣用。PostgreSQL、MySQL、MongoDB，都可以讓 Claude 幫你寫查詢、跑分析、生成報告。
對於非工程師來說這可能更有價值。團隊裏的數據科學家們現在也在用 Claude Code 寫查詢、做可視化。工具的邊界正在模糊。
【10】用 Claude Code 學習
最後這個技巧是關於怎麼用 Claude Code 來學習新東西。
首先，在 /config 裏開啓“Explanatory”或“Learning”輸出風格。這樣 Claude 在改代碼的時候會解釋“為什麼”這麼改，而不只是改完拉倒。
第二個用法：讓 Claude 生成 HTML 幻燈片來解釋不熟悉的代碼。Boris 說效果出奇的好。你可以直接在瀏覽器裏看一個圖文並茂的代碼講解。
第三個用法：讓 Claude 畫 ASCII 圖來解釋協議、架構、數據流。純文本的圖表意外地有助於理解複雜系統。
最後一個高級玩法：有人搭建了一個“間隔重複學習”（spaced repetition，一種基於遺忘曲線的學習方法）skill。你先向 Claude 解釋你對某個概念的理解，Claude 會追問來填補你的知識漏洞，然後把結果存下來。下次複習時再調出來。
Boris 在推文開頭強調“沒有唯一正確的使用方式”，這是最重要的一條。他的團隊內部使用方式都各不相同。這些技巧是起點，不是終點。找到適合你自己的方式，比照搬別人的設置更重要。