聯繫我

如果有任何問題或建議，歡迎隨時聯繫我：

• Email

前言

Day 21 結尾留了一個提醒：「Claude Code 讀專案讀得越多，帳單就跟著漲。」今天把這件事講透。

好消息是，第二階段學過的每一個省錢原則，在 Claude Code 裡幾乎都有對應的實戰設定——快取（Day 9）、壓縮（Day 12）、模型選型（Day 3、Day 4）、context 管理（Day 5）。今天不是學新東西，是把這些原則套進一個你每天都會用到的工具裡。

先講一個官方给的量級感受：跨企業部署的統計，平均每位開發者每天大約花 13 美元，每月 150-250 美元，90% 的使用者每天低於 30 美元。 這不是恐嚇你花費失控，是提醒你——這個工具的花費規模跟前面 13 天講的計價邏輯是同一套，值得認真管理。

本篇設定與策略，於 2026 年對照 Manage costs effectively 官方文件 查證。

目錄

一、CLAUDE.md：每次啟動都要付的入場費

CLAUDE.md 是 Claude Code 的專案記憶檔——本系列自己的 CLAUDE.md 就是活生生的例子。官方提醒一個容易被忽略的成本結構：

"Your CLAUDE.md file is loaded into context at session start. If it contains detailed instructions for specific workflows (like PR reviews or database migrations), those tokens are present even when you're doing unrelated work."

CLAUDE.md 在每次啟動階段就整份載入 context，就算你今天要做的事跟裡面某段特定流程完全無關，那段內容的 token 一樣付了。官方的具體建議：把 CLAUDE.md 控制在 200 行以內，只放真正的基本原則。

那專門情境的詳細流程（例如「PR 審查該檢查哪些項目」）該放哪？官方的答案是 Skills——skills 是隨需載入，只有真正被呼叫到才會進 context，不會像 CLAUDE.md 那樣每次啟動都攤開來付費。把專門流程從 CLAUDE.md 搬到 skills，是最直接的一項瘦身動作。

二、/clear 跟 /compact：兩種不同的歷史處理方式

Day 21 埋的伏筆在這裡兌現。這兩個指令對應的是完全不同的情境：

/clear——切換到不相關任務時用。 直接清空對話歷史，Day 12 提過的「每一輪都要重付整段歷史」問題，用 /clear 直接歸零。官方提醒：切換到不相關的工作卻沒有清空，殘留的舊 context 會在你之後的每一則訊息裡持續耗費 token。想之後找回這個對話？先用 /rename 幫它取個好認的名字，再 /clear，之後可以用 /resume 找回來。

/compact——延續同一個任務，但歷史開始變長時用。 這正是 Day 12 講的伺服器端摘要機制在 Claude Code 裡的實際入口。你甚至可以指定摘要時要保留什麼：

/compact Focus on code samples and API usage

也可以直接寫進 CLAUDE.md，讓每次自動壓縮都套用同一套規則：

# Compact instructions

When you are using compact, please focus on test output and code changes

判斷原則很簡單：任務還是同一個、只是聊得比較久 → /compact；已經換了完全不相關的任務 → /clear。混著用最常見的錯誤，是明明換了任務卻捨不得清空——省下的「重新解釋一次背景」的力氣，換來的是接下來每一輪都在多付根本用不到的舊 context。

三、選對模型：不是每個任務都要 Opus

Day 3、Day 4、Day 6 講過的選型邏輯，在 Claude Code 裡直接對應到日常操作：

"Sonnet handles most coding tasks well and costs less than Opus. Reserve Opus for complex architectural decisions or multi-step reasoning."

多數程式任務用 Sonnet 就夠，Opus 留給複雜的架構決策或多步驟推理——用 /model 隨時切換，或在 /config 裡設定預設模型。如果你的專案有 subagent 配置（處理特定子任務的專用代理），簡單的子任務可以直接指定 model: haiku，這正是 Day 4 講的「便宜模型的正確用法」在 Claude Code 裡的實作。

四、MCP 開銷：工具定義是預設延遲載入的

Day 9 提過工具定義本身要算 token，Claude Code 裡的 MCP 伺服器同樣適用這個邏輯，但官方有個好消息：

"MCP tool definitions are deferred by default, so only tool names enter context until Claude uses a specific tool."

MCP 的工具定義預設是延遲載入——只有工具名稱會先進 context，完整的工具描述要等到真正被使用時才載入。想知道目前 context 被什麼佔用，執行 /context 就能看到明細。

官方還給了兩個實務建議：優先用 CLI 工具而非 MCP（gh、aws、gcloud 這類指令列工具不會有任何工具清單的 context 開銷，Claude 可以直接執行指令）；用 /mcp 檢查目前設定的伺服器，停用沒在用的——沒在用卻還留著的 MCP 伺服器，一樣佔著 context 空間。

五、與其讓它自己摸索，不如直接告訴它：Skills

這是最容易被忽略、但效益很大的一招，而且不需要寫任何程式。

想像一個場景：你每次開新的 session，Claude 都要重新摸索你的專案——讀好幾個檔案才搞懂架構長怎樣、目錄怎麼分、命名有什麼慣例。每一次摸索都是實打實的 token。

Skill 就是把這段摸索的結果，一次寫下來備用。

它本質上就是一個 markdown 檔案，裡面用自然語言寫清楚某件事該怎麼做。例如一個叫 codebase-overview 的 skill，直接描述你的專案架構、目錄慣例、命名規則——Claude 呼叫它一次拿到的資訊，比自己 grep 半天省得多，而且更準確（因為那是你寫的，不是它猜的）。

Skill 跟 CLAUDE.md 的分工，正是第一節那個「入場費」問題的解法：

所以那句「把 CLAUDE.md 控制在 200 行以內」的完整版本是：基本原則留在 CLAUDE.md，「PR 審查該檢查哪些項目」「資料庫遷移的步驟」這類專門流程搬進 skill。 你不會每天都在做資料庫遷移，那段內容就不該每天都佔你的 context。

寫 skill 的門檻比你想的低——它就是一份寫給 Claude 看的工作說明書，用你平常交接工作給同事的方式寫就好。這也呼應 Day 17 那個黃金法則：如果一個沒有背景的同事看得懂，Claude 就看得懂。

還有一招叫 Hooks，但它是另一個層級的東西。 Hook 可以在 Claude 執行工具之前攔截、先把輸出過濾過再交給它——例如跑測試時只保留失敗訊息，把上萬 token 的完整輸出壓成幾百 token。這確實是 Day 8 技巧二「先篩選，再貼上」的自動化版本，效益很大。

但設定 hook 需要寫 shell script、處理 JSON 格式的輸入輸出，已經超出「使用 Claude Code」的範圍，進入「替 Claude Code 寫擴充」了。如果你有興趣，官方文件的 Hooks 章節有完整範例；如果你現在只想把日常用量壓下來，前面四節加上 skill 就足夠了，hook 可以之後再說。

六、快取生命週期：訂閱制跟 API 金鑰不一樣

這是一個容易讓長時間 session 突然變貴的細節。官方明講：快取的存活時間，訂閱帳號是 1 小時，用 usage credits 時降到 5 分鐘，API 金鑰或雲端供應商預設是 5 分鐘。

"Cache misses: your first message after a break longer than the cache lifetime misses the cache and reprocesses your full context."

休息超過快取存活時間之後傳的第一則訊息，會整段快取失效、重新處理全部 context——這也是為什麼「開著視窗放一整天，中午休息完回來問一句話，帳單卻很有感」的體感由來：不是那句話很貴，是那句話觸發了整段舊 context 的重新計費。如果你是訂閱帳號並且在用 usage credits，可以設定環境變數 ENABLE_PROMPT_CACHING_1H=1 保留 1 小時的存活時間，而不是降到 5 分鐘。

七、哪些操作會打斷快取（這張表值得貼在螢幕旁）

Day 9 講過快取的原理是前綴匹配：只要前面那一段一模一樣就命中，中間有任何一個字不同，後面全部要重算。Claude Code 幫你把請求排成「系統提示 → 專案脈絡 → 對話歷史」三層，讓最不常變的排最前面——但有些操作會直接改動前面那幾層，一改就是整段重算。

官方把這些動作列得很完整：

官方給的操作原則很簡單：

"Pick your model and effort level at the top of a session, then save /compact for natural breaks between tasks. The fewer changes you make mid-task, the higher your cache hit rate."

開場就把模型跟 effort 選定，中途不要改。 這句話呼應 Day 14 提過的「同一段對話裡固定 effort」——當時是從 API 角度講的，在 Claude Code 裡是同一件事，只是換成 /model 和 /effort 兩個指令。

三個容易踩到的細節：

① 走錯路想回頭時，/rewind 比 /compact 便宜。 rewind 是把對話截斷回到之前某一輪，而那個前綴早就快取過了，直接命中；/compact 是生一份新摘要，等於建立全新前綴，得從頭寫入。官方原文：「Rewinding truncates back to a prefix that is already cached, rather than building a new one as compaction does.」

② 中途編輯 CLAUDE.md 不會打斷快取——但也不會生效。 這點對本篇特別重要，因為前面整篇都在教你怎麼寫 CLAUDE.md。官方明講：專案根目錄與使用者層級的 CLAUDE.md 在 session 開始時讀取一次就留在記憶體裡，你中途改它，Claude 仍然用開場時載入的那個版本。新內容要等下一次 /clear、/compact 或重開才會套用。（例外是子目錄裡的巢狀 CLAUDE.md，那些是 Claude 第一次讀到對應檔案時才載入，在載入前修改是會生效的。）

③ 快取範圍是「同一台機器 + 同一個目錄」。 兩個不同目錄開的 session 不共用快取——包含同一個 repo 的不同 git worktree，因為系統提示裡帶了工作目錄路徑，路徑不同前綴就不同。如果你習慣開多個 worktree 平行作業，要知道它們各自在養自己的快取。

（反過來，同一個目錄下平行開的多個 session 會互相讀到對方的快取，這是少數可以「共用」的情況。）

八、寫具體 prompt，這條原則到哪裡都成立

Day 17 的黃金法則在 Claude Code 裡一樣適用：

❌ 「improve this codebase」→ 觸發大範圍掃描
✅ 「add input validation to the login function in auth.ts」→ 精準定位，最少檔案讀取

模糊的請求會讓 Claude 為了搞懂你要什麼而擴大搜尋範圍，具體的請求能讓它幾乎不用探索就知道該改哪裡。

九、追蹤花費：/usage 跟 /insights

養成定期檢查的習慣，比事後回頭查原因有效率得多。/usage 顯示目前 session 的詳細花費，包含依模型拆分的 token 用量；如果你是訂閱帳號，還能看到扣抵方案額度的分項統計，包含依 skill、subagent、外掛、個別 MCP 伺服器拆分的佔比——這能直接告訴你,是哪一個 MCP 伺服器或哪一類操作在吃掉你大部分的額度，比憑印象猜測準確得多。

/insights 則是另一種角度的報告——它分析的不是「花了多少 token」，而是「你平常怎麼工作」：常見的摩擦點（例如指令被誤解、產生有 bug 的程式碼）、以及怎麼用得更有效率的建議。這份報告會寫成 HTML 檔存在本機，適合每隔一段時間跑一次，回顧自己的使用模式有沒有值得調整的地方。

Before / After：一個典型的長時間開發 session

❌ Before：開一整天不清、什麼都塞進 CLAUDE.md

$ claude
（早上開始，一路工作到下午，中間換了三個完全不相關的功能，從沒 /clear 過）
（CLAUDE.md 裡塞了 500 行，包含各種特殊流程的詳細步驟）

✅ After：任務邊界清楚、專門流程搬去 skills

$ claude
> what does this project do?
（開始第一個功能）
...
/rename 功能A-開發
/clear
（開始不相關的第二個功能，先清空）
...
/compact 保留程式碼變更與測試結果
（同一功能內對話變長，用 compact 而不是整個清掉）

搭配一份精簡到 200 行內的 CLAUDE.md，加上把「PR 審查標準」「資料庫遷移流程」這類專門知識搬進對應的 skills。

Before 版本每一句話都在幫整個對話史付費，而且每次啟動都要吞下一份過胖的 CLAUDE.md。After 版本用 /clear 劃清任務邊界、用 /compact 處理同任務內的歷史增長、把專門流程移出常駐 context——三個動作，分別對應 Day 12 的「切斷成本累積」跟今天的「入場費瘦身」。

本篇自我挑戰

• 今日挑戰：執行 /context 看看你目前 session 的 context 都被什麼佔走了，再執行 /usage 看這個 session 的實際花費。檢查你的 CLAUDE.md 有沒有超過 200 行，如果有，找出哪些段落其實只在特定情境下用得到，考慮搬去 skills。

• 反思：「開著同一個對話视窗做完全不相關的事」是一個很容易養成的懶惰習慣——因為 /clear 感覺像是要重新來過。但今天學到的是，不清空的代價是每一句話都在幫你不需要的舊 context 付錢。 你有沒有其他因為「重新開始感覺麻煩」而持續累積不必要成本的習慣？

總結

Claude Code 的省錢邏輯，本質上是第二階段全部原則的實戰應用：CLAUDE.md 控制在 200 行內、專門流程搬去 skills（減少每次啟動的入場費）；/clear 處理任務切換、/compact 處理同任務內的歷史增長（呼應 Day 12）；選對模型、MCP 延遲載入、CLI 優先於 MCP（呼應 Day 3、Day 4、Day 9）；用 skill 取代讓它自己摸索（呼應 Day 8 的「先篩選再貼上」）；以及一個容易被忽略的細節——快取存活時間因帳號類型而異，長時間 session 的第一句話特別容易觸發重新計費。

本日關鍵字回顧

• CLAUDE.md 200 行原則：每次啟動整份載入 context，專門流程應搬去隨需載入的 skills。
• /clear vs /compact：前者用於切換不相關任務、後者用於同任務內歷史過長，混用是常見的浪費來源。
• MCP 延遲載入：工具定義預設只先進工具名稱，真正使用時才載入完整描述；/context 可查看目前佔用明細。
• Skill vs CLAUDE.md：前者隨需載入、用到才付費，後者每次啟動整份載入；專門流程應放 skill，基本原則才留在 CLAUDE.md。
• 快取存活時間差異：訂閱帳號 1 小時、API 金鑰預設 5 分鐘，休息超過此時間後的第一句話會觸發整段重新計費。
• 打斷快取的動作：/model、/effort、fast mode、MCP 增減、plugin 開關、/compact 都會重算前綴；編輯檔案、切權限模式、/rewind 則不會。
• CLAUDE.md 的載入時機：session 開始時讀一次即駐留記憶體，中途編輯不會生效也不會打斷快取，須 /clear、/compact 或重開才套用。

明天離開 Claude Code，回到更底層的問題——Claude Code 能操作外部工具（檔案、Git、MCP 伺服器），這個「連接外部世界」的能力，背後的協定原理是什麼？

Day 23，MCP 是什麼？把外部工具接進 Claude 的原理與實作。