Claude Code 怎麼省 Token？6 個工作階段管理技巧，降低額度消耗又不犧牲品質

Claude Code 完成同一個修正，消耗的額度可能差很多。差別往往不在程式碼有多長，而在 Claude 為了找到答案讀了多少檔案、執行了多少指令，以及這些內容在對話裡停留了幾輪。

Anthropic 在 2026 年 8 月 14 日公布 Claude Code 工作階段的成本拆解。最實用的結論不是「盡量少用 Token」，而是讓 Token 花在真正相關的檔案、指令與推理上。對訂閱制使用者來說，這會影響額度消耗；對透過應用程式介面（API）按量計費的使用者來說，則會直接反映在帳單上。Anthropic：Maximizing the value of your Claude Code sessions

本文將原文整理成一套可以直接使用的工作方式。先講結論：開始任務前選好模型與 Effort、不同任務之間使用 /clear，並控制檔案與指令輸出進入 Context 的數量。 這三件事，通常比在 Prompt 裡少寫幾句話更有影響。

以下操作以本機終端機與整合開發環境（IDE）裡的 Claude Code 為主。Claude Code Web 支援 /compact 與 /context，但不支援 /clear；雲端使用者要從側邊欄建立新 Session，達到相同的 Context 分離效果。Claude Code Web 工作階段文件

先看懂 Claude Code 的 Token 花在哪裡

Token 是模型處理文字的基本單位，可以把它想成被模型拆開計算的文字片段。一次 Claude Code 請求主要包含兩類 Token：

• 輸入 Token：Claude 要先讀的內容，包括系統指令、用來保存專案規則的 CLAUDE.md、你的訊息、先前對話、已讀取的檔案，以及指令輸出。
• 輸出 Token：Claude 產生的思考、工具呼叫與最後回答。

輸出 Token 通常比輸入 Token 昂貴。Anthropic 表示，輸出會逐一生成，每一枚 Token 都需要一次模型運算，因此每枚輸出 Token 的價格約為輸入 Token 的 5 倍。Claude Code 工作階段成本說明

/effort 控制的就是模型每一輪願意投入多少推理，設定越高，通常會產生更多思考 Token。Claude Code 模型設定文件

但 Claude Code 最容易被忽略的成本，其實是 Context Window。Context Window 是模型在目前工作階段能看到的工作記憶，包含對話歷史、檔案內容、指令輸出、CLAUDE.md、已載入的可重複工作流程（Skill）與系統指令。每當 Claude 進入下一輪，這些內容都可能再次送給模型，而不是只傳一次。Claude Code Context Window 文件

換句話說，一份不相關的測試輸出若在第 5 輪進入 Context，可能一路跟到第 30 輪。即使後面已經用不到，Claude 仍要在每一輪讀過並避開這些雜訊。

Prompt Caching 為什麼能降低成本？

Prompt Caching 可以翻成「提示快取」。當新請求的開頭和上一輪完全相同，系統可以直接讀取先前運算結果，不必重新處理整段內容。

依 Anthropic API 價格文件，5 分鐘快取的首次寫入成本是一般輸入的 1.25 倍，1 小時快取寫入是 2 倍；後續命中快取時，只需一般輸入價格的 0.1 倍。首次建立快取比較貴，但同一段 Context 在後續多輪被重複使用時，總成本會下降。Claude API Pricing

Claude Code 會自動管理 Prompt Caching，使用者不需要手動開啟。不過，在長對話中途切換模型、Effort 或加速生成的 Fast Mode，會改變快取的識別條件，下一輪可能必須重新處理整段對話。這不是不能切換，而是應該在新工作階段開始，或執行 /clear 之後再切換。

訂閱制與 API 的體感也不同。訂閱制使用者不會逐筆看到 Token 帳單，但同樣的請求仍會消耗方案額度。依 Claude 官方文章，訂閱工作階段的快取可維持 1 小時；API Key 預設為 5 分鐘，也可設定使用 1 小時快取。離開很久再回到舊工作階段，下一輪通常會重新處理既有 Context。

Claude Code 省 Token 的 6 個實用方法

1. 不同任務之間使用 /clear

/clear 會開始一段乾淨的對話 Context。當你已經完成登入頁問題，接著要處理付款 API，前一個任務讀過的元件、測試與 Log 通常不再有用，繼續留在同一個工作階段只會增加後續每一輪的負擔。

判斷方式很簡單：如果新任務不需要引用前一個任務的決策與檔案，就使用 /clear。 若之後可能回來查看，可以先用 /rename 替工作階段命名，再清空目前 Context。

2. 開始前先選模型與 Effort

模型決定每枚 Token 的基礎成本，Effort 則決定模型願意投入多少推理。例行格式修改、已知錯誤的小範圍修正，不一定需要最高階模型與最高 Effort；模糊的架構問題、跨模組除錯或高失敗成本任務，才比較值得使用更強的組合。

可以在新工作階段先執行：

/model
/effort

這一步不只是確認當下設定。Claude Code 會記住部分模型與 Effort 選擇，若沿用上一個高難度任務的設定處理簡單工作，可能在沒有察覺的情況下持續使用較高額度。

3. 用 @ 直接附上檔案

如果已經知道問題在哪個檔案，不要只說「測試壞了」，也不要讓 Claude 自己在整個程式庫（Repository）搜尋。可以直接指定檔案：

修正 @utils.test.ts 的失敗測試，修改範圍只限相關函式，完成後執行這個測試檔。

使用 @ 會在第一個請求直接附上檔案，省去搜尋或 Read 工具呼叫。檔案本身占用的 Context 並沒有消失，因此同一個工作階段通常只需附加一次，重複標記反而可能放入第二份副本。

4. 讓測試與指令只回傳必要資訊

Claude Code 執行測試、Build 或 git log 後，終端機輸出也會進入 Context。如果測試工具逐行列出 400 個通過項目，這些文字可能在後續每一輪被重新送出。

最實際的做法是使用測試工具提供的安靜模式、精簡 Reporter，或只執行相關測試。例如 Vitest 可以指定單一檔案並使用較短的輸出：

npx vitest run path/to/file.test.ts --reporter=dot

若團隊每天都會執行相同指令，可以把正確版本與安靜參數寫進 CLAUDE.md，讓 Claude 不必先猜一次。這種小設定能同時省掉探索回合與無關輸出。

5. 用 /context 檢查工作階段的隱性負擔

/context 會列出目前 Context Window 被哪些內容占用，包括系統指令、Memory、Skill、MCP 工具與對話訊息。MCP 是讓 Claude 連接外部服務與工具的標準。建議先在全新工作階段執行一次，這樣才能看出還沒開始工作前，環境已經載入多少內容。Claude Code 設定除錯文件

如果 CLAUDE.md 放了大量只在少數任務使用的流程，可以把它們改成需要時才載入的 Skill。沒有要使用的 MCP Server 也可暫時關閉。這不是把所有設定刪掉，而是讓常駐 Context 只保留每次工作都需要的規則。

6. 同一任務太長時用 /compact，高雜訊工作交給 Subagent

/compact 會把較長的對話整理成摘要，保留主要目標、決策與必要程式碼，釋放 Context 空間。它適合同一個任務已完成前半段，但後半段仍需要沿用關鍵決策的情況；若已經換成不同任務，使用 /clear 通常更乾淨。

官方建議在離開鍵盤一段時間前先執行 /compact。原因是摘要若在快取仍有效時產生，會比隔很久後重新處理整段舊對話便宜。執行時也可以補上保留重點，例如：

/compact 保留 API 契約、已確認的根因、修改檔案與尚未完成的測試

另一種情況是分析大量執行紀錄（Log）、搜尋很多檔案，最後只需要一小段結論。這類工作適合交給 Subagent。Subagent 是獨立的 AI 工作執行者，擁有自己的 Context Window；中間讀取的資料不會全部塞進主對話，只會把結果送回來。Claude Code Subagent 文件

但 Subagent 不是免費省額度工具。它需要建立自己的 Context，也可能重新讀取主對話已經看過的內容。小型修正直接在主對話處理較有效率；只有輸出很多、範圍獨立，且最後只需摘要的任務，隔離 Context 才真正划算。

真正該先處理的 4 個成本來源

依 Anthropic 的排序，最值得優先檢查的是：

1. 工作階段太長：每一輪都會帶上前面的內容，越後面的回合負擔越大。
2. Context 裡有太多無關內容：不需要的檔案、指令輸出與前一個任務，會在後續回合持續被讀取。
3. 模型或 Effort 超過任務需要：高成本設定會放大前兩項問題。
4. Prompt Cache 失效：長對話中途切換模型或 Effort，可能讓整段 Context 重新以完整價格處理。

這個順序很重要。很多人一想到省 Token，就先縮短 Prompt 或改用小模型；但如果一個工作階段已經累積 30 輪無關內容，少寫兩句 Prompt 幾乎不會改變整體消耗。先切斷不需要的歷史，再調整模型，通常更有效。

一套可以直接照做的 Claude Code 工作流程

開始工作前，先把任務邊界寫清楚，並確認模型與 Effort。已知目標檔案時直接使用 @，測試則指定單一檔案與精簡輸出。

任務進行中，若 Claude 開始讀取大量不相關檔案，可以立即縮小範圍，而不是等到最後才重來。需要分析大量 Log 時，讓 Subagent 只回報根因、證據與建議修改位置。

任務完成後，再判斷下一件事是否需要目前 Context。同一個功能的後續測試可以繼續，已完成的前半段可用 /compact 摘要；完全不同的需求則先 /rename，再用 /clear 開始。

這套方法的價值不只在省額度。Context 越乾淨，Claude 越不容易被舊需求、過期檔案與無關 Log 干擾，通常也更容易產生可驗收的修改。

Claude Code 省 Token 常見問題

/clear 和 /compact 有什麼差別？

/clear 會清除目前對話 Context，適合切換到不同任務。/compact 則把同一任務的歷史整理成摘要，適合仍需保留既有決策與進度時使用。

切換較小模型一定比較省嗎？

單枚 Token 通常會比較便宜，但不代表完成任務的總成本一定更低。若小模型需要更多回合、讀更多檔案或反覆修正，總消耗可能更高。例行工作適合較小模型，模糊或高風險決策仍應優先考慮一次做對。

Context 越大，Claude Code 就越好用嗎？

不一定。較大的 Context Window 能容納更多資料，但不相關內容也會增加成本與干擾。真正有價值的是「相關 Context」，不是把整個 Repository、完整 Log 與所有舊對話都留著。

Subagent 越多，Token 就省越多嗎？

不是。Subagent 能隔離大量中間輸出，但每個 Subagent 都要建立自己的 Context 並執行模型推理。小任務使用 Subagent 可能只增加額外成本，適合交付的是範圍獨立、輸出很多、最後只需要摘要的工作。

Claude Pro 或 Max 訂閱也需要管理 Token 嗎？

需要。訂閱使用者雖然不會看到逐筆 API 費用，但相同請求會消耗方案額度。縮短無關 Context、避免長工作階段與選對模型，仍能讓固定額度完成更多有效工作。

結語：省 Token 的核心，是讓每個工作階段只處理一件事

Claude Code 的 Token 效率，不是把每個 Prompt 壓到最短，也不是永遠選最便宜的模型。真正有效的方法，是在開始前選好模型與 Effort，讓 Context 只保留當前任務需要的檔案、輸出與決策。

我的建議很直接：先養成「一個工作階段，一個主要任務」的習慣，再依序導入 /context、@ 檔案標記、安靜測試指令與 /compact。Subagent 留給真正會產生大量雜訊的獨立工作。這樣做不只降低額度消耗，也能讓 Claude 的注意力更集中在你真正要解決的問題上。

資料來源

• Anthropic：Maximizing the value of your Claude Code sessions
• Claude Code Docs：Explore the context window
• Claude Code Docs：Model configuration
• Claude Code Docs：Create custom subagents
• Claude Code Docs：Debug your configuration
• Claude Code Docs：Use Claude Code on the web
• Claude API Docs：Pricing and prompt caching