下午四點，業務剛準備跟客戶確認報價，才發現自動化流程已把一封「缺少規格」的表單當成完整案件送進 CRM，還依舊版範本草擬了回覆。這種時候，真正需要的不是叫 AI 再試一次，而是讓它知道何時停下來、把哪一筆資料交給誰。

AI 工作流出錯時，第一個動作是什麼？

先停止會造成外部影響的下一步，保留現場資訊，再交由人判斷。

所謂「出錯」不只有系統跳出錯誤訊息。資料欄位空白、來源版本不明、同一客戶出現互相矛盾的需求，或工具回傳逾時，都代表流程不應繼續替公司承諾。比方說，Agent 可以把不完整的詢價標成「待補資料」，建立待辦並附上收到的原始內容；但不應自行猜測規格、寄出報價，或覆寫既有訂單。

這個停止點要在流程設計時先寫清楚：哪些情況只重試讀取，哪些情況必須通知人，哪些情況一律不可對外送出。NIST 的 AI Risk Management Framework 也強調以治理、量測與管理風險的方式使用 AI；對中小企業而言，先畫出停止點，就是把抽象原則放回每天的工作裡。

人工接手時，要交出哪些資訊才不會重做？

交接單應讓下一位同仁看懂「發生什麼、系統做過什麼、還差什麼」，而不是只收到一則失敗通知。

一筆待處理案件至少可保留案件編號、觸發時間、原始輸入、已查詢的資料來源與版本、已完成但尚未送出的動作，以及停止原因。這些欄位不必一次做成複雜平台；從共享案件清單或 CRM 的固定欄位開始，也能讓客服、業務與行政沿著同一筆紀錄接手。

接手人補齊資料或做出例外決定後，應把原因回寫到案件，而不是只在私訊中解決。下次流程遇到相同狀況時，團隊才有依據判斷該新增欄位、調整規則，還是繼續保留人工確認。翔懂AI關心的不是把每個判斷都交給模型，而是讓交接變得可追溯、可檢查。

可重複且不改變商業承諾的技術動作可以有限次重試；涉及資料意義或對外承諾的問題，必須轉人工。

例如，從已核准的知識庫讀取文件暫時失敗，可在設定間隔後重新讀取，並記錄每次結果；若仍失敗，就建立待辦。反過來說，客戶的交期、價格、退款或合約條款不一致，並不是多試幾次就能解決的技術問題，應由有權責的人確認。

設計時也要替「復原成功」定義條件。資料補齊後，是否需要重新跑完整流程？先前產生的草稿要不要作廢？同一筆案件能否被重複建立？這些問題先說明，才能避免兩位同仁各自處理同一客戶。若想從實際工作找出最常見的中斷點，可透過免費企業數智痛點評估整理流程與責任邊界。

定期回看例外類型，比追求一開始完全不出錯更實際。

可以每週挑出少量案件，觀察停止原因是否集中在同一個欄位、某個資料來源，或某項不清楚的規則。若「缺少產品規格」反覆出現，先改進表單或資料維護；若是工具權限不足，就釐清誰有權補救，不要把更高權限直接交給 Agent。

享飛數智股份有限公司與 FLYDI.AI 在討論落地流程時，會把自動完成、需要覆核與必須人工決定分開。對外網站若要把服務步驟與常見問答說得更清楚，可參考Schema.org 結構化資料規範整理語意；這能幫助搜尋系統理解內容，但不能取代內部的例外處理設計。更多協作方向可閱讀關於享飛數智。

不建議。應限制重試次數與範圍，並避免重複建立訂單、寄出多封通知或覆寫資料；超過門檻就交由人確認。

可以。先用所有相關同仁看得到的固定表單或案件清單，保留案件編號、狀態、接手人與停止原因；重點是資訊集中且可追溯。

應依工作需求、個資處理規範與內部資料保留政策決定。先避免記錄與處理無關的個人資訊，也要定期檢查不再需要的資料。

從想飛，到享飛。讓好想法真正落地，讓企業享受起飛。