店家考慮 AI 客服時，最怕的通常不是它不夠聰明，而是它太敢講——把沒有的優惠講成有、把三天的退貨期講成七天。一句話的差錯，後面是真的客訴。
會不會亂講，其實不看模型多強，看的是「一則訊息進來之後，系統對它做了什麼」。這篇把 lí-hó 的處理流程拆開講清楚：從 LINE 把訊息送過來，到回覆送出去，中間有六個步驟。
第 1 步：接收訊息，先驗身分
LINE 用 webhook 把訊息推送到我們的伺服器。問題是：任何人都可以往那個網址打一筆假資料，假裝自己是 LINE。
所以第一件事不是讀訊息，是驗簽章。LINE 每一則推送都帶一組用你的 channel secret 算出來的簽章，伺服器重算一次比對，對不上就直接擋掉，不進入後面任何流程。
這一步跟「AI 聰不聰明」無關，但它決定了別人能不能偽造顧客訊息、汙染你的對話記錄。
第 2 步：分段聚合，等人把話講完
真實的顧客不會把問題打成一段完整的話。他們會這樣傳：
「你好」
「請問」
「明天下午三點還有位子嗎」
「兩個人」
如果每一則都立刻回覆，顧客會收到四則答非所問的訊息，體感非常糟。
所以系統收到訊息後不會馬上回，而是等一個短暫的停頓，把這段時間內的連續訊息合併成一個完整問題，再一次處理。顧客感覺是「它在聽我把話說完」，實際上是刻意的延遲。
第 3 步：語意檢索，找出相關的知識
這是關鍵字機器人跟 AI 客服真正分家的地方。
關鍵字機器人的做法是硬比對：你設「退費」，顧客打「退費」才會中；打「可以退錢嗎」就不中，機器人沉默或回一句罐頭。
語意檢索（RAG）的做法是：把顧客的問題和你知識庫裡的每一條，都轉換成一組代表「意思」的數字（向量），再找出意思最接近的幾條。「可以退錢嗎」和「退費政策」在數字上很接近，所以會被找出來，即使一個字都沒重疊。
這一步的產出是幾條最相關的知識，不是答案。答案還沒生成。
第 4 步：依據作答，只講找到的東西
現在才輪到 AI 生成文字。但它拿到的不是「請回答顧客的問題」，而是「只根據下面這幾條知識回答顧客的問題」。
差別在哪？如果顧客問「你們有停車位嗎」，而你的知識庫從來沒寫過停車，那第 3 步就找不到相關知識，第 4 步的 AI 手上沒有依據，它不會去猜「應該有吧」，而是禮貌地把話題帶回它能幫上忙的範圍。
這就是「知識庫驅動」的實際意思：AI 的知識邊界，等於你自己寫下來的邊界。你沒寫的，它不會發明。
第 5 步：信心判斷，決定要不要開口
有依據不代表就該回。有兩種情況系統會主動踩煞車：
- 依據太弱：檢索到的知識跟問題只有邊緣相關，勉強拼湊出來的答案風險太高。
- 踩到升級關鍵字：退費、客訴、法律、投訴這類議題，即使知識庫寫得很清楚，也不該由 AI 單方面定案。
這一步是刻意讓 AI「少答一點」的設計。對一個客服系統來說，答錯一次的代價，遠高於多答對十次的好處。
第 6 步：回覆，或者交給人
通過前五步，回覆才會送出去。沒通過的，系統不會硬掰一個答案，而是把這則對話標記成「需真人」，讓你在收件匣裡一眼看到哪幾則需要你親自處理。
同時，這次「答不出來」會被記成一筆知識缺口。你之後可以打開缺口清單，看看顧客到底在問什麼你沒寫過的東西，補上去。下次同樣的問題，AI 就答得出來了。
為什麼要設計得這麼囉唆？
把六個步驟壓成一句話：先確認訊息是真的，等人講完，找出你寫過的相關內容，只根據那些內容回答，沒把握就不答，答不出來就交給人並記下來。
直接把顧客的訊息丟給大型語言模型，也會得到回覆，而且通常聽起來很順。但那個回覆的來源是模型從網路上學到的一般常識，不是你店裡的規則。它會很自然地告訴顧客「一般來說七天內可以退貨」——而你的政策是三天。
客服系統的價值不在於「會講話」，在於講的每一句都是你認可的話。中間這幾道關卡，就是為了這件事存在的。