2026 年 Claude Code：11 個技巧、快捷鍵與指令

如需更多使用 Ailoot 的說明，請參閱文件。

這篇 Claude Code 指南介紹哪 11 項技巧？#

在氛圍式編碼（vibe coding）中，問題已經不再是「Claude Code 能不能用？」而是「要怎麼和它合作，才不會耗盡額度或產生幻覺？」我先前的 9 篇指南介紹了相關概念：CLAUDE.md、Plan Mode、上下文工程、Skills、Subagents、MCP、/rewind、使用額度、第二大腦。本文整理了與這些概念搭配使用的技巧。

每個技巧都能解決一項痛點。你可以照順序讀，也可以直接跳到最急需的部分：快捷鍵看技巧 1；節省 Token 看技巧 4 和 5；平行工作看技巧 6；作者的技巧看技巧 8-11。

本文適合已經安裝 Claude Code 並至少使用一週的人。如果你才剛安裝，請先閱讀 CLAUDE.md 指南，再回來看本文。

如何切換 Claude Code 模式：Shift+Tab 快捷鍵#

新手最常犯的錯誤，就是一整天都停留在 default，手動核准每一項變更。這樣一小時後就會讓人筋疲力盡，甚至想直接執行 --dangerously-skip-permissions（本技巧最後會再談到）。Shift+Tab 提供折衷方式：你可以自行選擇何時需要 acceptEdits，何時需要 plan。

我切換模式時遵循的具體規則如下：

1. 開始複雜任務 - 持續用 Shift+Tab 切換，直到模式指示顯示 plan。Claude 會仔細思考並擬定計畫；在我核准前，它不會寫程式碼。
2. 核准計畫，開始實作 - 循環切換，直到模式指示顯示 acceptEdits。Claude 可以編輯檔案而不必請求核准，但執行 Bash 指令時仍會詢問。
3. 例行編輯（重新命名、簡單重構） - 直接切換到 acceptEdits，不必先擬定計畫。
4. 危險區域（資料庫遷移、刪除檔案） - 按 Shift+Tab 回到 default。

# 常見權限模式（請確認生效標籤，不要依賴固定按鍵次數）：
# default        - 標準權限提示
# acceptEdits    - 接受檔案編輯，其他工具權限仍適用
# plan           - 實作前先調查與規劃
# 其他模式取決於版本、設定與組織政策。

如果你使用的 Claude Code 版本（claude --version）無法使用 Shift+Tab，請確認是否已安裝最新版本。/doctor 指令會顯示安裝相關的完整資訊。

如何復原上一個動作又不遺失上下文：Esc Esc#

按一次 Esc 和連按兩次 Esc 的作用不同，因此大家常常搞混：

• 按一次 Esc - Claude 正在執行工作時立即中斷。它已經完成的所有工作都會保留。適合 Claude 方向錯了、而你想重新引導它時使用。
• 連按兩次 Esc - 如果輸入欄是空的，就會開啟檢查點選單（還原程式碼、還原對話、兩者都還原，或摘要）。如果輸入欄有文字，就會清除欄位內容並將文字放入歷史記錄（按向上鍵即可叫回）。

# 輸入欄空白時，Esc Esc 選單中的項目：
# 1. 只還原程式碼               - 還原檔案，保留對話
# 2. 只還原對話                 - 還原對話，保留檔案
# 3. 還原程式碼和對話           - 兩者都還原（最常見的選擇）
# 4. 從這裡開始摘要             - 從這個時間點開始摘要對話
# 5. 摘要至此                   - 摘要到這個時間點為止

每次送出提示詞時都會自動建立檢查點，不必記住任何事，而且你隨時都能回到先前的狀態。完整說明請參閱 /rewind 指南，其中也介紹如何搭配 git 進行大幅回溯。

Esc Esc 是新手最先該學會的技巧之一。不再害怕「把東西弄壞後無法復原」，就會更大膽地嘗試，成果也會好上許多。

什麼時候該用 /compact，而不是 /clear？#

/compact 的內部運作方式如下：Claude 會處理整段訊息歷史，並回傳一份保留重要細節的簡短摘要。一個實用技巧是附上提示：/compact keep the coding principles and current plan, discard the CSS discussion。這樣壓縮就會聚焦在指定內容上。

# 使用時機：
/clear                              # 完成一項功能，準備開始下一項
/compact                            # 工作階段很長，上下文已使用 >50%
/compact keep the architecture and plan  # 指定重點進行壓縮

該使用 /compact 的訊號是：/cost 指令或狀態列顯示上下文視窗已使用 70% 以上，但工作階段才過了一半。如果忽略這個訊號，Claude 就會開始「忘記」對話一開始的內容，害你浪費時間重新解釋。

上下文視窗的完整理論，請參閱上下文工程指南。指南也解釋了為什麼上下文是有限資源，以及效益為何會逐漸遞減。

如何即時追蹤 Token：/cost 指令#

「一天就把額度用光」是氛圍式編碼者最常見的疑慮之一。解決這種恐懼的主要方法，就是讓支出清楚可見。

/cost          # 顯示目前工作階段的支出（Token + $）
/statusline    # 設定狀態列：模型 + 目錄 + 上下文 % + 費用

一個簡單的規則：每 30-60 分鐘查看一次 /cost。如果一小時花不到幾美元，沒問題。如果更多，就表示可能有狀況：也許你忘了使用 /compact，導致上下文越來越大；也許選錯了模型（下一個技巧會詳談）；或者 Claude 正在重讀大型檔案 10 次。

完整的額度節省指南是「如何避免一天內耗盡 Claude Code 額度」，其中有 8 項規則。本文介紹的技巧，是用 /cost 和 /statusline 讓支出看得見。

你不只想追蹤 Token，還想建立一套讓 AI 代理不會自行超出額度的系統嗎？/cost 只是指標。AI 分身 + 第二大腦 + 上下文工程的完整組合，才能讓 Claude 從「有額度限制的助理」變成可以長時間穩定工作的工具。

工作該選哪個 Claude 模型：Haiku、Sonnet 還是 Opus？#

claude --model haiku   # 比 sonnet 便宜約 3 倍，適合例行工作
claude --model sonnet  # 預設值，平衡價格與品質
claude --model opus    # 比 sonnet 貴約 1.7 倍，適合複雜任務

根據 Anthropic 在 2026 年 5 月公開的定價，每 1M Token 的輸入/輸出費用分別為：Haiku $1/$5、Sonnet $3/$15、Opus $5/$25。也就是說，Haiku 比 Sonnet 便宜 3 倍，而 Opus 比 Sonnet 貴 1.7 倍。

我每天選擇模型的方式如下：

如果 Opus 平均來說都能「一次就答對」，那還要不要用 Sonnet 和 Haiku，這一點頗有爭議。我的看法是：對不會寫程式的企業家來說，Haiku 和 Sonnet 對 70% 的任務都有幫助。Opus 值得留給真正困難的 30%。

如何平行執行 3-5 個任務：/resume + git worktrees#

原理很簡單：一個 Claude 視窗開得越久，消耗的上下文就越多。每個請求都會把該視窗裡的所有內容載入模型，即使你現在談的是完全不同的事也一樣。用 5 個短視窗處理小任務，每個視窗只需記住自己的工作。總花費更少。

# 為特定任務啟動具名工作階段：
claude --resume "auth-refactor"
claude --resume "homepage-redesign"
claude --resume "db-migration"

# 使用 worktree，避免 git 工作互相重疊：
git worktree add ../my-project-auth feature/auth
cd ../my-project-auth
claude --resume "auth-refactor"

如果忘記各視窗在做什麼，不帶引數執行 claude --resume，就能查看最近工作階段的名稱和時間。在作用中的工作階段內，/agents 可以查看正在執行的子代理。

處理開發週期較長的功能時，我通常會這樣安排：

1. 視窗 1 - 在 plans/YYYY-MM-DD-feature.md 規劃。只討論，不寫程式碼。
2. 視窗 2（依照計畫）- 實作階段 1。完成後更新計畫（[x]）。
3. 視窗 3 - 如果階段之間沒有重疊，就與視窗 2 平行實作階段 2。
4. 視窗 4 - 綜整代理檢查兩個視窗的成果。
5. 視窗 5 - 合併後進行安全性審查（見技巧 8）。

什麼時候不該使用 worktrees？如果你每天只管理 1-2 個專案，切換 worktree 目錄的額外負擔可能會抵銷好處。每天有 3 個以上平行任務時，worktree 才開始發揮作用。

使用 @file 檔案參照避免幻覺#

檔案自動完成從 @ 符號開始。輸入路徑時，Claude 會顯示建議。你可以一次參照多個檔案：@src/lib/auth.ts @src/lib/session.ts @prisma/schema.prisma。

# 沒有明確路徑的提示詞（不佳）：
> 查看驗證邏輯並修正工作階段錯誤

# 使用 @ 參照的提示詞（正確）：
> @src/lib/auth.ts @src/lib/session.ts - 修正登出後 Cookie 沒有清除的錯誤

同一組技巧中的另一個方法是用 ! 進入 Shell 模式：

> !git status                # 不呼叫 Claude 直接執行，輸出進入上下文
> !npm test                  # 同上
> !cat /var/log/app.log | tail -50  # 同上

原因是，你不必花 Token 說「Claude，查看 git 狀態」——Claude 透過工具取得的答案也會一樣。! 更短，也更省成本。

這也和 CLAUDE.md 有關：主要檔案最多寫 200 行專案規則。更細的規則（例如 API 慣例）放在附有 YAML frontmatter paths: ["src/api/**/*.ts"] 的 .claude/rules/api-design.md。這樣 Claude 只有在編輯 src/api/ 的檔案時才會載入規則。完整說明請參閱 CLAUDE.md 指南。

如何避免長時間任務中斷進度：分階段計畫與 [ ] / [x]#

以下是我在每個專案都使用的計畫檔範本：

# 計畫：[功能名稱]
建立日期：2026-05-22
目標：[用一句話說明想達成什麼]

## 階段 1：[簡短名稱]
- [ ] Step 1.1：[具體行動]
- [ ] Step 1.2：[具體行動]
- [ ] Step 1.3：[具體行動]

## 階段 2：[簡短名稱]
- [ ] Step 2.1
- [ ] Step 2.2

## 成果
最後填寫：完整或部分實作的情況，以及尚待處理的事項。

規則是絕對的：每個代理都必須在每次工作階段後更新計畫。換句話說，每完成一個階段，就立刻打開檔案並標記為 [x]。如果不這麼做，下一個視窗就不知道階段已完成，可能會重做一次。

把計畫寫在檔案裡，而不是記在腦中，就能做到：

• 平行視窗（見技巧 6）可以分頭負責不同階段。
• 如果任務延續 3 天，兩天後回來時，也能立即知道進度到哪裡。
• 最後對照實際結果也很簡單（在檔案中執行 grep -c "\[ \]" 就能知道還有幾項未完成）。

不適用的情況：5 分鐘就能完成的緊急修正、單一檔案中的簡單編輯、讀取並摘要紀錄。不是每項工作都需要計畫。

這項技巧屬於第二大腦的概念。關於 business/、plans/、ai-clone/ 資料夾的完整說明，請參閱第二大腦指南。

如何預先找出 Claude 可能失敗的地方：列出 10 個理由進行自我批判#

以下是我逐字使用的提示詞架構：

想像這個點子資料夾已經套用了一種方法，讓你先假設專案已徹底失敗。請列出 10 個原因，說明一年後為什麼我花了很多時間，這個點子最後卻失敗了。你的任務不是顧慮我的感受，而是盡可能嚴厲地直說。

列出 10 個原因後，進入第二輪：針對我的反駁，逐一為每個原因辯護。我最站不住腳的地方在哪裡？

第三輪：寫出一份計畫，說明如何避免這些問題。

我會在三個階段使用它：

1. 最初有了「一切都很棒」的點子，而且我深信不疑時 - 自我批判會讓點子縮減 30-50%。
2. 計畫進行到一半時 - 我已經深陷工作、開始看不清問題。
3. 推出之前 - 最後一道篩選。

Claude 在對抗性思考模式下確實會挑戰你的看法。同樣的情況下，GPT-5 會先稱讚點子，再「試著找出可以改進的地方」。經過一年的嘗試，我注意到這項差異：

對我來說，對抗性思考模式的差異是這樣：ChatGPT 會說：「觀察得好，完全正確。」Claude 則會說：「同意，這完全是一團糟；我現在就重做。」需要批判時，第二種回覆能幫我省下好幾天的無效工作。

不適用的情況：以正向方式反覆調整 UI 和文案。對抗性思考模式不適合這些工作，會扼殺創意。

這項技巧稱為專案事前驗屍。我將它改編用於和 AI 代理合作：不是找一群人，而是和 Claude 進行事前驗屍。沒有人會害怕說「老闆，這個專案會失敗」，因此盲點幾分鐘內就會浮現。

如何用做一項研究的時間查閱 5 個來源：平行子代理#

提示詞架構如下：

你已經掌握完整上下文。請進行深入研究，並平行啟動 5 個子代理。

子代理 1：查看專業社群——誰正在解決這個問題？
子代理 2：查看 GitHub 上的開放原始碼解決方案——什麼最受歡迎？
子代理 3：查看新創加速器——這個利基市場中，誰正在吸引投資？
子代理 4：查看直接競爭者的網站——他們承諾提供什麼，價格是多少？
子代理 5：查看比較資料和評論——使用者在評論中怎麼說？

大家都回來後，啟動一個綜整代理，交叉比對 5 份報告，
並為我的第二大腦資料夾製作大綱。

與一般研究相比，有以下不同：

• 時間：5 條平行研究，而不是依序進行 5 次。一小時的工作只需 15 分鐘。
• 深度：每個代理各有專長。一個代理的確認偏誤不會影響其他代理。
• 上下文：每個子代理都有自己的上下文，與主上下文分開。

子代理的完整指南請參閱「2026 年 Claude Code 子代理」。其中也說明 Skills 和 MCP 的差異，以及各自的適用時機。

不適用的情況：調整外觀、修正錯誤、小型技術任務。研究不適合小於「需要 1 天以上的新功能」的工作。

如何用手機交辦 Claude 任務：口袋裡的 Telegram 機器人#

設定方式（4 個步驟）：

1. 可持續開機的電腦 - 在系統設定中停用睡眠（macOS：Energy Saver → Prevent computer from sleeping）。
2. 在終端機中執行 Claude Code，並連接到專案資料夾。
3. 官方 Telegram 外掛 - 執行 /plugin marketplace add anthropics/claude-plugins-official 新增市集，再安裝 /plugin install telegram@claude-plugins-official（實際步驟會隨時間更新，最新說明請見官方外掛儲存庫）。
4. 一個機器人綁定一個工作階段 - 這是目前的限制：一個機器人 = 一個專案 = 一個工作階段。如果需要第二個，就再設定一個機器人。

我每天會用機器人做這些事：

• 出門散步時想到點子，就立刻傳給機器人，免得忘記。機器人會把它加到 inbox.md，留待之後處理。
• 和潛在客戶通話後，我會問機器人：「根據上次通話的逐字稿，列出對我們有利的 3 個主要痛點。」一分鐘後，完整分析就會出現在聊天中。
• 早上在咖啡館時，我會說：「顯示我清單裡尚未完成的待辦事項。」不必打開筆電。

⚠️ 有個限制：目前無法透過機器人執行 /clear 或 /compact——機器人工作階段和終端機工作階段相同，上下文會一直增加。只能透過終端機手動重新啟動。

對我來說，這是過去兩週最實用的 Claude Code 擴充功能。它讓我從「坐在桌前時才和 Claude 工作」變成「任何時候想到事情，都能和 Claude 工作」。

首先該實踐什麼？7 天路線圖#

技巧彼此搭配，比單獨使用任何一項都重要。沒有 Esc Esc 搭配 Shift+Tab，實驗會讓人害怕。沒有 /cost 搭配 /compact，你就不知道何時該壓縮。在檔案中規劃卻不使用平行視窗，只會增加麻煩，沒有好處。

前 9 個技巧變成習慣後，就可以進入完整系統：AI 分身 + 第二大腦 + 上下文工程。這是我讓 Claude 連續工作 6 個月的方法，期間沒有幻覺、上下文遺失或在任務中途遭到截斷。

若要繼續使用各種模型，請前往 Ailoot。