Claude Code token 消耗突然變高原因：教程、排障和 FAQ

Claude Code 用得順手以後，很多人會遇到一個很現實的問題：前幾天還覺得額度夠用，突然某一天 token 消耗明顯變高，同樣是改一個小功能，費用和額度掉得比預期快很多。

這種情況不一定是 Claude Code 變貴了，也不一定是模型出問題。更多時候，是上下文、工具呼叫、檔案讀取範圍、長會話、Hooks、MCP 或任務寫法共同把 token 撐大了。排查思路應該先找“最近哪裡變了”，再決定是壓縮上下文、縮小任務範圍，還是調整工作流。

先理解 token 花在哪裡

Claude Code 的 token 消耗通常來自幾類內容：

• 你輸入的任務說明。
• Claude Code 讀取到的檔案內容。
• 終端命令輸出、測試日誌和報錯棧。
• 對話歷史和中間推理上下文。
• 工具呼叫結果，例如搜尋、讀取檔案、MCP 返回的資料。
• 專案規則檔案，例如 CLAUDE.md、Memory、Hooks 注入的資訊。
• 模型輸出本身。

所以，token 消耗突然變高，不一定是你的那一句提示詞變長了。更常見的是：Claude Code 為了完成任務讀取了更多檔案，保留了更長會話，或者工具輸出裡塞進了大量日誌。

快速止血：先做這幾步

如果你已經發現額度掉得很快，可以先按這個順序止血：

1. 開新會話，避免把舊上下文繼續帶進去。
2. 明確告訴 Claude Code 只讀取相關檔案。
3. 不要讓它一次分析整個倉庫。
4. 測試失敗時只貼最後 100 行關鍵日誌。
5. 臨時關閉不必要的 MCP 工具。
6. 檢查 Hooks 是否自動附加了大量輸出。
7. 把任務拆成“定位問題”和“修改檔案”兩步。

一個更省 token 的任務寫法是：

1
2
3

請只檢視 src/auth/session.ts 和 tests/auth/session.test.ts。
目標：找出登入態丟失的原因。
不要掃描整個倉庫，不要修改檔案，先給出排查結論。

這比“幫我看看登入為什麼有問題”更容易控制上下文。

原因一：長會話沒有清理

最常見的原因是會話太長。你前面讓 Claude Code 查過日誌、讀過大檔案、跑過測試、討論過方案，這些內容會逐步進入上下文。後面即使只是問一個小問題，也可能帶著很重的歷史包袱。

表現通常是：

• 同樣的小任務，越到後面越慢。
• Claude Code 開始引用很早之前的內容。
• 明明只改一處，它卻反覆回顧之前的方案。
• token 消耗隨著會話長度持續上升。

處理方法：

• 一個獨立任務開一個新會話。
• 長任務階段性總結後再繼續。
• 把已經確定的專案規則寫進 CLAUDE.md，不要靠長對話反覆儲存。
• 對舊討論只保留結論，不保留完整過程。

如果你已經完成定位，只剩改程式碼，最好新開一輪，把結論和目標用短提示詞重新交代。

原因二：Claude Code 讀取了太多檔案

有些任務描述太開放，Claude Code 會主動搜尋和讀取大量檔案。例如：

1

幫我最佳化這個專案的登入邏輯。

它可能會讀路由、元件、狀態管理、測試、配置、文件，甚至歷史指令碼。檔案越多，token 越高。

更好的寫法是：

1
2

請只分析登入態重新整理流程，優先檢視 src/auth 和 tests/auth。
如果需要讀取其他目錄，先說明原因。

排查時可以觀察 Claude Code 讀了哪些檔案。如果它不斷開啟無關檔案，說明任務邊界太寬，應該暫停並重新限定範圍。

原因三：測試日誌和構建輸出太長

測試失敗、型別檢查失敗、構建失敗時，日誌很容易膨脹。特別是前端專案、單元測試快照、依賴安裝日誌和編譯錯誤，幾百行輸出很快就會吃掉上下文。

常見高消耗來源：

• npm install 或 pnpm install 的完整輸出。
• pytest -vv 的詳細日誌。
• Playwright 失敗時的大段 trace 資訊。
• TypeScript 一次報幾百個錯誤。
• Docker build 的完整層輸出。

建議做法：

• 只保留關鍵錯誤段。
• 先執行更窄的測試命令。
• 讓 Claude Code 先看最後一段報錯。
• 對重複錯誤先人工歸類，再交給模型判斷。

例如：

1

pnpm test -- auth

通常比：

1

pnpm test

更適合排查單點問題。

原因四：CLAUDE.md 太長或規則重複

CLAUDE.md 很有用，但如果寫成幾千行專案百科，每次進入專案都會增加上下文負擔。尤其是把 README、架構文件、部署手冊和個人偏好全部塞進去，token 消耗會穩定變高。

建議 CLAUDE.md 只保留高頻規則：

• 技術棧。
• 常用命令。
• 禁止修改的檔案。
• 驗證方式。
• 專案特有約定。

不要放這些內容：

• 過期歷史。
• 大段業務背景。
• 完整 API 文件。
• 重複的編碼風格提醒。
• 臨時任務記錄。

如果文件確實很長，可以拆到 docs/，在 CLAUDE.md 裡只寫“需要時再讀取哪個檔案”。

原因五：Memory 裡積累了太多跨專案資訊

Memory 適合儲存長期偏好，但不適合儲存某個專案的細節。比如某個倉庫的路徑、命令、部署指令碼、臨時決策，如果進入長期記憶，換專案後也可能被帶出來。

這會造成兩個問題：

• token 變高，因為上下文裡混入了更多背景。
• 行為變差，因為 Claude Code 可能把舊專案規則套到新專案。

排查方法：

• 看最近是否頻繁要求 Claude Code“記住”某些專案細節。
• 檢查是否把臨時路徑、舊命令、一次性結論寫進了長期記憶。
• 把專案規則遷回專案內文件，例如 CLAUDE.md。

長期記憶應該儲存“團隊偏好”，專案檔案應該儲存“倉庫事實”。

原因六：Hooks 自動注入了大量內容

Hooks 可以讓 Claude Code 更可靠，但也可能悄悄增加 token。例如每次編輯後自動列印完整 diff、完整測試日誌、完整目錄樹，都會讓上下文變重。

需要重點檢查：

• Hook 是否每次都輸出完整檔案內容。
• Hook 是否列印完整環境變數。
• Hook 是否在失敗時重複輸出同一段日誌。
• Hook 是否對所有檔案改動都跑大測試。
• Hook 是否把報告寫回對話而不是寫入檔案。

更省的做法是讓 Hook 輸出摘要：

1
2

lint failed: 3 errors in src/auth/session.ts
full log saved to .tmp/lint.log

而不是把完整日誌直接塞回對話。

原因七：MCP 工具返回太多資料

MCP 很方便，但有些工具預設返回大量結果。例如文件搜尋、資料庫查詢、網頁抓取、程式碼索引，如果沒有限制結果數量，很容易把上下文撐大。

排查時看三個點：

• 一次搜尋返回了多少條。
• 每條結果是否包含全文。
• 是否重複查詢同一類資料。

可以要求 Claude Code 限制結果：

1

只取最相關的 5 條結果，不要展開全文。先告訴我每條結果為什麼相關。

如果 MCP 工具支援引數，優先設定 limit、page_size、summary_only 這類選項。

原因八：模型切換導致單次成本變化

有時候 token 數沒明顯增加，但消耗感覺更快，是因為模型切換了。更強模型、長上下文模型、思考能力更強的模型，單位 token 成本或使用額度折算可能不同。

需要確認：

• 當前使用的是哪個 Claude 模型。
• 是否從輕量模型切到了更強模型。
• 是否開啟了更高 effort 或類似長推理模式。
• 團隊配置是否最近調整過預設模型。

如果只是做簡單改寫、解釋和小指令碼，本來就不一定需要最高檔模型。可以按任務風險選擇模型。

原因九：失敗重試太多

當 Claude Code 連續跑錯命令、測試反覆失敗、補丁多次衝突時，token 會快速累積。每一次失敗都可能產生日誌、解釋、修復計劃和新的工具呼叫。

處理方法：

• 連續失敗兩次後暫停，不要繼續讓它盲改。
• 要求它先總結失敗原因。
• 縮小任務到最小復現。
• 把命令和錯誤輸出固定下來，再決定下一步。

可以這樣提示：

1

先停止修改。請只總結剛才兩次失敗的共同原因，並給出一個最小驗證命令。

這比讓它繼續“再試一次”更省，也更安全。

原因十：任務描述太抽象

抽象任務會讓 Claude Code 自己探索上下文，探索越多，token 越高。

高消耗寫法：

1

幫我把這個模組最佳化一下。

低消耗寫法：

1
2
3

請只最佳化 src/cache/store.ts 的過期清理邏輯。
不要改公開 API。
修改後執行 tests/cache/store.test.ts。

任務越像工單，Claude Code 越能少走彎路。

排障清單

如果你不知道 token 為什麼突然變高，可以按這張清單排：

推薦的省 token 工作流

一個比較穩的 Claude Code 工作流可以這樣設計：

1. 先描述目標和邊界。
2. 要求 Claude Code 只讀取必要檔案。
3. 第一輪只分析，不修改。
4. 確認方案後再讓它改小範圍檔案。
5. 執行最小相關測試。
6. 測試失敗只保留關鍵日誌。
7. 任務結束後新開會話處理下一件事。

示例提示詞：

1
2
3
4

目標：修復登入態重新整理失敗。
範圍：優先檢視 src/auth/session.ts 和 tests/auth/session.test.ts。
限制：第一輪不要修改檔案，不要掃描整個倉庫。
輸出：只給出最可能的 3 個原因和驗證方法。

這種寫法不花哨，但非常省。

FAQ

token 變高是不是 Claude Code 出 bug 了？

不一定。更常見的是上下文變長、檔案讀取變多、工具輸出變大，或者預設模型發生變化。先排查最近的專案配置和工作流變化。

關掉 MCP 會省 token 嗎？

如果 MCP 工具返回大量搜尋結果、網頁內容或資料庫記錄，關掉不必要的工具會省。更好的做法是限制返回數量和摘要長度，而不是完全不用。

CLAUDE.md 越詳細越好嗎？

不是。CLAUDE.md 應該寫高頻、穩定、會影響操作的規則。大段背景資料放到文件裡，需要時再讓 Claude Code 讀取。

為什麼小改動也消耗很多？

因為小改動可能發生在長會話後，也可能觸發大量檔案讀取、測試日誌或 Hooks 輸出。token 消耗看的是整輪上下文，不只看改動行數。

開新會話會不會丟掉重要上下文？

會丟掉舊對話細節，但這通常是好事。你可以把必要結論用幾行重新說明，避免把所有歷史過程繼續帶進去。

怎樣判斷是不是測試日誌太長？

看 Claude Code 最近是否接收了完整測試輸出、構建日誌或依賴安裝日誌。如果日誌裡有大量重複錯誤，先裁剪再讓模型分析。

團隊裡怎麼統一控制 token？

可以把省 token 規則寫進團隊 CLAUDE.md：預設先讀相關檔案、優先最小測試、失敗日誌只看關鍵段、改動前先說明範圍。Hooks 和 MCP 也要限制輸出大小。

小結

Claude Code token 消耗突然變高，通常不是單一原因。長會話、寬任務、長日誌、過長 CLAUDE.md、Memory 汙染、Hooks 輸出、MCP 大結果、模型切換和失敗重試，都可能疊加。

最有效的處理方式是先止血：新開會話、縮小範圍、裁剪日誌、限制工具輸出。然後把穩定規則沉澱到專案文件，把重複檢查交給自動化，把臨時上下文留在當前任務裡。這樣 Claude Code 仍然能保持高效率，但不會每次小改動都變成一次昂貴的全倉庫探索。