AI 聊天機器人怎麼做？網站、LINE 客服架構與上線清單

你想做 AI 客服，先回答三個營運問題：它答錯時怎麼停、查不到時怎麼轉真人、需要改訂單時能碰哪些系統？ 模型選擇要等這三條邊界清楚後再決定。

對第一次導入的團隊，我建議先做只能回答問題的網站版，確認知識庫品質後，再接 LINE 或開放查訂單等動作。這樣可以把風險拆開，也比較容易知道問題出在內容、模型還是通路整合。

AI 聊天機器人的基本架構

一個可上線的客服 Bot，至少有五個部分：

1. 通路：網站聊天框、LINE Official Account 或 App。
2. 後端入口：接收訊息、驗證來源、限制流量。
3. 知識與規則：FAQ、產品文件、營業資訊、不可回答範圍。
4. 模型：根據檢索內容組織答案，資料不足時停止回答。
5. 真人與監控：處理例外、保留紀錄、找出答錯原因。

如果 Bot 只需要回答公開 FAQ，這個架構可以很輕。若它要查會員、修改地址或取消訂單，就必須再加入登入、權限、工具呼叫、操作確認與稽核紀錄。

Dify、自建 API 與 GPTs 怎麼選？

先用 Dify 驗證網站問答

Dify 適合快速建立工作流、串接知識庫並發布 Web App。它的好處是不用先寫完整前後端，就能測試文件切分、檢索與 prompt。第一版若只想知道「公司 FAQ 能不能被穩定回答」，這通常是最快路徑。

但平台能發布 Web App，不等於能自動接好每個外部通路。當你要整合 LINE、CRM、訂單系統或特殊權限時，仍要確認官方連接方式，必要時寫自己的中介後端。

需要會員資料與交易動作時自建

自建後端的工作比較多，但你能清楚控制每個工具可以做什麼。例如「查訂單」只接受目前登入會員的訂單編號；「取消訂單」必須再次確認，並限制在出貨前。

模型不應直接連資料庫，也不應自己組任意 SQL。比較安全的方式，是提供少量、輸入格式固定的函式，例如 getOrderStatus(orderId)、requestHumanSupport(conversationId)，再由後端做身分與權限檢查。

GPTs 適合內部助理，LINE 仍需獨立串接

自訂 GPT 適合讓內部同事查文件或執行固定指示；要把客服放進 LINE，仍需處理 Messaging API 與自己的後端。若客戶必須離開原本通路、登入另一個服務才能使用，採用率與對話銜接都要另外評估。

第一版只做 20 個高頻問題

先從客服紀錄挑出最常見、答案明確、風險低的 20 題，例如營業時間、運送方式、退換貨流程與產品尺寸。每題整理成一個可維護的知識單元，至少包含：

• 使用者可能採用的不同問法。
• 經核准的答案與最後更新日期。
• 適用條件與例外。
• 下一步連結或真人處理方式。
• 不應由 AI 猜測的欄位。

不要把 200 頁 PDF 丟進知識庫就期待一切正常。若同一份文件同時保留三個版本，Bot 很可能檢索到過期政策；如果退貨規則散落在多份簡報，也很難知道哪一份才是準則。

一段能用的客服 System Prompt

下面這份可以當起點，但真正的限制仍要在程式權限與資料層實作：

你是本站客服助理，使用繁體中文回答。

回答規則：
1. 只根據「已檢索到的客服資料」回答，不使用外部常識補完政策。
2. 沒有足夠資料時，直接說目前查不到，並提供真人客服入口。
3. 不承諾退款、折扣、到貨時間或其他未出現在資料中的條件。
4. 回答先給結論，再列必要步驟；不要重複使用者的整段問題。
5. 使用者要求查詢或更改個人資料時，先走身分驗證與核准工具。

「不知道就說不知道」有幫助，但不能保證不亂答。你仍要限制資料來源、驗證工具參數，並用測試集量測實際行為。

LINE AI 客服怎麼接？

LINE 官方流程包含 Token、Webhook 與簽章驗證。使用者傳訊息後，LINE Platform 會把事件以 HTTP POST 送到你在 Developers Console 登記的 HTTPS webhook；你的伺服器驗證簽章、處理事件，再透過 Messaging API 回覆。

實作順序可以照這六步：

1. 建立 LINE Official Account 與專用 Messaging API channel。
2. 部署一個公開 HTTPS webhook，並在 Console 驗證網址。
3. 收到事件後先驗證 x-line-signature，不要接受來源不明的 POST。
4. 把文字送進客服工作流，取得回答或真人轉接結果。
5. 用 reply token 回覆，並處理逾時、重送與重複事件。
6. 關閉會造成重複訊息的預設自動回覆，完成測試後再上線。

LINE 官方也提醒 webhook 可能重送，順序也可能不同。後端應使用 webhookEventId 去重，長工作則先排入佇列，不要讓整個模型呼叫卡住 webhook 回應。

RAG 回答與執行動作要分開

客服常見的錯誤，是讓同一段 prompt 同時決定答案與修改資料。更清楚的設計是先分類：

• 公開知識問題：從核准文件檢索後回答。
• 個人查詢：登入後呼叫唯讀工具，回傳最少必要資訊。
• 寫入動作：顯示將要修改的內容，取得確認後才執行。
• 高風險或情緒案件：立刻轉真人，不讓模型自行承諾。

像「退貨要幾天」是知識問題；「幫我取消昨天的訂單」是寫入動作。兩者即使出現在同一句話，也不能使用同一種權限處理。

上線前怎麼測？

建立至少 50 題測試集，涵蓋正常問法、口語錯字、資料不足、惡意要求與需要真人處理的情況。每次改模型、prompt、文件或切分方式都重跑一次。

不要只看回答「像不像人」。真正有用的指標是：

• 答案是否和核准資料一致。
• 引用的政策版本是否正確。
• 應拒答時有沒有停止。
• 應轉真人時有沒有成功建立案件。
• 首次回覆時間與完整處理時間。
• 每一個成功解決對話的 API 成本。

對外上線前，另外測提示注入，例如要求 Bot 忽略規則、吐出 system prompt、揭露其他客戶資料或呼叫未授權工具。權限最小化與後端驗證才是關鍵防線；黑名單關鍵字只能當輔助。

一週維運流程

每週抽查無答案、低信心、負面回饋與真人轉接對話。先判斷原因，再決定修什麼：查不到正確段落就改知識文件或切分；找到正確資料卻答錯才調 prompt 或模型；工具失敗則查後端與權限。

每份政策標記負責人和更新日期。產品價格、活動與退換貨規則一變，應先更新單一準則來源，再重新發布知識庫。這比不斷在 prompt 增加例外規則可靠得多。

常見問題

做 AI 客服一定要先買付費方案嗎？

不一定。概念驗證可以從現有文件、少量測試題與平台試用額度開始；正式上線成本則包含模型、向量資料庫、主機、LINE 訊息、監控與人工維運。先算每個「成功解決的對話」成本，不要只看模型單價。

有 RAG 就不會產生幻覺嗎？

不會。RAG 只能提高模型取得正確資料的機會，仍可能檢索錯版本、忽略限制或組織出錯。應同時做準則管理、引用、拒答、測試與人工抽查。

網站 Bot 和 LINE Bot 應該先做哪一個？

若目的是驗證問答品質，先做網站版比較快；若大部分客服原本就在 LINE，驗證完成後再接 Messaging API。LINE 需要 webhook、簽章驗證與事件去重，整合成本會高於單純分享 Web App。

官方資料

• LINE Developers：Build a bot
• LINE Developers：Receive messages (webhook)
• Dify Docs：30-Minute Quick Start

接著若要自己寫後端，可從 AI API 串接教學 開始；要控制文件檢索品質，請看 RAG 實戰指南。