為什麼 AI 項目卡在 Demo 和生產之間

上線之前，先說明失敗後業務怎麼繼續

展示通常沿著準備好的輸入走完一條路徑。真實服務還會遇到依賴逾時、壅塞、重複點擊、使用者取消和資料更新。把這些情況寫進業務驗收，比先承諾某個上線週期更有價值。準備上線的範圍應說明誰使用、允許什麼動作、何時轉人工，以及誰有權暫停服務。

說明用假設例子，非真實客戶案例或容量承諾。 假設一個內部助理查詢知識庫後建立售後工單，試點從 5 位使用者擴大到 50 位。邏輯任務 task-42 已在工單系統建立記錄，但回傳途中斷線。使用者看到逾時後再次點擊，隨後又點取消。如果系統把每次點擊都當成新任務，可能建立重複工單；即使取消按鈕變灰，外部記錄也不一定被撤回。

用一次失敗，把依賴鏈拆出來

為這條流程畫出身分服務、知識索引、模型、任務佇列和工單系統。沿同一個任務編號記錄排隊等待、每段呼叫耗時、重試、版本和最終狀態，日誌盡量不儲存原始客戶內容。先查請求停在哪段，再決定修模型、連線、配額還是業務流程。

出問題的環節	應診斷什麼	業務應如何繼續
身分或權限服務不可用	身分是否仍可確認，權限是否過期	不能確認權限就停止受保護操作，不預設放行
索引更新失敗	來源文件與索引版本是否對應	暫停依賴新資料的回答，提供人工核對
模型限流或不可用	配額、並行、等待與重試是否疊加	有限排隊／退避，超出任務期限後清楚轉交
工單寫入結果未知	是否已產生外部記錄	先查狀態，不直接再建立
突發請求積壓	佇列年齡、在途任務和最慢依賴	限流、拒絕或延後新任務，不無界排隊

從 5 到 50 位使用者不等於簡單乘算模型容量：一個任務可能有多次呼叫，重試也會占資源。用代表性並行和慢依賴演練排隊、取消、成本及失敗行為，先確定允許的佇列與任務時限，再決定放量。

重試、重複與取消是不同的問題

給同一邏輯意圖分配穩定任務編號，重試沿用相同的冪等識別，並儲存請求摘要和結果狀態；不能只按提示詞文字去重，否則合法的相似請求也可能被壓掉。若外部系統支援冪等，應核對其範圍與有效期；不支援時，用狀態查詢、受控序列或人工核對降低重複風險，不能宣稱實現無條件「恰好一次」。

逾時只說明用戶端沒有及時拿到結果，不表示外部操作沒發生。task-42 應先查詢已建立記錄，再決定回傳原結果或補償處理。有限重試和退避的原則可參考 AWS 關於逾時與重試的說明。

取消應區分停止等待、停止後續步驟、請求上游取消，以及撤銷已完成的外部動作。儲存 cancel_requested 後仍要處理遲到結果；無法確認完成或取消時記錄 unknown，進入核對佇列。已建立工單需要單獨的關閉或補償流程，不能因為介面顯示取消就假裝從未寫入。

資料更新與回復都要有邊界

版本記錄應涵蓋程式、模型、提示詞、索引、權限政策和工具結構。資料負責人核准更新後，驗證新版本已入庫、舊快取失效、引用可存取，再重新執行受影響樣本。切回舊程式時不能順帶恢復已撤回的權限或失效政策；必要時先關閉受影響功能。

模型備援也要核對處理地區、費用、工具參數和回答行為。沒有核准的替代路徑，就明確提示稍後再試或轉人工。撤回發布之前，應說明在途任務如何暫停、排空或核對，不能只切回頁面或提示詞；外部副作用由其責任人另行處理。

發布評審可以直接複用的門檻清單

• 業務負責人： 確認允許情境、人工備援和失敗提示，先開放唯讀，再按驗收決定是否增加建議或寫入。
• 資料與安全負責人： 確認版本、權限、日誌和處理邊界；撤權失效、越權讀取或未經確認的寫入應阻止放量。
• 技術負責人： 演練依賴故障、重複、取消、遲到回呼與容量不足，提供任務狀態和核對證據。
• 維運負責人： 事先寫明暫停條件、可還原版本、開關與回復步驟，明確在途任務及外部記錄的處理人。
• 共同驗收： 約定品質、等待、費用和資料更新門檻；任何關鍵項沒有負責人或可複核結果，就繼續限制試點範圍。

上線決定應來自這些證據和責任安排，不來自「已經跑通」或固定天數。逐步擴大使用，才有機會在故障影響仍可控制時修正流程。