網站客服機器人怎麼建？Markdown vs RAG 知識庫架構實戰對比｜開發工具箱 6

前言

想幫自己的網站加一個 智能客服機器人，很多人第一個反應是去查「RAG 怎麼建」——向量資料庫、embedding、Supabase……看完就放棄了。但其實，你不一定要從 RAG 開始。

這篇是工具箱開發系列第六篇，要對比的是兩種最常見的知識庫架構：用 Markdown 文件直接當知識庫，以及用 RAG（檢索增強生成）做向量搜尋。這兩種方法在同一個工具箱裡並存——工具箱的說明機器人用 Markdown，AI 小編功能用 RAG——正好可以用真實的工程決策來對照。

除了比較兩種架構，這篇也會說明是怎麼做出來的：Claude Code 負責哪段、Groq 是什麼、提示詞怎麼設計。目標讀者是對 AI 自動化有興趣、玩過 Claude Code 或 n8n、但還不確定自己能不能做更複雜東西的人。如果你已經確定想建一套 智能客服 系統，或想先了解完整的 RAG 智能機器人 規劃方式，也可以從這裡開始。

為什麼知識庫的設計決定了智能客服機器人的上限

AI 回答不準的真正原因不是模型太弱

很多人在建 AI 機器人的時候，把大部分時間花在選模型、調參數、優化回應速度——但最後影響使用者體驗的，往往不是這些。同樣用 Claude 或 GPT-4，一個沒有知識庫的機器人只能靠模型的通識知識亂猜，一個有完整知識庫的機器人可以精準回答你的產品細節。模型的能力是上限，知識庫的品質才是日常表現的地板。

換句話說：如果你的機器人一直給出模糊或錯誤的答案，九成的問題不是模型不夠強，而是你給它的知識不夠準確或不夠完整。這個認知是建好智能客服機器人的第一步。

九個功能、使用者不知道從哪裡開始問

工具箱有文章上架工具、GSC 排名查詢、部落格文章生成、社群貼文追蹤、AI 小編、財務發票管理、訂閱費用監控……九個以上的功能模組，每個都有自己的操作邏輯和限制。對第一次進來的使用者，這個數量有點壓倒性——他們不知道「我現在遇到的問題要用哪個工具」，也不知道某個步驟卡住了要怎麼辦。

文件寫得再完整，使用者也懶得從頭讀。他們需要的是一個可以直接問的對象，一問一答，比手冊快。說明機器人存在的理由就是這個：讓使用者不用自己找文件，有問題直接問，它對照知識庫給答案。

整體架構：三個工具各自在做什麼

Claude Code——從聊天介面到後端一起做

Claude Code 負責把整個聊天機器人做出來。包含右下角可以展開的聊天視窗、訊息泡泡的排版、打字等待動畫、送出和接收的邏輯，還有後端接 AI 模型的那段程式。我把需求說清楚，Claude Code 從介面到後端一起實作，不需要自己寫任何一行程式碼。

這也是 vibe coding 的核心：我的工作是說清楚「這個機器人要長什麼樣、要做什麼事」，Claude Code 負責把它實現。遇到問題就描述問題，讓它想辦法，不需要自己去查語法。

Groq——為什麼聊天機器人要選速度快的 AI

Groq 是 AI 模型的提供方。很多人熟悉 Claude 或 ChatGPT，但 Groq 在這個場景有一個很明顯的優勢：速度。Groq 用自研晶片跑開源 AI 模型（這個專案用的是 Llama 3.3 70B），回應速度明顯比一般雲端 AI 快。

聊天機器人的使用者體驗裡，等待時間是最容易讓人放棄的環節。如果回覆要等超過兩三秒，使用者心理上就開始覺得怪，繼而放棄對話。選 Groq 是為了讓回覆感覺「幾乎是即時的」，而不是讓使用者盯著三個跳點等很久。如果你的應用對準確度要求更高、可以接受稍慢的速度，換用 Claude API 也完全可以，架構不需要改，換一個 API key 就好。

知識庫——把知識和 AI 分開管理

知識庫是這套系統的靈魂，也是這篇文章的重點。整個機器人的架構可以理解成：AI 是一個會說話的引擎，知識庫是它的油箱——引擎再好，油箱空了就跑不動。

把知識和 AI 分開管理有一個很重要的好處：你的知識更新了，不需要重新訓練模型，不需要重新部署系統，只需要更新知識庫，下一個問問題的使用者就立刻得到更新後的答案。這個設計讓維護成本變得非常低，也讓非技術背景的人可以自己維護機器人的知識內容。

Markdown vs RAG——兩種知識庫做法的完整對比

方法一：Markdown 文件怎麼當知識庫

Markdown 做法的核心概念很直覺：把你的知識寫成一份純文字文件，每次使用者問問題，系統就把這整份文件加上使用者的問題一起送給 AI，讓 AI 在「讀過這份說明書」的狀態下回答。

工具箱說明機器人用的就是這個做法。有一份叫做 CHATBOT.md 的文件，裡面是每個工具的功能說明、操作步驟、常見問題。每次對話，整份文件都會被帶進去當作 AI 的背景知識。

Markdown 做法的優點：

• 零額外基礎設施：不需要向量資料庫、不需要 embedding 服務、不需要額外帳號
• 維護成本極低：有新功能就加一個段落，存檔後立即生效，不需要重新部署
• 可讀性高：任何人都能直接打開文件來讀和編輯，不需要技術背景
• 快速起步：從零到機器人可以回答問題，整個建置可能不到兩小時

Markdown 做法的限制：

• 知識量有上限：AI 模型每次能接收的文字有長度限制（context window），文件太長就必須截斷
• 無法精準查段落：整份文件一次全部送進去，AI 需要自己從幾千字裡判斷哪段最相關
• 沒有語意搜尋：只靠文字匹配，問「月費監控」找不到「訂閱費用」這種語意相近但詞彙不同的段落

方法二：RAG 架構怎麼運作

RAG（Retrieval-Augmented Generation，檢索增強生成）的核心思想是：不要把整份知識庫一次全部塞給 AI，而是先讓機器搜尋出「最相關的那幾段」，再把這幾段帶去讓 AI 回答。

這個流程分三個步驟。第一步：知識先被「向量化」——把文字轉成數值格式（embedding），讓電腦能計算語意上的相似度，而不只是文字匹配。第二步：向量資料存進向量資料庫（例如 Supabase）。第三步：每次使用者問問題，系統先把問題也向量化，去資料庫找最相近的幾個段落，只帶著這些段落去問 AI。

工具箱的 AI 小編功能就是這樣設計的：每個客戶可以上傳品牌資料的 PDF，系統用 Google Gemini Embeddings 把文件向量化、存進 Supabase Vector Store，AI 在生成貼文時能精準查詢品牌知識。這套 RAG 架構和說明機器人的 Markdown 做法在同一個工具箱裡並存。

RAG 做法的優點：

• 可以處理大量知識：不受 context window 限制，幾萬字、幾十萬字的文件都可以
• 精準段落匹配：只帶入最相關的幾段，而不是整份文件，AI 的回答更聚焦
• 語意搜尋能力：能找到詞彙不同但語意相關的內容，覆蓋範圍更廣
• 適合多文件場景：多個客戶、多個產品線的知識可以共存，查詢時自動過濾

RAG 做法的代價：

• 需要額外基礎設施：向量資料庫的帳號和設定
• 建置更複雜：需要 embedding 模型、向量化流程、查詢邏輯，在 n8n 裡要接更多節點
• 更新流程較繁瑣：新增知識不是改文件就好，需要重新跑向量化流程存進資料庫
• 維護成本更高：多一層基礎設施就多一個可能出錯的地方

對比表格：兩種架構的關鍵差異一覽

比較項目	Markdown 文件	RAG 架構
知識量上限	受 context window 限制	幾乎無上限
建置難度	低，一份文件就能啟動	中高，需向量資料庫與 embedding
更新方式	直接編輯文件，立即生效	需重新向量化並更新資料庫
搜尋方式	整份文件一起送，AI 自行判斷	語意搜尋，只帶最相關段落
維護成本	低，文字編輯即可	較高，多一層基礎設施
適合情境	知識量小、更新頻繁、快速起步	知識量大、多文件、需精準匹配

什麼條件下需要從 Markdown 升級到 RAG

升級的判斷不是「RAG 比 Markdown 更專業所以要用 RAG」，而是看你的知識量和使用情境是否已經超出 Markdown 能負荷的範圍。以下三個條件出現任何一個，就是升級的訊號：

第一：知識量超過單一文件容量。當 CHATBOT.md 長到超過幾萬字，AI 開始因為文件被截斷而找不到對的資訊，回答變模糊，這時候 RAG 的分段查詢就開始有意義。

第二：需要查詢多份獨立文件。如果每個客戶、每個產品有自己的知識庫，用 Markdown 就需要維護很多份文件，且無法跨文件查詢。RAG 的向量資料庫可以把多份文件統一存進去，查詢時自動找到對的那份。

第三：搜尋準確度明顯下降。當使用者反映「問了但沒得到對的答案」，而你確認答案其實在文件裡，通常是 AI 在長文件裡找錯了段落。RAG 的精準段落匹配可以解決這個問題。

提示詞設計——讓智能客服只說它該說的話

System Prompt 的兩個組成部分

不管用 Markdown 還是 RAG，知識庫只是原料，提示詞（system prompt）才是決定機器人「個性和邊界」的地方。提示詞結構分兩個部分：第一部分是知識內容，也就是 Markdown 文件的全文，或 RAG 查詢出來的相關段落；第二部分是行為規則，告訴 AI 怎麼使用這份知識。

很多人只設計第一部分，忽略了第二部分。結果機器人雖然有知識，但回答方式、語氣、邊界都不受控，使用者體驗就很不穩定。行為規則是讓機器人在設計意圖範圍內穩定運作的保護機制。

四個不可缺少的行為規則

工具箱說明機器人的提示詞裡，行為規則包含以下四條：

語言和語氣：全程繁體中文、口語化說明、不說程式術語。這條規則讓機器人的回答對行銷背景的使用者友善，不會突然冒出「API endpoint」或「localStorage」這種詞。目標受眾是誰，語氣就往誰靠。

回答長度：以 1–3 句為主，不給不必要的廢話。聊天機器人的場景裡，使用者想要的是快速確認，不是閱讀一篇文章。長篇大論反而讓人找不到重點。

知識邊界：如果文件裡沒有相關資訊，說「這個細節我不確定，建議詢問管理員」，不亂猜。這條規則防止 AI 在知識庫沒覆蓋的地方自行發揮，產生聽起來有道理但其實錯誤的資訊。

範疇限制：問題超出工具箱範疇時，禮貌說明只負責這個主題。避免使用者把它當成通用 AI 助理使用，偏離設計目的，也避免機器人「越界」給出你無法負責的回答。

這件事 Markdown 和 RAG 都一樣需要做好

RAG 解決的是「找到對的知識」這個問題，提示詞解決的是「怎麼用這個知識回答」這個問題。兩者是不同層次的問題，不能互相取代。

即使你把整個知識庫都用 RAG 搭好，如果行為規則沒設計清楚，機器人還是可能給出語氣不對、範圍太廣、或者該說「不確定」卻硬要回答的問題。先把提示詞設計好，再去選知識庫架構，比顛倒過來更有效率。

人化視角——同一個工具箱裡並存的兩套架構

為什麼說明機器人先選 Markdown

做工具箱的時候，我一開始有考慮過直接用 RAG——AI 小編功能已經有一套 Supabase + Gemini 的 RAG 流程在跑，把同樣的架構複製過來感覺是最「標準」的做法。

但我停下來想了一下：說明機器人的知識庫是幾千字的工具說明，不是幾萬字的品牌文件。用 RAG 在這個規模上，查詢精準度的提升微乎其微，但維護複雜度直接翻倍——每次更新說明，不只要改文字，還要重新跑 embedding、確認向量資料庫同步。這個代價不值得。

我把這個判斷描述給 Claude Code，它幫我確認：CHATBOT.md 目前的大小遠低於 Groq 模型的 context window，直接放進系統提示詞沒有截斷問題。確認之後選了 Markdown，快速驗證機器人的實用性，等知識量真的長到一個程度再升級。

什麼條件會觸發升級

目前決定「什麼時候升級 RAG」的判斷標準只有一個：Markdown 開始出現可以量化的問題——使用者反映答案找不到、文件開始被截斷、或者需要跨多個客戶查詢知識。在這之前，繼續用 Markdown 就好。

工具箱裡已經有 RAG 的實作可以直接參考，升級的時候不是從零開始，是把現有架構複製過來調整。這讓「升級」這件事的成本比想像中低，也讓「先用簡單的做法快速驗證」這個策略更值得採用。技術選型的最高原則不是選最先進的，而是選現在規模最合適的。

常見問題 FAQ

Q1：我沒有工程師背景，Markdown 這種做法做得到嗎？

完全做得到。Markdown 文件就是純文字，你不需要會任何程式語言就能編輯它；聊天介面是 Claude Code 幫你做出來的，不需要自己寫；Groq 的設定只需要一個 API key，申請後填入環境變數就好。整個流程裡，你唯一需要投入時間的是「把你的產品說清楚」——這件事不需要技術背景，需要的是你對自己產品的了解。

Q2：Markdown 和 RAG，我應該從哪個開始？

如果你的知識庫在幾千字以內、更新頻繁、想快速驗證機器人有沒有用，從 Markdown 開始。如果你的知識量已經超過一份文件能容納、需要查詢多份文件、或者需要精準的語意搜尋，才考慮 RAG。不要因為「RAG 看起來比較專業」就從 RAG 開始——先驗證你的知識庫設計方向是對的，再決定要不要升級架構。

Q3：提示詞要怎麼設計才不會讓機器人亂回答？

提示詞裡至少要包含四件事：語言和語氣的設定（目標受眾是誰就往誰靠）、回答長度的限制（聊天機器人不需要長篇大論）、知識邊界的定義（文件裡沒有的就說不確定，不要亂猜）、以及範疇限制（超出設計目的的問題禮貌拒絕）。這四條規則寫清楚，機器人的行為就會穩定很多。

Q4：知識庫更新後，機器人多久會知道？

用 Markdown 做法的話，更新完文件存檔，下一個問問題的使用者馬上就得到新答案，系統每次都是即時讀取文件，不需要重新部署。如果是 RAG 架構，更新後需要重新跑 embedding、把新的向量資料存進資料庫才會生效，通常是幾分鐘的流程。兩者的更新速度差距在大多數使用情境下不是決定性因素，選架構還是要回到知識量和搜尋精準度的需求。

Q5：Groq 是什麼？和 Claude API 或 ChatGPT 差在哪裡？

Groq 是一家做 AI 推理加速的公司，用自研晶片跑開源 AI 模型（例如 Meta 的 Llama 系列），速度比一般雲端 GPU 明顯更快。和 Claude API 或 OpenAI 的差別在於：Claude 和 GPT 是各家自己的閉源模型，Groq 跑的是開源模型，通常更便宜、速度更快，但在複雜推理任務上可能稍弱。聊天客服這種有固定知識範疇的應用，Groq 的速度優勢很值得利用。

總結

Markdown 還是 RAG，本質上不是技術優劣的選擇，而是規模與需求的判斷。知識量小、更新頻繁、想快速驗證，Markdown 是最低摩擦的起點；知識量大、需要跨文件搜尋、對精準度有高要求，RAG 才發揮它的價值。兩者是升級關係，不是替代關係——從 Markdown 開始，等遇到 Markdown 解決不了的問題，再升級 RAG。

整個開發過程，從聊天介面到後端 API，全部是 Claude Code 做的，沒有自己寫任何一行程式。知識庫是一份 Markdown 文件，維護它的人不需要任何技術背景，只需要把產品說清楚。建智能客服機器人最難的不是選架構，而是把你的知識整理成 AI 能準確使用的格式——這件事根本不需要寫程式。

下一篇會繼續分享工具箱的其他功能，包含訂閱費用監控的設計思路。

想了解更多 AI 工具與 n8n 實務應用結合，歡迎參考官方網站：https://aiqkangber.com/