你的 AI 客服有 95% 的回答看起來很好，但剩下 5% 會報錯退款條件；這個產品能上線嗎？答案取決於那 5% 能否被系統攔住，而不是平均回答有多自然。
AI 產品設計模式的目標，是把模型的不確定性限制在可觀察、可復原的範圍。下面六種模式不綁特定框架，從單次問答到會操作工具的 Agent 都適用。
模式一：Schema First，先定義產品契約
只要模型輸出會進入資料庫、畫面元件或下一個 API，就先定義 JSON schema，再驗證每個欄位。不要從一段自然語言用正則表達式硬抓金額、日期或狀態。
例如客服分類只允許三種結果：
{
"category": "refund | shipping | other",
"needs_human": true,
"reply": "string"
}Provider 支援 structured outputs 時用原生 schema；回到後端後仍要再驗證一次。欄位缺少、類型錯誤或值不在允許集合，就停止後續流程、有限重試或轉人工。詳細實作可搭配 Structured Output 指南。
OWASP 把未妥善處理模型輸出列為重要風險：若模型產生的 HTML、SQL、shell 指令或檔案路徑直接進入下游，可能演變成 XSS、SQL injection、路徑穿越或遠端執行。模型輸出要和使用者輸入一樣採零信任處理。
模式二：Grounding，讓答案附得出依據
公司政策、價格、庫存與最新資訊不應靠模型記憶回答。用 RAG 或受控工具先取得資料，再要求模型根據結果回答並附上文件名稱、版本或連結。
Grounding 的重點不只是「有向量資料庫」。你還要控制哪些資料可被搜尋、文件何時失效、同一政策有幾個版本，以及檢索不到時如何拒答。若回答引用不存在的段落，產品應視為失敗，不能因文字流暢就通過。
一個實用規則是把內容分成兩層：公開且可回答的核准知識，以及需要登入與權限檢查的個人資料。模型可以協助組織答案，資料存取權仍由後端決定。
模式三：Plan Then Approve，規劃和執行分開
會寄信、退款、刪檔或發布內容的 Agent，不應在同一步驟裡自行決定並立即執行。先讓模型產生結構化計畫，再由程式檢查權限、顯示具體影響，最後取得使用者或核准人的確認。
例如取消訂單前，畫面應顯示訂單編號、退款金額、受影響品項與不可復原結果。確認內容由受信任的後端資料組成，不要完全沿用模型產生的摘要。
OWASP 對 Excessive Agency 的建議很直接：只提供必要工具、縮小每個工具的功能與權限、避免開放式 shell／URL 工具，並在高影響動作前要求人工核准。授權檢查要在下游系統執行，不能問模型「這位使用者可不可以刪除」。
模式四：Task Routing，按任務選模型
不要把所有請求都送進最大模型，也不要讓模型用一句「我的信心是 92%」決定是否相信自己。路由條件應來自產品可觀察的訊號，例如任務類型、輸入長度、是否需要工具、資料敏感度與固定測試結果。
客服意圖分類可以用速度快的小模型；合約條款比較可用能力較高的模型；付款與醫療決策即使換成更強模型，也可能仍需人工核准。每條路由都要有自己的成功率、延遲與成本監控。
先保留一個模型完成 MVP，等流量與失敗案例足夠，再加入第二條路由。過早維護多家 Provider，往往會讓訊息格式、工具參數與錯誤行為變得更難測。
模式五：Bounded Failure，限制等待與損失
每個模型與工具呼叫都要有 timeout、重試上限與可預期的降級。429 或暫時性 5xx 可以指數退避；400、401、403 應直接修正請求或權限。涉及寫入的動作使用 idempotency key，防止網路重試把同一筆退款做兩次。
降級不一定是切換另一家模型。搜尋摘要失敗可以顯示原始結果；客服生成失敗可以回傳核准 FAQ；高風險流程則應暫停並建立人工案件。選擇哪種 fallback，要看錯誤答案與沒有答案哪個成本更高。
當供應商持續錯誤或延遲超標，可暫時打開 circuit breaker，停止送出更多請求並保護自己的佇列。系統恢復後先用少量流量探測，不要一次把積壓任務全部灌回去。
模式六：Eval-Driven Release，用測試決定上線
建立一份代表真實使用情況的測試集，包含正常案例、邊界、應拒答、提示注入、工具失敗與高風險動作。每個案例定義可驗證的通過條件；能用程式判斷的格式、引用和工具參數先自動評分，語氣與複雜正確性再抽樣人工審查。
換模型、prompt、知識文件、chunking 或工具 schema 都可能改變結果，所以這些變更都要重跑 Evals。OpenAI Evals API 也把評測建模為資料來源、測試準則與多次 run，核心觀念就是讓不同模型與設定在同一標準下比較。
離線測試通過後，用 shadow 或 canary 方式逐步上線。先讓新版本處理少量低風險流量，監控成功率、人工轉接、延遲與每次成功成本；沒有退步再擴大。不要在星期五傍晚把全站 prompt 一次換掉。
客服系統怎麼逐步套用？
第一版先做只讀 FAQ：RAG 找核准文件，模型產生帶來源的回答，找不到就轉真人。此時主要驗證 Grounding、Schema 與 Evals。
第二版加入會員查詢，但工具只能讀取目前登入者的必要欄位；工具參數先通過 schema 與權限檢查。第三版才加入取消訂單等寫入動作，而且走 Plan Then Approve、idempotency 與稽核紀錄。
這種順序讓每一次新增能力都對應一個明確風險控制。若第一版的文件版本仍然混亂，加入 Multi-Agent 或更強模型只會放大問題。
常見 Anti-Patterns
用模型自評信心當安全閘門
模型輸出的 0.92 並不是經過校準的保證。可以把自評當一個訊號，但正式決策應結合引用是否存在、schema 是否有效、工具結果與人工標註資料。
Prompt 裡重複寫「絕對不要出錯」
Prompt 可以定義行為，無法取代權限、輸出驗證與核准流程。禁止刪除的真正控制應在工具與資料庫權限，不應只靠 system prompt。
一開始就上 Multi-Agent
多 Agent 會增加呼叫次數、狀態、延遲與除錯路徑。只有任務能清楚拆分、單 Agent 已有穩定基準，而且平行處理能帶來可量測收益時，才值得採用。
把完整 Chain-of-Thought 當產品輸出
要求模型公開冗長推理過程不等於提高正確率，也可能暴露內部提示或產生看似合理的事後解釋。產品應要求簡短依據、來源與可驗證結果；複雜推理能力由模型與評測決定。
導入順序
先做 Schema First 與可觀察日誌，因為沒有穩定契約就無法量測。接著建立 Grounding 與 Evals，確認答案品質。只有當模型開始碰外部工具，才加入權限閘門與人工核准；當流量與成本真的成為問題，再做 routing、cache 與更複雜的 fallback。
這套順序也能避免「架構很漂亮、產品仍然答錯」的情況。每增加一個模式，都要能指出它降低哪種已觀察到的失敗。
常見問題
Human-in-the-Loop 會不會讓 AI 失去自動化價值？
不會。把人工放在高風險、低頻或模型不確定的節點，其他流程仍可自動化。好的 HITL 會顯示具體動作、依據與差異，讓核准者快速判斷，而非重新完成整個任務。
Fallback 一定要換另一家模型嗎？
不一定。依功能可回傳快取、核准模板、原始搜尋結果、排入背景工作或轉人工。另一家模型只有在同一測試集通過，而且資料與工具介面都符合要求時才適合自動切換。
多少筆案例才足以建立 Evals？
先從 30 到 50 個高價值與高風險案例開始，每次正式失敗就補進回歸集。案例是否代表真實流量，比單純追求龐大數量更重要；不同功能應有各自的通過標準。
參考資料
- OpenAI API：Evals
- OWASP：Improper Output Handling
- OWASP：Excessive Agency
- NIST：AI Risk Management Framework
準備動手實作時，可從 AI API 串接教學 建立 timeout 與日誌，再用 LLM 評估指南 做第一份回歸測試集。