「每天 21:00 提醒我明天的行程」——這個任務需要博士級的推理能力嗎？

不需要。它需要的是：讀一份 Markdown、抽出明天的項目、排成一則通知。國中生程度的工作。但在 $40 事故之前，我的系統就是用 Claude 旗艦在跑這種任務——開超跑去倒垃圾，還是每天倒。

昨天講了止血，今天講制度：怎麼幫每一個任務配對「剛好夠聰明」的模型。這套三層路由跑了幾個月，再也沒有出現過任何一次費用意外，而且沒有任何一項服務的品質讓我想調回去。

三層分工：免費、低價、高階

我把可用的模型分成三層，每層有明確的適用範圍：

排程系統裡只允許 T1 和 T2，T3 在自動化語境全面禁用——不是「盡量不用」，是白名單直接擋掉（明天講的品質閘道會把這條變成硬規則）。

先誠實：分層的邏輯就是錢的問題。$40 燒下去之後我就是想省錢，沒有更高尚的出發點。但「要省在哪」需要一個判準，我用的是任務價值密度：排程任務的輸出我平均花 10 秒看完，一天幾十次；互動對話一次半小時，直接影響我的決策。把預算從前者挪到後者——省要省在刀背上——結果是總支出下降、體驗反而上升。省錢是動機，價值密度是方法，別倒過來講得自己好像一開始就很懂。

而說得更準一點，目標其實不是「花得越少越好」，是每月花費可控、可預期：一套會不定期爆錶的系統，再聰明你也不敢長期養著；分層路由真正買到的，是讓這套 AI 服務能被一個固定的月預算穩定養下去——排程走可控的 API 小額、深度走固定月費的訂閱，帳單從「驚喜」變成「房租」。

關鍵發現：任務需求決定模型「下限」

真正動手做路由時，我撞到一個規格表上看不出來的坑：在我的系統裡，最便宜的那層（Gemini 通道）吃不到工具呼叫（tool call）——不能執行 shell、不能寫檔案、不能搜尋網路。而我的排程任務裡有一大類是「跑腳本」型的：更新快取、同步持倉、跑健康檢查。這些任務的本體是 exec，模型只是那個「決定執行並回報結果」的調度員。

第一次把快取更新 job 降到 Gemini 時，它的回應堪稱靈魂拷問：任務要它執行腳本，它回了一段描述自己會怎麼執行腳本的文字。像請了一個只動口不動手的工讀生。job 顯示成功（有輸出嘛），快取卻一天沒更新——又是一次安靜的失敗。

這裡要把話講精準，因為我第一時間也誤診了：這不是 Gemini 的天生缺陷——Gemini 的 API 本身支援 function calling。不能用的是「我的框架接這條通道的方式」：框架的 exec／寫檔工具沒有接上 Gemini 這一路，而它失敗的方式又不是報錯（見坑三），是若無其事地生成文字，所以我一開始把整件事記成「模型不支援」。這個誤診本身就是教訓的一部分：規格表說支援，不代表你的整合鏈上真的能用；你的鏈上不能用，也別急著怪到模型頭上。實測，兩個方向都要實測。（至於要不要回頭把這條整合修好？算過帳就放下了：Haiku 一次呼叫不到一分錢，修整合的工程換不回這個價差。）

這給了我路由設計的第一原則：**成本決定模型上限，能力需求決定下限。**省錢是在「能力及格」的前提下省，及格線由任務的硬需求劃定：

• 要 exec / 寫檔 → 至少 T2（支援工具呼叫的模型）
• 要網路搜尋 → 至少 T2，或乾脆移出排程、改成人工觸發
• 純讀檔 + 寫文 → T1 就好，一毛都別多花

動手做：路由決策樹

新增任何排程任務時，我按這棵樹走一遍：

注意最右下角那個分支：**「需要最強模型的任務，不配進排程。」**這是分層裡最反直覺、也最省錢的一條。如果一個任務真的需要旗艦級推理——例如深度的投資覆盤、系統架構的重新設計——那它幾乎必然也需要人的參與和確認，把它做成無人排程本身就是設計錯誤。我的做法是把這類工作移到互動對話裡：包月的 **Claude Code（Max 5x 方案）**與 Cowork 做深度分析，API 排程只做便宜的例行事務。按次計費的通道跑量、訂閱制的通道跑深度——旗艦模型的重度使用一旦改成月費吃到飽，「深度分析要不要省著用」這個猶豫就直接消失了，兩邊的計費模式各自用在最划算的地方。

實際路由結果，以幾個代表性任務為例：

訂閱制的排程：同一條規則的另一半

上面說「需要旗艦推理的任務，不配進排程」——精確的說法其實是：不配進「按次計費」的排程。這條規則後來長出了另一半：訂閱制那頭也有排程能力（Claude 的 scheduled tasks），我把「需要深度、但例行發生」的工作全搬到那裡跑——台美股的盤前與收盤報告、每週投資反思、月度循環檢視、AI 資本支出新聞監控……共九個 routine，每天準時產出完整分析，用的就是 Claude 旗艦。

為什麼這不違反鐵則？回頭看 $40 事故的公式：故障 × 排程 × 按次計費，三個因子相乘才會爆錶。訂閱制把第三個因子直接歸零——月費固定，排程跑一百次和跑十次成本一樣，「爆錶」這個風險類別在這條通道上不存在。於是完整的分工變成三條通道：

• API 排程（按次）：便宜的確定性雜務——通知、快取、健檢
• 訂閱排程（月費）：昂貴的例行深度——每日投資分析、週覆盤
• 互動對話（月費）：真正需要來回討論的事——架構、決策、寫作

各自的計費模式決定各自能承載什麼。你可能會問：既然訂閱吃到飽，為什麼不把 API 排程也全搬過去？兩個原因：訂閱的額度同樣有限（下面那次沉默斷供就是證據，吃到飽的「飽」也有胃容量）；而且 exec 類任務要碰 NAS 本地的檔案與腳本，訂閱端的排程搆不到這台機器。所以分界其實很自然：**便宜且確定的留在 API、昂貴且純分析的去訂閱、要碰本地的只能留在本地。**順帶一提，那九個 routine 的 prompt 我同樣收進 git 管版本——跟明天要講的「規則要住在檔案裡」是同一個信仰。

誠實補一筆：這條通道也有自己的故障型態——它斷的時候不是燒錢，是沉默。八月中就真實發生過：訂閱方案的模型額度用罄，兩天內七份報告無聲缺席，沒有任何告警（額度用完不是錯誤，是「正常地什麼都沒發生」）。補救是換一顆模型繼續跑。訂閱制把成本風險換成了可用性風險——天下沒有免費的排程，只有你選擇承擔哪一種風險。

我踩過的坑

**坑一：用「模型名稱」而不是「能力」寫規則。**初版路由規則直接寫死模型 ID，某次服務商改版換代，ID 失效、job 全數報錯。後來規則改成按「層級」寫，層級到模型 ID 的對照集中在一處，換代只改一行。另外我還寫了一支小腳本，定期驗證設定裡的 model ID 是否仍然有效——模型的生命週期比你的系統短，把「模型會退役」當成常態設計。

坑二：低估了「品質敏感」的判斷難度。「模板文字」和「品質敏感」的界線比想像中模糊。我的經驗法則後來收斂成一句話：如果這段輸出寫錯了、我會基於它做錯決定，就是品質敏感；如果寫錯了我頂多覺得文筆差，就是模板。用「錯誤的後果」分類，比用「任務聽起來難不難」準得多。

**坑三：Gemini 通道接不到工具——而且它不會報錯，它會演。**有個需要跑腳本的任務，我一開始貪便宜路由到 T1。這條通道拿不到工具（前面講過，是整合層的限制不是模型的），但它不會回你一個錯誤——它會生成一段看起來像做完了的文字：「已為您更新快取 ✅」。任務狀態綠的、訊息成功送達、內容文情並茂，唯獨腳本根本沒被執行。發現的方式是那支腳本該產出的檔案，時間戳停在三天前。這就是決策樹第一個分岔「需要工具呼叫？」為什麼放在最上面：能力下限是硬約束，不是偏好——路由錯了不會失敗給你看，會安靜地演給你看。

小結＋明日預告

三層路由的本質是把「模型選擇」從美學問題變成工程問題：能力定下限、成本定上限、後果定敏感度。實測幾個月：零費用意外、體感品質零下降——對比事故那一夜，這就是設計和放任的差距。

但規則寫在我腦裡沒有用，我自己就是最常違規的人。明天講怎麼把這些規則變成「法律」：任何排程任務都要過的五道閘門。

🔑 這篇的關鍵字
模型分層路由：T1 Gemini（模板化文字）· T2 Claude Haiku（需要工具/exec 的自動化）· T3 Claude 旗艦（只有互動對話，由 Claude Code 訂閱 Max 5x 承接、不走 API 計費）
三個判準：能力定下限、成本定上限、後果定敏感度
完整分工是三條通道：API 排程跑便宜雜務（按次）· 訂閱排程跑例行深度（月費，九個 routine）· 互動跑討論——爆錶公式「故障×排程×按次計費」被訂閱制拔掉第三個因子；代價是它斷的時候不燒錢、改沉默（八月中七份報告無聲缺席實例）
鐵則：背景排程一律禁用 Claude 旗艦 · 把模型白名單寫成設定檔（單一事實來源），不要散落在各 job 裡

我是一名金融業資訊工程師，這是我半年來在家自架 AI Agent 系統的實錄。