Chatbot 是什麼？類型、應用情境、導入流程與平台選擇
Chatbot 不一定使用生成式 AI。本文說明規則型、意圖辨識型與生成式 Chatbot 的差異，並整理應用情境、七步導入流程、平台選擇、轉真人、知識維運與隱私風險。
作者：Frank Chiu
Chatbot 是一種透過文字或語音與使用者對話的軟體介面。它可以回答問題、引導流程、蒐集資料，或連接後端系統完成查詢與建立工單。
不是每個 Chatbot 都使用生成式 AI。規則型機器人照決策樹走，意圖辨識型先判斷使用者想做什麼，生成式 Chatbot 則可能根據知識庫與大型語言模型組織回答。
本文會從類型、應用情境、導入流程、平台選擇、轉真人與維運風險開始，帶你規劃第一個真正能用、也知道何時該停下來的 Chatbot。資料查核日：2026 年 8 月 17 日。
Chatbot 是什麼？
Chatbot（聊天機器人）是一種讓人透過文字或語音與軟體對話的應用程式或互動介面。使用者不必先找到正確選單或表單，而是可以直接提出問題、提供資料，或用對話方式完成一項任務。
一次完整互動通常包含四個步驟：接收使用者的文字或語音、判斷這句話代表的需求、依規則或資料選擇回覆，再把答案顯示出來或執行受限制的動作。Chatbot 可以出現在網站、App、通訊軟體、客服系統、電話語音服務或公司內部工具。
「Chatbot」描述的是對話式互動方式，不指定背後一定使用哪一種技術。最簡單的 Chatbot 可以只依按鈕、關鍵字與決策樹前進；另一類會用自然語言處理與意圖辨識，把不同問法導向既定流程；生成式 AI Chatbot 則可能使用大型語言模型與知識庫來組織新回答。
Chatbot 除了回答問題，也可以蒐集欄位、查詢訂單、建立客服單、預約時間或轉接真人，但前提是它已連接對應系統並取得明確權限。看起來能聊天，不代表它理解所有事實、可以任意存取公司資料，或有權自行完成任何操作。
IBM 的官方定義同樣把 Chatbot 的核心放在文字或語音的對話介面，並明確指出不是所有 Chatbot 都使用 AI。可參考 IBM：What is a chatbot?。
Chatbot 有哪些常見類型？
| 類型 | 怎麼回答 | 適合任務 | 主要限制 |
|---|---|---|---|
| 規則型 | 依按鈕、關鍵字與決策樹前進 | 營業時間、資格確認、預約導引 | 超出腳本就容易卡住 |
| 意圖辨識型 | 先把自然語句分類到 intent，再執行流程 | 查訂單、改預約、客服分流 | 需要範例語句、欄位與例外設計 |
| 生成式 | 依提示、模型與知識來源組織答案 | 產品說明、內部知識問答、內容輔助 | 可能答錯、過度推論或引用過期內容 |
實務上不必三選一。退款資格可以走規則，常見問題可以查知識庫，無法確認時再轉真人，通常比全部交給生成式模型更穩。
Chatbot 和 AI Agent 有什麼不同？
Chatbot 的主要邊界是「用對話回應使用者」，通常一次處理一個問題或一段已設計好的流程。AI Agent 的主要邊界則是「朝目標採取行動」：它可能自行拆解多步驟、選擇工具、讀取中間結果，再決定下一步。
兩者會重疊，但不能只看畫面判斷。有些 Chatbot 能查資料或送出表單，仍然只是權限有限的對話流程；有些 AI Agent 也使用聊天視窗接收任務，但聊天只是入口，真正差異在於它是否具備規劃、工具使用、狀態管理與一定程度的自主執行能力。延伸可看AI Agent 運作原理。
哪些工作適合用 Chatbot？
適合的任務通常高頻、重複、邊界清楚，而且結果可驗證。目標不是讓機器人「什麼都能聊」，而是替特定讀者完成一件事。
- 客服分流：辨識訂單、退換貨、帳號、產品與人工服務需求。
- 常見問題：根據已核准的政策、課程、服務或內部文件回答。
- 名單蒐集：詢問需求、預算、聯絡方式與同意事項，再寫入 CRM。
- 預約與查詢：取得日期、地點或訂單編號，連接後端完成查詢。
- 員工支援：回答請假、設備、制度與新進流程，必要時建立工單。
醫療判斷、法律結論、高額退款、刪除資料與公開承諾等高風險任務，不宜只靠 Chatbot 自動決定。它可以先蒐集資訊或準備草稿，但應保留清楚的人工核准點。
如果目標其實是寫作、研究或一般問答，而不是對外服務流程，先理解ChatGPT 的基本用法，可能比直接建一套 Chatbot 更省事。
Chatbot 導入流程：從一個任務開始
步驟一：寫清楚使用者與任務
不要用「提升效率」當需求。改寫成：「讓已下單客戶輸入訂單編號後，查到目前狀態；查不到或要求退款時轉真人。」
同時定義不服務的事情，例如不回答庫存承諾、不修改付款資訊、不處理敏感申訴。
步驟二：定義成功與失敗
至少設定任務完成率、正確率、轉真人率、無答案率與處理時間。降低真人訊息量可以是結果，但不能靠把使用者困在機器人裡達成。
步驟三：整理知識與資料責任
列出 Chatbot 能使用的網站、FAQ、產品文件與資料庫。每個來源都要有 owner、版本、更新時間與下架規則。
同一個問題若在官網、客服手冊與舊 PDF 有三種答案，先處理內容衝突，再談模型準確率。
步驟四：設計對話、例外與轉真人
除了正常流程，也要設計聽不懂、缺欄位、查無資料、重複提問、情緒升高與要求真人的路徑。
轉真人時應帶上已蒐集的資料與對話摘要，避免客服重新問一次。人工服務時間與等待方式也要直接說明。
步驟五：串接系統並縮小權限
只問 FAQ 的機器人不一定需要 CRM 寫入權限。要查訂單時，也應先做唯讀查詢，再評估是否允許修改、取消或退款。
測試環境、測試帳號與假資料要先準備好。不要用第一位真實客戶來測試寄信、建立工單或更新訂單。
步驟六：用真實問題集測試
測試集要包含常見問法、錯字、口語、同義詞、否定語句、一次問兩件事與超出範圍的問題。只測團隊自己寫的標準句，會得到過度樂觀的結果。
步驟七：小流量上線並持續維運
先讓部分使用者或單一入口使用。每週檢查未解決問題、錯誤答案、轉真人原因、知識過期與系統失敗，再決定是否擴大。
Chatbot 是長期服務，不是一次性網頁專案。沒有內容 owner、系統 owner 與客服 owner，上線後通常很快失準。
工商時間
如果你想要更系統化、更輕鬆的學好 SEO 與 AI SEO，歡迎參考我與知識衛星合作的 SEO 線上課程：《SEO 排名攻略學》、《AI SEO 流量變革》。
透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。
透過《SEO 排名攻略學》獲得穩定的 SEO 流量與實戰經驗。
再搭配《AI SEO 流量變革》看懂 AI 搜尋趨勢，搶佔 AI 搜尋紅利。
Chatbot 平台怎麼選？先比較八個條件
Google Dialogflow CX、Microsoft Copilot Studio、Amazon Lex 等平台，都能建立對話介面，但產品定位、雲端生態與開發方式不同。平台清單會變，以下判斷條件比較耐用。
| 條件 | 要問的問題 | 常見陷阱 |
|---|---|---|
| 通路 | 網站、App、LINE、Teams、電話或社群是否原生支援？ | Demo 能聊，不代表能上到你的入口 |
| 任務 | 只回答，還是要查詢、寫入與跨系統動作？ | 把高風險動作和一般問答混在一起 |
| 知識 | 能否指定來源、顯示引用、控制版本與權限？ | 把舊文件全丟進去，卻沒有淘汰規則 |
| 轉真人 | 何時轉、轉到哪裡、能帶哪些上下文？ | 只留「聯絡客服」，沒有交接 |
| 治理 | 身分驗證、資料區域、保存、稽核與管理員控制是否符合需求？ | 只看模型名稱，忽略資料生命週期 |
| 分析 | 能否看到無答案、完成、放棄、轉真人與滿意度？ | 只看對話量，把使用量當成效 |
| 維運 | 誰能修改、測試、分環境與回復版本？ | 只有外包商知道怎麼改 |
| 成本 | 按訊息、對話、token、模型、通路還是席次計費？ | 只算平台月費，漏掉串接與人工維護 |
低程式碼平台適合快速驗證；雲端 NLU 平台適合需要語音、流程與後端整合的團隊；自建方案則換得更高控制，但也承擔開發、監控與安全責任。
實作範例：先做一個訂單查詢 Chatbot
第一版只處理三件事：查詢訂單狀態、說明配送時程、轉真人。不要一開始就加入推薦、退費、會員修改與所有產品問答。
- 使用者選「查訂單」，輸入訂單編號與驗證資訊。
- Chatbot 以唯讀權限查詢狀態，回傳目前節點與官方說明。
- 查無訂單、資料不符、逾期或要求退款時，建立客服案件。
- 案件包含訂單編號、已驗證欄位、對話摘要與使用者問題。
- 客服處理完成後，標記機器人是否能在未來改善該問題。
這個範例的價值不在對話多自然，而是每一步都有輸入、輸出、權限與失敗處理。
知識庫不是上傳完就結束
生成式 Chatbot 常用網站、PDF、FAQ 或內部文件作為知識來源。真正困難的是「哪一份才有效」，不是檔案數量。
- 每份來源標示 owner、適用產品、版本與更新日。
- 相同政策只保留一個權威來源，舊頁導向或下架。
- 答案若屬高風險，顯示來源並限制生成範圍。
- 定期抽查無答案與低滿意對話，回補真正缺少的內容。
- 離職、改組或供應商更換時，重新檢查帳號與資料權限。
這也解釋了為什麼內容行銷與內容治理會影響 Chatbot 品質：來源混亂時，模型再強也只是更快地整理混亂。
隱私、安全與錯誤回答要怎麼管？
NIST 的生成式 AI 風險文件提醒，第三方整合可能增加隱私、智慧財產與錯誤內容風險。導入時應先做資料最小化，而不是先把所有資料餵給系統。
- 聊天前說明身分、用途、蒐集資料與人工服務方式。
- 不要要求不必要的身分證、信用卡、病歷或完整帳密。
- 敏感操作重新驗證身分，並保留人工核准。
- 限制知識來源、工具與可執行動作，採最小權限。
- 設定保存期限、刪除方式、存取稽核與事件處理流程。
- 對不確定問題允許拒答，不用「像答案」取代正確答案。
若平台會處理客戶或員工資料，正式上線前還要由資訊安全、法務或個資負責人依實際契約與情境確認。
Chatbot 常見失敗：不是模型不夠強
- 範圍太大：第一版就想回答所有產品與政策。
- 沒有退路：無答案時重複同一句，也找不到真人。
- 來源互相衝突：舊 PDF 與官網新政策同時存在。
- 只測標準句：上線才遇到錯字、口語、反問與多意圖。
- 權限過大：為了方便，問答機器人也取得修改資料權限。
- 沒有 owner：客服以為 IT 會改，IT 以為行銷會更新內容。
- 只看對話量：使用很多，不代表完成任務或降低錯誤。
比較務實的上線標準是：遇到已知問題能正確完成，遇到未知問題能安全失敗，並且有人看得到失敗。
總結：先讓 Chatbot 把一件事做好
Chatbot 是對話介面，不等於生成式 AI，也不必一開始就做成 Agent。最穩的路線是選一個高頻低風險任務，定義成功與轉真人，整理權威知識，再小流量測試。
平台選擇時，先比較通路、任務、知識、整合、治理、分析與總成本。能回答很多問題只是展示；能在正確邊界內完成任務，才是可維運的服務。
Chatbot 常見問題
Chatbot 一定要使用 AI 嗎？
不一定。按鈕、關鍵字與決策樹也能建立 Chatbot。是否使用生成式 AI，應看問題是否開放、答案風險與是否需要自然語言理解。
中小企業適合先做哪一種 Chatbot？
先做單一任務，例如常見問題分流、訂單查詢或預約蒐集。範圍小，才容易準備資料、測試與衡量。
Chatbot 可以完全取代客服嗎？
通常不應這樣設計。它適合處理重複與可驗證任務；例外、申訴、情緒、高風險決策與權限問題仍需要真人。
建立 Chatbot 最貴的是平台月費嗎？
不一定。知識整理、系統串接、測試、人工接手、資安審查與持續維運，常比第一眼看到的訂閱費更影響總成本。
怎麼判斷 Chatbot 有沒有用？
看任務完成率、正確率、無答案率、轉真人率、處理時間與滿意度。不要只看對話數或「回答看起來很自然」。
官方參考資料
