我個人整理了 Claude Code 的 30 個操作技巧，這些技巧是它的創作者 Boris Cherny 認為必不可少的。這真的是一篇傳奇文章。
老實說，知不知道這些技巧，會讓你的 Claude Code 體驗有天壤之別。你會發現，過去那些重複輸入相同指令、或是花好幾個小時重做的時間，完全是白費的。
順便問一下，你在使用 Claude Code 時，有沒有遇過這些問題？
- 你覺得每次都要下同樣的指令，真希望它能自己學會。
- 大規模修改導致不斷重做，讓你覺得還不如自己動手修更快。
- 功能太多，不知道從哪裡開始。
- 對話變得很長又零散，常常出現「等等，我剛才不是說過了嗎？」的狀況。
當你妥善設定好上下文、驗證、權限、平行設計和自動化之後，Claude Code 的體驗就會徹底改變。
這篇文章是由 ClaudeCodeStudio 獨立研究撰寫，以 2026 年 4 月 23 日為止的第一手資訊為優先，包括 Boris Cherny 的 X 貼文、Anthropic 的官方文件，以及官方 GitHub 儲存庫/動作！
既然 Boris 已經明確說過「我創造了 Claude Code」，我就把他的操作建議當作第一線的聲音，同時交叉比對 CLI 選項和官方文件的設定！😆
如果你使用 Claude Code，這篇絕對必讀！！！
一定要存起來！！！！
它真的會讓你的生產力提升 10 倍！我們開始吧！👇
■ 先掌握三個原則
讓 Claude Code 在實戰中變得強大的最大因素，歸結起來只有三點。
在 Plan 模式中分開「調查」和「實作」。讓 Claude 自己驗證自己的工作。以及以平行工作階段為前提來運作。
Boris 不斷強調：「幾乎都要用 Plan 模式」、「給 Claude 一個驗證輸出的方法」，以及「3–5 個 git worktrees」。
■ 「沒有單一正確答案」的哲學
閱讀 Boris 的貼文，會發現他反覆強調一個立場：使用 Claude Code 沒有單一的正確方法，而是應該把它當作一個高度可自訂的操作工具。他自己也說「使用 Claude Code 沒有唯一正確的方式」。
基於這個前提，他建議的最有效工作流程如下 👇
在 Plan 模式中調查/規劃
↓ 實作階段
↓ 透過測試、螢幕截圖和 CLI 進行自我驗證
↓ 建立 PR
↓ 程式碼審查 / Ultrareview
↓ 將學到的經驗回饋到 CLAUDE.md、Hooks 和 Skills
記住這個流程，我們來看看 30 個具體技巧。
■ 30 個操作技巧
這些是按照在實戰中的效果排序的。來自 Boris X 貼文的技巧著重於方向，而設定和限制的細節則由官方文件和 GitHub 加強。研究預覽功能會清楚標示。
■ 技巧 1：先在 Plan 模式中隔離大型修改
只要把調查、規劃和實作分開，就能大幅減少誤實作和重做。很簡單，但這就是為什麼 Boris 說「幾乎都要用 Plan 模式」。
範例：「在 Plan 模式中讀取 src/auth 和 secrets。在開始實作 Google OAuth 之前，先整理受影響的檔案、資料流程和測試觀點。」
沒有 Plan 模式就跳入大型修改，常常會導致上下文遺失或中途修正方向。先讓它掌握大局，真的會改變實作的準確度。
■ 技巧 2：讓 Claude 自己驗證
Boris 稱這是「單一最高槓桿的事情」。讓 Claude 執行測試、檢查螢幕截圖，並自己驗證 CLI 輸出。
「修復後，執行 npm test，只有當所有測試都通過時才視為完成。」
光是這樣，就能讓 Claude 在人類審查之前就找到並解決問題。如果驗證指令太重，可以從最小的冒煙測試開始。
■ 技巧 3：平行執行 3–5 個 Git Worktrees
Boris 稱平行 worktree 操作是「最重要的生產力提升」。
透過加入多個 worktrees，例如 git worktree add ../repo-auth -b feat/auth，並在每個 worktree 中啟動 Claude，等待時間降為零，而且獨立的任務可以同時進行。
最佳數量取決於你的環境。3–5 個是指標，但根據審查頻寬、CPU 和你自己的上下文切換成本，有些人可能 2 個就夠，有些人則可以處理 6 個。
■ 技巧 4：無情地編輯 CLAUDE.md
CLAUDE.md 是你專案的特定規則手冊。如果放著不管，它會過時，Claude 就會開始根據錯誤的前提行動。
Boris 的政策很簡單：「隨著時間無情地編輯你的 CLAUDE.md」，以及「當 Claude 第二次犯同樣的錯誤時，就加到裡面」。
反過來說，也要刪除不再需要的規則。如果它變得太臃腫，會吃掉上下文，所以定期修剪很重要。
■ 技巧 5：將每日重複的任務變成 Skills 並提交到 Git
每次在對話中解釋重複的流程都是在浪費時間。建立 .claude/skills/deploy/SKILL.md，然後用 /deploy staging 來呼叫。
Boris 說：「如果你一天做超過一次，就把它變成 skill 或 command」，並補充說「在你需要它之前，它幾乎不花任何成本」。
不過，如果 Skill 變得太臃腫，它的觸發條件可能會變得不明確，所以要把長篇的參考資料拆開。
■ 技巧 6：把團隊設定放在 settings.json 並用 Git 管理
對專案特定設定進行版本控制，可以確保整個團隊有相同的 Claude Code 體驗。它能加快入職速度，並防止設定依賴於單一個人。
顯然，絕對不要提交個人的 API 金鑰或 token。別忘了檢查你的 .gitignore。
■ 技巧 7：預先批准安全權限，拒絕危險區域
每次都被問「你允許這個操作嗎？」是不是很有壓力？使用 allow/ask/deny 可以消除這種對話疲勞。
"allow": ["Bash(npm test *)"], "ask": ["Bash(git push *)"], "deny": ["Read(./.env)", "Read(./secrets/**)"]
Boris 說「預先批准常見權限」，官方文件也指定「規則按順序評估：deny… ask… allow」。原則是明確拒絕 .env 或 secrets，以避免過寬的萬用字元。
■ 技巧 8：使用 --add-dir 跨越多個資料夾/儲存庫
有很多情況需要顯示 monorepo 外部的文件或函式庫。
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../docs --add-dir ../shared-libs
這樣就可以在參考外部文件的同時進行編碼。請注意，必須啟用環境變數，才能讀取所加入目錄中的 CLAUDE.md。
■ 技巧 9：用子 Agent 進行角色分工
把調查、審查和除錯全部塞進主要上下文，會讓對話變得混亂。Boris 說：「我定期使用幾個子 agent」，每個子 agent 在自己的專用上下文視窗中執行。
準備好 code-reviewer、debugger 或 data-scientist 等子 agent，並為它們寫清楚描述。
■ 技巧 10：用 PostToolUse Hooks 自動化格式化/檢查
每次 Claude 編輯檔案時，自動執行格式化工具或 linter。
告訴 Claude：「寫一個 hook，在每次檔案編輯後執行 prettier --write。」
它會處理從產生 hook 到整合到 .claude/settings.json 的所有事情。這能自動化程式碼風格一致性，並消除審查中的風格評論。
■ 技巧 11：透過 PR 評論更新 CLAUDE.md
在 PR 中隨著程式碼一起變更「未來規則」。Boris 說：「在我同事的 PR 上標記 @.claude，來新增一些東西到 CLAUDE.md。」
例如，評論：「@claude 把這個學習加到 CLAUDE.md。永遠從 Plan 模式開始修改 src/billing 中的內容。」這能減少未來重複的回饋。
■ 技巧 12：用狀態列隨時掌握當前狀態
螢幕底部顯示的資訊，可以讓你一眼看出「你在哪個分支做什麼、用了多少上下文、以及成本」。
/statusline show model name, git branch, context percentage, cost
從分支、context% 和成本開始，通常就足以及早發現上下文耗盡或分支錯誤。
■ 技巧 13：用 Chrome 擴充功能加速前端工作
Boris 建議：「前端工作使用 Chrome 擴充功能。」因為它可以分享瀏覽器登入狀態，你可以讓 Claude 比較螢幕截圖來進行 UI 驗證。
Claude 偵測到程式碼中看不到的 UI 破損，是一大優點。不過，由於螢幕截圖無法衡量可訪問性或感知速度，必要時請使用 Lighthouse 或 e2e 測試。
■ 技巧 14：讓 Claude 透過 CLI 處理分析任務
讓 Claude 使用 SQL 或 CLI，可以把開發、分析和策略整合到同一個工作空間。
「使用 bq CLI 拉取過去 7 天各管道的轉換指標，總結異常，並提出假設。」
正如 Boris 所說：「使用 Claude 進行數據分析」，這個技巧不僅對開發者有效，對產品經理也很有用。
■ 技巧 15：如果規格模糊，讓 Claude 訪談你
官方文件有一個章節：「讓 Claude 訪談你。」與其直接跳入實作，不如讓 Claude 提問來引出需求。
在實作前填補規格缺口，能大幅減少重做，特別是在「要建什麼」還不明確的時候。
■ 技巧 16：區分 CLAUDE.md 和自動記憶的角色
人類在 CLAUDE.md 中寫規則。Claude 在自動記憶中記住發現的偏好和習慣。保持這個區別可以防止設定變得混亂。
■ 技巧 17：用路徑特定規則和壓縮來設計
在 monorepo 中，區分「全域規則」和「本地規則」。把全域慣例放在根目錄的 CLAUDE.md，本地規則放在 src/billing 等目錄。
■ 技巧 18：積極管理上下文
官方文件明確指出：「積極管理上下文。」把重要的操作知識提升到 CLAUDE.md 或 skills，並定期使用 /compact 來整理上下文視窗。
■ 技巧 19：用 /rewind 和檢查點嘗試「可怕的變更」
Claude Code 中的每個操作都是一個檢查點。按兩次 Esc 或使用 /rewind，可以透過僅程式碼、僅對話或兩者來回到訊息檢查點。
■ 技巧 20：透過 MCP 伺服器連接外部工具
直接從 Claude Code 操作 Slack、Jira、資料庫或內部 API，能大幅減少工具切換。
■ 技巧 21：用非互動模式 (claude -p) 整合到腳本/CI
非互動模式是 Claude Code 自動化的入口。
claude -p "列出所有 API 端點" --output-format json
■ 技巧 22：用 claude -p 按檔案分散大型遷移
在一個工作階段中處理大規模遷移是不可能的。最好水平分散。
■ 技巧 23：直接從問題管理工具實作
讓 Claude 讀取 GitHub Issues 或 Linear 票證，然後直接進入實作。
■ 技巧 24：用 Hooks 強制執行規則
CLAUDE.md 是「建議」，hooks 是「執行」。不要混淆兩者。使用 hooks 來處理「零例外」的情況，以保證動作一定會發生。
■ 技巧 25：用 /simplify 進行平行程式碼審查
三個審查 agent 同時檢查冗餘、品質和效率，甚至執行修復。
■ 技巧 26：在 GitHub Actions 中使用 @claude 提及
使用官方的 claude-code-action，你只需在 PR 或 Issue 中提及 @claude，就能實作程式碼變更或獲得答案。
■ 技巧 27：區分程式碼審查和 Ultrareview
例行審查和深度審查是不同的。日常使用 Code Review，合併前使用 /ultrareview 進行深度審查。
■ 技巧 28：將重複操作變成 Routines
把每週維護或與 PR 相關的任務移到雲端。「當你的筆電關閉時，它仍然在運作。」
■ 技巧 29：將繁重規劃卸載到雲端的 Ultraplan
與其在終端機中等待，不如在瀏覽器中逐章審查計劃。
■ 技巧 30：用遠端控制管理雲端工作階段
一個從本地機器控制雲端上 Claude Code 工作階段的功能。
■ 尚未確定的操作要點
我也會誠實說明一些方向明確但最佳實踐尚未建立的地方，例如 Chrome 擴充功能和 e2e 測試的組合，或是使用 Stop hooks 進行長時間的「連續數天」操作。
■ 從哪裡開始
對於開發者，從技巧 1、2、4、7、9 和 18 開始。對於產品經理，技巧 14、15、23、27 和 28 最有效。
■ 每週檢查清單
- 你是否指出了同樣的錯誤兩次？→ 加到 CLAUDE.md。
- 有沒有重複的任務可以做成 skills/hooks？→ 自動化它們。
- 上下文使用率是否太高？→ 檢討
/compact習慣。 - worktrees 的數量是否合適？→ 根據頻寬調整。
■ 結論
掌握 Claude Code 的關鍵是按順序鞏固操作組件：Plan → Verify → Persist → Automate。你不需要一開始就全部做到。只要技巧 1、2 和 4，就能從根本上改變你的開發體驗。
另外，我已經開始了一個 Open Chat！
你可以在這裡加入 👇
我會在那裡分享有用的資訊並舉辦免費研討會，請加入吧！😆
𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗦𝘁𝘂𝗱𝗶𝗼 @ 𝗝𝗮𝗽𝗮𝗻 (@ClaudeCode_love) 由三位 Claude Code 愛好者經營。我們每天發布關於實用 CLI 用法和自動化的文章。追蹤我們，獲取真實產品開發範例和最新全球資訊！👀
