今天介紹 OpenRouter 時，我們講到：
模型 A 掛掉。
可以切模型 B。
Provider A 有問題。
可以換 Provider B。
聽起來很方便。
但這裡最容易犯一個錯：
只要失敗，就叫另一個 AI 繼續做。
其實有些失敗：
適合切換。
有些失敗：
根本不應該再讓 AI 繼續。
所以今天只學一個方法。
在設定 OpenRouter Fallback 前：
先拿一張紙。
畫三格：
主模型。
備援模型。
轉人工。
然後把一條真正的工作放進去。
先用一個最簡單的例子
假設你有一個 AI 客服。
工作是：
根據公司已確認的商品資料，回答一般產品問題。
主模型：
模型 A。
你希望：
模型 A 暫時不能用時。
自動換模型 B。
這很合理。
但如果客戶問：
「你們可以賠我 20,000 元嗎？」
這時不能因為：
模型 A 不知道。
就切模型 B。
B 不知道。
再切 C。
直到某個模型願意回答：
「可以。」
這不是 Fallback。
這叫：
一直換人猜答案。
所以第一格：主模型
先寫：
正常情況下，這件工作由誰做？
例如：
一般 FAQ。
↓
便宜模型 A。
複雜摘要。
↓
較強模型 B。
不要一開始就想：
「哪個模型最強？」
先回答：
正常工作需要多強？
如果只是：
分類 Email。
擷取品名。
重新整理格式。
通常不一定需要最昂貴模型。
第二格：備援模型
再問：
主模型失敗時，什麼情況可以安全地再試一次？
OpenRouter 的 Model Fallback 可以在主要模型發生錯誤後，依順序嘗試指定的備援模型；官方目前列出的觸發情況包括 Rate Limit、服務停機、Context Length 驗證錯誤及部分內容過濾情況。
但今天不要把所有 Error Code 背起來。
先記一個原則：
如果問題是「AI 服務沒跑成功」，才優先考慮備援。
例如：Rate Limit
主要模型現在太多人使用。
請求被限制。
原始資料沒有問題。
任務也沒有問題。
只是：
現在這條路太塞。
這時切另一個可用模型：
合理。
例如：Provider 暫時故障
模型本身可能完全沒問題。
只是目前執行它的某個 Provider：
過載。
斷線。
沒有回應。
OpenRouter 可以在啟用 Fallback Routing 時，對部分 Provider 錯誤改走另一個 Provider Endpoint。
這就像：
高速公路前面封路。
不是目的地錯了。
只是換另一條路。
但第三格更重要：轉人工
現在問：
什麼情況即使換十個模型，也不應該繼續？
第一個：
資料根本不存在。
例如客戶問：
「我這筆退款到底核准了沒有？」
你的系統裡根本沒有退款狀態。
模型 A 不知道。
換模型 B：
還是不可能真的知道。
再換模型 C：
只會增加產生一個看似合理答案的機會。
真正應該做的是：
停。
轉人工。
或要求補資料。
第二種：原始資料互相矛盾
例如資料庫說：
客戶方案到 8 月 31 日。
合約 PDF 卻寫：
9 月 30 日。
這不是：
模型 A 不夠強。
而是：
兩個來源本身不同。
換更強模型：
最多只能幫你指出衝突。
不能替公司決定：
哪份合約正式有效。
所以這種情況也是：
轉人工。
第三種：需要正式商業決定
例如：
退款。
折扣。
正式報價。
付款條件。
合約承諾。
修改客戶權限。
這些問題就算模型回答得非常漂亮：
最後也可能需要人核准。
所以不能設計成：
模型 A 拒絕。
↓
模型 B。
↓
模型 C。
↓
終於有一個模型答應。
這反而是在繞過原本的安全邊界。
第四種：工作本身超出 AI 權限
例如 AI 只能：
整理退款申請。
卻被要求：
直接把錢退回去。
這時不應該：
換一個更強模型。
真正問題是：
這件事原本就不在自動執行範圍。
一樣：
轉人工。
所以 Fallback 要解決的是「可恢復的技術失敗」
不是：
所有失敗。
這一句就是今天最重要的觀念。
可以先把問題分成兩大類。
第一類：執行失敗
例如：
Rate Limit。
Provider 暫時不可用。
模型服務短暫過載。
在符合你資料政策與功能需求的前提下：
可以考慮備援。
第二類：工作本身不能自動決定
例如：
缺資料。
資料衝突。
沒有權限。
高風險決定。
正式承諾。
這時：
不要 Fallback。
轉人。
還有一種情況比較容易混淆：模型能力不夠
例如：
便宜模型做簡單分類很好。
但遇到：
10 份文件。
多條件比較。
复杂推理。
錯誤率突然變高。
這時可以設計：
便宜模型。
↓
較強模型。
這種「升級模型」也可以是路由的一部分。
但要注意：
「品質不好」和「服務壞掉」不是同一種失敗
如果 Provider 回 429：
你知道：
請求根本沒有正常完成。
比較容易自動判斷。
但如果 AI 很流暢地回答了一個：
錯誤答案。
API 可能顯示：
成功。
HTTP 也可能完全正常。
OpenRouter 不會因為：
「這答案其實不好。」
就自動知道應該換模型。
這時你需要的不是單純 Fallback。
而是：
結果驗證。
例如商品分類
你要求 AI 把商品分類成：
食品。
家電。
家具。
如果結果必須落在這三個選項之一：
很好驗證。
但如果 AI 產生：
「其他。」
系統可以判定：
不符合規則。
再交給：
較強模型。
這是可以設計的。
但是自由文字品質就比較難
例如：
「幫我判斷這位客戶到底是不是生氣。」
AI 回：
「不是。」
系統很難只靠格式知道：
這個答案到底對不對。
這種工作就不能只相信：
Response Success。
所以今天三格卡旁邊：
再多寫一句。
備援是因為什麼失敗而啟動？
一張完整路由卡可以長這樣
工作：
產品 FAQ 回覆。
主模型
模型 A。
使用條件：
資料完整。
一般低風險問題。
備援模型
模型 B。
只在以下情況啟動：
Rate Limit。
Provider 暫時不可用。
主要模型服務故障。
轉人工
以下情況停止：
資料找不到。
兩份資料互相矛盾。
退款。
折扣。
正式客戶承諾。
需要修改帳戶資料。
就這麼簡單。
先不要急著加入第三、第四個備援
OpenRouter 確實可以設定多個 Model Fallback；官方目前的 fallbacks 參數最多接受三個備援項目，而且實際計費以最後真正完成請求的模型為準。
但第一版流程沒有必要：
A。
B。
C。
D。
E。
全部排進去。
模型越多：
你越難回答：
最後到底誰處理了？
為什麼前面失敗？
不同模型輸出格式是否一致？
成本變多少？
第一版只用「1＋1＋人」
最好理解。
1 個主模型。
1 個備援模型。
1 個轉人工規則。
先跑穩。
再決定要不要增加複雜度。
還要記一件事：Provider Fallback 和 Model Fallback 分開
假設：
你使用同一個模型。
只是 Provider A 暫時不能服務。
OpenRouter 可以依設定嘗試其他 Provider。
這比較像：
同一個人，換另一條電話線。
而 Model Fallback 是：
模型 A 不行。
改找模型 B。
比較像：
換另一個人處理。
兩種備援不要混成一件事。
更不能把「人」當最後一個最差的 Fallback
人工不是：
AI 全部失敗後才勉強使用。
有些工作一開始就應該設計：
人是正常流程的一部分。
例如：
AI 整理退款原因。
↓
人核准。
↓
系統執行退款。
這不是：
AI 不夠先進。
而是：
責任設計。
OpenRouter 的錯誤類型其實可以幫你做這件事
OpenRouter 官方目前會把不同 Provider 錯誤標成較一致的 error_type，例如 Rate Limit、Provider Overloaded、Provider Unavailable、Authentication、Permission Denied 等，讓程式可以區分不同錯誤原因。
但不要做成：
任何 Error → 換模型。
例如：
authentication
可能代表 API Key 有問題。
換另一個模型：
不一定解決。
payment_required
可能代表帳戶餘額不足。
一直換模型：
也沒有意義。
permission_denied
甚至可能代表：
你根本不應該執行這件事。
所以 Error Type 的用途是：
判斷下一步。
不是：
全部導向 Fallback。
還有一個容易漏掉的例外：串流已經送出一半
OpenRouter 官方目前說明，如果錯誤發生在 Streaming 還沒有輸出任何 Token 以前，仍可能透明切換其他 Provider。
但是如果內容已經送出一部分後才發生 Mid-stream Error：
就不能再偷偷切另一個 Provider 接著生成，因為部分內容已經交付給你的 App。
這代表：
備援不是任何時刻都能無縫接手。
所以正式 App 還是需要：
錯誤狀態。
重試規則。
使用者提示。
最後記得把「切過備援」留下紀錄
OpenRouter 的 Usage Accounting 會在回應中提供 Token、Cost、Reasoning Token 與 Cache 等使用資訊，可以拿來追蹤實際成本。
你的系統最好再一起記：
本來指定哪個模型。
最後哪個模型完成。
有沒有 Fallback。
人工有沒有修改。
因為如果你發現：
100 件工作有 60 件都切備援。
真正問題可能不是：
「幸好有備援。」
而是：
主模型根本不適合當主模型。
今天可以直接做的動作
找你現在一條 AI 工作。
不要改程式。
先拿紙畫三格。
主模型
正常由誰做？
備援模型
只有哪些技術失敗時可以換？
轉人工
哪些情況不准再換模型硬做？
如果第三格完全是空白：
反而要小心。
因為幾乎所有真正進入商業流程的 AI：
最後都應該有一些事情知道：
這裡不能再自動往下。
可以直接複製的 Prompt
你是我的 AI 模型路由設計助手。
我要使用 OpenRouter 或其他多模型 Gateway 處理以下工作：
[描述工作]
目前主要模型：
[模型]
候選備援模型：
[模型]
請不要設計成「只要失敗就一直換模型」。
先替我建立三格路由卡。
第一格：主模型
說明：
正常情況下由哪個模型執行。
這個模型只負責哪些工作。
什麼條件下可以直接接受結果。
第二格：備援模型
只列出真正適合自動切換的情況。
優先區分：
Rate Limit。
Provider 暫時不可用。
服務過載。
可恢復的技術故障。
模型能力不足而需要升級。
對每一種情況說明：
是否可以自動切換。
切到哪個模型。
最多重試幾次。
第三格：轉人工
只要遇到以下問題，禁止繼續透過更換模型硬做：
原始資料缺少。
資料互相矛盾。
權限不足。
需要正式退款。
需要正式報價。
需要改變合約或交易條件。
需要對外正式承諾。
答案無法被可靠驗證。
其他高風險或不可逆操作。
最後再告訴我：
哪些問題屬於「AI 服務失敗」。
哪些問題屬於「工作本身不能自動決定」。
不要把這兩類混在一起。
第一版只使用：
1 個主模型。
1 個備援模型。
1 組轉人工條件。
不要一次設計多層複雜 Router。
今天最容易犯的錯
看到 OpenRouter 有 Fallback。
就把流程寫成：
失敗 → 換模型 → 再失敗 → 再換。
真正需要先問的是：
為什麼失敗？
如果是：
服務暫時壞掉。
可以換。
如果是：
資料根本沒有。
不要換。
如果是：
便宜模型能力不足。
可以升級。
如果是：
正式付款與合約決定。
不要換。
如果是：
權限不足。
更不能為了「讓流程成功」去找一條權限更大的路。
今天最重要的一句話
Fallback 是替技術故障準備的，不是替不確定答案找一個願意猜的模型。
所以使用 OpenRouter 前：
先不要急著做聰明 Router。
只畫：
主模型。
備援模型。
轉人工。
當你可以清楚說明：
什麼事情正常做。
什麼故障可以換。
什麼情況一定停。
才真正適合把 AI 路由放進正式工作。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 一分鐘教學｜2026/08/11：設定 LiteLLM 備援前，先把錯誤分成「可切換、不可切換、轉人工」
