最近我又被提醒一次：做 AI 自動化，最危險的不是模型不夠聰明，而是你太相信它今天會正常上班。
很多人做 AI workflow，腦中都還是傳統 API 的想像：選一個夠強的模型、把 prompt 調好、定時跑起來，事情就會穩穩發生。聽起來很合理對吧？但只要你真的把它放進每天固定產出的流程裡，很快就會發現現實不是這樣。
模型會限流、會抽風、會臨時額度不足、會回奇怪錯誤，甚至供應商今天心情不好，你的整條管線就跟著一起停擺。對使用者來說，他不會在意是 Anthropic、OpenAI 還是哪一家炸掉，他只會看到：「今天報告怎麼沒來？」
我最近重新整理一套 AI 例行報告流程，感受特別深。原本看起來只是幾個定時任務：時間到了，抓資料、整理脈絡、生成摘要、送到指定地方。架構圖畫起來甚至很漂亮。但真正進到每天都要準時出貨的狀態後，問題就不是「能不能生成」，而是「今天這一輪失敗時，要怎麼不要讓整套系統跟著一起死」。
單一模型不是核心，完成任務才是核心
這個觀念我以前其實也知道，但知道跟真的把它落進系統，是兩回事。
很多 AI 工具的設計，本質上還是「模型中心」：
- 我主要用哪個模型？
- 這個模型擅長什麼？
- token 成本多少？
- 回答品質比較好嗎？
這些問題都重要，但如果你的場景是每日報告、定時摘要、例行巡檢、通知生成，那真正該放在最前面的問題其實是：
- 這份輸出今天一定要產生嗎？
- 允許延遲多久？
- 如果主模型掛掉，哪個次佳模型可以接手？
- 品質下降時，最低可接受線在哪裡？
也就是說，系統的核心不該是「維持某個模型的純度」，而是「確保任務完成」。
這句話講起來很像廢話，但很多團隊真的會不小心把自己綁死。因為大家都想追最好的答案，所以流程會慢慢演變成：只有 A 模型能跑、prompt 也只針對 A 優化、輸出格式也偷偷依賴 A 的語氣。結果一旦 A 模型當天失常，整條 workflow 就像被拔掉總電源。
說穿了，這不是 AI 問題，是典型的單點故障設計。
AI 流程裡，失敗不是例外，是日常輸入
以前做系統時，我們很習慣把 failure 當 exception。也就是說，正常流程先寫好，錯誤處理最後再補。
但 AI workflow 很不一樣。你如果把失敗當例外，它最後一定會變成你的主流程。
我現在比較接受的思路是：
flowchart TD
A[定時任務觸發] --> B[收集資料]
B --> C[嘗試主模型]
C -->|成功| D[輸出報告]
C -->|失敗/限流| E[切換備援模型]
E -->|成功| D
E -->|仍失敗| F[降級輸出]
F --> G[送出最小可用結果與告警]
這張圖看起來很樸素，但重點在於：失敗不是流程旁邊的小支線，而是正規分支。
我現在看 AI 任務，會先分三層：
- 主路徑：最佳品質輸出
- 備援路徑：可接受品質輸出
- 降級路徑：至少不要靜默失聯
只要這三層先想清楚，整體穩定性就會比你狂修 prompt 有感得多。
備援不只是換模型，還包括降規格
很多人講 fallback，只想到「主模型失敗就換另一個模型」。這當然是第一步，但還不夠。
因為模型切換之後，常常會連帶出現其他問題：
- 輸出格式沒那麼穩
- 推理深度不同
- 語氣風格不同
- 成本變高或速度變慢
- 某些工具調用能力不一致
所以真正成熟的備援，不該只有 provider fallback，還要有任務降級策略。
例如一份報告原本想做得很完整，包含：
- 多來源資料交叉整理
- 結構化段落
- 風險標註
- 額外評論
但如果主模型掛了，備援模型也比較弱，那就不要硬撐同樣規格。你應該直接切成：
- 保留關鍵事實
- 保留最重要判讀
- 拿掉花俏修辭
- 拿掉可有可無的延伸段落
這種設計心態很像做 distributed systems：當資源緊張時，不是要求每個元件照舊表現，而是讓整體服務維持可用。
AI 也是一樣。與其追求「每次都完美」，不如先確保「今天至少交得出來」。
監控指標也要改：不是只看成功率
另一個我最近更有感的點是，AI 流程的監控不能只看 success / fail。
因為有些任務 technically 成功了，但實際上已經爛掉。
例如：
- 任務有跑完，但內容空洞
- 有產出，但格式不符
- 有摘要，但重點全漏
- 延遲太久，等於錯過使用時機
所以如果你真的把 AI 放進營運流程，我會建議至少盯這幾種訊號：
- 是否準時完成
- 是主模型完成，還是 fallback 完成
- fallback 發生頻率是否升高
- 是否進入降級輸出
- 最終輸出字數、結構、關鍵欄位是否完整
重點不是把 dashboard 做得多華麗，而是讓你知道：系統是不是正在悄悄變差。
很多 AI workflow 最可怕的地方，不是突然全掛，而是「表面還活著，但內容品質已經慢慢腐爛」。
技術主管該盯的，不只是模型能力，而是可營運性
我現在愈來愈覺得，AI 導入真正困難的地方，不是 demo 做不出來，而是做出來之後要不要敢接到日常流程上。
demo 階段大家都很興奮，因為效果很驚艷。但一旦進入 daily operation，評分標準就完全不一樣了：
- 今天有沒有準時出來
- 出來的東西能不能直接用
- 出問題時是不是有人知道
- 短暫失敗時能不能自己恢復
這時候你需要的不是更華麗的 prompt engineering，而是比較土、但真的有用的工程紀律：
- 明確的 fallback 順序
- 可接受的降級策略
- 任務完成導向的設計
- 失敗可觀測、可追蹤、可回補
說得直接一點，AI 導入到後面，拚的其實不是魔法感，而是工程感。
結語：把失敗寫進設計裡，系統才會真的成熟
我以前也會期待找到那種「夠強、夠穩、夠便宜」的完美模型，然後整條流程都靠它撐住。現在回頭看，這種想法有點天真。
模型永遠會變，供應商永遠會出狀況，價格、額度、政策也都可能改。真正能留下來的，不是你今天押對哪一匹馬，而是你有沒有把系統設計成：就算馬今天跌倒，車還是能想辦法往前滑一段。
如果你最近也在把 AI 接進每日報表、通知、摘要、巡檢這類流程，我很推薦先別急著再調 prompt。先問自己一句：主模型今天掛了，這套東西還剩下什麼？
如果答案是「整個沒了」，那你現在最該補的，可能不是模型能力，而是系統韌性。
如果這篇剛好幫你少踩一個凌晨報告沒出的坑，那我這次重新檢查整條流程的焦慮，至少就沒有白費了。