假設一間美國展覽服務公司嘅人工智能助手，提交工作單之後收到錯誤。工作人員見到一句自然語言說明，自動化程式就要判斷，應該補資料、搵負責人，定係等服務恢復。呢個係虛構嘅問題分流練習，唔係真實事故。如果系統淨係睇失敗兩個字，或者由模型靠語氣估下一步，流暢嘅解釋就可能掩蓋錯誤動作。

互聯網標準九四五七，為網絡介面提供問題詳情格式。當中類型欄位標示問題類別，詳情欄位解釋今次發生嘅情況；規範唔建議程式解析詳情欄位去攞決策資料。我哋建議將穩定類別交畀已審核嘅處理規則，再由人工智能用易明嘅說話解釋結果，唔好將會改動嘅文案當成控制開關。

Microsoft Graph 用自己嘅錯誤物件：代碼欄位可以畀程式判斷，訊息欄位就係畀開發者睇嘅說明，內容可能會變，唔應該當成程式依賴，亦唔應該直接畀用戶睇。呢點唔代表所有服務都有同一個結構。先按每個介面嘅文件做好配接，再將認得嘅類別交畀業務流程；唔識嘅類別就交由人手核對。

練習入面，可以將欠缺工作單日期交返去補資料，將權限不足交畀授權負責人。呢啲係我哋建議嘅業務對應，唔係狀態碼自動賦予嘅權利。人工智能唔可以因為讀到權限錯誤就提升權限，亦唔可以將所有錯誤都變成重試。保留原始回應所需嘅證據，再講清楚邊啲已確認，邊啲仲未知。

我哋建議面向客戶嘅提示要講清楚下一步，例如請補充活動日期，再重新提交。內部例外堆疊、權杖同私人內容，唔應該隨手貼入提示。互聯網標準九四五七提醒設計者，留意錯誤訊息洩露實作細節嘅風險。有用嘅解釋應該幫人恢復工作，唔係將全部除錯輸出都交畀用戶。

準備虛構錯誤樣本：穩定代碼保持不變，淨係改英文措辭或者換成中文，處理路線應該一樣。之後加入未知代碼，確認唔會自動執行危險動作。記錄比對規則、解釋文字同人手處理入口。呢個係建議驗收實驗，未喺客戶系統運行。目標係可以解釋嘅問題分流，唔係令每次錯誤訊息聽落更加有信心。