「我想做一個 AI 客服機器人,我看 OpenAI、Claude 都很厲害,丟我的 FAQ 給它就好了吧?」
每個月會有 3-5 個客戶這樣問。我一開始認真照著做,結果第一個月就 churn 了 60% 的提問者——客戶問「我的訂單到哪了?」AI 回「您可以聯絡客服查詢訂單狀態」,然後客戶就不想問了。
AI 客服不是把 FAQ 倒給 LLM 就會變聰明。下面這篇拆解三個常見部署陷阱,以及怎麼設計出真的有用的版本。
陷阱 1 · 把「靜態 FAQ」當訓練資料
最常見的錯誤。老闆把 30 條 FAQ 整理好,丟給 OpenAI / Claude 當 system prompt,以為這樣就能應對客戶問題。
為什麼這不會 work?
客戶問問題的方式跟 FAQ 寫法完全不同。FAQ 寫的是:
Q: 退貨政策是什麼? A: 7 天內可退貨,商品須完整未拆封。
客戶會問:
「我昨天收到的東西,盒子撕了但東西沒用過,還能退嗎?」
LLM 看到 FAQ 條款,只會回:「依據我們的政策,商品須完整未拆封才能退貨。」——這是字面正確、實際無用的回答。客戶實際想知道的是「我這個情況可以退嗎?」
怎麼修?
不是把 FAQ 丟進去,而是把「情境決策樹」設計給 LLM:
退貨判斷:
- 7 天內 + 完整包裝 → 直接同意
- 7 天內 + 包裝拆但商品未用 → 案例分流(請客戶提供照片)
- 7 天內 + 商品已用 → 視商品類型(衣物 NG、3C 視 SN 號)
- 超過 7 天 → 不接受,但提示客戶下次優惠券
這樣 LLM 會根據客戶實際情境給出有判斷力的回答,而不是引述條款。
陷阱 2 · 不接後台,變成「會講話的看板」
第二個常見災難:AI 客服跟後台沒接。
客戶問「我訂單到哪了?」——AI 回的是 FAQ 教條,因為它根本看不到訂單系統。客戶火大,還是得開 LINE 找真人。AI 客服存在的意義 = 0。
「能查訂單」是 AI 客服最低門檻的功能。沒接到後台的 AI 客服,本質上就是會自然語言對話的 FAQ 頁,比一個寫得好的 FAQ 頁還沒用(至少 FAQ 頁不會給錯誤期待)。
該接什麼?
最少要接這幾個:
- 訂單系統(查訂單狀態、物流追蹤)
- 會員系統(查會員等級、累積點數)
- 常見操作(修改地址、取消訂單、申請發票)
- 庫存系統(某商品還有貨嗎)
技術上這就是 LLM function calling / tool use——你定義一組「工具」(API),LLM 判斷該不該叫、叫哪個、傳什麼參數。Claude 跟 OpenAI 都支援。
我自己用 Anthropic SDK 接的範例:
const tools = [
{
name: 'get_order_status',
description: '查詢客戶訂單狀態與物流追蹤',
input_schema: {
type: 'object',
properties: {
order_number: { type: 'string', description: '訂單編號' }
},
required: ['order_number']
}
},
// ... 其他工具
];
const response = await anthropic.messages.create({
model: 'claude-opus-4-7',
max_tokens: 1024,
tools,
messages: [{ role: 'user', content: userQuestion }]
});LLM 看到「我訂單 #12345 到哪了」會自動叫 get_order_status({ order_number: '12345' }),拿到真實資料再組成回答。這是有用的 AI 客服跟玩具的差別。
陷阱 3 · 沒有「轉真人」的優雅 fallback
第三個踩雷點:AI 自信滿滿地答錯。
LLM 有個本質問題叫 hallucination ——它會編造答案。如果你的 system prompt 沒寫清楚,客戶問「你們有 XXL size 的衣服嗎?」,LLM 可能會自己編「有」(實際你只做到 XL)。客戶下單發現沒貨、或收到大小不對的衣服,信任直接歸零。
兩個必做的設計
1. 限制範圍 + 明確 fallback
system prompt 一定要寫類似:
你只回答關於 [我們品牌名稱] 的訂單、商品、會員問題。
如果問題超出範圍、或你不確定答案,回答:「這個問題我不太確定,可以幫你轉接客服真人嗎?」
這比讓 LLM 硬猜安全 100 倍。
2. 自動轉接機制
設計幾個觸發條件 → 自動轉真人:
- 客戶說「我要找真人」「客服」「轉接」
- 客戶連續抱怨/負面情緒(可用情緒分析判斷)
- 客戶問題超過 3 輪沒解決
- 涉及退款、爭議、客訴
我做的版本會在這些情境直接給出 LINE 客服連結 + 把對話歷史 push 到客服 Slack channel,真人接手時知道前面聊過什麼。客戶不用重複講三次故事,這個 UX 體感差很多。
真實的 ROI:AI 客服該為誰省錢、為誰提升體驗?
適合做 AI 客服的場景:
- 每天有 50+ 客戶詢問,真人客服忙不過來
- 60-80% 是重複問題(訂單、物流、規格)
- 你已經有完整後台 API 可以接
不適合的場景:
- 一天問題 < 10 個 → 真人回比較快、體驗也好
- 大多問題需要「商業判斷」(B2B 客製、特殊優惠) → AI 容易說錯
- 還沒整理好後台資料 → 接了等於沒接
很多老闆問 AI 客服,是因為真人客服成本壓力,但實際上問題量還沒到自動化的門檻。那種狀況,把 LINE 自動回覆模板做好,比上 AI 划算 10 倍。
落地步驟(誠實版本)
如果你決定要做,這是現實的時程:
| 階段 | 內容 | 時間 |
|---|---|---|
| 1. 資料盤點 | 把過去 3 個月的客服對話分類,看哪些問題占 80% | 1 週 |
| 2. 後台 API 整理 | 把要接的功能整理成 API,沒有就要先做 | 2-4 週 |
| 3. 情境決策樹設計 | 不是 FAQ,是判斷邏輯 | 1-2 週 |
| 4. LLM 接入 + tool use | 寫 prompt、串 API、測試 | 2-3 週 |
| 5. 灰度上線 | 先處理 30% 流量,觀察 1 個月 | 1 個月 |
| 6. 全量 + 持續優化 | 每週看對話 log、修 prompt | 永遠 |
現實的 MVP 從決定做到上線,8-12 週。號稱「兩週做好」的供應商,大概率是把 ChatGPT 套個 UI——你會踩進上面三個陷阱。
結語:AI 客服不是「省人力」工具,是「分流」工具
最重要的觀念:AI 客服的目標不是取代真人,是把『真人不需要處理的事』過濾掉——讓真人客服專注在「需要判斷力、需要溫度」的對話。
設計對了,真人客服處理的問題會從 100% 降到 20-30%,但每個處理時間更長、解決更深——整體服務品質反而會升,不是降。設計錯了,AI 客服每天得罪 60 個客戶,真人收尾收到崩潰。
如果你正在評估,聊 15 分鐘,我會幫你判斷:
- 你的問題量到底夠不夠 AI 客服 ROI
- 後台改造工作量多大
- 從 FAQ 自動回覆到完整 AI 客服,中間有哪些便宜的中繼方案
不一定要直接做全套。多數情況下,先做「LINE 自動分流 + 真人接手」就夠用兩年。