模型分流把測試成本壓下來

我把 coding 任務先分級，再把便宜模型放前面，能省錢又不太傷品質。

我用 AI coding assistant 用到現在，最常冒出來的不是「它做不到」，而是「靠北，這題根本不值得用這麼貴的模型」。輸出看起來沒問題，demo 也挺順，直到我去看 usage log，才發現自己在替一個本來可以很無聊的任務，付了很不無聊的錢。這種感覺很差，因為它不是失敗，是默默漏錢。

更煩的是，這種浪費很容易被包裝成效率。大模型回得快、講得像樣、通常也能把事情推到八九成，所以你會懶得再想。久了之後，習慣就長歪了：什麼都先丟最貴的那顆。這不是架構能力，這比較像手滑。

我後來才想通，模型選擇不是一次性的「我家就用這個」決策，而是 triage 問題。不同任務本來就該走不同路徑。這篇把我拆開這套思路的來源放在這裡：The New Stack 對 Claude Fable 與 GPT-5.5 成本差異的文章。它不是在講玄學，是在提醒你同一個 coding test，放不同模型上，成本可以差很多。

我現在比較不把這件事看成模型選型，而是看成路由。簡單工作走便宜路，難工作才上重裝。對 agentic workflow 來說，這不是小優化，這是你帳單會不會失控的分水嶺。

別再用感覺選模型，這是在燒錢

“Claude Fable cost $9 in one coding test. GPT-5.5 cost $1.50.”

這句話的重點不是誰比較強，而是同一種工作，放到不同模型上，成本可以差到很誇張。翻譯一下就是：你如果不先分類任務，就很容易把高價推理拿去做低價雜工。那不是聰明，那是浪費。

我看過很多團隊把 code review、test generation、refactor、甚至簡單 bug 修補，全丟給同一顆高階模型。理由通常很熟：比較保險、比較省事、比較不會出事。問題是，省事常常就是貴。只要任務本質上是格式轉換、局部改寫、結構抽取，你根本不需要拿最貴的腦袋去處理。

實操上，我會先把 AI 任務切成三桶。第一桶是低風險機械活，像 summarizing、rewrite、extract、format。第二桶是中風險工作，像寫測試、局部重構、dependency analysis。第三桶才是高風險，像架構決策、跨模組 bug 診斷、長鏈路 planning。第一桶幾乎不該碰最貴模型，第二桶用能過門檻的最便宜方案，第三桶才值得花錢。

這個切法聽起來很直白，但真的落地時，你會發現很多「我們以為很難」的工作，其實只是流程沒拆乾淨。你把任務拆開之後，貴模型的使用率通常會掉很多，而且不會影響結果。

我之前幫一個內部 code assistant 看過 log，最貴模型被拿去做的事情，大半是改命名、補註解、轉格式。那一刻我真的有點想翻桌。不是模型有問題，是我們把它當萬用刀，結果拿來切吐司。

模型分流其實就是 routing，只是換個比較不難聽的名字

所謂 model triage，我自己的白話版本就是：不要把昂貴 intelligence 用在便宜問題上。這概念一點都不新，我們早就在 compiler、cache、queue、background job 上做同樣的事。AI 只是把浪費放大，因為每次呼叫都會寫進帳單。

很多 agent builder 最常犯的錯，是先選模型，再補工具。這順序很怪。比較合理的是先問「這是什麼類型的工作」，再問「哪顆模型最適合」。不然你的 agent 就會變成一台永遠走最高配路線的自動販賣機，什麼都吐最貴版本。

實操寫法我會很土炮：在主模型呼叫前，加一個輕量 classifier。可以是規則，也可以是便宜模型，混用也行。我偏好先用規則，因為便宜、可預測、可 debug。像 request 裡有 summarize、extract、rewrite、format，就先走低階；有 bug、compare approaches、plan implementation，就往上；如果看不懂，就先問清楚，不要硬猜然後把錢燒掉。

• 低階模型：抽取、改寫、分類、簡單 code edit。
• 中階模型：寫測試、重構、dependency tracing、工具呼叫。
• 高階模型：架構、跨系統 debug、長鏈路規劃。

這樣做的好處是，你不再是憑感覺下注，而是把模型選擇變成 policy。政策一旦寫下來，就能測、能改、也能吵架。比起「我覺得這題比較難」，這種做法至少像個工程團隊。

還有一個很實際的好處：triage 會逼你定義什麼叫 good enough。這件事很煩，但必要。很多團隊口頭上說要最強模型，其實只是還沒有成功標準，所以只好用貴來掩飾不確定。

便宜模型不是次等品，重點是它少不必要的戲

我現在看模型，不太只看它聰不聰明。我更在意它會不會亂演。因為在 coding 工作裡，最討厭的不是答案不夠華麗，而是答案看起來很像對的，結果你還得花更多時間清理。

我遇過一種很典型的狀況：大模型寫出來的 code 很漂亮，但 review 成本高，因為它會塞很多自信但不必要的東西。小一點的模型呢，可能沒那麼會講故事，但產出比較直，反而更好讀、更好改。對日常工作來說，這常常更有用。

也就是說，品質不是單一維度。你要一起看 correctness、review cost、latency、spend。便宜但讓你多花兩倍 review 時間，不叫便宜；貴一點但讓你少問三輪問題，那可能反而划算。只看 benchmark 很容易自嗨，因為 benchmark 不會幫你付 cloud bill，也不會幫你消化工程師的注意力成本。

我之前做 unit test generation 時就踩過這個坑。大模型寫的測試比較漂亮，但小模型寫的版本，我掃得快、改得快、丟回去重跑也快。最後我選的不是最美的答案，而是最省總成本的答案。

實操上，我會開始記這幾個數：第一輪接受率、平均追問次數、人類修改時間、每個完成任務的總成本。只看 inference cost 太狹隘，因為真正貴的是整個流程，不是單次呼叫。

• 看 first-pass acceptance rate，不要只看模型有沒有回。
• 看 follow-up prompts 數量，這很誠實。
• 看 human edit time，因為工程師時間最貴。
• 看 completed task cost，不要只看單次 token。

當你開始這樣量，模型選擇就不再是信仰問題，而是營運問題。

Agent 需要預算，不只是腦袋

我會把這篇文章真正值得抄的地方，濃縮成一句話：如果你的 agent 能自己呼叫工具、自己繞圈思考、自己反覆嘗試，那它的成本也會跟著失控。這種系統不能只看「會不會做事」，還要看「做事會不會花太多錢」。

我看過很多 agent 在那邊 spinning wheels，查半天、試半天、重做半天，最後答案只好一點點，但費用已經翻過去了。那不是聰明，那是有 UI 的無限帳單。你如果不設 budget，它就會自己長出 budget 破洞。

實操寫法很直接：每個 agent 都要有 spend guardrails。不是只管安全，也要管花費。限制嘗試次數、限制 tool calls、只在低階失敗時升級、當邊際收益不值得時就停。這些規則看起來像在綁手綁腳，但其實是在保護你的產品不變成研究專案。

我特別建議 coding agent 先走兩段式。第一段做 task classification 和 difficulty estimation，第二段才決定 model 與 tool budget。低風險就卡住預算，高影響或低信心才升級。這樣不是很炫，但很有效。

我也喜歡把這件事做得很 boring。因為 boring 的意思通常是：帳單不會突然跳出來嚇你。這點真的很重要。

別讓 ego 決定你該不該升級模型

很多人會過度使用 premium model，不一定是技術判斷，更多時候是 ego。不是說大家愛面子，而是「用最強模型」聽起來比較安心，也比較像有在做事。問題是，你的工作不是去討好 API。你的工作是把事情做完，而且不要把錢燒得太難看。

還有一個很常見的狀況，是團隊把模型名稱當成能力證明。好像只要貼出某個高階模型的名字，整個系統就突然高級了。其實不是。真正有料的是你能不能把任務拆對、把升級條件寫清楚、把不該升級的地方壓住。

實操上，我會把 routing policy 寫得很短，直接放在 code 附近，不要丟到沒人看的簡報裡。規則要能被團隊真的照做：什麼情況用便宜模型、什麼情況才升級、誰可以 override、override 要寫理由。這種東西如果不落地，最後就會變成大家各自用各自喜歡的模型。

我自己比較喜歡把這叫做 model humility。不是說模型很弱，而是說很多工作其實沒必要把最貴的算力拿出來。能用小模型解決，就先用小模型；真的不行，再有意識地升級。

我會怎麼把這套真的做進產品

如果今天要我把這套 triage 做進一個產品，我不會先搞什麼巨型 router service，也不會先寫一個看起來很企業的 policy engine。那種東西很容易變成另一個平台專案，最後大家只是在幫架構本身打工。

我會先做三件事：一個便宜 classifier、一條清楚的 escalation path、一份完整 log。先把 80% 的價值拿到，後面再慢慢調。這樣比較像工程，不像表演。

白話一點就是：

• 先分類任務。
• 先用最便宜、但夠用的模型。
• 失敗、模糊、高風險才升級。
• 把 cost、retries、human edits 記下來。
• 每週回頭修 routing 規則。

我看過夠多 AI 系統之後，越來越確定一件事：失敗通常不是「模型太小」，而是「我們根本沒問這題值不值得走昂貴路徑」。那是 routing 問題，不是 intelligence 問題。

而且這件事很好測。你可以直接把一些任務往下路由，再把一些往上路由，比 acceptance rate、latency、spend。便宜路徑守得住就留，守不住就承認它不夠用。至少你學到東西，不是默默燒錢。

可抄的模板

# AI coding tasks 的 model triage policy

## 目標
用最便宜、但足夠完成任務的模型。
只有在任務模糊、風險高、或第一次失敗時才升級。

## 任務分桶

### Bucket 1：低成本機械活
使用最便宜且可接受的模型。
例子：
- 摘要 code / 文件
- 改寫文字
- 抽取欄位
- 格式化 JSON / markdown
- 簡單 code edit

### Bucket 2：中等複雜度工作
先用中階模型。
失敗再升級。
例子：
- 寫 unit tests
- 小型 refactor
- dependency tracing
- tool-assisted lookup
- 單一檔案或模組內的 bug isolation

### Bucket 3：高複雜度或高風險工作
直接用最強模型。
例子：
- 架構決策
- 跨服務 debugging
- 長鏈路 planning
- security-sensitive changes
- 需求不清楚的任務

## Routing 規則

1. 如果 request 明顯是機械活，走 Bucket 1。
2. 如果需要 reasoning 但範圍有限，走 Bucket 2。
3. 如果 request 模糊、面向使用者、或做錯代價很高，走 Bucket 3。
4. 如果 Bucket 1 失敗兩次，升到 Bucket 2。
5. 如果 Bucket 2 失敗兩次，或任務仍然模糊，升到 Bucket 3。
6. 如果還是不清楚，先問 clarifying question，不要硬猜。

## 成本 guardrails

- 最多 2 次 retry 才能升級
- 每個任務最多 3 次 tool calls
- 每個 bucket 設 token budget
- 如果下一次嘗試的改善機率很低，就停

## 要記錄的 metrics

- 使用哪個 model
- 任務屬於哪個 bucket
- retry 次數
- tool call 次數
- human edit time
- first-pass acceptance rate
- 每個完成任務的總成本

## 每週 review 問題

- 哪些任務其實被過度路由到昂貴模型？
- 哪些便宜模型任務其實需要太多修補？
- escalation 有沒有發生在對的地方？
- 我們是不是在 routine work 上付 premium rates？
- 哪些 routing 規則該收緊？

## 簡單 implementation sketch

text
if task.is_mechanical():
    model = cheap_model
elif task.is_bounded_reasoning():
    model = mid_model
elif task.is_ambiguous() or task.is_high_risk():
    model = premium_model

result = run_model(model, task)

if result.failed and retries < 2:
    escalate_one_level()


## 團隊規則
如果你 override router，請寫下理由。

## 成功定義
在不降低 first-pass usefulness、也不增加 human cleanup time 的前提下，把總成本壓下來。

這份模板故意寫得很平，因為你真的不需要什麼華麗系統。你需要的是一套規則，能阻止 AI spend 每次都在有人說「直接上最強模型」時偷偷往上漂。

原始來源是 The New Stack 這篇文章。上面對 routing、分桶、guardrails 的整理是我自己的拆解與改寫，不是原文照抄。