Claude Code Token 燒太快？8 招讓你的 Session 撐 10 倍久

你剛開始用 Claude Code。很厲害。然後它變慢了。

你裝了 Claude Code。叫它修一個 bug。它讀你的檔案、理解問題、寫出修正。神奇。

然後到了第 15 個問題，有什麼不對了。Claude 開始忘記你之前說過的事。回答變不精確。最後你看到可怕的 compaction 訊息 — Claude 不得不壓縮對話因為 context window 滿了。

發生了什麼？你沒做錯什麼。問題是隱形的，這篇讓它現形。

---

前言

想像一張桌子。每次你問 Claude 問題，它不是只看你的問題 — 它會把整份說明書、所有可能用到的工具、以及你們所有對話的逐字稿全攤在桌上。你的實際問題只能用剩下的空間。

桌子有 200K tokens 寬。聽起來很大，直到你發現 40% 在你坐下之前就被佔滿了。

---

Part 1：Token 都花去哪了？

你看不見的東西

每一條你送出的訊息都帶著隱形行李：

你的規則（CLAUDE.md） — 如果你設了 CLAUDE.md 寫 coding 標準、專案慣例、工作流指令，Claude 每個 turn 都會重讀全部。一份完整的 CLAUDE.md 可以是 3-15K tokens。這值得 — 它讓 Claude 對你的專案有用。但不是免費的。

Tool 定義 — 每個裝了的 MCP tool（GitHub、Playwright、資料庫等）都把完整的使用說明加進對話裡。一個 tool = 500-2000 tokens。裝了 20 個？那就是 10-40K tokens 的永久開銷，每條訊息都帶著，即使你大部分都沒用到。

對話歷史 — Claude 說過的、你說過的、它讀過的檔案、跑過的指令 — 全都還在，每個 turn 都在長大。

一個典型 session 的 token 分布：

什麼	多大	什麼時候
系統指令	2-8K	永遠在
你的 CLAUDE.md	3-15K	永遠在
Tool 定義	5-50K	永遠在
對話歷史	逐 turn 增長	永遠在
Claude 讀的檔案	每個 1-10K	讀的時候

加起來： 一個有完整 CLAUDE.md 和 15-20 個 MCP tool 的新 session，還沒打字就花了 50-80K tokens。200K context window 的 25-40% 被基礎設施吃掉了。

隱藏的 Buffer

大部分人不知道的事：Claude Code 內部 reserve 了大約 33K tokens 做 buffer（來源）。這個空間用來做 compaction 時的摘要和生成回應。你不能關掉它。（注意：這個數字可能隨 Claude Code 更新而改變 — 跑 /context 看你的實際可用空間。）

也就是說你的 200K context window 其實接近 ~167K 可用。Auto-compaction 在遠低於 100% 時就觸發。如果你覺得 compaction「比預期早」— 這就是原因。

為什麼越到後面越糟

第 1 個 turn：你有 ~120K tokens 可以做正事（扣掉開銷 + buffer）。

第 10 個 turn：對話歷史長了，Claude 讀了一堆檔案、改了一些東西、跑了一些指令。大概剩 70K。

第 20 個 turn：你在 debug 一個複雜的問題，Claude 一直重讀檔案確認、tool 結果不斷堆積。剩 20K。Claude 開始忘記第 3 個 turn 你說過什麼。

第 25 個 turn：compaction。Claude 壓縮對話釋放空間，但過程中遺失細節。第 7 個 turn 討論過的修法？沒了。

這不是 bug。context window 就是這樣運作的。關鍵是知道什麼把它填滿 — 才能控制。

---

Part 2：四個最大的浪費

浪費 #1：同一個檔案讀了又讀

這是最大的 token 浪費。社群普遍觀察到大量讀檔 token 是重複的 — Claude 讀它已經讀過的檔案，內容幾乎沒變。

看一個典型的 bug fix 過程：

1. Claude 讀 server.ts 理解結構（4,000 tokens）
2. Claude 讀 handler.ts 找 bug（3,000 tokens）
3. 你問「error handling 怎樣？」→ Claude 再讀一次 server.ts（4,000 tokens）
4. Claude 改了 → 讀 handler.ts 確認（3,000 tokens）
5. Build 失敗 → Claude 兩個都再讀一次（7,000 tokens）

21,000 tokens 花在讀兩個檔案。兩次讀取之間檔案幾乎沒變。但 Claude 沒有「只給我看改了什麼」的功能 — 每次都重新讀整個檔案。

浪費 #2：你從來不用的 Tool

你裝了一個很酷的 MCP server，帶 15 個 tool。你用了 2 個。另外 13 個什麼都不做，只是每個 turn 消耗 500-2000 tokens。

就像帶一箱 30 個工具去修漏水的水龍頭。你需要一把扳手。另外 29 個工具只是讓箱子更重。

小技巧： gh CLI 做同樣的 GitHub 操作（開 PR、看 issue、看 diff），比 GitHub MCP server 省很多 token。做 GitHub 相關的事，先試 gh。

浪費 #3：太長的 CLAUDE.md

你的 CLAUDE.md 被注入到每一個 request 裡。每個 turn。每個追問。如果你的 CLAUDE.md 是 10,000 tokens，你在 Claude 還沒看你的程式碼之前就被收了 10,000 tokens 的稅。

大部分人在 CLAUDE.md 裡放太多東西。詳細的 coding style guide、長篇的架構說明、完整的慣例清單 — 都是有用的資訊，但不需要放在每個 turn 都載入的檔案裡。

浪費 #4：不再相關的舊對話

到了第 15 個 turn，前 8 個 turn 通常已經不相關了 — 試探性問題、走錯路、改變方向。但它們還在 context 裡，佔空間，有時還用過時資訊誤導 Claude。

「等等，你不是說要用方法 X 嗎？」— 那是第 3 個 turn。我們在第 6 個 turn 就放棄了。但 Claude 兩個都看得到。

---

Part 3：你可以做什麼

修正 0：先看你的 Token 花在哪

修任何東西之前，先量。Claude Code 有內建指令告訴你 context 被什麼吃掉了：

/context    — 顯示分布：system prompt、tools、memory、對話歷史
/cost       — 顯示這個 session 的 token 用量和費用
/memory     — 顯示 Claude 載了哪些持久檔案
/mcp        — 顯示哪些 MCP server 和 tool 在跑

現在就跑 /context。這是一個真實 session 的畫面：

Estimated usage by category
⛁ System prompt:   6k tokens (0.6%)
⛁ System tools:   11k tokens (1.1%)
⛁ MCP tools:     934 tokens (0.1%)   ← lazy loading 讓這個很小
⛁ Custom agents: 1.5k tokens (0.1%)
⛁ Memory files: 10.5k tokens (1.0%)  ← CLAUDE.md + rules
⛁ Skills:        2.7k tokens (0.3%)
⛁ Messages:    196.6k tokens (19.7%) ← 對話本身
⛶ Free space:  737.8k (73.8%)
⛝ Autocompact buffer: 33k tokens (3.3%)

這個 session 用的是 1M context window，一個長 session 下來才用 23%。如果用預設的 200K window，同樣的開銷就超過 100% — 直接 compaction。注意底部的 33K autocompact buffer — 這是真的、被 reserve 的、你用不到的。

你可能會發現某個 MCP server 吃了 18K tokens，或你的 CLAUDE.md 比你以為的大。先修最大的那個 — 這比所有其他技巧加起來都值。

修正 1：用對的模型做對的事

不是每個任務都需要最大的模型。Claude Code 可以切換：

任務	最佳模型	為什麼
複雜重構、架構設計	Opus	需要深度推理
寫程式、寫測試、日常工作	Sonnet	快而且夠用
改名、格式化、查資料	Haiku	便宜又快

在 Claude Code 裡用 /model 切換。日常用 Sonnet、難題才用 Opus，token 成本可以砍很多 — Opus 每 token 大約是 Sonnet 的 5 倍。

修正 2：在對的時機用 /compact 和 /clear

Claude Code 有兩個管理 context 的指令：

/compact — 摘要你的對話並釋放空間。適合切換任務但想保留一些 context 時。

/clear — 完全清除對話歷史。更徹底，但新任務跟之前完全無關時最適合。

判斷原則： 如果你接下來的任務不需要前 20 則訊息的內容，用 /clear。需要的話用 /compact。

用 /compact 的時機：

• 你剛做完一個任務，準備開始另一個
• 你探索完了，準備開始動手實作
• Claude 開始搞錯對話前面的內容

用 /clear 的時機：

• 你要切到完全不同的專案或功能
• 你的 context 已經超過 60% 而且要開始新東西
• 你寧可重新開始也不要帶著陳舊的 context

把它想成工作之間清理桌面。/compact = 整理紙張。/clear = 清空桌面。

修正 3：描述問題，不要指定檔案

不要說：

「讀 server.ts」

改成：

「handleAuth 好像回傳 null 的 case 沒處理，查一下」 「登入按鈕按下去會閃一下然後沒反應」

你不需要記行數或檔名。給 Claude 一個函式名、功能描述、或你看到的症狀，它會自己用 Grep 找到對的檔案和那幾十行程式碼。

差別在哪？「讀 server.ts」= Claude 讀完 400 行（3-4K tokens）。描述問題 = Claude 精準找到相關的 30 行（300 tokens）。差 10 倍，而且你完全不用記任何行數。

修正 4：精簡你的 MCP Tool

看看你的 session 載了哪些 MCP tool。如果有 20 個但常用的只有 5 個，你每個 turn 白白燒 15-30K tokens 在閒置的 tool 上。

三個方法：

• 延遲載入 — Claude Code 已經對很多 tool 這樣做了。檢查你的自訂 MCP server 有沒有支援。
• CLI 取代 MCP — gh（GitHub）、supabase、vercel 當 CLI 用，比 MCP 版本省很多。
• 按需啟用 — 只在需要的 session 才開特定 MCP server。

修正 5：CLAUDE.md 精簡

目標 2,000 tokens 以下。只放最重要的：

• 3-5 條最重要的規則
• 關鍵的專案慣例
• 指向詳細文件的路徑

其他的 — 詳細的 style guide、架構文件、debug playbook — 放在獨立檔案裡，Claude 需要時才讀，不是每個 turn 都帶。

# CLAUDE.md（精簡版）

## 規則
- TypeScript strict mode
- 不可變模式
- 先寫測試再實作
- Never re-read a file you already read this session unless it was edited.
  When debugging, search by function name or symptom, not by reading entire files.
  Use subagents for exploratory research.

## 架構
詳見 docs/ARCHITECTURE.md

## 慣例
詳見 docs/CONVENTIONS.md

最後那條關於讀檔和 subagent 的規則，把三個最大的 token 節省直接寫進 Claude 的行為裡 — 不用你每次提醒，它會自動照做。

Claude 需要時隨時可以讀 ARCHITECTURE.md。但不需要每個 turn 都帶著。

小技巧：叫 Claude 自己審查 CLAUDE.md。 直接說：

「讀你的 CLAUDE.md，看什麼過時或不需要的，建議一個 2000 token 以內的精簡版。」

Claude 會檢查檔案、標出過時的部分、提出精簡版。2 分鐘的事，之後每個 session 都能省幾千 tokens。

修正 6：用 Subagent 做探索性工作

當你需要 Claude 研究某件事 — 翻檔案、搜 codebase、調查錯誤 — 用 subagent。它們在獨立的 context window 裡跑，主對話保持乾淨。

「用 subagent 調查這個 codebase 的認證機制」

Subagent 讀了 20 個檔案、探索程式碼，然後帶回摘要。你的主 context 只收到摘要（幾百 tokens），不是那 20 個檔案（40K tokens）。

注意：subagent 不是免費的。 它一樣燒 token — 只是燒在獨立的 context window 裡。好處不是「省錢」，是「主對話活更久」。把它想成開一個新的瀏覽器分頁查資料，查完關掉，只把結論帶回來。分頁裡看的那些網頁不會塞爆你正在寫東西的分頁。

修正 7：考慮 1M Context Window

截至 2026 年，Claude Opus 4.6 和 Sonnet 4.6 支援 1M token context window，沒有額外費用。如果你的 session 在 200K 一直撞牆，切到 1M 直接多 5 倍空間。

這不修根本浪費 — 你還是在為重複讀檔和閒置 tool 付錢。但它在你套用其他修正的時候給你喘息空間。

---

Part 4：給 Claude 一個搜尋引擎找你的筆記（進階）

修正 0-7 對大部分人已經夠用。Part 4 和 5 是給有幾百篇筆記、跨 session 工作的進階用戶。

修正 0-7 是減少浪費。這一步改變遊戲。

沒有搜尋引擎的模式：

1. 你問 Claude 一個之前遇過的 bug
2. Claude 不記得（不同 session）
3. Claude 讀 5-10 個檔案試著找答案
4. 30,000 tokens 之後找到了

有搜尋引擎的模式：

1. 你問 Claude 一個之前遇過的 bug
2. Claude 搜你的筆記（200 tokens）
3. 找到那個檔案（讀 2,000 tokens）
4. 總共 2,200 tokens 取代 30,000

QMD 就是這樣的工具 — markdown 檔案的本地搜尋引擎。它索引你的筆記，讓 Claude 毫秒內找到答案，不用一個一個檔案讀。732 篇文件，搜尋 30ms。

QMD 有三種搜法：

工具	速度	適合什麼
search	~30ms	你知道關鍵字 — 「vLLM OOM」、「Ollama keep_alive」
vector_search	~2s	你知道意思但不確定用了什麼字 — 「模型佔太多記憶體」
deep_search	~10s	複雜問題，自動展開多種問法搜尋再排序

另外還有 get（讀特定文件）和 multi_get（批次讀取）。Claude 在 MCP 裡直接呼叫這些工具，你不用手動操作。

但 keyword search 有個天花板：它只能找到跟你的問題用一樣的字的筆記。vector_search 能幫一部分（用語意搜），但如果兩篇筆記之間的關聯是概念層面的 — 例如「Ollama 把模型留在記憶體」和「vLLM 啟動時 crash」都是同一個 128GB 記憶體池的問題 — 你需要的不是搜尋，而是一張關聯地圖。

---

Part 5：讓你的筆記學會旁徵博引（進階）

這就是知識圖譜登場的地方。別被名字嚇到 — 概念很簡單。

知識圖譜就是一張你的筆記之間怎麼關聯的地圖。

想像你有 400 篇不同主題的筆記。有些相關，但用不同的字。一篇寫「Ollama 把模型留在記憶體」跟另一篇「vLLM 啟動時 crash」深度相關 — 都是同一個 128GB 記憶體池的問題。但 keyword search 搜「vLLM crash」永遠不會找到 Ollama 那篇。

知識圖譜預先算好這些連結。它掃描所有筆記、找出共享的概念、在相關的文件之間畫線 — 即使它們用完全不同的詞。

結果：

Claude 怎麼找資料	讀了幾個檔案	花了多少 Token
把可能相關的都讀一遍	10-20 個	~40,000
Keyword search（QMD）	3-5 個	~10,000
知識圖譜搜尋	2-3 個	~4,000

一樣的答案。Token 少 10 倍。

知識圖譜不只省 token — 它找到你不會去搜的筆記。這才是真正的魔法：你自己筆記裡你不知道存在的連結。

Musubi：給你的筆記建一張地圖

聲明：Musubi 是我們開發的開源工具。下面的介紹基於我們自己的使用經驗。

Musubi（日文「結び」，繫起來的意思）就是對你的 markdown 筆記建這張地圖的工具。不需要 AI 服務 — 在本地跑，讀你的檔案，自動算出怎麼連。

# 設定（一次）
uvx --from "git+https://github.com/coolthor/musubi" musubi init

# 建圖
musubi build

# 問：跟這個主題相關的有什麼？
musubi neighbors "vLLM memory issue"
# → ★ vllm-oom-startup.md（直接相關）
# → + ollama-keep-alive.md（鄰居 — 同一個記憶體池）
# → + unified-memory-conflict.md（鄰居 — 同一個根因）

第二和第三個結果是 keyword search 永遠不會找到的 — 它們完全沒提到 "vLLM"。但知識圖譜知道它們透過「共用記憶體」的概念連在一起。

Musubi 自己不花任何 LLM token — 圖譜建立靠的是確定性的概念比對，不是 AI 服務。README 上寫得很清楚：他們不會在沒有數據的情況下宣稱「省 40% token」。工具內建 benchmark（musubi benchmark），你可以自己跑、自己看實際數字。

跟 Claude Code 整合時，Musubi 在 Claude 搜尋網路或讀檔案之前自動執行。如果答案已經在你的筆記裡，Claude 讀那篇就好，不用從頭搜。少讀檔案、少燒 token、更好的答案。

---

帶走這些

你的 context window 滿很快是因為隱形開銷 — 不是因為你的問題太長。

今天就做（免費、立即生效）： 0. 跑 /context 和 /cost 看你的 token 花在哪

1. 用對的模型 — 日常用 Sonnet，難題才用 Opus
2. 切任務時 /compact，不相關就 /clear
3. 描述問題（「登入按鈕沒反應」），不要指定檔案
4. 關掉不用的 MCP tool（GitHub 改用 gh CLI）
5. CLAUDE.md 精簡 — 細節放獨立檔案
6. 用 subagent 做探索性工作

準備好再做（需要設定）： 7. 給 Claude 搜尋引擎找你的筆記（QMD） 8. 加知識圖譜讓相關的筆記自己浮出來（Musubi）

原則： 省 token 最好的方法不是讓對話變短 — 是讓 Claude 的搜尋變精準。不要壓縮，要瞄準。

---

QMD 和 Musubi 都是開源的。可以用在任何 markdown 檔案、在本地跑、不需要 AI 服務或雲端帳號。