AI 摘要
- Spotify 工程師公開 Claude Code 省錢架構。
- 此架構用 Gemini 2.5 Flash 分擔簡單工作。
- Claude 端 Token 消耗平均下降約九成。
Spotify 工程師 Dimitri Mazmanov 公開一套以 Gemini 2.5 Flash 為核心的 Claude Code 成本優化架構，透過輕量模型分流與硬性攔截機制，讓 Claude 端的 Token 消耗平均下降約 90%。這套做法不是要取代旗艦模型，而是把檔案讀寫、樣板生成等粗活交給平價模型，讓 Claude 專注在高價值推理與架構決策。
產品定位與目標用戶
這套架構鎖定在大型專案中使用 Claude Code 等終端 AI 編碼代理的軟體工程師與開發團隊。當工程師把繁重任務交給 AI 編碼代理時，最令人心驚的往往不是模型寫不出解法，而是終端機裡急速狂飆的 Token 帳單與迅速見底的用量上限。馬茲馬諾夫指出，許多操作本質上只是純粹的檔案輸入與輸出（I/O）與模式比對，根本不需要動用高推理能力、每百萬 Token 價格昂貴的旗艦模型來硬扛。
主要功能：bulk-reader 與 code-writer 雙工模式
馬茲馬諾夫運用 Spotify 內部開發者平台「Portal by Spotify」所具備的「AiKA Modes」功能，宣告式定義出兩套隨開即用、無須常駐伺服器的微型代理人，並指定使用平價輕量的 Gemini 2.5 Flash 作為打工模型。這兩種模式分別是 bulk-reader 與 code-writer。
- bulk-reader（巨量閱讀器）：當專案需要掃描多個大檔案時，Claude 不會直接開啟檔案，而是把檔案路徑與問題丟給 bulk-reader，由平價模型先行讀完後，僅回傳條列式的關鍵濃縮資訊給 Claude。
- code-writer（代碼生成工）：針對重複性高的單元測試、型別定義或樣板代碼，由 Claude 提供規格與現有參考範本，指示工作模型依樣畫葫蘆並直接寫入磁碟，產出的冗長代碼甚至完全不需要流經 Claude 的對話視窗。
這種「上下文隔離」策略，成功將動輒數萬 Token 的語法雜訊擋在門外。即使平價模型在無狀態的暫態環境中重複讀取檔案，消耗的也僅是低廉的二線模型成本，讓旗艦大腦始終維持在精煉而高價值的思維狀態。
| 模式 | 主要用途 | 運作方式 | 輸出與效益 |
|---|---|---|---|
| bulk-reader | 掃描多個大檔案，過濾上下文雜訊 | Claude 把檔案路徑與問題丟給 bulk-reader，由 Gemini 2.5 Flash 先行閱讀 | 僅回傳條列式關鍵濃縮資訊，避免數萬 Token 語法雜訊進入 Claude 對話視窗 |
| code-writer | 生成重複性高的單元測試、型別定義或樣板代碼 | Claude 提供規格與現有參考範本，指示工作模型依樣產出 | 直接寫入磁碟，冗長代碼不需流經 Claude 的對話視窗 |
硬性攔截：shunt 外掛與 PreToolUse 鉤子
混合模型架構最常遇到的痛點是模型的自作主張。馬茲馬諾夫一開始嘗試在專案根目錄的設定檔「CLAUDE.md」中寫下提示規則，叮嚀 Claude「遇到簡單任務請委託給工作模型」。然而實測發現，純文字 Prompt 屬於弱約束，Claude 在複雜任務中經常拋諸腦後、依舊自顧自地狂讀大檔，且每個專案都必須重複複製這套規則，難以標準化。
為此，他轉向 Claude Code 核心的「PreToolUse」事件鉤子（Hook），打造出名為「shunt」的專用外掛。shunt 扮演嚴格的看門人角色，在 Claude 呼叫工具的毫秒瞬間進行動態攔截。當 Claude 試圖使用 Read 工具打開單一超過 350 行的原始碼，或企圖在終端機中透過以下指令窺探大檔時，shunt 會立刻切斷執行，並強迫 Claude 轉向調用 bulk-reader：
cat
head
tail
less
more唯有當 Claude 精準指定特定程式碼行數區間（Line Range），或是使用管線指令精確過濾內容時，外掛才會視為合理操作並放行。
這套三層架構形成了閉環：Hook 負責強制防呆阻止誤讀，Claude Code Skill 提供標準化的調用協定，底層 Shell 腳本則透過 CLI 發送請求。即便模型出現幻覺或忘記指令，底層攔截器依然能築起防火牆，將節省 Token 的期望轉化為無法逾越的硬性制度。
| 約束方式 | 做法 | 限制 |
|---|---|---|
| 提示詞弱約束 | 在 CLAUDE.md 寫下規則，要求 Claude 把簡單任務委託給工作模型 | Claude 在複雜任務中經常忽略；每個專案都要重複複製規則，難以標準化 |
| shunt 硬性攔截 | 透過 PreToolUse 事件鉤子，在工具呼叫瞬間動態攔截超過 350 行的讀取 | 強制 Claude 轉向 bulk-reader；指定行數區間或精確過濾時才放行 |
技術指標與實測結果
在 Spotify 的 Java 大型單一儲存庫（Monorepo）中，馬茲馬諾夫針對四種不同開發情境進行對比實測，結果顯示透過 bulk-reader 過濾摘要後，Claude 端的 Token 消耗量平均驟降約 90%，省下的運算資源極為可觀。
技術邊界與限制
- 在代碼審查測試中，輕量模型雖然能輕易指出命名規範與表面語法模式，卻完全漏掉極度隱晦的執行緒安全（Thread-safety）並發問題。
- 跨模型委託需要透過 CLI 與 API 發起外部請求，通常會引入 10 到 30 秒的處理延遲。
- 這也是為何必須設立 350 行門檻，避免小檔案得不償失。
結論
「降本」並非要將旗艦模型邊緣化，而是讓各個層級的算力各司其職。高深推理、系統架構設計與安全邊界依然由 Claude 把關，粗活累活則交給小模型代勞。唯有在架構上建立這種剛性分工，開發團隊才能在 AI 代理人普及的浪潮中，既守住代碼品質，又不必承受失控的帳單代價。
Reference Link : techbang.com
