AI 客服不要急著接 LINE：從 OpenClaw 外掛版本錯誤，看小企業導入 AI 前要先檢查什麼

很多小企業看到 AI 客服、LINE 自動回覆、AI 助理這些工具，第一個反應通常是：「是不是接起來就可以用了？」

實際測過之後，答案通常不是。

這篇不是要說 AI 客服不能做，而是要記錄一個很真實的導入現場：看起來只是把 LINE 官方帳號接到 AI 工具，但真正上線前，會遇到版本相容、外掛更新、容器限制、訊息進出邊界、繁體中文品質、人工接手、風險操作限制等一連串問題。

如果這些沒有先確認，小企業很容易把「測試能跑」誤會成「正式營運可用」。

這次踩到的問題：LINE 外掛比核心系統新

這次測試的情境很單純。

我們想讓 LINE 官方帳號能接到 AI 工具，由 AI 協助回覆用戶訊息。部署環境在 Zeabur 容器上，核心系統是 OpenClaw，LINE plugin 則是後來安裝的外掛。

表面上看起來，只要三件事：

1. 安裝 LINE plugin
2. 設定 LINE token 與 secret
3. 讓 webhook 可以接收 LINE 訊息

但實際載入時出現錯誤：

TypeError: createSetupTranslator is not a function

這種錯誤對一般使用者來說很難懂，因為它不像「密碼錯誤」或「網址不存在」那麼直覺。

真正原因是：LINE plugin 的版本比 OpenClaw 核心系統更新，它需要新版核心裡才有的功能，但目前容器內的核心版本較舊。

換句話說，不是 LINE 壞了，也不是 AI 壞了，而是「外掛與核心版本不相容」。

這就是小企業導入 AI 工具常見的第一個坑：工具介紹看起來都支援，但實際環境的版本、部署方式與更新限制，可能讓功能根本不能穩定啟動。

為什麼這不是單純安裝問題？

很多人看到外掛錯誤，第一反應會是：「那就更新就好了。」

但小企業現場不一定能這麼簡單處理。

如果系統部署在容器平台，核心版本可能受映像檔、套件來源、平台限制影響。若核心不能升級，而外掛又要求新版核心，就會卡在中間。

舊核心可以跑，但不能用新版外掛。

新外掛功能比較完整，但舊核心載不起來。

強行更新可能造成原本可用的服務失效。

回退版本時，又要確認設定檔、資料、webhook、憑證與外部服務是否相容。

這代表 AI 客服不是「裝一個外掛」而已，而是一個小型系統整合問題。

如果沒有先做版本盤點，後面很容易變成反覆試裝、反覆重啟、反覆改設定。最後花最多時間的不是 AI 回覆品質，而是環境相容性。

更大的問題：AI 能不能直接回客戶？

即使外掛成功安裝，也還不能代表 AI 可以直接對外回覆客戶。

真正要問的是：訊息送出去以前，有沒有一道正式的 outbound gate，也就是「對外發送前檢查關卡」。

很多 AI 工具可以接收訊息，也可以生成回覆，但這不等於它適合直接面對客戶。尤其是 LINE 客服場景，AI 若直接回覆，至少要先處理幾個問題：

• 是否一定使用繁體中文？
• 是否避免簡體字或不自然翻譯腔？
• 是否會誤判客戶問題已經解決？
• 是否會叫客戶做高風險操作？
• 是否會要求客戶提供密碼、帳號或敏感資料？
• 是否會承諾「一定修好」？
• 是否能在不確定時明確轉人工？
• 是否能留下工程師接手摘要？

如果這些檢查只靠 AI 自己「想一想」，那不是正式 gate。正式 gate 應該是系統流程中的硬限制，而不是靠提示詞祈禱 AI 每次都乖。

這也是這次測試後的重要結論：AI 可以先做內部助理，但不應該急著直接接 LINE 客戶。

Inbound 與 outbound 要分開看

很多 AI 客服測試會犯一個錯：只看訊息有沒有進來，卻沒有檢查訊息怎麼出去。

Inbound 是客戶訊息進來。

Outbound 是系統回覆送出去。

這兩件事完全不同。

Webhook 能收到 LINE 訊息，只代表 inbound 路線通了。AI 能生成文字，只代表模型有輸出。真正危險的是 outbound，也就是 AI 產生的內容要不要直接送到客戶手機上。

如果沒有 outbound gate，就可能發生幾種風險。

AI 可能把內部判斷直接講給客戶聽。

AI 可能把尚未確認的推測說成結論。

AI 可能在高風險情境下給出錯誤建議。

AI 可能用不適合品牌的語氣回覆。

AI 可能把「請工程師確認」說成「已經判斷完成」。

這些問題在 demo 階段不一定會暴露，因為 demo 通常只測幾句安全問題。但正式客服每天遇到的問題很雜，有電腦不開機、筆電進液體、檔案不見、網路異常、網站打不開、帳號登入失敗、客戶情緒不耐煩等情境。

這些都不是只靠一句「請 AI 小心回答」就能解決。

比較安全的第一階段：內部客服助理模式

對小企業來說，比較穩的做法不是一開始就讓 AI 自動回 LINE，而是先採用「內部客服助理模式」。

流程可以像這樣：

客戶在 LINE 提問後，由小陳或客服把問題貼給 AI。AI 不直接回客戶，而是產生內部建議，包含：

• 問題類型判斷
• 需要追問的資訊
• 目前可能風險
• 不建議客戶自行操作的項目
• 是否需要工程師接手
• 給工程師看的摘要
• 可供人工參考的回覆草稿

最後仍由人工判斷要不要貼回 LINE。

這樣做看起來比較慢，但它有幾個好處。

第一，AI 還沒有直接碰到客戶，不會因為一句錯話造成信任風險。

第二，客服可以觀察 AI 是否真的理解問題。

第三，所有錯誤都可以累積成測試案例，日後再決定哪些類型可以半自動化，哪些一定要轉人工。

第四，工程師可以從 AI 整理的摘要快速掌握現場情況，不必重新問一次全部問題。

這不是反對 AI，而是讓 AI 先在安全範圍內工作。

AI 客服上線前，至少要先檢查這些事

如果小企業想導入 LINE AI 客服，正式上線前建議先做一份檢查表，而不是只看 demo 成功。

一、檢查版本相容性

核心系統、外掛、部署平台、Node 或 Python 版本、容器限制，都要先確認。

外掛文件寫支援，不代表你現在的環境能跑。

這次遇到的 OpenClaw 與 LINE plugin 問題，就是典型例子。外掛本身可能沒錯，核心系統也可能沒錯，但兩者版本對不起來，服務就會卡住。

二、檢查部署平台限制

如果部署在 Zeabur、Cloudflare、VPS、Docker 或其他容器環境，要先確認平台能不能支援需要的常駐服務、port、環境變數、secret file、webhook callback、log 讀取與重啟方式。

很多 AI 工具在本機測試可以跑，但放到雲端容器後，會遇到不同的權限與網路限制。

小企業最容易低估的，就是「本機成功」不等於「雲端穩定」。

三、檢查訊息路徑

要分清楚 inbound 與 outbound。

Inbound 是客戶訊息進來。

Outbound 是 AI 或系統訊息送出去。

很多測試只確認收得到訊息，卻沒有真正控制送出去前的檢查。

如果 AI 要直接回客戶，必須先有明確規則：哪些話可以送出、哪些話要人工確認、哪些情境必須停止自動回覆。

四、檢查語言品質

LINE 客服面對的是正式客戶，繁體中文、語氣、品牌感、避免簡體字，不能只靠事後抽查。

若 AI 會中英混雜、突然出現簡體字、語氣太像機器人，正式上線就有風險。

這不是單純美觀問題，而是信任問題。

客戶看到客服回覆不自然，會直覺覺得公司不穩、服務不可靠，甚至懷疑是不是外包機器人亂回。

五、檢查高風險操作

例如叫客戶拆機、重灌、清除資料、提供密碼、下載不明工具，這些都不能讓 AI 自由建議。

AI 可以提醒風險，但不能越界指揮客戶做危險動作。

像筆電潑到咖啡、硬碟資料不見、電源有燒焦味這類情境，AI 最安全的角色不是教客戶自行處理，而是協助收集資訊，提醒停止危險操作，並轉工程師確認。

六、檢查人工接手

AI 不確定時，要能產生清楚的工程師接手摘要，而不是假裝自己已經診斷完成。

客服系統最怕的不是 AI 不會，而是 AI 不會卻裝會。

比較好的做法是讓 AI 在不確定時明確輸出：

• 已知資訊
• 尚未確認資訊
• 可能風險
• 建議追問
• 是否需要工程師接手
• 給工程師看的摘要

這樣人工接手時不會斷線。

七、檢查紀錄與回溯

每一次 AI 建議、人工修正、最後是否採用，都應該留下紀錄。

這些資料不是為了追責，而是為了看 AI 到底適合處理哪些問題。

例如某些問題 AI 每次都能穩定整理，未來可以提高自動化程度。某些問題 AI 常常過度推測，就應該列入高風險類型，永遠要求人工確認。

沒有紀錄，就沒有改善。

小企業導入 AI，真正要先做的是流程整理

這次 LINE AI 客服測試給我的最大提醒是：AI 導入不是從工具開始，而是從流程開始。

如果原本客服流程沒有定義清楚，AI 接上去只會把混亂放大。

原本不知道哪些問題要轉工程師，AI 也不會自然知道。

原本沒有禁止客戶自行拆機的規則，AI 也可能亂給建議。

原本沒有人檢查語氣與繁體中文，AI 回覆就可能讓品牌看起來不穩定。

所以導入 AI 客服前，應該先問幾個問題：

• 哪些問題 AI 只能整理，不能回答？
• 哪些問題一定要轉人工？
• 哪些話術可以給客戶看？
• 哪些內容只能給內部工程師看？
• 哪些行為是 AI 永遠不能建議的？
• 錯誤回覆發生時，誰負責修正？
• 怎麼記錄每一次人工修正？
• 哪些測試案例累積到一定數量後，才允許進下一階段？

當這些問題有答案，AI 才有機會變成助力。否則 AI 只是更快地把錯誤送到客戶面前。

為什麼 demo 成功不代表正式營運可用？

AI 工具 demo 通常很漂亮。

問一句話，AI 回一句話。

貼一張圖，AI 分析一段。

接一個 webhook，LINE 看起來就能收到回覆。

但正式營運不是 demo。

正式營運會遇到很多 demo 不會測的事情。

客戶可能一次貼很多張圖。

客戶可能只打「不能用」三個字。

客戶可能同時問價格、維修、資料救援、帳號密碼、保固與急件。

客戶可能在晚上傳訊息，AI 可能自動回了不該承諾的內容。

客戶可能描述錯誤，AI 卻照著錯誤描述繼續推論。

如果沒有邊界，AI 會很努力，但不一定安全。

所以小企業導入 AI，不應該只問「AI 會不會回答」，而是要問「AI 回錯時，系統能不能停得住」。

這次實測後的結論

這次 OpenClaw 與 LINE plugin 的版本錯誤，只是一個表面問題。

真正值得記錄的是：AI 客服不是「能接 LINE」就完成，而是要先確認整個系統是否可控。

如果只是個人測試，裝起來試試看沒有問題。但如果要面對正式客戶，尤其是小企業的 LINE 官方帳號，就不能只看 demo。

要看版本、部署、訊息路徑、語言品質、風險邊界、人工接手與紀錄回溯。

目前比較穩的方向，是先把 AI 放在內部助理位置，讓它協助小陳或客服整理問題、提醒風險、產生工程師接手摘要。

等測試案例累積夠多，知道哪些問題 AI 穩定、哪些問題容易翻車，再考慮下一階段。

AI 客服可以做，但不要急著把它推到最前線。

對小企業來說，真正重要的不是「有沒有 AI」，而是 AI 出錯時，系統還能不能停得住、查得到、修得回來。