LINE 自動回覆系統骨架
先用規則保證答案一致,再用 AI 處理模糊與自然語言;每一條路都要能轉真人。
黃志弘 Leo
2026-09-01 發佈 · 2026-10-08 更新 · 39 人看過
很多店家的 LINE 官方帳號,停在「自動回覆=關鍵字對到罐頭訊息」。客人多問一句就沒反應,最後還是全部靠真人盯。
這份教學帶你把自動回覆做成一套真正可靠的系統:
該一字不差的答案,交給規則。
模糊的自然語言,才交給 AI。
兩邊都設好安全網,接不住的隨時轉真人。
看完你會掌握三件事:
一、整條訊息處理流水線的骨架,從驗簽去重、會員狀態到回覆送出。
二、AI 該放在哪裡才有價值,而不是亂答。
三、讓系統上線後不出包的品質設計要領。
下面流程圖的每個節點都能點開,看它的作用、設計技巧與驗收方式。三個視圖分別是:完整骨架、AI 放哪裡、做好系統的技巧。
點任一節點看細節。目前選取的節點會標成金色。
分成三種處理方式
閘門過或不過
整條流水線共用的資料底座
作用
接收文字、圖片、貼圖、位置、按鈕回傳與加入好友等事件。
設計技巧
先定義支援哪些事件;不支援的格式要給明確提示,不能默默失敗。
驗收方式
為每種事件準備一筆測試資料,確認都能被正確辨識與追蹤。
同一個問題先問自己:這題有沒有唯一正確答案。
優先不用 AI
- 價格、資格、退款規則等「必須一字不差」的答案
- 預約時段、訂單狀態、會員點數等即時資料
- 身分驗證、付款、取消預約等會改動資料的操作
- 已有明確按鈕、關鍵字或狀態機可以處理的流程
做法:規則引擎加資料庫或 API;結果可預測、好測試、成本低。
AI 最有價值的位置
- 同一需求有很多說法,關鍵字抓不到真正意圖
- 從核准的知識庫找答案,再整理成自然口吻
- 摘要長對話,替真人客服整理問題與已知資訊
- 生成不同語氣、追問缺少欄位、辨識負面情緒
做法:檢索增強生成(RAG)加結構化輸出;AI 不直接當資料真相來源。
- 先問:這個問題有唯一正確答案嗎?
- 有的話,查規則或 API,把答案原封不動送出。
- 沒有的話,交給 AI 理解與整理。
- 兩條路的結果,都要再通過信心與風險閘門才能送出。
建立高品質自動回覆系統的六個步驟,照順序做。
列出前 20 個常見問題、需要的資料、成功與失敗出口。
一個實用的路由順序:精準關鍵字 → 當前流程狀態 → 規則分類 → AI 意圖判斷 → 只追問一個必要問題 → 真人接手。
為什麼要照這個順序
把 AI 擺在最前面,最常見的結果是:客人問營業時間,它答得很漂亮但答錯了。規則先跑,是為了讓「必須一字不差」的答案永遠一致——但一致不等於真實,規則背後的資料要有人維護;AI 後跑,是為了接住規則接不住的說法。閘門擺最後,是因為就算前面兩層都覺得自己對,送出去之前還是要有人問一句「這句話真的可以發嗎」。有一個例外要記住:付款、取消、改資料這種會動到真實資料的操作,確認與授權要放在「執行之前」,不能等做完才檢查。
另外三個共用底座常被忽略。知識庫沒有版本,答案就會停在半年前的政策;會話狀態沒有逾時,使用者隔天回來會接到昨天那句追問;紀錄沒有留,你永遠只能靠客訴來發現系統壞掉。
進階補充:這頁是入門,不是上線藍圖
這一頁講的是骨架與觀念。真的要把系統跑上正式環境、接真實客人與金流,還有一層可靠性工程是這裡沒展開的:
訊息佇列的深度與重試監控、每個意圖各自的準確率追蹤、AI 回答的引用來源驗證、對話層級的追蹤紀錄、模型與知識庫版本的可重現、緊急關閉開關與事件重放工具。
入門階段不用被這串嚇到,照上面的骨架把規則層做穩、高風險一律轉真人,就能安全地開始。等量大了、要接金流了,再回來把這層補齊,或找有做過的人幫你把關。