AI 客服最容易從 FAQ 起步，也最容易在接上訂單、退款和會員資料後迅速增加風險。它能回答「多久出貨」不代表能判斷某張訂單是否延遲；能查訂單也不代表應該替任何輸入 Email 的人顯示地址。
導入前把能力分成公開知識、登入後查詢、需要核准的動作與禁止事項，逐層開放。
公開知識先建立唯一來源
配送、退換貨、付款、保固、尺寸與聯絡方式要有正式頁面、market、版本、owner 和生效日。AI 只使用核准資料，回答附上可閱讀來源。若政策依商品、地區或促銷不同，資料需包含條件，不能讓模型自行拼接。
網頁更新後確認 index 或 retrieval 何時同步。舊政策要下架或標記失效，避免搜尋同時取回兩個答案。沒有資料時直接說明並轉人工，比生成一個合理答案安全。
訂單查詢需要身分與最小權限
顧客登入後才能查看自己的訂單、履約、退款與配送狀態。若使用訂單編號加 Email 驗證，評估猜測、共享信箱和資訊洩漏風險；高風險資料或動作增加一次性驗證。客服 App 僅申請必要 scope，服務端保管憑證。
回覆只呈現完成任務所需資訊。不要把完整地址、付款細節、內部風險標記和客服備註交給模型。Log 需遮蔽個資，保存期間和存取角色也要明確。
查詢與動作分成兩條路
「我的包裹在哪」是查詢；「取消訂單」「改地址」「退款」會改變商業狀態。動作前重新顯示訂單、金額、條件與後果，要求明確確認，完成後回傳可查證的結果。超過時限、已履約、部分退款或高金額一律轉人工。
不要讓模型直接組任意 Admin API 呼叫。用允許清單包裝固定工具，server 端再驗證身分、訂單 ownership、參數與政策。每次動作記錄 request、tool、結果、錯誤和 actor。
轉人工條件要具體
顧客要求真人、連續兩次無法回答、來源衝突、付款與詐欺、傷害或安全、法律要求、敏感個資、負面情緒升高和系統錯誤，都應立即轉接。轉接時把已確認資訊與引用來源交給客服，顧客不必重說一遍。
營業時間外說明預計回覆方式，不假裝真人在線。若沒有即時人工服務，提供 ticket 編號與可追蹤管道。
建立真實問題評測集
從去識別的客服紀錄整理高頻、長尾、拼字、繁簡、混合語言、例外政策和惡意提示。每題定義可接受答案、必要來源、禁止內容與是否轉人工。按 market、商品與顧客狀態測試，不能只用理想 FAQ。
指標包含正確、完整、來源有效、拒答適當、轉接成功、工具錯誤、解決率、重複聯絡和顧客回報。自動評分可協助篩選，重大流程仍由人抽查。
上線採只讀與小流量開始
第一階段只回答公開知識；第二階段在登入後提供訂單只讀資訊；最後才考慮低風險、可回復動作。每次擴權都更新威脅模型、測試、客服訓練和 rollback。資料結構可參考 商品資料供 AI 使用。
監看來源命中、無答案、API error、延遲、人工接手與個資事件。供應商、prompt、模型、知識或政策更新都要留版本，品質突然下降時才能找出變更。
準備事故處理
錯誤優惠、錯誤退款、個資外洩或大量誤答發生時，先關閉相關工具或回到純 FAQ，保存 log 並確認影響範圍。修正公開政策、受影響訂單與顧客溝通，再用相同案例做回歸。
讓顧客知道互動邊界
對話開始時清楚說明這是 AI 助理、可處理哪些問題、資料如何使用，以及怎麼找真人。不要用真人姓名、照片或「正在為您查詢」等話術掩飾系統身分。顧客詢問來源時，提供政策或訂單狀態的可讀證據。
若會保存對話改善服務，需依市場和 consent 規則說明。拒絕提供資料的顧客仍應能使用一般客服或自助查詢，不能用同意訓練作為取得訂單支援的交換條件。
對客服團隊保留控制權
真人接手後能查看 AI 已做的查詢、引用、工具結果與不確定點，也能修正錯誤標籤。AI 不應在背景繼續對同一顧客發訊息，handoff 狀態由單一系統控制。客服修正回到知識 owner，不只留在私人備註。
每週回顧被轉接最多的問題、無來源回答和重複聯絡。若某類問題本質上需要判斷或協商，就保留真人處理，不以自動化率要求 AI 強行回答。
AI 客服是否成功，不能只看少了多少人工 ticket。回答可靠、顧客知道何時面對 AI、敏感動作有保護，而且真人能順利接手，才是可長期運作的 Shopify 客服流程。