營運與維護 · 實作指南
別讓 AI 根據錯誤資訊的語氣決定下一步
以穩定問題類別和已審核規則處理錯誤，讓 AI 解釋結果，保留未知情況的人工作業入口。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
一則錯誤資訊，為什麼有兩條處理路線？
假設一家美國展會服務公司的 AI 助手提交工作單後收到錯誤。工作人員看到一句自然語言說明，自動化程式卻需要判斷該補資料、找負責人，還是等待恢復。這是虛構問題分流練習，不是實際事故。若系統只看“失敗”兩個字，或讓模型憑語氣猜下一步，流暢解釋就可能掩蓋錯誤動作。
- 人員：理解發生什麼
- 程式：選擇已審核路線
- 模型：解釋，不自行授權
已接受的區域說明圖重繪，並非未經修改的原始截圖。
給機器穩定識別，給人清楚解釋
RFC 9457 為 HTTP 介面提供問題詳情格式，其中 type 識別問題類別，detail 解釋本次發生的情況；規範不建議程式解析 detail 來取決策資訊。[1] 我們建議將穩定類別送入已審核的處理規則，讓 AI 用易懂語言解釋結果，而不是把可變文案當作控制開關。
- type → 問題類別
- detail → 本次解釋
- 可變文案 ≠ 控制開關
已接受的區域說明圖重繪，並非未經修改的原始截圖。
供應商格式不同，不要硬套一個欄位
Microsoft Graph 使用自己的 error 物件：code 可供程式判斷，message 是開發者說明，內容可能變化，不應作為程式碼依賴或直接展示給使用者。[2] 這不等於所有服務都遵循同一結構。先按各介面文件建立配接機制，再把已辨識類別交給業務流程；未知類別進入人工核對。
- 先讀供應商文件
- 識別穩定代碼
- 未知類別 → 人工核對
已接受的區域說明圖重繪，並非未經修改的原始截圖。
同一句“無法完成”，不等於同一個動作
練習中可以把“缺少工作單日期”送回資料補充，把“權限不足”交給授權負責人。它們是我們建議的業務對應，不是狀態碼自動授予的權利。AI 不能因為讀到權限錯誤就提升權限，也不能把所有錯誤都變成重試。保留原始回應的必要證據，再說明已確認和仍未知的部分。
- 缺日期 → 補資料
- 缺權限 → 找負責人
- 失敗 ≠ 自動重試
已接受的區域說明圖重繪，並非未經修改的原始截圖。
解釋要有幫助，但不搬出內部細節
我們建議面向客戶的提示寫清下一步，例如“請補充活動日期，再重新提交”。內部例外堆疊、權杖和私人內容不應被順手貼進提示。RFC 9457 提醒設計者注意錯誤資訊暴露實作細節的風險。[1] 有用的解釋應幫助恢復工作，而不是把除錯輸出全部交給使用者。
- 說明恢復步驟
- 移除秘密與私人內容
- 內部除錯資訊另行保護
已接受的區域說明圖重繪，並非未經修改的原始截圖。
驗收時故意換一句話
準備虛構錯誤樣本：保持穩定代碼不變，只改英文措辭或換成中文，處理路線應保持一致；再加入未知代碼，確認不會自動執行危險動作。記錄比對規則、解釋文字和人工入口。這是建議的驗收實驗，未在客戶系統執行。真正的目標是可解釋的問題分流，而不是讓每次錯誤資訊聽起來更自信。
- 代碼相同，換措辭
- 處理路線應相同
- 未知代碼，不執行危險動作
已接受的區域說明圖重繪，並非未經修改的原始截圖。