先把回覆拆成三種責任
客服自動化常見的錯誤，是把完整對話直接交給大型語言模型，要求它產生一段看似合理的回覆。這種做法在展示時很流暢，進入正式營運後卻容易混淆三件事：企業允許怎麼說、目前有哪些可用事實，以及這則訊息能不能直接送出。較穩定的設計，是把流程拆成模板、檢索與真人確認三層。
模板定義語氣、必要欄位、免責文字與可做出的承諾；檢索從訂單、CRM、ERP、知識庫或產品文件取得當下資料；真人確認則依風險決定是否放行。模型的角色主要是分類需求、整理資訊與組織語句，而不是憑記憶決定退款規則、交付日期或帳戶狀態。
- 適合模板：收件確認、補件通知、維護公告、固定作業說明。
- 適合檢索後生成：產品操作、方案差異、訂單進度與跨系統狀態說明。
- 需要真人確認：退款、報價、合約解釋、個資揭露、權限異動與例外承諾。
模板要限制承諾，不要限制所有語句
模板最有價值的地方，不是讓每封信長得一樣，而是固定不能出錯的部分。例如退款回覆可以固定申請條件、處理程序與必要提醒，再讓模型依客戶問題調整開頭和說明順序。如果整段文字都鎖死，客服人員會為了處理例外而繞過系統；如果只留一個空白提示詞，模型又可能生成超出政策範圍的承諾。
模板中的變數應標示來源與驗證規則。訂單狀態必須來自訂單系統，付款資訊必須來自授權服務，日期則要區分預估、排程與已確認。必要欄位缺失時，流程應停止或改成索取資料的安全回覆，而不是讓模型猜測。模板也需要版本、適用通路、產品範圍、語言與生效日期，否則 LINE、電子郵件和網站客服可能長期使用不同政策。
工程上可把模板視為可測試的業務規則：用正常資料、缺漏資料、過期資料與衝突資料測試輸出，並檢查禁用詞、必要揭露和連結。這比只評估文字是否自然，更接近真正的營運風險。
檢索的重點是來源、權限與拒答
RAG 並不會自動讓答案正確。知識庫若混有舊版手冊、內部草稿與不同產品線文件，模型仍可能引用錯誤內容。文件匯入時應保留產品、版本、生效日、地區、客戶層級與文件擁有者等中繼資料；檢索時先用權限與適用範圍過濾，再進行語意搜尋。對 ERP 或 CRM 等結構化資料，通常應透過受控 API 查詢，而不是把定期匯出的表格當成即時事實。
回覆流程還要處理沒有答案與答案衝突的情況。當檢索不到有效來源、文件彼此矛盾，或客戶問題超出授權範圍時，系統應明確降級為補問、轉人工或保守回覆。設計拒答條件，往往比持續調整提示詞更能降低錯誤承諾。
每次生成應記錄使用的文件識別碼、版本、查詢條件與系統資料時間戳。審核介面最好直接顯示支撐答案的片段，而不是只附一串連結。這讓客服能快速確認事實，也讓工程團隊在出錯時判斷問題來自資料、檢索排序、提示詞還是模板規則。
真人確認要依風險分流，並形成可用回饋
並非所有訊息都值得逐封審核。低風險且可由單一可靠來源驗證的內容，例如案件已受理或文件已收到，可以考慮自動送出；需要解釋產品或整合狀態的回覆，可先產生草稿供客服確認；涉及金額、法務、隱私、帳戶權限或非標準承諾的內容，則應強制由具權限的人員核准。分流條件應寫成明確規則，不能只依賴模型自行評估信心。
有效的審核畫面應同時呈現客戶原文、建議回覆、引用來源、關鍵系統欄位與風險提示，並標出模型新增的日期、金額、承諾和操作指令。審核者需要能快速修改，也應能選擇修改原因，例如來源過期、語氣不當、政策不符或缺少上下文。若只記錄核准與退回，後續很難知道該改善模板、資料還是分類器。
導入時可先選範圍清楚、來源穩定的需求，採草稿模式觀察人工修改，再逐步開放低風險自動發送。評估不只看回覆速度，也要追蹤轉人工原因、重新開啟對話、來源缺失、錯誤承諾與審核耗時。成熟的客服自動化不是追求取消人工，而是讓人工集中處理真正需要判斷的部分；若牽涉多個既有系統，及早由整合團隊釐清資料責任與放行規則，通常能避免後期反覆補洞。