案例性質：以下為 SasaDaily 假設示範案例。公司、人數、客服量、成本、時間與改善幅度全部是教學情境，不是 OpenRouter 客戶公開導入成果。
一家 8 人的小型跨境皮件品牌。
自己設計：
皮包。
皮夾。
背帶。
卡套。
再透過自己的網站銷售到：
台灣。
日本。
美國。
新加坡。
每天真正花掉團隊時間的，不只是製作商品。
還有大量客服。
例如：
「這個包可以放 13 吋筆電嗎？」
「皮革淋到雨怎麼處理？」
「我的包裹現在在哪？」
「這條背帶和另一款相容嗎？」
「我收到的顏色跟照片感覺不一樣。」
「商品邊角有刮痕，可以換嗎？」
「信用卡好像被扣了兩次。」
看起來全部都叫：
客服。
但其實：
難度、風險和需要的 AI 能力完全不同。
這家公司以前只有一個做法
所有客服都送給：
同一個 AI 模型。
簡單問題：
它回答。
複雜問題：
它回答。
翻譯：
它回答。
客訴：
也還是它回答。
這樣最簡單。
但開始大量使用之後，團隊發現兩個問題。
第一：
很多簡單工作根本不需要那麼強的模型。
第二：
有些看起來回答成功的客訴，最後人工還是要全部重看。
所以問題變成：
不是要不要用 AI。
而是：
哪一件工作應該用哪一個 AI？
OpenRouter 在這個案例裡負責的是「路由」
團隊不讓 OpenRouter 自己決定：
退不退款。
賠多少錢。
哪個客戶比較重要。
OpenRouter 只負責一件事：
把符合規則的工作送到適合的模型與 Provider。
第一版先做三條路。
A 路：一般高頻客服
例如：
尺寸。
材質。
基本保養。
已確認的配送說明。
產品相容性。
這些問題：
高頻。
低風險。
答案來源明確。
使用成本較低、但經過測試已足夠完成這類工作的模型。
B 路：複雜問題
例如：
客戶一次問五個條件。
多件訂單互相影響。
多語言客訴。
瑕疵照片加上長篇描述。
不同資料來源需要一起整理。
這些案件才升級：
較強模型。
C 路：轉人工
例如：
退款。
補償金額。
信用卡重複扣款。
正式價格調整。
客製商品變更。
資料互相矛盾。
無法確認客戶身份。
這些不進入：
「再換一個更強模型。」
而是：
停。
第一步：先分類，不先回答
一封客服訊息進來。
AI 第一個工作不是：
立刻寫回信。
而是先判斷：
這屬於哪一類？
例如：
產品資訊。
物流。
一般退換貨詢問。
複雜客訴。
退款。
付款問題。
資料不足。
接著才決定：
走 A。
走 B。
還是 C。
這一步非常重要
因為如果一開始所有訊息都直接要求：
「幫我回答客戶。」
AI 很可能跳過：
這件事究竟能不能自動回答。
更好的流程是：
先分類。
再路由。
再產生結果。
最後驗收。
A 路：大量低風險問題走較便宜模型
例如客戶問：
「這個皮包可以裝 A4 文件嗎？」
公司本身已有：
正式產品尺寸。
產品資料。
FAQ。
AI 只需要：
找到正確資訊。
整理成客戶語言。
這類案件每天可能非常多。
如果一件工作使用較便宜模型就能穩定完成：
沒有必要每次都使用最高階模型。
但「便宜」不是唯一條件
這家公司先拿：
過去 50 件一般客服。
用候選模型測試。
看：
答案正確率。
是否漏條件。
格式一致性。
人工修改分鐘。
最後才決定：
哪一個適合成為 A 路主模型。
不是看到價目表：
最便宜。
就直接上線。
B 路：真正複雜才升級
例如客戶說：
「我買兩個包，其中一個收到時有刮痕，另一個尺寸好像也和原本想的不一樣，我下週要出國，如果換貨來不及，有沒有其他方式？」
這件事情包含：
兩個商品。
瑕疵。
尺寸。
時間。
換貨。
可能補償。
不能只當成：
一般 FAQ。
AI 可以先使用較強模型：
整理客戶真正遇到的問題。
確認缺少哪些資料。
準備可能的處理選項。
但還不能：
自己答應退款。
自己決定補償。
自己保證星期幾一定送到。
所以強模型也沒有取得更大的商業權限
這一點很重要。
模型能力升級。
不等於：
權限升級。
B 路模型可以：
理解更複雜。
整理更完整。
但公司原本不允許 AI 決定的事情：
仍然不允許。
Provider 故障時，才使用 Provider Fallback
假設 A 路使用的模型沒有問題。
只是目前 Provider A：
暫時過載。
這時：
OpenRouter 可以依路由設定改走其他符合條件的 Provider。
工作本身沒有改。
模型也不一定要換。
只是：
執行服務的路換了。
模型本身失敗時，再考慮 Model Fallback
如果主要模型請求失敗。
而且錯誤屬於：
可恢復的技術故障。
才進入：
備援模型。
但這家公司第一版只設定：
1 個主模型＋1 個備援模型。
不做：
A 不行換 B。
B 不行換 C。
C 不行換 D。
一路換到有人願意回答。
因為有些問題根本不是模型故障
例如：
客戶說自己被扣款兩次。
但公司目前付款系統資料：
還沒同步。
這不是：
模型 A 不夠強。
換模型 B：
還是沒有資料。
真正正確的流程是：
資料不足 → 停止 → 財務確認。
同樣的，資料衝突也不能靠換模型解決
假設：
訂單系統顯示客戶買的是黑色。
客服附件卻顯示棕色。
AI 不應該：
自己猜一個。
也不應該：
換更強模型猜。
應該：
標示衝突。
轉人確認。
每一個 Fallback 結果都要重新驗收
這就接上今天的快問快答。
假設主模型故障。
備援模型成功回覆。
OpenRouter 顯示請求完成。
還不能立刻：
寄給客戶。
這家公司把成功分三層。
第一層：服務成功
有沒有正常取得 Response？
例如：
沒有 Timeout。
沒有 Provider Error。
請求真的完成。
第二層：格式成功
客服系統要求固定輸出：
案件類型。
訂單編號。
風險等級。
回覆草稿。
是否需人工。
這些欄位都有嗎？
格式正確嗎？
允許值正確嗎？
第三層：商業結果成功
再檢查：
訂單真的存在嗎？
商品資料正確嗎？
AI 有沒有自行改價格？
有沒有自行答應退款？
有沒有承諾公司沒有確認的交期？
有沒有把付款問題錯當一般 FAQ？
只有三層都過：
才算真正完成。
所以 HTTP 成功不是公司的 KPI
這家公司不把：
API Success Rate。
當主要成果。
因為就算：
99.9% API 都成功。
如果：
20% 回覆需要人工重寫。
仍然很差。
真正要追的是：
完成一件可用客服要多少成本。
這家公司先記五個 KPI
KPI 一：一次可直接使用率
AI 第一版結果：
多少可以直接進下一個流程？
多少需要修改？
多少必須重做？
KPI 二：人工修改時間
不是只問：
「AI 有沒有幫忙？」
而是：
原本客服一件要 6 分鐘。
AI 做完後：
人還要花多少分鐘？
如果還要 5 分鐘：
價值就很有限。
KPI 三：每件可用客服總模型成本
包括：
主模型。
Fallback。
重試。
不是只記：
第一次呼叫價格。
KPI 四：Fallback 比例
例如：
100 件裡有多少真的切過備援？
如果只有：
2 件。
正常。
如果：
60 件。
就應該查：
為什麼主模型或 Provider 一直出問題？
KPI 五：轉人工是否正確
這個非常重要。
例如：
付款爭議。
退款。
高額補償。
資料衝突。
AI 正確停止：
不是失敗。
反而代表：
流程邊界有效。
假設每週有 1,000 件客服
以下全部是教學數字。
不是 OpenRouter 公布成果。
假設：
700 件屬於一般低風險客服。
200 件屬於較複雜問題。
100 件屬於：
退款。
付款。
特殊補償。
資料衝突。
原本所有 900 件 AI 可處理或協助的案件：
全部使用同一個較高成本模型。
現在改成：
700 件走 A 路。
200 件才走 B 路。
最後的 100 件：
AI 只整理背景。
人決定。
要怎麼算到底有沒有省？
不要直接說：
「便宜模型省 70%。」
應該把自己的實際數字帶進來。
例如 A 路：
每件模型成本。
人工修改時間。
Fallback 比例。
B 路：
每件模型成本。
人工修改時間。
再加：
100 件人工案件的整理時間。
最後算：
每件完成客服的總成本。
一個示範計算
假設只是示範：
原本平均每件客服：
AI 成本 0.06 美元。
人工檢查 2 分鐘。
改成分流後：
A 路 700 件：
平均 AI 成本 0.015 美元。
人工檢查 45 秒。
B 路 200 件：
平均 AI 成本 0.08 美元。
人工檢查 2.5 分鐘。
C 路 100 件：
AI 只做初步整理。
最後人處理。
這時不能只看：
A 路變便宜很多。
真正要把三路：
一起加總。
還要把失敗與重試算進來
假設：
A 路有 5% 需要 Fallback。
那 5% 的案件：
成本可能比正常案件高。
也可能多花時間。
所以真正平均成本應該把：
成功。
Fallback。
人工修改。
全部一起算。
再加一個「成本煞車」
Agent 或自動化最大的成本風險之一：
不是一通電話很貴。
而是：
它一直跑。
例如：
主模型錯。
重試。
切 Provider。
再錯。
切備援。
又重新產生。
如果沒有邊界：
一個案件可能跑很多次。
所以正式上線前設定：
單一案件最大重試次數。
單一案件最大模型成本。
每日或每月使用預算。
超過：
停止。
不要再自動追。
OpenRouter 本身已有預算與 Guardrail 能力
OpenRouter 目前提供 Guardrails，可限制：
可使用模型。
可使用 Provider。
預算。
資料政策。
企業 Workspace 也能進一步設定不同期間的支出上限。
這家公司不把它當：
月底才看的報表。
而是：
真正的系統煞車。
例如客服 Workspace
只允許：
經公司測試的模型。
經公司允許的 Provider。
設定：
每日預算。
再把付款與高風險資料：
放在更嚴格的資料規則之外。
這比 Prompt 裡寫：
「請不要花太多錢。」
可靠得多。
敏感資料也不要因為方便就全部送進模型
跨境電商客服可能碰到：
Email。
姓名。
電話。
地址。
甚至付款資訊。
OpenRouter 目前提供 Sensitive Info Guardrail，可以在 Request 到達模型 Provider 前：
偵測部分敏感資訊。
選擇：
遮蔽。
或阻擋。
但這也不能被理解成：
開了就永遠不會漏個資。
因為偵測本身也有能力邊界
例如規則型資料：
Email。
電話。
信用卡格式。
相對容易偵測。
姓名與地址這類需要語境判斷的資料：
本身就可能存在漏判。
所以更好的設計還是：
工作不需要的敏感資料，一開始就不要送。
例如問商品保養
根本不需要：
完整信用卡號。
完整住址。
付款紀錄。
就不要把整筆 Customer Record 一起丟給模型。
這就是：
最低資料原則。
一般客服真正需要的資料其實很少
例如：
商品名稱。
規格。
官方 FAQ。
訂單狀態。
配送規則。
如果足夠回答：
就只提供這些。
不是因為 OpenRouter 可以串很多模型：
就代表每一個 Provider 都應該收到整份客戶資料。
正式退款的流程完全分開
客戶要求退款。
AI 可以做：
整理原因。
找訂單。
找已確認退貨政策。
指出需要確認的資訊。
然後停止。
接下來：
客服或主管確認：
是否符合規則。
退款多少。
採取什麼補償。
真正執行金錢操作。
正式補償也一樣
例如客戶收到刮傷皮包。
AI 可以整理：
照片。
訂單。
商品價格。
過去溝通。
但：
補發新品。
折價。
退多少錢。
這些會直接改變公司成本與客戶權利。
所以：
人核准。
多語翻譯也不能直接等於正式承諾
例如 AI 把：
「我們會盡快確認。」
翻譯成：
「我們保證明天寄出。」
這就是問題。
所以正式對外內容至少還要檢查：
價格。
日期。
退款。
賠償。
保固。
交期。
這些承諾字眼。
第一階段甚至不用讓 AI 自動寄出
最安全的版本可以是：
收到客服。
↓
分類。
↓
路由。
↓
AI 產生草稿。
↓
三層驗收。
↓
一般低風險案件才進人工快速確認。
↓
寄出。
等一段時間確定：
真的很穩。
才考慮把極低風險 FAQ 進一步自動化。
第一個月不要追求「自動化比例最高」
追求：
哪些案件最適合交給 AI。
假設最後只有：
60%。
真的能穩定省時間。
比：
95% 全自動。
但每天一直返工、退款出錯。
好得多。
可以直接使用的 OpenRouter 商業流程 Prompt
你是我的跨境電商 AI 客服路由顧問。
我要使用 OpenRouter 或其他多模型 Gateway。
公司客服工作包括：
[列出工作]
目前每週案件：
[數量]
可使用的公司資料：
[FAQ／產品資料／訂單／物流／其他]
請替我把客服分成三路。
第一路：高頻低風險
條件：
答案有正式資料來源。
做錯容易發現。
不涉及金錢與正式承諾。
替這一類設計：
主要模型策略。
1 個備援模型。
Provider Routing 原則。
固定輸出格式。
自動驗收條件。
第二路：複雜但仍可由 AI 協助
例如：
多條件客訴。
多語訊息。
長篇內容。
多份資料比較。
替這一類設計：
較強模型策略。
必要資料。
驗收條件。
什麼情況必須停止。
第三路：轉人工
只要涉及：
退款。
補償。
付款爭議。
價格修改。
正式折扣。
合約。
客製訂單正式變更。
資料衝突。
身份無法確認。
其他不可逆或高風險操作。
一律停止。
不要透過不斷更換模型繞過人工確認。
另外替每件工作設計三層成功標準：
一、服務成功。
二、格式成功。
三、商業結果成功。
只有三層都通過，才允許進入下一步。
再建立 KPI：
每件總模型成本。
一次可直接使用率。
人工修改分鐘。
Fallback 比例。
轉人工比例。
錯誤率。
並設定：
單件最大重試次數。
單件最大 AI 成本。
每日或每月總預算。
如果可以從輸入資料中移除不必要的：
姓名。
Email。
電話。
地址。
付款資訊。
請列出應先遮蔽或不要送進模型的欄位。
最後只給我：
第一版最值得上線的三種客服。
第一個月不應自動化的三種客服。
不要為了提高自動化比例，把高風險工作硬塞進 AI。
什麼時候應該換掉主模型？
不是看到：
新模型排行榜比較高。
就換。
先看自己的紀錄。
例如最近一個月：
主模型使用 10,000 次。
Fallback：
只有 1%。
人工修改：
很低。
成本也合理。
其實沒有急著換。
反過來：
如果主模型：
經常失敗。
人工一直修改。
簡單工作成本太高。
這時才值得重新測試。
什麼時候備援模型其實不合格？
如果技術上每次都能回覆。
但：
輸出格式常錯。
Tool Calling 不穩。
分類經常不同。
人工修改時間明顯增加。
就算它：
「Fallback 成功率很高。」
仍然可能不是好的 Backup。
因為真正要備援的是：
工作能力。
不是只有：
API 會說話。
這家公司最後真正要看的三個數字
如果只能選三個：
第一
每件可用客服總成本。
不是 Token 單價。
第二
一次可用率。
AI 第一版成果有多少真的能用？
第三
人工修改時間。
AI 到底替人省了多少？
這三個數字比：
用了幾個模型。
API 成功幾次。
更接近商業價值。
今天最容易犯的錯
看到 OpenRouter 可以使用大量模型。
就設計：
簡單問題一個。
難題一個。
翻譯一個。
摘要一個。
客訴一個。
每種語言再一個。
最後整套系統：
沒有人知道工作到底去哪裡。
第一版不需要這麼複雜。
這家公司甚至只要：
一個低成本主力。
一個高能力模型。
一個備援。
一條人工出口。
就足夠開始。
今天最重要的商業判斷
OpenRouter 對一家小型跨境品牌真正有價值的地方：
不是可以炫耀：
「我們用了很多種 AI。」
而是把原本所有工作：
都丟給同一個模型。
改成：
簡單工作，不浪費高階模型。
困難工作，才使用更強能力。
服務故障，才啟動備援。
資料缺失，不靠模型猜。
涉及錢與客戶承諾，直接交給人。
然後每一件工作都必須通過：
服務。
格式。
商業結果。
三層驗收。
當一家公司真的知道：
哪類工作要花多少模型成本。
哪個 Backup 真的可靠。
多少結果需要修改。
什麼事情應該直接停。
OpenRouter 才不只是：
「讓你可以換很多模型的 API。」
而是開始變成：
一套管理 AI 工作成本、穩定性與風險的路由層。
真正成熟的多模型策略不是：
模型越多越好。
而是：
每一件工作都知道為什麼走這條路，而且走錯時知道在哪裡停。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 商業案例｜2026/08/11：6 人戶外旅遊公司怎麼用 LiteLLM？一般詢問走低成本模型、故障切備援，付款與行程變更直接轉人工
AI 商業案例｜2026/08/10：8 人線上課程平台怎麼用 Langfuse？從學員客服成本、人工修改到真正解決率，找出值得留下的 AI 流程
