【2026 最新】Claude Code 省 Token 真的有效嗎？用自己的 Repo 驗證 RTK、Caveman 與壓縮工具

最後更新：2026年7月29日 · Terry Chen

Claude Code 省 Token 真的有效嗎？用自己的 Repo 做 A/B 驗證教學首圖

你在 RTK 的儀表板看到「省了 90%」，或看到 Caveman 顯示少了幾千個 token，第一個反應很合理：那我的 Claude Code 應該更便宜了吧？但這兩句話其實不是同一件事。少幾個輸出 token，不等於少付錢；少一段終端輸出，也不等於任務沒有多跑一輪。

這篇是給想把 Claude Code 用在真實專案的讀者寫的「驗證篇」。不需要統計學背景，也不需要把外掛全拆掉重寫；我們會用自己的 Repo 做最小 paired A/B：同一個任務、同一個提交、同一套品質門檻，讓數字回答「它有沒有幫我把同一件事做得更便宜」。

Table of Contents

先說結論：Claude Code 省 Token 的唯一及格公式

真正的節省＝任務品質不變時，完成同一件事的中位成本下降。這句話就是本文的錨點。任何「節省 60%、90%」的宣傳，都先問：它壓縮的是哪一段？它有沒有讓重試、工具呼叫或 cache 重讀變多？最後的測試有沒有照樣通過？

token 帳：輸入、輸出、cache write、cache read 各自是多少。
工具帳：Claude 讀了多少檔、跑了幾次指令、是否因資訊被壓掉而重跑。
美元帳：同一個 session 的估算成本是否真的下降。
成果帳：測試、lint、型別檢查與人工驗收是否維持同一標準。

只要最後一帳沒過，前面再漂亮的省 token 圖表都不該叫「省錢」。它最多是把訊息壓短；你真正省下的，可能是畫面上的雜訊，而不是完成工作的成本。

Claude Code 省 Token 的四本帳：token、工具呼叫、成本與成果品質 — 壓縮工具通常只碰到其中一層；驗證時要把四本帳一起看。

為什麼「少 90%」不等於帳單少 90%

把 Claude Code 想成一位在專案裡工作的工程師。它不是只回覆一句話：它還會讀檔、搜尋、跑測試、拿到終端結果，再把一路累積的對話帶進下一回合。因此「工具壓掉了哪一段」比 headline 上的百分比更重要。

① RTK 壓的是 Bash 輸出，不是整個 session

RTK 自己的 README 寫得很清楚：它在 shell 指令與 agent 之間過濾、整理輸出，例如把冗長的 git status 或測試成功訊息縮短。它的「節省」是 Bash 輸出讀取量的估計，而且用 bytes / 4 換算 token；這不是完整帳單。更關鍵的是，Claude Code 內建的 Read、Grep、Glob 不會經過這個 Bash hook。

白話說：RTK 像替貨運箱子壓縮泡泡紙，確實能少一點體積；但如果你的 agent 大部分時間走的是讀檔與搜尋的「另一條走廊」，它根本碰不到那些內容。先量你自己的工作負載走哪條路，才知道它有多少空間可省。

② Caveman 壓的是 agent 的說話方式，不是它的整個工作

Caveman 的 README 把定位說得很坦白：它主要讓 agent 少講鋪陳、保留程式碼、指令與錯誤字串。它也提醒，輸入與 reasoning token 不會因此消失，skill 本身還會加進每回合的指令內容。短回答可能更好讀，但「輸出字變少」仍只是四本帳裡的一格。

③ cache 是折扣，不是免費重播

Claude Code 的 Prompt Caching 文件指出，cache_read_input_tokens 是從快取取回的內容，價格約為一般 input 的一成；它比較便宜，卻不是零。官方也說明，長 session 每一次工具呼叫都會帶來新的請求與工具結果，而舊對話會被重新讀入。換句話說，快取像影印折扣：同一份資料再看比較便宜，但你還是在付影印費。

這也是為什麼只看「新輸入 token」很容易誤判。壓縮掉一段指令輸出，卻讓 agent 多問一次、多讀一次、或換另一條路探索，最後反而可能把回合數與 cache read 拉高。

JetBrains 的結果是警鐘，不是你的答案

2026 年 7 月，JetBrains 用同一套 paired A/B 方法測試這兩個工具。他們把 Caveman 強制開啟後，在其 SkillsBench agent 任務中量到約 8.5% 的輸出 token 降幅，而不是宣傳的 65%；他們特別提醒，這仍是強制啟用下的上限。完整設計與品質分數可看 Caveman 的 paired benchmark。

同系列的 RTK benchmark 在其低 reasoning effort 設定下，80 組乾淨配對的中位任務成本反而高約 7.6%，同時回合與 cache read 變多；高 effort 的那組則接近持平。這不是「RTK 對所有人都沒用」的判決，而是很好的提醒：工具自己的局部計數器，不能替你的 Repo 開收據。

把公開 benchmark 當成「值得測什麼」的地圖，不要當成「你的結果已經出爐」的答案。

Claude Code 省 Token：用自己的 Repo 做 paired A/B

paired A/B 的意思很簡單：同一項工作做兩次。A 是乾淨的 Claude Code；B 只多一個你要測的工具。不要在同一次對話中先跑 A 再跑 B，因為後者已經吃到前者留下的 context；每次都從新的 session 開始，才能讓比較公平。

Claude Code paired A/B 實驗的四步驟流程 — 最小實驗：固定版本與任務，交錯順序重複，再讓品質門檻決定數字有沒有資格被比較。

Step 1：先寫下品質 gate，成本才有意義

痛點是：B 花得少，卻少改了一個檔案或悄悄留下 bug，你若只比成本會把退步誤認成節省。解法是把完成條件寫在 prompt 前面，例如「pnpm test、pnpm lint 與型別檢查均通過；人工 review 沒有 P0/P1 問題」。你慣用的專案指令才是 gate；只要 B 沒過，它在這個任務上就是未完成，不參加省錢排名。

Step 2：挑 4 個「你真的會做」的小任務

一個局部 bug：鎖定一個檔案或一條 failing test。
一個小功能：有明確輸入、輸出與驗收測試。
一個 log／測試任務：最能暴露終端輸出壓縮有沒有價值。
一個讀碼任務：要求找出流程、提出最小修改，觀察 agent 是否主要用內建讀檔工具。

不要挑你最愛展示的 terminal-heavy demo。你想知道的是「我平常一週會不會變便宜」，不是「它在最適合它的 30 秒裡多漂亮」。四類任務已足以做第一輪；若你的工作型態很集中，就用最常見的那一類取代。

Step 3：固定會偷偷改答案的變因

每一對開始前先記錄 git rev-parse HEAD、claude --version、模型與 effort、權限模式、MCP／plugin 清單，以及你要貼進去的完整 prompt。A 與 B 用同一個 commit、同一份 prompt、同一個模型設定；唯一差異是「有沒有啟用被測工具」。官方的成本文件也建議先建立自己的 baseline，才擴大使用方式。

接著每個任務至少做 3 對：第一對 A→B，第二對 B→A，第三對再交錯。agent 有非決定性，外部服務也會波動；交錯順序不是讓實驗變學術，而是避免「剛好第一個 session 特別順」被錯當成工具效果。

Step 4：每次結束立刻記錄 `/usage`

完成任務後，在 Claude Code 輸入 /usage，把該 session 的 input、output、cache read、cache write 與 total cost 記下來。官方說明，這個美元數字用本機 token 數與標準牌價計算；API 使用者的權威帳務應看 Console，而 Pro／Max 訂閱者的 session 美元數字並不等於實際訂閱扣款。把任務、模型與設定鎖住後，它可作為相對比較資料。

task,pair,arm,commit,claude_version,model,effort
bug-01,1,A,abc123,2.x,同一模型,同一 effort
bug-01,1,B,abc123,2.x,同一模型,同一 effort

input,cache_write,cache_read,output,turns,retries,cost,gate,review
…,…,…,…,…,…,$…,PASS,OK

「turns」填 agent 的來回回合數；「retries」填因為資訊不足、指令失敗或改走另一條路而重跑的次數。若你暫時不想整理 transcript，至少把明顯的重跑寫進 notes。這兩欄正是壓縮工具最容易在漂亮 token 數字背後留下的成本。

Step 5：看中位數與品質，不看最漂亮的一次

把每個任務的 A 與 B 成本配成一對，再看中位數差異：(median(B) − median(A)) / median(A)。中位數不會因為一個超長 context 或意外重試就把結論扭歪。先替自己定一條有商業意義的門檻，例如成本至少降 10%，而 B 的通過率不得低於 A；低於門檻或落在正常波動內，就誠實記成「尚無結論」。

Claude Code 壓縮工具的 A/B 結果判讀卡，依序看品質、成本、回合與 cache — 判讀順序：先讓成果過關，再比較中位成本，最後追問回合、重試與 cache 是否把省下的部分吃掉。

壓縮為什麼可能帶來更多重試與回合？

想像你請同事把 500 行測試輸出摘要成 10 行。若那 10 行剛好留下所有 failing assertion，你省到的是雜訊；若它藏掉了一個路徑、exit code 或上下文，同事就會再跑一次完整指令、再讀一次檔案，甚至沿錯的方向 debug。原本少傳的 token，很快就被多出的回合補回去。

JetBrains 在 RTK 的低 effort 配對裡確實看到較多 turns 與 cache reads；但真正值得你複製的不是那個數字，而是它的偵錯方式：把最大差異的任務 transcript 拉出來，看 B 是否多了 fallback command、raw-output 重讀或不必要的探索。你的結果若是「成本持平、品質持平、回合少」，那仍可能是值得保留的工作流改善。

Claude Code 省 Token 的優先順序：先縮任務，再縮字

壓縮外掛排在最後，不是因為它們沒價值，而是因為它們改的是最局部的地方。先完成下面四件事，測試結果才不會被一個膨脹的 baseline 污染：

把任務範圍說清楚：寫出目標檔、驗收條件與不要碰的區域。官方也指出，模糊的「改善整個 codebase」會觸發廣泛掃描；精確任務能減少不必要的讀檔。
讓模型與 effort 配合難度：先用能通過 gate 的較低成本組合，真正的架構難題再升級。這比把同一個昂貴 session 的句子縮短更有槓桿。
管理 context：不相關的工作就用 /clear，用 /context 查誰佔空間，關掉目前不用的 MCP。Anthropic 也建議把龐大的專用說明移出基礎 CLAUDE.md，改成按需載入的 skills。
只對可預期的大輸出做前處理：例如測試只回傳 failures，或讓 codebase overview skill 取代反覆掃檔。這比對每一條指令做盲目壓縮更容易驗收。

想先完成這些基本槓桿，可回看 Claude 怎麼省 token？新手必學 10 招。這篇則幫你補上最重要的一步：任何新工具上線前，都用自己的成果與成本驗收它。

Claude Code 省 Token 常見問答

Q1：RTK 顯示很高的 savings，我可以直接相信嗎？

不能直接把它當成帳單。它量的是經過它的 Bash 輸出估計值；請把它當成「這裡可能有優化空間」的提示，然後用 paired A/B 的 /usage、品質 gate 與重試數確認。

Q2：Caveman 回覆變短，值得安裝嗎？

可能值得，理由可以是可讀性與節奏。若你的工作喜歡簡潔狀態回報，它有明確價值；但把「我喜歡它」與「它讓同一任務成本下降」分成兩個結論，各自量一次。

Q3：cache read 既然便宜，我還需要在意長 session 嗎？

需要。便宜不是免費；長 context 仍會在後續請求中反覆被帶入。切換到不相關任務時，新的乾淨 session 通常比硬把所有歷史一起背著更可預測。

Q4：我是 Pro 或 Max，美元欄位還有意義嗎？

有，但用來比相對差異。訂閱方案的使用量包含在方案額度內，/usage 的美元是標準牌價估算；搭配使用量 bar、同一設定下的 A/B 差異，才能看出哪個工作流比較吃你的額度。

Q5：每次 prompt 一定要一字不差嗎？

要。prompt 是實驗條件的一部分；改一個驗收條件，就可能改掉讀檔範圍、工具選擇與完成路徑。把 prompt 存成一個小檔案，複製貼上即可。

Q6：只跑一個任務，能不能得到結論？

只能得到線索。先跑一個任務可確認安裝與紀錄流程，正式判斷至少用幾種日常任務並重複配對；一個離群 session 很容易蓋過工具的真實效果。

Q7：我可以同時測 RTK、Caveman 與另一個壓縮器嗎？

第一輪不要。一次只換一個變因：先 A 對 RTK、再 A 對 Caveman；若各自都過 gate，才做「兩者一起」的第三組。這樣你才知道哪一個帶來效益，哪一個帶來重試。

Q8：什麼時候該停止調參？

當差異小於你的操作成本。若省下的 token 需要你多花時間排查、重跑或教育團隊，先把工作流留在簡單、可理解、能穩定通過 gate 的版本。工具是手段，不是儀表板競賽。

給新手的 5 個實驗重點

先定義「任務做對」；再看它花多少。
把 output、tool output、cache 與美元拆開記。
新 session、同 commit、同 prompt，才能配對。
交錯 A/B 順序並重複，不迷信單次佳績。
先縮任務範圍、模型與 context；壓縮器最後才上場。

📚 延伸閱讀

Claude Code vs Codex：先弄懂兩個 coding agent 的工作方式，才知道哪一邊該量什麼。
Claude、Claude Code、Cowork 怎麼選：不同介面共享的額度與 context，會改變你看「成本」的方式。
AI Agent Harness 是什麼：理解模型之外的執行層，才看得懂工具呼叫為何會改變成本。
自己做 AI Agent Harness：用最小迴圈理解 plan、tool、verify 如何累積成真正的工作量。
Claude Opus 4.8 完整解析：模型能力、思考深度與任務難度該怎麼搭配。
AI Builds Itself：從敘事視角看 agent 如何把規劃、工具與回饋串成工作流。
AI 專區：把今天的 A/B 方法套到下一個你想嘗試的 AI 工具。
AlphaLab 課程：想把 AI 工作流變成可重複的系統，可從完整課程開始建立底層方法。

結語：別替工具背書，替你的工作負載背書

今天就建立一個 experiments/token-ab 小資料夾，放進 4 個日常任務、同一份 prompt 與一張紀錄表。你不需要證明 RTK 或 Caveman 是好是壞；你只要回答更有用的問題：在我的 Repo、我的模型與我的品質標準下，它有沒有讓同一件事變得更便宜、更穩定？