同樣的 Claude Code，不同的人用會得到完全不同的結果。
有些人很快就燒光 5 小時的額度，有些人卻覺得綽綽有餘。
--> 差別就在於設定與習慣。
⭐️ 這裡整理了 12 個正確的 Claude Code 使用技巧。 ⭐️
所有指令和提示詞都附上了，你可以直接複製貼上。
--> 內容有點長，一次看不完... 不如先加入書籤吧？？？
⚠️ 開始之前.. 先檢查你的版本 ⚠️
本文提到的大部分功能都是最近幾個月才推出的。如果你的版本太舊，這些指令會無法運作。
在終端機輸入 claude --version 檢查一下，如果版本太低，直接執行 claude update 就好。
本文的指令是基於 10 月 18 日的 v2.1.302 版本。
1. 為每個 Sub-agent 設定不同的 Effort
Effort（努力程度）決定了 Claude 在回答前思考的深度。選項包含 low、medium、high、xhigh 和 max，不過可用的級距會因模型而略有不同。
很多人以為越高越好，就無腦設成 Max 或 XHigh。
但事實並非總是如此。
在開發同一個 App 做比較時，Max 花了 79 分鐘，而其他 effort 只花了 16 分鐘。
結果幾乎一模一樣。你只是在浪費更多時間和 token 而已。
以下是我從經驗中整理出來的結論：
--> （核心）🔥 只要你能寫出詳細的提示詞，用 low 或 max 的最終結果通常差不多。 🔥
--> 如果是發想點子，low 或 medium 反而效果更好。
不過，困難的設計、棘手的 bug 和重要的 code review，有時候確實需要更高的 effort。
重點不是「永遠都用 low」。
從 10 月 7 日起.. 呼叫 sub-agent 時可以指定 effort！
從 10 月 7 日的更新（v2.1.292）開始，主 Claude Code 在呼叫 sub-agent 時可以指定 effort 了。
現在你可以這樣下指令：
把目前的任務分成三個階段，交給 sub-agent 執行。
1. 用 low effort 尋找檔案位置並整理資料
2. 用 medium effort 評估修改方向的優缺點
3. 用 high effort 對最終程式碼進行找 bug 的 review
請顯示每個 sub-agent 實際被分配的 effort，
並且只把結論和證據的檔案路徑帶回給主 agent。
如果每次都要講很麻煩，就把 agent 存成檔案。
--> 例如，存在專案的 .claude/agents/ 資料夾裡，檔名取為 light-research.md。
name: light-research
description: 僅用於尋找相關檔案與證據位置的輕量研究
model: haiku
effort: low
兩種方法——每次呼叫時指定（如上面的提示詞），或是透過檔案固定下來——都行得通！
2. Context 管理與避免浪費 Token
🤪 Claude Code 突然變笨的原因，大多出在 context。
Context 就是 Claude 一次能記住的工作區。對話、讀取的檔案、指令執行的結果全都會累積在這裡。
--> 現在的 Claude Code「預設」就有 1M（100 萬 token）的 context。
問題在於把這 1M 塞得太滿。
這不只是 Claude 的問題，而是 Codex 等所有 LLM 共同的限制。
⭐️ 技巧：把 autocompact 設在 500~700k ⭐️
所以我會把自動壓縮的門檻往前拉。
/autocompact 600k
這樣會把觸發自動壓縮的視窗大小降到 600k token。
在塞滿 1M 之前，Claude 就會自動摘要對話並騰出空間。
（要恢復預設值，輸入 `/autocompact auto`。）
⚠️ 第二個要注意的事：快取過期 ⚠️
如果你一個 session 用很久，一定要檢查這個。
Claude Code 每次發送請求時，都會把之前的整段對話重新送出。之所以又快又便宜，是因為有快取機制——已經處理過的部分不會重複計算。
但這個快取不是永久的。
- Pro 或 Max 訂閱（方案內用量）：主對話快取 1 小時
- API key 或額外購買的用量額度：5 分鐘
- Sub-agent：即使有訂閱也是 5 分鐘
我曾經在畫面上看到約 852k 的 uncached（未快取）。在這種狀態下，就算只送出一行 "continue"，也得在沒有快取的情況下重新處理約 850k token。用量可能會瞬間掉一大截。
常見導致快取失效的情況：
- 休息很久後，繼續使用一個超大的 session
- 在 session 中途切換模型（每個模型的快取是分開的）
- 變更已連接的 MCP 工具設定
應對方法很簡單：
- 離開前先清理。趁快取還活著時用 `/compact`，或者用 `/clear` 重新開始。
- 更新到最新版本。從 v2.1.299 起，超過 200k token 的對話會在閒置約 54 分鐘後、1 小時快取過期前自動壓縮。你可以在
/config的 Idle compaction 選項中停用此功能。）
**
3. 用 /doctor prompt-audit 清理過時的規範
從以前的建議照抄過來的 CLAUDE.md。每次犯錯就一條一條加上去的規則。
大部分都是為舊模型寫的。
新模型遵循指令的能力比舊模型好太多了。
⚠️ 所以過去那些需要強調「必須！！」「絕對不行！！」的規則，現在可能反應過度了。⚠️
而且還累積了不少跟目前程式碼互相衝突、或彼此矛盾的規則。
現在只要一行指令就能檢查。
1/doctor prompt-audit
這是 9 月底更新（v2.1.283）加入的功能。
它會檢查什麼？
- 專案及其上層資料夾中的 CLAUDE.md、CLAUDE.local.md、AGENTS.md
- ~/.claude/CLAUDE.md（套用到所有專案的個人規範）
- .claude/ 內的規則、技能、自訂指令、sub-agent 定義、輸出樣式
對於外掛的技能和 agent，它只會回報問題，不會提供修復建議。
判斷標準是根據你目前正在使用的模型。它會找出該模型已經過時的提示詞模式，並產出一份附帶修復建議的報告。
（它不會去讀可能包含金鑰的檔案，例如設定檔或 .mcp.json。）
4. 當 Claude 一直犯同樣的錯時，該修的是工作環境
⛏️ AI 又在亂搞了。為了一個問題卡了好幾個小時。 ⛏️
如果你第三次在糾正同一件事，那就不是模型的錯，而是工作環境的錯。
這個方法我從 Claude Sonnet 3.7 時代就開始用，已經超過一年了。 簡單來說就是..
--> 讓 AI 去分析它失敗的那個 session，然後把原因和驗證方法寫進專案規範裡。
⭐️ 像這樣做！「用 Session ID 分析錯誤」 ⭐️
1. 在不斷出錯的 session 裡輸入 `/status` 取得 Session ID。把它複製下來。
2. 開啟一個新的 Claude Code session（用 Codex 也行），貼上這段：
1"<Session ID>" → 找出這個 Claude Code session 中失敗兩次以上的地方。23找出我已經提醒過但它還是持續犯錯的地方，以及瓶頸所在。45將發生原因分類（錯誤假設、缺少 context、程式碼結構、缺乏測試）67並針對 CLAUDE.md、.claude/rules、技能、8hooks 或測試提出最小幅度的修改建議，以防再次發生。
3. 檢視建議，只套用好的部分。
4. 驗證效果。重新嘗試之前失敗的請求，看看現在是否行得通。
⚠️ 不要把什麼東西都塞進 CLAUDE.md。⚠️
越寫越長只會吃掉 context，而且規則會互相打架！！！
- 整個專案通用的規則放 CLAUDE.md
- 特定資料夾／檔案的規則放 .claude/rules/ 或該資料夾內的 CLAUDE.md
- 重複的操作流程做成技能
- 絕對不能違反的規則透過 Hooks 和權限來控管（技巧 #10）
- 反覆出現的同一個 bug 靠迴歸測試來防堵
偶爾用技巧 #3 的 `/doctor prompt-audit` 清理累積的規則。技巧 #4 負責建立，技巧 #3 負責打掃。
**
5. 用 Claude-Mem 跨 session 保留工作記憶
session 一結束，Claude Code 就會忘記對話內容。
**「上次我們為什麼那樣做？」
「那個錯誤是怎麼修的？」**
每次開新 session 你都得重新解釋一遍。
我用了一整年唯一沒換過的 Claude Code 外掛，解決了這個問題。
--> 就是 claude-mem。
⭐️ 它在 GitHub 上有超過 100k 顆星。 ⭐️
它跟基本的記憶功能有什麼不同？
Claude Code 本身有基本的 Auto Memory。差異如下：
基本的 Auto Memory 會把 Claude 認為重要的內容和從專案中學到的東西摘要成筆記。可以用 /memory 查看，不需要安裝任何東西。
claude-mem 會自動記錄之前的 session 做了哪些任務、錯誤怎麼解決的、決策背後的理由。並在下一個 session 取出需要的紀錄。
我的畫面顯示最多省下了 87% 的 token。
安裝只要在終端機打一行：
1npx claude-mem install
或者在 Claude Code 裡面以外掛形式安裝：
1/plugin marketplace add thedotmack/claude-mem2/plugin install claude-mem
❌ 以下情況不建議使用 ❌
- 你主要使用 Codex
- 你已經有其他記憶外掛或自訂的交接系統
疊加功能重複的工具只會增加複雜度和成本。
如果你只用 Claude Code，那還是非常強烈推薦。
6. 用 Statusline 一眼掌握模型、Effort、Context 和用量
在使用 Claude Code 的時候，你一定會一直想：
- 這個 session 是 Opus？Sonnet？還是 Haiku？
- Effort 設了多少？
- Context 用了多少？
- 5 小時和每週的額度還剩多少？
🔥 Statusline 會讓這些資訊一直顯示在終端機底部。 🔥
建立它很簡單。在 `/statusline` 後面描述你想要的樣子，Claude 就會產生並套用腳本。
我分享過的 5 種設計
我之前分享過 5 個可以直接複製貼上的 statusline 提示詞。
1. Minimal：一行顯示模型、effort、專案、context
2. Pastel Blocks：適合深色終端機的粉彩高亮色塊
3. Nord Powerline：區塊之間用平滑箭頭分隔
4. Limit Dot Bar：給 Pro/Max 用戶。用圓點條顯示 5 小時與 7 天用量及重置倒數
5. Vivid Gauge：萊姆綠徽章搭配斜線量表。包含 context token 數量
完整的提示詞都在原貼文裡。複製貼上後，Claude 馬上就能幫你建好。
1. Minimal： https://x.com/lucian__03/status/2103173295118098750
2. Pastel Blocks： https://x.com/lucian__03/status/2103173396075065594
3. Nord Powerline： https://x.com/lucian__03/status/2103173518573916178
4. Limit Dot Bar： https://x.com/lucian__03/status/2103173612832444536
5. Vivid Gauge： https://x.com/lucian__03/status/2103173754218258607
7. 讓 Claude 自己執行並驗證結果
Claude 說「實作完成！」但一跑起來就失敗。按鈕點不到、畫面破版，或什麼都沒出現。
測試過了但 App 還是壞掉的情況，比你想像中多很多。
所以要讓 Claude 自己去啟動並操作 App。為此有這些指令：
- /run：實際執行專案 App 並操作它來驗證修改。
- /verify：建置並執行 App，確認修改的功能是否正常運作。不能用測試／型別檢查來代替。
- /run-skill-generator：把如何執行這個專案（指令、環境變數、前置步驟）存成技能。複雜的專案請先做這一步。
- /verify 會把驗證過的方法存成專案技能（.claude/skills/verify/）以便重複使用。
使用流程：
1. 實作功能，先檢查測試／建置
2. 用 /run 執行 App
3. Web 就點擊／輸入，CLI 就給範例輸入／輸出
4. 用 /verify 再次確認目標是否達成
5. 失敗就修正重跑。保留實際的指令結果／截圖作為證據
8. 把寫程式的 AI 和 Review 的 AI 分開
你自己寫的文章看不出錯字。AI 也是一樣。
寫程式的 session 會偏向「這樣寫是對的」。
⭐️ 所以要用一個擁有全新 context 的 reviewer。⭐️
- /code-review：找出修改過的程式碼、PR、分支、路徑中的 bug／準確度問題。
- 可以用 /code-review high 設定強度（從 low 到 max）。
（預設只回報；加上 --fix 才會自動修正。）
- /security-review：檢查分支與遠端預設分支 diff 中的安全問題（驗證、輸入檢查、資訊洩漏）。
- /simplify：清理重複、低效和過於複雜的程式碼。不是用來找 bug 的（那是 /code-review 的工作）。
建議順序：
1. 用 /simplify 清理程式碼
2. 用 /verify 驗證功能（技巧 #7）
3. 用 /code-review 找 bug
4. 如果有動到登入／付款／API 金鑰／個資，再加上 /security-review
不用每次都跑完這 4 個。
⚠️ 小修改可能只要跑 /code-review 就夠了。⚠️
想要更深度的 review，可以用 /code-review ultra（等同於 /ultrareview）。
（這是雲端深度 review；Pro/Max 用戶有 3 次免費機會。）
9. 在寫複雜程式碼前，先定義設計與完成標準
遇到複雜任務時，先給 Claude 範圍和完成標準，而不是長篇大論的程式碼指令。
如果不這麼做，Claude 會自己任意擴大範圍。
⚠️ 它會去改不必要的檔案，做你沒要求的事。⚠️
使用 Plan Mode：
按 Shift+Tab 會顯示 plan mode on，或輸入 /plan。也可以像 /plan fix login bug 這樣附加任務。
（Plan Mode 只會讀取檔案和規劃。核准後才會修改程式碼。）
流程：探索 → 規劃 → 核准 → 實作 → 驗證。
改錯字／單行修改就不用規劃了。官方文件的規則是：如果一句話就能描述完的修改，就跳過 plan。
10. 用 Hooks 自動強制執行關鍵規則
就算 CLAUDE.md 寫了「不要動這個檔案」，Claude 有時還是會去動。
🔥 CLAUDE.md 是指導；Hooks 才是強制執行。 🔥
最常用的 3 個：
- PreToolUse：在編輯檔案／執行指令之前。阻擋受保護檔案的編輯或危險指令。
- PostToolUse：剛執行完之後。自動格式化／lint 編輯過的檔案。
- Stop：當 Claude 試圖結束時。如果測試還沒跑完就不准停。
範例：阻擋 prod 設定檔的編輯
叫 Claude 幫你建 hook：
--> 「建立一個 PreToolUse hook，阻擋對 config/production.env 的編輯。」
適合的使用情境：
- 編輯程式碼檔案時自動跑 formatter（PostToolUse）
- 碰關鍵資料夾前要求確認（PreToolUse）
- 沒跑測試就阻擋結束（Stop）
- 阻擋危險指令（PreToolUse + Bash）
11. 用 Git Worktree 同時跑多個 Claude Session
如果兩個 Claude 視窗在同一個資料夾裡工作會怎樣？
🚫 它們會因為編輯同一個檔案而衝突。（非常痛苦..） 🚫
Worktree 會把 repo 依照任務拆分成獨立的資料夾／分支。
Claude Code 只要一行指令就能做到：
在兩個終端機分別執行：
claude --worktree feature-authclaude --worktree feature-dashboard
用簡寫的 -w 也可以。
它會建立 .claude/worktrees/feature-auth/，並在 worktree-feature-auth 分支上工作。
--> ⭐️ 兩個 session 不會碰到彼此的檔案。 ⭐️
注意事項：
新的 worktree 是從遠端預設分支（main）開始，而不是目前的分支。
傳入 PR 編號，例如 claude --worktree "#1234"，就能從該 PR 開始。
結束 session 時會詢問你要保留還是刪除剩下的 work。
警告：
- Worktree 只隔離檔案／分支。共用的本機 DB／port／部署目標／API 帳號還是會衝突。
- 如果編輯了相同的檔案，仍有可能發生合併衝突。
- 耦合度高的任務要先定義好介面或排定順序。
- 每個 session 會消耗各自的用量。平行處理 ≠ 省 token。
12. 用 /goal 反覆驗證直到達標
Claude 跑一輪就停了。就算有 3 個測試失敗，它也可能跟你說「大致修好了」。
- Goal 會讓 Claude 一直工作到符合完成標準為止（從 v2.1.139 起）。
- /goal 可顯示目前的目標／狀態。
- /goal clear 可解除目標／停止。
運作方式...
每一輪結束後，會用一個小而快的模型評估條件是否達成。如果沒有，Claude 就繼續下一輪。
要在目標裡包含驗證方法（例如「輸出測試指令／結果」）。 裁判模型需要證據。
跟 /loop 或 Stop hook 有什麼不同？
--> Goal 在失敗時會立刻開始下一輪。裁判確認成功時才會停。
/loop 是固定間隔重複任務（例如 /loop 5m check deploy）。
Stop hook 是在回合結束時跑自訂腳本來檢查條件。
組合起來效果最好：
1. 用 /plan 定義範圍／標準（技巧 #9）
2. 用 claude -w 拆分任務（技巧 #11）
3. 透過 Hooks 格式化／阻擋（技巧 #10）
4. 用 /goal 反覆執行直到符合標準（技巧 #12）
5. 用 /run 和 /verify 確認（技巧 #7）
6. 用 /code-review 以全新的 context 進行 review（技巧 #8）
總結
1. 依任務調整 effort。委派給 sub-agent。
2. 不要把 context 塞滿。注意快取過期。
3. 用 /doctor prompt-audit 清理舊的 CLAUDE.md。
4. 反覆出錯時，該修的是環境而不是模型。
5. 用 claude-mem 實現跨 session 記憶。
6. 用 statusline 監控模型／effort／context／額度。
7. 用 /run 和 /verify 驗證，不要只聽它說「完成了」。
8. 把寫程式和 review 的 AI 分開。
9. 複雜任務先規劃。
10. 用 Hooks 強制執行關鍵規則。
11. 用 worktree 平行處理。
12. 用 /goal 堅持到成功為止。
Claude Code 更新非常快。有新技巧我會再分享。
如果覺得有幫助請加入書籤，也歡迎分享給在用 Claude Code 的朋友。
感謝閱讀！
文中引用的先前單篇貼文：
Sub-agent effort： https://x.com/lucian__03/status/2108194703782916166
Effort，Max 不見得最好： https://x.com/lucian__03/status/2104641991279874134
autocompact 500~700k： https://x.com/lucian__03/status/2108589402914177236
852k uncached 與快取過期： https://x.com/lucian__03/status/2106396357527531800
/doctor prompt-audit： https://x.com/lucian__03/status/2104560017407869028
AI 自我改進（Harness 更新）： https://x.com/lucian__03/status/2081761475560157477
claude-mem： https://x.com/lucian__03/status/2108997241864159442
5 種 statusline 設計： https://x.com/lucian__03/status/2103173166973718537
