我讓 Fable 當腦，Sonnet 當手，省了一半 Token

大多數人用 AI 時犯的第一個錯誤，就是把最強模型當成一把萬能鑰匙。每次開始工作就派出 API 最貴的模型，做完所有事情，然後驚訝地發現 Token 用量爆表。但仔細想想，一個完整的工作其實並不需要每一步都用最高層級的思維。就像公司不會派薪水最高的人整天複製貼上和整理表格，AI 也不應該被這樣浪費。

Model Routing 的核心概念是「算力分配」，而不只是「模型選擇」。它包括兩個維度：第一是選擇模型的等級（是派最強的還是成本低的），第二是決定推理強度（要它快速回答還是深度思考、多花 Token 檢查）。這兩個維度組合出來，就能為每一步工作找到最適合的配置。高價值決策（產品策略、系統架構、重要審查）需要強模型加高推理；快速判斷（在三個方向中選一個研究）可以用強模型但不用最高推理；明確規格下的技術執行可以用便宜模型但提高推理強度去處理難題；格式轉換、資料分類這些機械工作就用便宜模型低推理。

但在選模型之前，要先過兩道關。第一道是公司的資安政策——某些資料根本不能丟到外部 API。第二道是任務特殊需求——如果需要 Live Web 或 X 的實時資訊，就不能只看單純的模型實力，而是看誰能接到那條資料流。

真實的成本結構遠比 API 單價複雜。一個實驗驗證了這一點：同樣的網站專案，用 Fable 5 從頭到尾做，成本是 $21.7；如果用 Model Routing——Fable 負責規劃和審查、Sonnet 負責執行、Opus 做中間判決、Sonnet 負責修正——成本掉到 $9.15，節省了 58%。這不是因為便宜模型品質差，而是因為規格清楚後，執行階段本身就不需要最高層級的判斷力。更重要的是，這套分配方式還要求你建立清晰的交接流程：Research 產出研究包、Design/Spec 產出清楚的規格書、Execute 產出可檢查的成品、Review 產出問題清單、Fix 按清單修改。每一步的輸出成為下一步的輸入。當問題出現時，你才知道該退回哪一步。

這個流程還有個隱藏好處：它讓不同模型能無誤協作。便宜模型不會因為規格模糊而亂做；強模型不會被浪費在機械工作上。一旦 Spec 寫得很清楚，便宜模型即使在執行時提高推理強度去處理複雜邏輯，成本仍然比強模型便宜。但有個條件——如果執行時發現問題不是實作錯而是 Spec 本身錯了，就必須升級回強模型重新處理方向，不要讓便宜模型硬改。

這套方法的精妙之處在於，它不綁定特定的模型排行榜。模型會變、價格會變、平台政策也會變，但架構不變：任務可以拆、模型可以換、資料權限清楚、驗收標準存在、出錯可以回退。