除了這三個習慣，官方文章裡還有沒有其他值得注意的省錢重點？
有，官方文章還提到指令輸出的管理——如果一個指令印出的內容不多不少，剛好卡在系統會完整保留的門檻以下，這些內容就會整段留在對話裡、被反覆重送；而超過某個門檻的超大輸出，系統反而會自動把內容寫進檔案、只在對話裡放簡短預覽，不會造成負擔。這代表中等長度、逐行印出的指令輸出（例如跑過的測試清單）反而是比較容易被忽略的成本來源。另外也提到子代理（subagent）機制，能把不需要留在主對話裡的雜訊丟到一個獨立的上下文處理完就丟棄，適合處理「會產生大量你不需要保留的輸出」的工作。
這篇文章只挑了對日常使用影響最直接的三個習慣，如果你的工作情境經常牽涉大量指令輸出或需要頻繁執行雜項任務，這兩個延伸主題值得進一步了解。
如果我不確定自己的使用習慣有沒有踩到這些成本破口，有沒有辦法先檢查一下？
可以在乾淨的新對話裡執行 /context 指令，查看目前這個 session 實際載入了什麼內容，確認有沒有夾帶了用不到的檔案、殘留自上一個任務的內容，或是掛著沒在用的工具。這個檢查動作能幫助你在動手處理正事之前，先確認自己的起始狀態是乾淨的，而不是在不知情的狀況下拖著一堆雜訊開始新任務。
如果發現有不需要的工具或服務常駐佔用上下文空間，也可以透過對應的管理指令暫時關閉，等真的需要用到再重新開啟，避免每一輪都白白帶著這些用不到的設定一起送出去。
這些成本考量，會不會反過來讓人不敢好好使用 Claude Code 的完整功能？
這個顧慮可以理解，但這幾個習慣的重點不是「少用」，而是「用得精準」。用 @ 指名檔案、維持設定穩定、任務之間清空對話，這些做法都不會犧牲 Claude Code 能完成的工作範圍，反而可能因為減少了不必要的摸索過程，讓每一輪對話都更直接聚焦在真正的問題上，某種程度上還可能提升處理效率，而不只是省錢。
真正該避免的心態，是反過來因為擔心成本而過度保守——例如該讓 Claude 讀取的檔案硬是不敢讀、該交給子代理處理的雜訊硬要自己扛在主對話裡。這些習慣的目的是把資源用在刀口上，不是要你減少任務的複雜度或深度，兩者是不同層次的問題。
這些習慣需要每次都手動注意，還是有辦法變成自動化的固定流程？
有幾個部分可以直接寫進 CLAUDE.md，變成不需要每次重新想的固定規則——例如把自己每天常跑的那幾個指令連同安靜引數一起寫進去，或是把「這個專案的 compact 該保留什麼重點」寫成一段固定說明，之後不需要每次都臨時決定。這類設定屬於「做一次、之後每個 session 都受益」的類型，前期花一點時間整理，能省下後續反覆手動判斷的成本。
至於清空對話、用 @ 指名檔案這類跟當下任務直接相關的動作，因為每次情境不同，比較難完全自動化，還是需要在動手前花幾秒鐘判斷「這次任務適合怎麼開始」，但只要養成習慣，這個判斷過程很快就會變成不需要特別思考的直覺反應。
Anthropic 在 2026 年 8 月 14 日發布的官方文章裡，用一個小例子點出多數人沒意識到的事：同樣是修一個壞掉的測試，一個 session 只送出 5 次請求就收工，另一個 session 因為先在整個程式庫裡到處搜尋，才走到同一個檔案，結果送出了 18 次請求。同一個任務，用法不同，帳單可以差到三倍以上。這篇文章不重複官方文章裡所有的技術細節，只抓三個對日常使用影響最大、最容易立刻改的習慣。
先建立一個核心觀念：Token 計費的機制，是對話裡任何已經送進去的內容——你讀過的檔案、跑過的指令輸出——都會在接下來的每一輪被重新送出，直到這個 session 結束。這代表一個 session 拖得越長，光是重複夾帶前面所有內容的成本，就會遠比單一輪的新增內容更可觀。省錢的重點從來不是「少問問題」，而是確保每一輪送出去的內容，都真的跟現在要做的事有關，而不是拖著早就用不到的舊資料一起跑。
官方文章裡有個簡單的對比：只說「測試壞了」，Claude 得自己先搜尋、再打開幾個檔案才能確認是哪個測試出問題，光是找到問題就先燒掉好幾輪；直接說出檔名「修 utils.test.ts」省下大部分摸索的過程；而用 @ 直接標記檔案「修 @utils.test.ts」，檔案會直接附進訊息裡，連讀取這個動作本身都省了。差別就在於你願不願意先幫 Claude 定位，還是讓它自己從零開始找。
Prompt caching 是控制成本最關鍵的機制——只要這次請求的開頭跟伺服器剛處理過的內容完全一致，重複的部分就能用便宜很多的價格重新利用，不需要整段重新處理。但這個機制要求請求開頭必須逐字對上，任何改動都會讓後面全部打掉重算：包括對話中途切換模型、調整思考強度、或是打開快速模式。如果一個 session 才剛開始、或是剛清空過對話，這時候切換設定成本很低；但如果是在一段很長的對話中間才臨時換，代價會明顯放大。實務上的做法是開工前先把模型跟設定定好，而不是邊做邊調。
官方文章裡的實測數據很具體：同樣三個任務，如果每做完一個就清空對話再開始下一個，跟把三個任務全部擠在同一個 session 裡處理相比，後者送出的 token 量是前者的 1.9 倍。原因跟前面提到的機制一致——session 越長，每一輪要重新夾帶的舊內容就越多。一個簡單的操作原則：開始做新任務時清空對話，同一個任務做到一半、需要保留脈絡但想瘦身時，再用摘要功能整理而不是整段留著。
如果你是按用量付費使用 Claude Code，這三個習慣改變的不是「能不能完成任務」，而是完成同一個任務要花多少錢——用 @ 指名檔案能省下摸索過程的請求次數，維持設定穩定能保住快取帶來的價格折扣，任務之間清空對話則能避免舊內容被無謂地反覆重送。這些調整不需要額外學習成本，純粹是使用習慣的改變，卻能讓同一份訂閱額度或 API 用量，實際處理更多工作。