系統整合 · 實作指南
AI 工作流程重試，如何避免多建一張訂單
用操作紀錄區分業務意圖與網絡重試，避免把重送當成新訂單。
先問這是不是同一項業務意圖
假設一個訂單接收試點：背景工作已建立訂單，但回應途中斷線；再次執行的模型又建議新增，客戶其實只要求一張。建議在呼叫模型之前，先為這項業務操作建立識別碼，重試沿用同一碼。不能只憑相同文字或金額判斷重複，因為客戶也可能真的要求兩張內容相同的訂單。操作意圖應來自已確認的請求，而不是由模型重新猜測。
用紀錄表，不靠對話記憶
操作紀錄可保存所屬公司、意圖識別碼、已驗證參數、處理狀態與外部紀錄編號，狀態例如準備、提交、確認或待核對。可行時，識別碼保留和本地資料修改應在同一交易內完成。同一碼卻帶來不同參數時應暫停調查，不能默認後來的內容正確。紀錄不需要保存密碼或整段客戶私隱資料；保留足以核對業務結果的資料即可。
流程一覽
不確定時先核對外部結果
若目標系統支援冪等請求，應按其合約傳送操作碼，並核對保留期限。若不支援，先使用穩定外部參考號查詢結果，再決定是否重送。這不等於所有系統都能保證只執行一次；沒有唯一參考或查詢能力的目標，可能仍須人工確認。員工畫面要顯示待核對，避免另一位同事看到逾時便另外新增一次。
刻意測試成功後斷線
驗收時刻意模擬寫入成功後斷線、兩位員工同時提交、延遲重送，以及同一碼參數被改動。評估的不是成功回應數，而是有否多建業務紀錄、還有多少操作無法確認。AWS 與 Stripe 的文件提供冪等設計背景，本文的紀錄表和介面安排則是實作建議。每項待核對操作都應有負責人與處理期限，才不會長期積壓。
一頁驗收紀錄
訂單試點可保存一頁驗收表，列出操作身份、首次提交、模擬故障、外部訂單實際數量和核對負責人。與客戶一起檢查結果，不只交一份技術測試報告。另加一項反例：客戶確實要兩張完全相同訂單時，系統必須兩張都接受，不能為減少重複而誤刪合法業務。這能把技術去重與真實意圖分開，並讓雙方理解例外處理的界線。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。