評估與品質 · 實作指南
讓助手有用地說不知道
承認不知道的下一步，應像正常工作一樣有負責人與流程。
定義無法回答的狀態
找不到、內容矛盾、資料過期與沒有權限，是不同結果，需要不同回應及分流。文件只是超出某員工權限時，不應說它不存在；但訊息亦不能透露敏感文件細節。目的在於尊重證據與角色限制，同時告訴員工下一步可做甚麼。這些狀態應在設計時確認，不要等助手第一次答錯後，才臨時補上一句「請聯絡管理員」。
提供具體下一步
在假設的導入助手中，缺少流程可以建立內容負責人的任務，客戶名稱不明確則應要求澄清。如有正式人工程序，提供連結。泛泛道歉只會讓使用者重新開始，並沒有改善服務。交接給人員時，保留足夠問題背景，讓同事不必重問，但工單不應收集超過處理需要的客戶資料。也要說明由誰接手及如何追蹤進度。
流程一覽
同時測試拒答與過度拒答
全部拒答的系統容易顯得謹慎，卻沒有實際用途。建立成對測試：一題證據充分，另一題只缺少一個關鍵事實而不能直接回答，交由業務審核者判斷。同時記錄不必要升級與無依據答案。平衡點取決於決策後果及人工接手速度，不能只為追求某個模型分數。若同事經常可以立刻找到答案，應查明助手為何過度拒答。
把不確定性變成改善清單
把未解決問題按原因分類，先改善最有價值的缺口。有些需要補文件，有些需要改善檢索，有些只是介面未問清楚。模型缺少公司知識，不代表應立即微調。來源中的評估與風險管理資料提供背景，本文建議則是一套可維護的不確定性流程：指定負責人、處理目標與回饋環節。若沒有解決去向，拒答只會把工作推回員工身上。
檢查人工接手能力
估算指定團隊實際能處理多少未解決問題。預期數量超出能力時，應縮小助手範圍或先改善接收流程。技術上謹慎的系統，若把所有疑問變成沒人有空處理的工單，仍會損害服務品質。試點應記錄等待時間、重複查詢與放棄情況，讓人員容量成為設計條件，而不是最後才發現的瓶頸。
來源與延伸閱讀
編輯原則
本系列以 AI 輔助原創撰寫，並對照連結的公開來源。實作建議與假設情境屬編輯分析，並非客戶實績。來源發布日期及產品細節可能與本系列整理日期不同。