AI 客服知識庫怎麼開始？台灣 SME 先做 30 天 PoC，別一開始就買整套系統

AI 客服知識庫如果一開始就從買平台、串通路、上很多文件開始，台灣 SME 很容易先把錢花掉，卻還不知道系統到底能不能穩定回答客戶問題。比較穩的做法是先用 30 天 PoC 驗證四件事：高頻問題有沒有整理成可檢索內容、哪些問題必須轉人工、資料能不能持續更新，以及這套流程有沒有真的縮短客服時間或留住更多詢問。知識庫做得起來，關鍵通常不是模型，而是內容與流程先被整理好。Dify Docs OECD

為什麼很多 SME 一開始就做反

很多團隊以為導入 AI 客服的第一步是挑一套最強的平台，但官方文件與市場上真正表現好的內容，都在提醒同一件事：知識庫的核心是 retrieval，不是模型名單。Dify 的教學開頭直接說明，knowledge base 是為了解決 context 與 hallucination，不是把所有回答交給模型自由發揮。Dify Docs

這也是為什麼 SME 常常會覺得「明明 demo 可以，正式上線卻不敢放給客戶用」。問題通常不是 AI 突然變笨，而是資料來源太散、FAQ 沒有統一版本、客服和業務各講各的、轉人工條件也沒有先寫好。平台只是把這些混亂放大得更快。

OECD 在 2025 年的 SME 研究也指出，非採用者最大的障礙不是成本，而是覺得 AI 不適合自己的工作、擔心法規與版權、以及不確定餵給模型的資料會發生什麼事。這對台灣 SME 很有代表性，因為客服流程同時碰到客戶資料、商品資訊與品牌承諾，本來就不能只看功能清單。OECD

30 天 PoC 要先驗什麼

如果你現在準備做 AI 客服知識庫，我會先把第一個月當成流程驗證，而不是當成正式上線。目標不是證明 AI 很厲害，而是回答一個更現實的問題：這套東西有沒有足夠穩、足夠省時、而且不會把客服風險放大。

這個 PoC 的用意，是先確認你有沒有找到「最適合先自動化」的那一段客服流程。若你第一批問題大多是營業時間、配送、退換貨、預約、更改訂單、付款方式，通常就很適合先試。因為這類問題高頻、格式相對固定，也容易回頭驗證對錯。

反過來說，如果第一批問題大多是客製報價、醫療判斷、法務條件、特殊售後爭議，或任何需要讀細節才能承諾的情境，就不適合把「直接回答」當成第一波目標。這時比較穩的做法是先讓 AI 做摘要、分類、建議回覆，讓真人決定最後答案。

哪些內容該先進知識庫，哪些不要急著放

第一批知識庫內容不需要最完整，但一定要最常用。Gamania CRM 的知識庫整理建議很實際：先根據工單歷史、顧客回饋與常見痛點，決定優先內容，然後再談分類、標題與系統整合。這比先把所有舊文件丟進去更有效。Gamania CRM

我會先放四類內容：第一，顧客真的常問的 FAQ；第二，客服原本就有固定說法的流程問題；第三，需要引用公開政策的資訊，例如退換貨、付款、配送、預約；第四，能引導下一步的資訊，例如如何預約、如何提供訂單號、如何找真人協助。

暫時不要急著放的內容，通常有三種。第一種是版本很多、沒人知道哪份才是最新的資料。第二種是需要人判斷才能承諾的敏感內容。第三種是包含客戶個資、內部備註、價格底線或未對外公開的條件。把這些內容混進第一波知識庫，只會讓團隊更不敢用。

FAQ 頁、客服稿與 AEO/GEO 怎麼一起做

很多團隊把「給客戶看的 FAQ 頁」和「給 AI 用的知識來源」分開做，結果兩邊越做越不一致。其實 Google 對 AI features 的說法很直接：想在 AI Overviews 或 AI Mode 裡被當成支援連結，還是回到既有 SEO 基本功，包括內容可抓取、重要資訊有文字版本、結構化資料與可見文字一致、內部連結清楚。Google Search Central

這代表客服知識庫和 AEO/GEO 並不是兩套工程。你把 FAQ 頁寫成清楚、可引用、可更新的 HTML 內容，對搜尋與客服其實同時有利。搜尋引擎需要能索引的答案，客服 bot 需要乾淨一致的來源，兩者都不喜歡只有圖片、沒有邊界、或版本不明的內容。

最實用的做法是讓對外 FAQ 頁和知識庫用同一份核心答案，再依通路加上不同層級的說明。網站 FAQ 可以多放限制條件、例外情況與內部連結；客服 bot 則用同一核心答案，再加上「如果這不是你的情況，請提供訂單號或轉人工」這種分流語句。

工具怎麼選：文件型、筆記型、聊天流程型

工具不用先比誰最先進，而是先看你的內容狀態與團隊能力。若你只是需要把多份文件、網頁或簡報快速集中整理，Gemini Notebook 類型的工具很適合先做內部研究或草稿驗證，因為它本身強調根據上傳來源回答，並提供 inline citations。Gemini Notebook Help

如果你已經有一批比較乾淨的 FAQ、政策與教學內容，而且想把問答流程、分類、轉人工與通路回覆一起設計，Dify 這種聊天流程型工具就更接近正式 PoC。它的官方教學直接示範了 question classifier、direct reply、knowledge retrieval 與 LLM node 的組合，也提醒要檢查 chunk coherence 和 retrieval test。Dify Docs

若你的目標只是先把知識整理成共用來源，不急著放給客戶看，那也可以先從最簡單的文件型知識庫開始，例如網站 FAQ、共用文件夾、產品與客服規範頁。很多 SME 真正缺的不是 AI 平台，而是還沒有一套可以放心交給 AI 檢索的內容資產。

資料治理與隱私，為什麼要在 PoC 前就講清楚

如果你的知識庫會接觸客戶資料，不能等到上線後才問資料存在哪裡、會不會被拿去訓練模型。Google Workspace 對 Gemini Notebook 的說明已經把這類問題講得很明白：企業版情境下，上傳檔案、聊天與輸出不會被人工審閱，也不會用來改進生成式 AI 模型；但一般使用情境若主動提交回饋，完整互動內容可能被審閱。Google Workspace Help

這不是叫所有 SME 都去用某個特定工具，而是提醒你：資料治理不是採購完成後才補的文件。只要 PoC 會碰到真實詢問、訂單資訊或個資，就該先確認資料來源、儲存位置、刪除方式、回饋機制與誰有權限更新內容。否則準確率還沒驗證，風險先被放大了。

適合誰，不適合誰

這套做法特別適合已經有固定客服量、常見問題重複度高、而且希望把官網、LINE、表單或聊天視窗的說法統一的台灣 SME。像是零售、電商、教育、診所自費服務、美業、健身、補教、旅宿、地方型服務，都很適合先跑這種 30 天 PoC。

它不太適合兩種情況。第一種是你連客服常見問題都還沒有收斂，今天客服說法和明天完全不一樣。第二種是每個詢問都高度客製、幾乎每次都要由專業人員判斷，像複雜法務、醫療、財務承諾或大型 B2B 客製專案。這些情況不是不能用 AI，而是不該把「直接回答」當成第一步。

資料更新與來源

本文於 2026 年 7 月 23 日 查核 Dify、Google Gemini Notebook、Google Workspace、Google Search Central 與 OECD 的公開資料後整理。文中提到的 30 天 PoC 週次安排與內容優先順序，是根據上述來源與台灣 SME 常見客服導入邏輯所做的實務建議，不是任何單一平台的官方規範。

• Dify Docs: Customer Service Bot With Knowledge Base
• Google Help: Learn about Gemini Notebook
• Google Workspace Help: Gemini Notebook data protection
• Google Search Central: AI features and your website
• OECD: Generative AI and the SME Workforce

要特別注意的是，平台功能、資料保護條款、使用上限與搜尋呈現方式都可能更新。真正要上線對外客服前，仍應以你準備採用的平台最新官方文件、自己的資料治理規則與實際客服流程為準。

結論

AI 客服知識庫做得起來，通常不是因為你先買了最貴的系統，而是因為你先把高頻問題、答案來源、轉人工規則與更新責任整理好。對多數台灣 SME 來說，先用 30 天 PoC 驗證資料、流程與成本，再決定要不要自建、採購或只做內部輔助，會比一開始就追求全面自動化更穩，也更能真的留下可複用的客服與內容資產。

FAQ

AI 客服知識庫一定要先買平台才做得起來嗎？

不一定。很多台灣 SME 更需要先整理 FAQ、政策、流程與轉人工規則，等內容來源穩定後，再決定是否採購聊天流程型工具。

30 天 PoC 最重要的指標是什麼？

至少要看可解決比例、誤答率、首次回應時間、人工介入類型、每次對話成本，以及這套流程有沒有真的讓客戶更容易完成下一步。

哪些內容最適合當第一批 AI 客服知識庫來源？

最適合先放的是高頻 FAQ、公開政策、固定流程說明，以及能引導下一步的標準答案。版本很多或需要專業判斷的內容，先不要急著放。

AI 客服知識庫和網站 FAQ 頁面要分開做嗎？

不一定。比較好的做法是共用同一份核心答案，再依通路補上不同層級的說明。這樣對客服與 AEO/GEO 都比較有利。

什麼情況下不適合把 AI 客服直接對外上線？

如果客服問題高度客製、牽涉個資或專業承諾、版本又很多還沒整理好，就不適合一開始直接讓 AI 對外回答，應先做分類、摘要或轉人工輔助。