Claude Code 節省用量：別把所有指令塞進主對話
XDA 一名作者分享，他處理自託管 app 與 Docker 問題時，透過縮減主 session 的常駐指令，以及把較長的調查交給 subagent，聲稱把 Claude 的 token 用量減半。對經常以 Claude Code 處理大型 codebase、log 與設定檔的開發者而言，重點不在於把 prompt 寫得更長，而是避免每次工作都帶著無關背景。
不過，這是個人使用經驗，原文沒有公開前後任務的 token 紀錄、測試次數或成本明細，減半效果未經獨立驗證。尤其 subagent 本身也會消耗資源；主對話變短，並不等於整項任務的總用量必然下降。
將 CLAUDE.md 當成索引，而非規格書全集
按原文作者的做法，根目錄的 CLAUDE.md 只保留專案用途、主要檔案位置、測試指令與重要限制等共通資料。至於只適用於某個模組的細節，則放到靠近相關程式碼的目錄級指令檔。
例如前端與後端分開的專案，可各自在相應目錄保留專門指示。當工作只涉及其中一部分，理想情況下模型毋須在一開始便攜帶另一部分的操作規則、設定與文件。對包含 Compose 檔、app 設定、scripts 和文件的自託管專案，這種分層尤其合理：修改一項設定時，未必需要把整套部署知識都放進對話。
這個安排的代價是維護成本。共通規則若重複散落多處，或目錄級指令互相矛盾，模型即使少讀了內容，仍可能作出不一致的改動。因此，根目錄文件應清楚界定全局規則；局部文件只寫該範圍獨有的操作、限制與驗證方式。
Skills 適合重複流程，不宜取代專案導覽
原文作者把反覆出現的 Docker 排錯程序放入 skill，例如指定設定檔位置、要執行的指令及回報格式，讓程序按需要載入。這適合步驟穩定、輸出格式一致的工作，因為它把「如何處理」與每次都需要知道的專案背景分開。
可用一個簡單準則取捨：
- 經常使用、步驟大致固定的流程，可考慮放進 skill。
- 只與某個目錄或元件有關的規則，放在該範圍的指令檔較易理解。
- 每次工作都不可缺少的限制與測試方式，才留在根目錄
CLAUDE.md。
這樣做的目的不是把資料藏起來，而是令模型只在需要時取得足夠資訊。若一項指令其實每次都會影響決策，硬拆出去反而可能令工作要來回補充上下文，得不償失。
Subagent 要計總帳，不只看主 session
作者以資料庫錯誤為例：可讓 subagent 專門檢查啟動錯誤與相關 log，再向主 session 返回附有證據的精簡結論。由於大量 log 和探索過的無關設定不會長留在主對話，主 session 的 context 可保持聚焦。
但原文同時指出，subagent 使用自己的資源。較合適的情況，是問題範圍清晰、調查量大，而且結果能濃縮為短小且可採用的結論；簡單改動留在主 session，通常更直接。換言之，subagent 是隔離長篇調查的工具，不是自動省 token 的開關。
如何量度是否真的省錢
要驗證分層是否有效，應比較「完成同類任務的總成本」，而非只看主對話長度。可為幾類常見工作建立紀錄，例如修正設定、追查 container 無法啟動、修改前端元件；每次記下任務範圍、主 session 用量、subagent 用量、重試次數，以及完成後是否仍需人工補救。
比較時應保持任務難度相近，並把所有子工作一併計入。若平台提供用量或帳單紀錄，應以那些紀錄核對；若只有對話層面的估算，便只能用作趨勢參考。真正有價值的指標，是在相近品質與完成時間下，整個工作流有否少耗資源。
原文的啟示是，context 管理本身已是 agent 工作流的一部分。下一步值得觀察的，不是某個技巧能否普遍「減半」，而是不同專案在採用分層指令、按需流程與 subagent 後，總用量與排錯品質會否同時改善。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- XDA Developers — I cut my Claude token use in half by moving instructions out of the main session — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
