你的產品依賴一個你控制不了的第三方服務
從 Fable 5 被禁談起：每個做 AI 產品的 PM，都應該知道自己的依賴風險在哪裡。
Fable 5 在 2026 年 6 月 12 日被美國政府下令停用。
從上線到禁令，三天。
我滑到這個新聞的時候，非常驚訝，因為如果我的產品正在用它，我只有三天的時間反應。
夠嗎？
WHY：為什麼這件事和你有關
這個看起來是政策問題、是 Anthropic 的問題，但實際上是PM的問題：你的產品能不能在三天內換掉一個核心依賴？
這不是極端情境。
第三方 API 關閉、供應商漲價、服務條款改變，每年都在發生。只是這次輪到 AI 模型，而且速度快到大多數人沒辦法反應過來。
WHAT：什麼是 Dependency Risk
在產品管理上有一個名詞，就是在定義這種事件：Dependency Risk（依賴風險）
是指你的產品依賴一個你無法控制的外部元件，一旦它出問題，你的產品跟著出問題。
傳統 vs. AI 模型
傳統第三方 API，你換一個，通常只是接口不同，功能差異小。但是換一個 AI 模型，是換掉整個「行為」。
輸出的語氣、準確率、格式、邊緣案例的處理方式，全部可能不一樣，因為這影響用戶體驗的核心判斷引擎。
AI Dependency 的五個層次
根據 TrueFoundry 的分析，AI 供應商依賴通常會累積在這五層：
每累積一層，切換成本就翻一倍。
真實的規模
根據 Zapier 的調查，74% 的企業表示，如果失去主要 AI 供應商，會立刻出現營運中斷或完全停擺。
更值得注意的是：89% 的主管「相信」自己能在一個月內完成切換，但真正試過的人裡面，58% 說切換失敗或遠比預期困難。
也許發生機率很小，但是我不願意冒這個風險，所以在看到這個消息以後，我安排團隊評估支援多 AI Model 的可行性。
HOW：PM 可以做什麼
知道你的產品的風險暴露程度，然後從最低限度的防禦開始往上加。
第一步：做一次依賴盤點
列出你的產品呼叫了哪些 AI 模型、在哪些功能上、有多核心。不需要精確，粗分三級就夠：
第二步：問工程師一個問題
「如果現在要換掉這個模型，最快幾天？」
不要問能不能換，問要花幾天，因為這個答案可以描述產品的風險暴露有多深。
第三步：決定你的容忍底線
也許不用每個產品都要支援多模型架構。但是你應該要知道：
- 我能接受幾天的中斷？
- 超過這個時間，我要提前做什麼？
如果你的答案是「零天，不能中斷」，那切換多模型功能就是一個應該排進 backlog
第四步：讓架構反映你的風險承受度
工程實作上，有幾個常見做法：
- 用 AI Gateway（LiteLLM、TrueFoundry 等）統一介面，底層模型可以替換
- 保持 prompt 的模型中立性，不要過度依賴某個模型的特殊語法
- 在非核心功能先試跑備用模型，讓工程師熟悉切換流程
FAQ
Q：Dependency Risk 只有 AI 產品需要注意嗎？
不。任何依賴第三方服務的產品都有這個風險。AI 產品特別值得注意，是因為模型行為難以複製，切換成本比一般 API 高很多。
Q：多模型架構會大幅增加工程複雜度嗎？
不一定要上完整的多模型架構。第一步只是讓介面抽象化，讓底層模型可以替換。這個改動通常不大，但能大幅降低未來的切換成本。
Q：PM 需要自己懂模型技術嗎？
不需要懂技術細節，但要能問對問題。「如果這個模型不能用，我們幾天內能切換？」這個答案會讓你知道現在的風險在哪裡。
Sources