如果把做一個 AI 客服比成開餐廳，現成的聊天機器人像是外送平台上的便當，拿來就能吃，菜色卻不是你決定的。Dify 則比較像一間水電與爐具都接好的廚房，刀具和調味料就擺在工作檯上，只是食材（模型和你自己的文件）得自己帶進去。
對網站經營者來說，客服每天重複回答的，往往就是那幾題：運費怎麼算、交期要幾天、改稿可以改幾次。這些答案其實早就寫在產品說明或 FAQ 裡，缺的只是一個能讀懂文件、再用口語回答客戶的窗口。Dify 是開源的 AI 應用開發平台，用視覺化畫布把模型、知識庫與工具接在一起，做好的應用可以發布成網頁、API，或直接嵌進自己的網站。
它不會替你想好客服該怎麼回答，這既是好處也是門檻。知識庫怎麼切、提示詞怎麼約束、哪些內容可以對外公開，全都由你決定，而這些決定做得好不好，對客服品質的影響通常比挑哪個模型更大。
Dify 是什麼？
Dify 的文件首頁把它定位成開源的 AI 應用開發平台，你可以用它建立 agents、agentic workflows 與聊天機器人，而且這些應用能讀取你自己的資料。名稱則取自 Do It For You 的字首。
所以它不是裝好就能聊天的現成產品，而是搭機器人的工作台。Dify 的 GitHub 專案頁把它描述成一個工作區，裡面同時有視覺化工作流程、RAG 管線、Agent、模型管理與可觀測性，每個應用還附帶一組 API，讓你能把做好的東西接進別的系統。
這裡的 RAG 指的是檢索增強生成，做法是先到你自己的資料裡找出最相關的段落，再交給模型據此回答，讓答案有依據、減少亂編。對客服來說，這就是「照文件回答」背後的做法。
做好的應用有幾種出口，可以發布成網頁應用、透過 API 串接，也能以 MCP server 的形式讓其他 AI 工具呼叫。對想做客服的人來說，最實用的組合是知識庫加聊天應用，只要把產品說明或 FAQ 放進去，就能得到一個只依文件回答的客服。
Dify 的應用類型，只照文件回答的客服選 Chatbot 即可
在 Dify 建立應用的第一步是選類型，這個選擇會影響後面能搭多少流程。Dify 的 Key Concepts 頁建議從 Workflow 與 Chatflow 兩種裡選。Workflow 處理單次任務，從輸入一路跑到結果，像報告生成、資料處理、批次處理都屬於這一類；Chatflow 則是在 Workflow 之上加了對話層，每則訊息都會觸發一次流程，還能儲存對話變數、讓 LLM 節點具備記憶，而且一律從使用者輸入開始。
另外還有 Chatbot、Agent、Text Generator 三種基本類型。它們跑在同一個工作流程引擎上，只是操作比較簡化，屬於舊式介面。其中 Chatbot 最單純，一個模型加一段提示詞就是一個對話應用。Dify 的 Chatbot 說明頁寫明，每個對話最多保留 500 則訊息或 2,000 tokens 的歷史，超過上限就移除最舊的訊息。
客服情境的取捨很直接。只要照文件回答，Chatbot 就夠用；需要先判斷問題類別、再依條件走不同回應，才輪到 Chatflow。Dify 另有新版 Agent（目前仍是測試版），可以在專屬的沙箱中執行指令、讀寫檔案，客服入門用不到，知道有這個選項就好。
知識庫讓機器人照自己的文件回答
客服靠不靠得住，關鍵在於回答有沒有依據。Dify 的知識庫（Knowledge）是一組你自己的資料，可以接進 AI 應用，成為模型作答時的額外依據。Dify 的說明列出的用途包括客戶支援機器人（用產品文件、FAQ 與疑難排解指南回答）、內部知識入口、內容生成與研究分析。
建立知識庫有三條路：快速上手的現成知識庫、可以自訂處理流程的自訂知識庫（Knowledge Pipeline），以及透過 API 連到外部知識庫，資料不用搬進來。入門走第一條就好。知識庫可以建很多個，每個各自設定，所以產品說明和服務政策也可以分開放。
知識庫可匯入的文件格式、來源與檔案上限
根據 Dify 部落格的新手教學，雲端版能匯入的檔案類型相當多，PDF、Word、PowerPoint、Excel、CSV、TXT、Markdown、HTML、XML、EPUB 等常見格式都支援，連 EML、MSG 這類郵件檔也收。自架版的範圍則窄一些，Dify 的環境變數說明指出，預設的文件解析器只處理 TXT、Markdown、PDF、HTML、Excel、Word（DOCX）與 CSV，舊版 Word（DOC）、PowerPoint、XML、EPUB 與郵件檔要改接 Unstructured 解析服務才能匯入。不論用哪一版，客服常用的 PDF 與 Word（DOCX）檔都能直接上傳，格式通常不會是障礙。
匯入來源有三種：本機檔案、同步 Notion、同步網站。後兩種要先接好連線或供應商，入門時最省事的是直接匯入檔案。根據 Dify 文件的上傳說明，Sandbox 方案一次只能上傳 1 個檔案、每個檔案上限 15 MB；Professional 與 Team 方案則是一次最多 50 個、每個檔案上限 50 MB。
比檔案格式更值得花時間的，是文件本身的寫法。Dify 的說明並沒有限定文件形式，產品手冊、FAQ、政策都可以放，不過就客服來說，整理成單一主題、標題清楚的 FAQ 或產品說明，通常比整本掃描的 PDF 好用。例如龐果設計可以把運費、交期、改稿次數各整理成一份短文件，而不是丟進一本 80 頁的作品型錄。
切片、索引與檢索的入門設定，兩項建立後無法更改
文件匯入後會被切成較小的段落（chunk），讓系統能快速找到對的那一段。切片設定包括分隔符號與最大長度，General 模式還能設重疊字數，讓相鄰兩段保留一點連續性。模式有 General 與 Parent-child 兩種。General 的所有段落共用同一套設定，命中的段落直接回傳；Parent-child 則切成較小的子段與較大的父段兩層，比對子段、回傳完整的父段，比較適合大型手冊，也比較進階，入門用 General 即可。前處理還能合併連續的空白與換行，或移除網址與電子郵件。
索引方式有 High Quality 與 Economical 兩種。High Quality 會用嵌入模型把內容轉成向量，能依語意比對，並支援向量、全文與混合三種檢索；Economical 只比對關鍵字，不耗 tokens，也不佔知識庫儲存空間，但客戶換個說法問就容易漏掉。Dify 部落格給的入門建議是切片用 General、索引用 High Quality、檢索用向量檢索。
檢索設定裡有幾個預設值值得知道。Top K 預設為 3，也就是每次取回最相關的 3 段；分數門檻預設為 0.5，門檻設得越高，能被取回的段落越少；Rerank 模型預設關閉，開啟後會額外消耗該模型的 tokens，使用前還要先到整合頁的模型供應商設好 API key。另外，Dify 的索引與檢索說明提到，向量檢索與全文檢索的 Top K 和分數門檻只在 Rerank 階段生效，要套用這兩項設定，就得先加入並啟用 Rerank 模型。
這一組設定裡有兩個選項建好之後就改不回來。切片模式建立後不能更改，只有分隔符號與最大長度能隨時調整；High Quality 索引建立後也無法切回 Economical，反過來 Economical 則能升級成 High Quality。如果文件的結構大改，想換切片模式，就只能重建一個知識庫，所以第一次建的時候，最好先拿一小份文件試過。
上線前先用切片預覽與檢索測試把關
知識庫最常見的失敗有兩種，一是文件切壞了，二是客戶的問法找不到對應段落。儲存前可以先用 Preview Chunk 看文件被切成什麼樣子，像是一個問題的答案有沒有被從中間切斷、標題有沒有跟內文分家。確認沒問題再儲存處理。
知識庫建好後，另有檢索測試頁可以直接輸入問題，看系統抓回哪幾段。測試時要用客戶真正會問的說法，例如「改稿可以改幾次」，而不是照文件標題「修改次數說明」去搜，後者幾乎一定命中，前者才看得出檢索設定準不準。
在測試頁調整的檢索設定只對當次測試有效，不會改動知識庫本身。要注意的是，測試與正式檢索走同一個端點，所以也會計入請求頻率上限。Dify 的 Knowledge Request Rate Limit 頁寫明，執行檢索測試與在應用中查詢知識庫都算一次請求，Sandbox 方案每分鐘 10 次、Professional 100 次、Team 1,000 次。以免費方案來說，一分鐘內做滿 10 次檢索測試，接下來的一分鐘裡，這些受限的知識庫操作就會暫時無法執行。
用知識庫組出第一個 AI 客服的流程
從零到上線，整條路徑是準備模型、建知識庫、建應用並接上知識庫、寫提示詞、預覽除錯、發布。比起按鈕位置，更需要先想清楚的是每個階段要決定什麼，以及決定錯了會怎樣。
接上知識庫有兩種組法。用 Chatbot 的話，在應用內的 Context 加入建好的知識庫並設定檢索；用 Chatflow 的話，則是在 Start 與 LLM 節點之間放一個 Knowledge Retrieval 節點，檢索結果交給 LLM 節點，最後由 Answer 節點輸出。兩者的邏輯相同，都是使用者提問後，系統先到知識庫找依據，再讓模型據此回答。
先備妥模型與文件，再建立應用
Dify 本身不含模型，所以動手前要先確定有模型可用。Dify Cloud 可以免費註冊，新帳號預設在 Sandbox 方案，內含 200 點 AI credits（定價頁稱為 message credits），可以呼叫 OpenAI、Anthropic、Gemini 等供應商的模型。這 200 點是一次性配額，不會每月重置。
用 AI credits 涵蓋的模型不需要自備 API key，只要先到整合頁安裝對應的模型供應商外掛就能使用，也可以改填自己的 key。點數是依每次 AI 回應（一次輸入加一次輸出的模型呼叫）計算，不看用了多少 tokens，實際扣多少則依模型而定，大模型扣得比較多，所以拿來練習的客服不必選最大的模型。
另一項準備是文件。先備妥一份最常被問到的內容就好，產品說明、FAQ 或服務政策都行，不用一開始就把所有資料塞進去。Sandbox 的知識庫文件數有上限，先從一份開始，也比較容易判斷是文件寫得不好，還是設定出了問題。
提示詞要寫明人設、回答範圍與查無資料時的說法
客服的好壞有一半在提示詞。Dify 的 Chatbot 說明建議把提示詞當成一個穩定的角色來寫，而不是一次性的任務，並涵蓋三件事：定義角色與語氣、指定輸出格式、設定限制。
套到客服上，這三件事可以寫得更具體，下面是常見的寫法，並非 Dify 的規定。第一，角色與語氣要寫明，例如龐果設計的客服人員，語氣親切、回答簡短；第二，限定只依知識庫提供的內容回答；第三，超出範圍或查不到資料時，用一句固定的話回覆，並請客戶留下聯絡方式由專人處理。這三條交代清楚，機器人才不會在沒有依據時自己編答案。
加入知識庫之後，客戶每送出一則訊息，Dify 就拿它當檢索查詢，把找到的內容放進提示詞當脈絡。這代表客戶問得越口語，知識庫裡就越需要有對應的說法。另外可以在 Add Features 開啟引用與出處，答案會附上來源，方便你自己核對機器人是不是真的照文件講。
變數是提示詞裡的佔位符，每個變數對應一個讓使用者在對話前填寫的欄位，同一個機器人因此能適應不同情境，例如先讓客戶選詢問的服務類別。變數型別有短文字、段落、下拉選單、數字、核取方塊與 API 變數，其中短文字上限 256 字元。不知道提示詞怎麼起頭的話，可以用 Generate 功能讓模型協助起草或改寫，每次生成都會存成一個版本，隨時可以回溯。
客服問題需要分流時改用 Chatflow
單純問答用 Chatbot 就夠了。當客服要先判斷問題屬於哪一類、再走不同的回應，就需要 Chatflow。它多了 Question Classifier 節點，會依使用者的輸入把問題分到你定義的類別。每個類別有兩個欄位，一個是給模型讀的描述，模型靠它決定走哪個分支，另一個是畫布上顯示的標題。描述寫得越明確，分類就越準。
Dify 的客服示範分成三類：售後服務（保固、退貨、維修）、產品使用（設定說明、疑難排解、功能說明）與其他問題。套到龐果設計的情境，可以改成報價與交期、檔案規格、其他三類，每一類各接一套回應。
需要的話，還能再加 If-Else 條件判斷、HTTP Request 連到外部服務，或 Human Input 讓流程暫停、等人工輸入。入門的順序建議是先用 Chatbot 跑通，確認知識庫答得準，再升級成 Chatflow，這樣出問題時比較容易分辨是知識庫的問題，還是流程設計的問題。
預覽除錯通過後再按下發布
發布前，先在除錯預覽輸入與知識庫有關的真實問題，也要故意輸入知識庫沒涵蓋的問題，確認機器人會依提示詞的約束回應，而不是硬編一個答案。這一步比什麼都重要，因為客戶實際遇到的，多半就是文件沒寫到的邊角問題。
按下發布後，Dify 會同時建立網頁應用與 API 端點。之後只要修改設定，就得再按一次發布，才會同步到線上版本。發布前建議先設好應用說明、圖示與品牌、存取控制與頻率限制。
模型供應商與工具都從整合頁安裝
在 Dify 裡能用哪些模型、工具與資料來源，取決於整合頁裡裝了什麼。整合分成七種類型：模型供應商、工具、資料來源、觸發器、Agent 策略、自訂端點與擴充。安裝來源有三處，分別是經過審核測試的 Marketplace、公開的 GitHub 儲存庫，以及本機的 .difypkg 套件檔。工作區的擁有者與管理員可以控制誰能安裝與除錯。
模型供應商頁可以設五種預設模型：系統推理、嵌入、Rerank、語音轉文字與文字轉語音。其中嵌入模型會用在知識庫的索引與檢索，所以選的是什麼嵌入模型，會直接影響客服找資料的準確度。入門時只需要動這一塊，其他類型等到需要時再裝。
模型費用的部分，改填自己的 API key，費用就由自己在供應商的帳號計費，也能取得更高的頻率上限。AI credits 不支援的供應商，則只能裝好外掛後填入自己的 key 使用。Professional 與 Team 方案另外可以用負載平衡，把請求分散到多把 key。
語系方面，Dify 的原始碼有繁體中文（zh-Hant）語系，操作介面可以切成繁體中文；文件的中文版則是簡體，查說明時要有心理準備。
發布後能以網址、API、網站嵌入與 MCP 使用
客服做好之後，要放在客戶看得到的地方。網頁應用在建立應用時就會自動產生，發布後有網址可以直接分享。網頁應用可以調整名稱、圖示、描述（建議 160 字內）、輸入框提示文字（上限 64 字元）、主題色、語言，以及版權與隱私權連結；在應用裡啟用的功能，例如對話開場白、建議追問、來源引用，會自動帶到網頁應用上。
API 端點讓你把客服接進自己的系統，MCP server 則讓應用能被 Claude Desktop、Cursor 這類工具呼叫，客服場景多半用不到。要特別留意的是，根據 Dify 的 Web App Settings 說明，網頁應用預設是公開的，任何知道網址的人都能開啟。所以對外公開的客服，知識庫只能放你願意讓所有人看到的內容，內部報價單或合約範本不該放進去。
網站嵌入的聊天氣泡與 iframe 兩種做法
嵌入網站有兩種做法。聊天氣泡（Chat Bubble）是浮在頁面上的按鈕，訪客點開後以浮層顯示完整介面，不會離開原頁面，適合全站都要有客服入口的情況。iframe 則是把應用直接放進頁面內容，一直可見，功能與網頁應用相同，適合做成專屬的客服頁。
兩種做法都要先取得應用的嵌入 token，外觀可以用 CSS 變數或 containerProps 調整，像氣泡的位置、大小與顏色都能改。如果你的網站是 WordPress，概念上就是把 Dify 給的嵌入程式碼貼進自訂 HTML 區塊或主題模板，貼法本身不複雜，失敗多半出在前置條件。
嵌入失敗時，可以依序檢查幾件事：token 是否與應用的嵌入設定頁一致、設定是否在嵌入腳本之前載入、瀏覽器主控台有沒有 JavaScript 錯誤、網站的 Content Security Policy 是否允許 iframe，以及更新應用設定後有沒有重新發布（沒有重新發布，嵌入的版本不會跟著變）。網站與 Dify 應用也都要使用 HTTPS。
上線後用日誌與標註回覆持續修正答案
客服上線不是結束，答案要靠真實對話持續修正，這也是 Dify 比單純聊天機器人外掛多出來的部分。日誌會記錄網頁應用、API 與應用內使用的真實對話，每則回答都能看到 token 消耗與延遲，也能打開背後的原始提示詞或節點的逐步追蹤，找出機器人是在哪一步抓錯了資料。
日誌也支援評分。終端使用者按讚或倒讚的紀錄，與你的團隊成員評分是分開統計的，團隊成員給倒讚時還可以附上註解，說明哪裡答錯。發現答錯時，可以直接在日誌裡為該問題加上一則改良後的標註。
標註回覆開啟後，系統會先拿使用者的問題去比對已有的標註，語意相似度超過設定門檻，就直接回傳標註內容，不再讓模型生成；沒有命中，才走一般的生成流程。Dify 也會記錄哪些標註被用過、各用了幾次。這種固定答案的做法很適合客服裡政策、保固這類答案必須前後一致的題目，同一個問題不會今天這樣答、明天那樣答。
日誌保留期限依方案不同。根據 Dify 的 Logs 說明，Sandbox 方案的所有日誌保留 30 天，過期永久刪除，升級後也救不回來；Professional 與 Team 的對話日誌在訂閱期間內都會保留。儀表板則能看效能、成本與使用者互動，用來判斷客服有沒有被實際使用。
Dify 雲端版與自架版的取捨
Dify 有兩種用法，一種直接用雲端版，一種自己架在伺服器上。雲端版免維運，註冊就能用，代價是按方案付費、額度有限；自架的 Community 版免費，資料與伺服器都由自己管，代價是更新、備份與安全都得自己負責。企業版另外提供自架加單一登入（SSO）、角色權限控管（RBAC）與支援服務，需要洽詢報價。
兩種用法沒有絕對的高下，要看你有沒有人手維運，以及資料能不能放在雲端。
雲端版 Sandbox、Professional 與 Team 的價格與額度
根據 Dify 定價頁，雲端版分 Sandbox、Professional 與 Team 三個方案，按工作區計費，可選月繳或年繳，表中價格以年繳計：
| 項目 | Sandbox | Professional | Team |
|---|---|---|---|
| 價格 | 免費 | 590 美元／年 | 1,590 美元／年 |
| AI credits | 200（一次性） | 每月 5,000 | 每月 10,000 |
| 成員數 | 1 | 3 | 50 |
| 應用數 | 5 | 50 | 200 |
| 知識庫文件數 | 50 | 500 | 1,000 |
| 知識庫儲存空間 | 50 MB | 5 GB | 20 GB |
| 知識庫請求頻率 | 每分鐘 10 次 | 每分鐘 100 次 | 每分鐘 1,000 次 |
| 標註額度 | 10 | 2,000 | 5,000 |
| 日誌保留 | 30 天 | 不限（訂閱期間內） | 不限（訂閱期間內） |
對客服影響最大的是文件數、儲存空間與標註額度。只放一份 FAQ 跑完入門流程，免費帳號綽綽有餘；但客服文件一旦超過 50 份，或索引後的資料超過 50 MB，就會碰到 Sandbox 的上限，標註也只有 10 則可用。儲存空間的算法也要留意，Dify 的知識庫儲存空間說明指出，計入的是 High Quality 索引產生的向量，而不是原始檔案大小，一份文件索引後可能佔掉原檔好幾倍的空間。
模型費用不在這張表裡。方案額度只管 Dify 平台本身，模型的呼叫費用要看是用 AI credits，還是自備 API key 由供應商計費。
自架版的硬體需求與啟動方式
自架的最低門檻不高。根據 Dify 的 Docker Compose 部署說明，硬體至少要 2 核心 CPU 與 4 GiB 記憶體，並安裝 Docker 與 2.24.0 以上版本的 Docker Compose。在 macOS 上用 Docker Desktop 的話，文件另外要求替 Docker 虛擬機配置至少 2 顆虛擬 CPU 與 8 GiB 記憶體。
做法大致是取得原始碼、複製環境設定檔，再用 docker compose 啟動。啟動後會跑起一組容器，包括 7 項核心服務（api、worker、web 等）、8 項相依元件（預設含 Weaviate 向量資料庫、PostgreSQL、Redis 與 Nginx 等），外加 1 個負責設定檔案權限、跑完就結束的初始化任務。容器都起來之後，從瀏覽器開啟安裝頁設定管理員帳號，就能登入使用。
啟動只是開始，維運才是自架的主要成本。升級的步驟隨版本不同，要看該版本的發布說明，並比對新舊環境設定檔；網域、HTTPS、備份也都要自己處理。自架的 Community 版只有單一工作區，需要多工作區與企業管理功能的話，要看企業版。
開源授權附帶的兩項使用限制
Dify 是開源專案，但採用的授權是 Dify Open Source License，以 Apache 2.0 為基礎再加上附加條件，所以 GitHub 沒有把它辨識成標準的 Apache-2.0，授權欄歸在 Other（其他）。附加條件有兩項，部署前值得先看清楚。
第一項，未經 Dify 書面授權，不得用原始碼經營多租戶環境，授權裡把一個工作區定義為一個租戶。第二項，不得移除或修改 Dify 控制台或應用前端的 LOGO 與版權資訊，這一條只針對前端（原始碼的 web 目錄或 web Docker 映像檔），沒有用到前端的部署方式則不受限。
換成實際情境，用 Dify 做公司內部工具或自家網站的客服，只要保留前端的 Dify LOGO 與版權資訊，就不必另外申請授權；要是想把 Dify 包裝成多個客戶共用的服務對外提供，或拿掉前端的 Dify 標誌，就得先向 Dify 取得商業授權。
選用 Dify 前要先確認的資料與費用限制
動手前有幾項限制最容易被忽略，先弄清楚邊界，才不會做到一半發現走不下去。
模型費用不包含在 Dify 的方案裡。200 點 AI credits 用完，或改用 AI credits 不支援的供應商，就得自備 API key，由供應商另外計費。知識庫的切片模式與 High Quality 索引建好後無法回頭，想換只能重建知識庫。
Sandbox 的文件數與儲存空間偏小，日誌 30 天後永久刪除，需要長期追蹤客服表現的話，要把這點算進去。網頁應用預設公開，所以知識庫只放願意對外回答的內容。答案品質也取決於文件本身，文件過時或互相矛盾，機器人就會照著答錯，這不是 Dify 能替你補救的部分。自架版的更新與維運，同樣由自己負責。
如果還在猶豫從哪裡開始，最穩的起點是挑一份 FAQ，用免費的雲端版跑通一個 Chatbot，確認它答得準、查不到時也懂得收手。等這個最小版本站穩了，再決定要不要升級成 Chatflow 做問題分流，或是把 Dify 搬到自己的伺服器上。