Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎麼影響快取

Mon, 18 May 2026 18:30:24 +0800

Claude Code 長任務裡，Prompt Cache 命中率會直接影響成本和速度。很多人只知道「快取能省 Token」，但不清楚哪些操作會讓快取突然失效。

理解它並不難：每次請求都可以看成一條從左到右的上下文鏈條：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的內容越穩定，快取收益越大；越靠左的內容一變，後面的快取也更容易跟著失效。反過來，越靠右的內容變化，影響範圍越小。

所以優化 Claude Code 的 Prompt Cache，不是靠玄學，而是靠一個原則：任務開始前把模型、MCP、Skills、CLAUDE.md 等基礎上下文準備好，任務中途盡量不要改。

Prompt Cache 快取的不是文字本身

Prompt Cache 不是簡單地把提示詞字串存起來。對 Transformer 模型來說，更關鍵的是前綴上下文經過注意力層計算後的 Key/Value 狀態，也就是常說的 KV cache。

這意味著兩個事實：

同一段上下文，只要前綴保持穩定，就可以在後續請求中複用一部分計算結果。
如果模型、工具定義、系統提示詞或前綴訊息發生變化，之前的快取就可能無法複用。

Anthropic 官方文件也把失效層級概括為 tools -> system -> messages。工具定義變化會影響整段快取，系統層變化會影響 system 和 messages，messages 層變化則主要影響訊息快取。

Claude Code 裡還會額外涉及 CLAUDE.md、Skills、MCP、外掛和子代理等上下文，所以實際使用時更容易踩到快取失效點。

快取殺手一：中途切換模型

切模型是影響最大的操作。

Prompt Cache 是按模型隔離的。Opus、Sonnet、Haiku 這類模型的結構和權重不同，同一段文字算出來的 KV cache 也不同。你在 Opus 裡跑了很長上下文，再切到 Sonnet，並不能讓 Sonnet 複用 Opus 的快取。

這會帶來一個反直覺結果：中途為了省錢切模型，可能反而讓前面已經累積的快取全部失效。原本可以按 cache read 價格讀取的上下文，需要重新寫入和計算。

更穩妥的做法是：

主對話盡量固定一個模型。
需要便宜模型處理支線任務時，用 subagent 隔離出去。
讓支線代理完成搜尋、探索、整理，再把結果摘要交回主對話。

這樣主對話的長上下文盡量不動，快取命中率更穩定。

快取殺手二：中途新增 MCP 或重載外掛

MCP 會向 Claude Code 提供工具。新增 MCP 伺服器後，工具列表會變化，而工具定義處在上下文鏈條最左側。

從 Prompt Cache 的角度看，工具列表一變，後面的 system 和 messages 都可能需要重新計算。尤其是 MCP 很多時，工具定義本身就可能占用大量 Token，快取失效的代價會很明顯。

不過有一個細節：Claude Code 通常在會話啟動時讀取 MCP 配置。你中途改了配置，當前 session 不一定立刻受影響。真正需要小心的是觸發重新載入的動作，例如重啟、恢復會話、重新載入外掛或讓工具列表重新組裝。

建議是：

開始長任務前，一次性裝好需要的 MCP。
不要做一半才發現缺工具，再安裝並重載。
對大型 MCP 工具集，優先考慮按需載入或減少預設啟用數量。
不常用的 MCP 不要長期掛在預設配置裡。

如果工具定義穩定，Prompt Cache 才有長期命中的基礎。

快取殺手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的專案記憶文件，適合放構建命令、測試命令、架構約定、程式碼風格和專案注意事項。

它對 Claude Code 很有用，但也會進入上下文。官方說明指出，CLAUDE.md 會在 session 開始時讀取，並作為使用者訊息提供給 Claude；它也會使用 Anthropic 的 Prompt Cache。首次請求會按完整輸入計費，後續請求如果在快取有效期內命中，就按更低的 cache read 成本處理。

問題在於：CLAUDE.md 是內容定址的。你一改文件內容，舊快取就對不上了。

所以不要在長任務中途頻繁改 CLAUDE.md。更好的方式是：

任務開始前先檢查 CLAUDE.md 是否夠用。
把穩定規則寫進去，把臨時指令放在目前對話裡。
如果只是一次性任務，不要為了臨時需求修改長期記憶文件。
如果必須改，最好在一個階段結束後再開始新 session。

CLAUDE.md 應該是穩定的專案說明，而不是每輪任務都改的便條。

快取殺手四：中途安裝或更新 Skills

Skills 也是上下文的一部分。安裝新 Skill、更新 Skill，或者讓 Skill 列表發生變化，都會讓注入到會話裡的上下文不同。

這類變化通常不會在目前 session 裡立刻完整生效，而是在重新載入、恢復會話或新開會話時體現出來。問題是，一旦重新組裝 messages，舊快取就可能命中不了。

建議和 MCP 類似：

開始任務前先確認需要哪些 Skills。
同一類任務盡量固定 Skill 集合。
不要在一個長任務中途邊做邊裝 Skill。
如果安裝了新 Skill，最好把它當成新階段的開始。

對經常做內容生產、程式碼審查、部署、翻譯的工作流，可以把常用 Skills 固定下來，讓上下文結構盡量穩定。

快取殺手五：空閒時間超過 TTL

Prompt Cache 不是永久保存。常見預設有效期是幾分鐘級別，Anthropic 文件和 Claude Code 相關說明裡都提到過 5 分鐘左右的快取窗口。超過 TTL 後，即使你發送完全一樣的請求，服務端也可能已經清掉快取。

這也是很多長任務使用者的體感來源：剛才還很省，去喝杯咖啡回來，再發下一步，Token 又突然漲上去了。

長任務尤其容易遇到這個問題。你可能要看 Claude Code 的輸出、檢查文件、跑測試、思考下一步，這些操作一不小心就超過 5 分鐘。

如果你的使用環境支援，可以在長任務前啟用 1 小時 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 裡可以寫成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小時快取寫入成本通常會高於 5 分鐘快取寫入成本。它不適合所有短任務，但對大型程式碼庫、長對話、複雜多步驟開發任務，往往比頻繁快取過期更划算。

怎麼安排一次更省 Token 的 Claude Code 長任務

比較穩的流程可以這樣做：

任務開始前選定模型，不要中途頻繁切換。
提前啟用需要的 MCP，不用的 MCP 先關掉。
檢查 CLAUDE.md，只保留穩定、關鍵、長期有效的規則。
提前準備好本次任務需要的 Skills。
如果是複雜任務，考慮啟用 1 小時 TTL。
把大任務拆成幾個階段，但每個階段內部盡量保持上下文結構穩定。
需要探索支線問題時，用 subagent 或單獨 session，不要污染主對話。

這套做法的目標不是絕對不讓快取失效，而是避免那些代價最高、最容易被忽略的失效。

一個簡單判斷標準

你可以用一句話判斷某個操作是否危險：

這個操作會不會改變模型、工具定義、系統上下文或會話開頭的固定訊息？

如果答案是會，那它大概率會影響 Prompt Cache。越靠近上下文鏈條左側，影響越大。

常見操作可以這樣理解：

切模型：高風險，模型快取隔離。
新增 MCP 或重載外掛：高風險，工具列表變化。
修改 CLAUDE.md：中高風險，專案記憶變化。
安裝 Skills：中高風險，注入上下文變化。
普通對話繼續追問：低風險，主要追加 messages。
空閒超過 TTL：高風險，服務端快取過期。

小結

Claude Code 的 Prompt Cache 優化，關鍵不是背參數，而是讓會話前綴穩定。

模型不要隨便切，MCP 和 Skills 不要邊做邊裝，CLAUDE.md 不要當臨時草稿頻繁改，複雜任務盡量延長 TTL。只要這些基礎動作穩定下來，Claude Code 在長任務裡的 Token 成本和回應速度都會更可控。

最實用的一句話是：開始前配好，開始後少動。

Prompt Cache on KnightLi的博客