Spotify分流外掛：Claude Code省9成Token

讀一個4,014行的檔案，原本要吃掉33,684個Token。現在只要5,737個。

省了82%。

計算機科學家 Butler Lampson 有句被傳了幾十年的話：電腦科學裡的任何問題，都可以靠多加一層間接層來解決。

Spotify 的工程師用這句話，替 Claude Code 省下了九成的帳單。

誰動的手，為什麼現在才有人管這件事

主角是 Spotify 工程師 Dimitri Mazmanov。他在內部開發者平台「Portal by Spotify」裡，用 AiKA Modes 建了兩個輕量模式，再把整套機制重構成一個叫「shunt」的 Claude Code 外掛。

為什麼現在才有人認真處理？因為帳單先受不了了。

有數據預測，到2028年，AI 寫程式的總成本可能超越工程師薪資。目前已有四分之一的工程主管，每月為每位工程師支付200至500美元的 Token 費用，部分團隊甚至突破2,000美元。

而 Mazmanov 的研究發現了一個尷尬的事實：Claude Code 燒掉的大量 Token，主要不是用在複雜推理上，而是耗在讀大型檔案、產生測試檔這類重複勞動。僅僅為了回答一個簡單的方法呼叫，系統就去讀了五個檔案——推理能力幾乎沒動用，Token 卻已經燒掉一大截。

拆開看：三個模式、三層架構、三組實測

先講兩個模式。

bulk-reader，專門取代 Claude 讀大檔，只輸出結構化重點摘要。

code-writer，處理測試檔、設定檔這類格式可預測的工作，並依照參考範例的風格產生程式碼。

兩者都跑 Gemini 2.5 Flash，走的是高 CP 值路線。

再看外掛的三層設計。

第一層 Hooks。 在每次工具呼叫前強制執行：「check-file-size」攔截超過350行門檻的讀取指令，導向 bulk-reader；「check-bash-read」則擋下 cat、head 這類對大檔的讀取命令。門檻可在 .claude/settings.json 用 SHUNT_MIN_LINES 自訂。

第二層腳本。 封裝 Portal CLI，負責組裝請求、回報 Token 用量，分 bulk read 與 code write 兩種。

第三層 Skills。 說明呼叫時機的文件。

DEV Community 專欄作家 jamilxt 分析，這種分層最關鍵的地方在於：就算 Claude 沒去讀 Skills 說明，Hooks 機制照樣能強制擋下昂貴的讀取行為。

實測數據由 AI 策略平台《TenTen》的 Ewan Mak 在一個16萬2千行的 Java monorepo 上跑出來：

4,014行單一檔案，33,684 → 5,737，省82%。

7,408行原始碼與測試檔配對，75,990 → 4,148，省94%。

1,281行跨服務多檔案，16,221 → 821，一樣省94%。

綜合下來，平均約省九成。

這對誰有意義

對工程團隊，最直接的是成本。每月200至500美元的單人開銷，若能砍掉九成，規模化之後是一筆不小的數字。

對模型供應商則是另一層訊號：複雜推理交給昂貴模型，讀檔、生成樣板這類雜活交給便宜模型，這種分層調用可能成為常態。換句話說，未來被優化的不見得是模型本身，而是「誰來做哪一件事」。

對開發者工作方式也有影響。外掛本身還內建六種指令：setup、doctor、search、service、actions、feedback，涵蓋驗證、健檢、自然語言搜尋目錄與產生服務簡報。

說實話，9成不是重點

真正值得注意的，其實不是那個9成。

而是它戳破了一個長久以來的假設：AI 程式碼工具的 Token 消耗，大部分被視為「思考成本」。但實測顯示，很大一塊其實是「體力活成本」。

一旦你把這件事看清楚，優化方向就變了——不是讓模型更會想，而是別讓它去做不用想的事。

邊界也要看清楚

這套機制不是萬能。

Mazmanov 自己提醒，委派模型產生的摘要不含精確行號，因此無法用於直接編輯程式碼，需要精準修改時仍得讓 Claude 本體讀取特定段落。

測試中也出現過委派模型漏掉深層邏輯問題的情況——例如錯過一個執行緒安全性漏洞，反而是 Claude 取得完整上下文後迅速找出缺陷。因此路由規則明確排除偵錯、架構決策與安全性審查。

此外，每次委派需經網路來回，約10至30秒，預設逾時180秒。

接下來值得觀察的是：這種分流思路，會不會被更多 AI 程式碼工具採納。省錢從來只是起點，真正的問題是——AI 到底該把算力花在哪。

FAQ

Q1：shunt 外掛是怎麼幫 Claude Code 省 Token 的？

它用三層機制把工作分流：Hooks 在工具呼叫前攔截超過350行的檔案讀取，導向輕量的 bulk-reader；腳本封裝 Portal CLI 組裝請求並回報用量；Skills 說明呼叫時機。大型讀取改由 Gemini 2.5 Flash 處理，只回傳結構化摘要，因此大幅減少本體的 Token 消耗。

Q2：實測的節省幅度有多少？可信嗎？

《TenTen》的 Ewan Mak 在16.2萬行 Java monorepo 實測：4,014行單檔省82%，7,408行原始碼與測試檔配對省94%，1,281行跨服務多檔省94%，平均約九成。但這是單一專案的測試結果，實際成效可能因程式碼結構與使用情境而異。

Q3：所有工作都適合分流給輕量模型嗎？

不適合。委派摘要不含精確行號，無法直接編輯程式碼；測試中也曾漏掉執行緒安全性漏洞。因此路由規則排除偵錯、架構決策與安全性審查等核心工作。此外每次委派需10至30秒網路來回，對即時性要求高的任務不見得划算。