Claude Code 開發者 Boris Cherny 於今年二月一日（2026/2/1）在 社群媒體 Threads 上分享了一系列來自 Claude Code 團隊內部的使用技巧。這些技巧不只是出自 Boris 個人經驗，更是整個開發團隊在實際使用中累積的智慧結晶。Boris 在文中特別強調，「使用 Claude Code 沒有唯一正確的方式，每個人的工作環境都不同，應該實驗找出最適合自己的方法。」
本文將逐一翻譯、整理這十大心法，並結合 Claude Code 官方文件補充說明，相信這也有助於可能正在 AI Coding、Vibe Coding 的你們！
一、平行作業（Do more in parallel）
Boris 指出，Claude Code 團隊最推薦的生產力提升技巧是：「同時開啟 3 到 5 個 git worktrees，每個都運行獨立的 Claude 會話。」他表示這是「單一最大的生產力解鎖」，也是團隊成員最常使用的技巧。Boris 提到，雖然他個人使用多個 git checkouts，但大多數團隊成員更偏好 worktrees——這也是為什麼 Claude Desktop 應用程式內建支援 worktrees 的原因。根據 Boris 的分享，有些使用者會為 worktrees 命名，並設定 shell 別名（如 za、zb、zc），讓他們能夠在不同 worktree 之間一鍵切換。還有人會設置專門的「分析」worktree，只用於閱讀日誌和執行 BigQuery 查詢。
根據 Claude Code 官方文件明確說明了 worktrees 的優勢：
- 每個 worktree 都有獨立的檔案狀態，非常適合平行運行多個 Claude Code 會話
- 在一個 worktree 中所做的變更不會影響其他 worktree，防止 Claude 實例互相干擾
- 所有 worktrees 共享相同的 Git 歷史記錄和遠端連線
對於長時間運行的任務，你可以讓 Claude 在一個 worktree 中工作，而你在另一個 worktree 中繼續開發。
瞭解更多 worktree 設定：
二、計畫優先（Start every complex task in plan mode）
「每個複雜任務都從計畫模式（plan mode）開始。將你的精力投入計畫中，這樣 Claude 就能一次性完成實作。」
他提到，有位團隊成員會讓一個 Claude 撰寫計畫，然後啟動第二個 Claude 以資深工程師的角度來審查這個計畫。
此外，當事情出錯時，不要繼續推進，而是立即切換回計畫模式重新規劃。團隊成員也明確告訴 Claude，驗證步驟同樣需要進入計畫模式，而不僅僅是建置階段。
三、好好寫 CLAUDE.md（Invest in your CLAUDE.md）
「每次修正錯誤後，都要加上這句話：『更新你的 CLAUDE.md，這樣你就不會再犯同樣的錯誤。（Update your CLAUDE.md so you don't make that mistake again.）』Claude 在為自己撰寫規則方面異常出色。」
Boris 分享，有位工程師會讓 Claude 為每個任務或專案維護一個 notes 目錄，在每個 PR 後更新，然後在 CLAUDE.md 中指向這個目錄。
上述二、三兩點，如果不了解的話，強烈建議可以先看我之前摘要的這一篇「初階版」Claude Code 教學 XD：
四、建立自訂 Skills 並提交至 Git
Boris 建議：「建立你自己的 skills 並將它們提交到 git，在每個專案中重複使用。」如果你是團隊協作的話，可以參考以下建議：
- 如果你每天做某件事超過一次，就將它轉換成 skill 或斜線指令（slash command）
- 建立一個
/techdebtslash 指令，在每次會話結束時執行，以找出並消除重複的程式碼 - 設定一個 slash 指令，將 7 天的 Slack、Google Drive、Asana 和 GitHub 內容同步到一個上下文中
- 建立類似分析工程師風格的代理，能夠撰寫 dbt 模型、審查程式碼並在開發環境中測試變更
Agent Skill 是 Anthropic 2025年末公開的一項功能，設計理念是「漸進式揭露」（progressive disclosure）——只顯示足夠的資訊幫助 Claude 決定下一步該做什麼，然後在需要時揭露更多細節，被認為在 Context Engineering 的角度相當實用！
Skills 可以被儲存在個人層級的設定、專案層級的設定，也可以團隊協作時使用。官方文件提供了建立 skill 的範例，包括程式碼解釋、程式碼庫視覺化等。
根據 Claude Code 的「Skills」文件，每個 skill 都需要一個 SKILL.md 檔案，包含兩個部分：位於 --- 標記之間的 YAML frontmatter（告訴 Claude 何時使用這個 skill）和包含 Claude 在調用 skill 時遵循的指令的 markdown 內容。
詳細你可以從以下網址可以看到更多設定細節！
社群上也有提供所有 Skills 總整理：https://skillsmp.com/categories
五、讓 Claude 自己修復大部分錯誤
Boris 分享了團隊修復錯誤的方式：首先啟用 Slack MCP，然後將 Slack 錯誤討論串貼到 Claude 中，只要說「修復（fix it）」就好，無需切換上下文。或者，直接說「去修復失敗的 CI 測試」，不要微觀管理如何修復。團隊成員也會將 Claude 指向 docker 日誌來排查分散式系統問題——Claude 在這方面表現出人意料地好。
六、提升提示技巧
Boris 分享了幾個提示技巧：
- 挑戰 Claude：說「對這些變更進行嚴格審查，在我通過你的測試之前不要建立 PR」，「讓 Claude 成為你的審查者（Make Claude be your reviewer.）」、或者說「向我證明這能運作（ Prove to me this works）」，讓 Claude 比較 main 分支和你的功能分支之間的行為差異。
- 在得到很平庸的修復時，說：「知道你現在所知道的一切，放棄這個方案並實作優雅的解決方案。（Knowing everything you know now, scrap this and implement the elegant solution）」
- 在交付工作之前撰寫詳細的規格並減少歧義。越具體，輸出就越好。
七、終端機技巧
Boris 提到團隊喜愛 Ghostty 終端機，多位成員喜歡它的同步渲染、24 位元色彩和適當的 Unicode 支援。
為了更容易管理多個 Claude 實例，使用 /statusline 自訂狀態列，可以讓畫面始終顯示上下文使用量和當前 git 分支。
他也建議使用語音聽寫，因為說話速度比打字快三倍，而且提示會因此變得更加詳細。
八、使用子代理（Subagents）
在任何你想讓 Claude 投入更多運算資源的請求後面加上「使用 subagents」。這樣的用意是保持主代理的上下文視窗乾淨且專注。
使用 /subagents 指令來查看和管理子代理。子代理有獨立的上下文視窗，可以處理特定的子任務。
Boris 建議，透過 hook 將權限請求路由到 Opus 4.5——讓它掃描攻擊並自動批准安全的請求。
什麼是 Hooks？可參見我寫的這篇：
如何設定，可參考官方說明：
九、使用 Claude 進行資料與分析
Boris 建議讓 Claude Code 使用「bq」CLI 即時提取和分析指標。他們在程式碼庫中有一個 BigQuery skill，團隊中的每個人都直接在 Claude Code 中使用它進行分析查詢。Boris 表示已經超過 6 個月沒有寫過一行 SQL 了！
十、與 Claude 一起學習
Boris 分享了幾個使用 Claude Code 進行學習的技巧：
- 在
/config中啟用「Explanatory」或「Learning」輸出風格，讓 Claude 解釋其變更背後的「為什麼」。 - 讓 Claude 產生視覺化的 HTML 簡報來解釋不熟悉的程式碼。它能製作出令人驚訝的好簡報！
- 要求 Claude 繪製新協定和程式碼庫的 ASCII 圖表，幫助你理解它們。
同場加映：Agent Team
Claude Code 2月初新增功能，現在支援「代理團隊（Agent Team）」，也稱為「Swarm」。
協調多個 Claude Code 實例共同協作，如團隊共享任務、代理間訊息傳遞及集中管理。
Agent Team 讓使用者能協調多個 Claude Code 實例協同工作。一個會話作為團隊負責人，負責協調工作、指派任務並整合結果。隊員們獨立作業，各自在自己的上下文視窗中，並且彼此直接溝通。與 Subagents 不同的是，使用者可以直接與個別隊員互動，而不需透過負責人。
Boris Cherny 分享的這十大心法，每一項都經過 Claude Code 團隊的實戰驗證。不過正如 Boris 在開頭所強調的：「沒有唯一正確的使用方式，每個人的設定都不同，你應該實驗找出最適合自己的方法。」
我自己其實也沒有全然都使用（有些不太符合習慣、或平常遇到的專案並不大），例如 Hooks 的部分我自己暫時還沒有用得很習慣，如果害怕出錯我自己仍不會輕易開「Auto-accept」的模式，不過使用 Plan mode、使用 Skills（或是一些工具有開放 llm.txt）我覺得很有助於開發！
另外，我看完以後的 takeaway，確實會想多多嘗試平行作業（worktree）跟增加subagents 的運用，歡迎大家也可以分享看法！
