Dify 完整入門指南：應用編排、知識庫、API 發佈與 LLMOps 實作全攻略

很多團隊想做一個自家的 AI 應用——例如一個讀得懂公司文件的問答機器人，或一個能照規則處理任務的小助手——但一想到要自己接模型、寫後端、管理對話紀錄，就被嚇退了。Dify 就是為了把這段路鋪平而生的開源平台，它把「呼叫大型語言模型、串接自己的資料、編排對話與流程、最後發佈成可呼叫的服務」這幾件原本要分頭處理的事，集中到同一個介面裡。你不用從零寫一套後端，而是在它的畫布上把元件拼起來，就能得到一個能上線的 AI 應用，並且一路都看得到對話紀錄與用量，方便持續調校。這篇指南會帶你認識 Dify 的應用類型、它的編排畫布怎麼用、知識庫怎麼把你的資料變成模型查得到的內容，最後講清楚怎麼把做好的應用發佈成 API，讓你的其他系統也能呼叫它。

一、Dify 是什麼：把做 AI 應用的零件集中在同一個平台

要理解 Dify，可以把它想成「做 AI 應用的工作台」。過去要做一個 AI 應用，你得自己處理好幾塊：怎麼呼叫模型、怎麼把公司資料餵給模型參考、怎麼設計多輪對話的邏輯、怎麼把對話紀錄存下來、怎麼把成品包成一個服務給別人用。Dify 把這些零件都整合進來，讓你在一個介面裡就能完成。它是開源的，可以自架在自己的伺服器上，也有官方的雲端版本可以直接用，這對在意資料落地的團隊是個重要的選項。它最核心的價值在於「降低自己造輪子的成本」——你把心力放在設計應用的邏輯與內容上，底層那些重複又繁瑣的工程，交給平台處理。

二、四種應用類型：聊天助手、文字生成、Agent 與工作流

Dify 在你新建應用時，會先要你選一個應用類型，搞懂這幾種類型的差別，是用好 Dify 的第一步。我整理了一張對照表，幫你快速判斷該選哪一種：

這張表最該記住的是：如果你的需求是「一問一答、要記得前面講過什麼」，就選聊天助手；如果是「給一段輸入、產一段輸出、彼此不相關」的批量任務，例如把一批標題改寫，就選文字生成；如果任務需要模型自己決定去查資料、算數字、呼叫外部服務，那是 Agent 的場域；而如果你的流程有明確步驟、有條件分支，像是「先分類、分類是 A 就走這條、是 B 就走那條」，工作流類型的節點畫布會最適合。選錯類型不會讓你做不出來，但會讓你做得很彆扭，所以一開始就對準需求很重要。

三、編排畫布：把提示詞、變數與邏輯拼起來

選好類型後，你會進到 Dify 的編排介面。以最常用的聊天助手與工作流為例，核心是幾個可以拼接的元件。第一個是提示詞（Prompt），這是你給模型的指令骨幹，你可以在裡面放入變數，讓同一套提示詞能依不同輸入產生不同回應。第二個是變數與輸入欄位，你可以定義使用者要填什麼，這些值會被帶進提示詞裡。第三個是模型設定，你選用哪個模型、把溫度等參數調成多少，都在這裡決定。

工作流類型還多了一塊節點畫布，跟前面講過的工作流自動化工具神似：你把「開始、LLM 呼叫、知識檢索、條件判斷、結束」這些節點用線連起來，資料就沿著線從一個節點流到下一個。這讓你能表達比單純問答更複雜的邏輯——例如先用一個 LLM 節點判斷使用者意圖，再依意圖走不同分支，各自接不同的處理。編排畫布的精神是：把原本要寫程式才能表達的流程，變成拖拉與連線就能完成的事。

┌──────────────┐    ┌──────────────┐    ┌──────────────┐    ┌──────────────┐
│   開始節點    │ ─▶ │  知識檢索節點  │ ─▶ │   LLM 節點    │ ─▶ │   結束節點     │
│  接收使用者輸入│    │ 查知識庫找依據 │    │ 帶著依據生成回答│    │  回傳給使用者   │
└──────────────┘    └──────────────┘    └──────────────┘    └──────────────┘
       │                                                            │
       └────────────  輸入與檢索結果沿著連線往右流動  ──────────────────┘

這張圖畫的是一個典型的「帶知識庫的問答應用」骨架：使用者的問題先進到知識檢索節點，從你的資料裡撈出相關段落，再把問題與這些段落一起交給 LLM 節點生成回答，最後回傳。理解了節點之間靠連線傳資料這件事，你就能把更複雜的應用拆成一個個節點來設計。

四、知識庫：把你的資料變成模型查得到的依據

Dify 的知識庫，是讓 AI 應用「答得準」的關鍵。模型本身不知道你公司內部的文件，知識庫的作用就是把你的資料切成片段、建立索引，當使用者提問時先從這些片段裡找出相關的，再連同問題一起交給模型，讓它根據你的資料來回答，而不是憑空編。這套機制就是常聽到的檢索增強生成的應用，Dify 把建立知識庫的過程做得相當直覺。

實務上你會這樣建：先把文件（例如產品手冊、常見問答、政策文件）上傳到知識庫，Dify 會把它們切成片段並建立索引；接著在你的應用裡掛上這個知識庫，設定每次檢索要撈回幾段、相關度門檻設多少；之後使用者提問時，應用就會自動先查知識庫、再生成回答。要答得準，有兩個地方值得花心思：一是文件本身要乾淨、結構清楚，切出來的片段才會有意義；二是檢索的段數與門檻要試，撈太少可能漏掉關鍵依據，撈太多又會塞進雜訊干擾模型。

五、把應用發佈成 API：讓其他系統也能呼叫

做好的 Dify 應用，不只能在它自己的對話介面用，更實用的是發佈成 API，讓你既有的系統去呼叫。Dify 為每個應用提供 API 存取端點與金鑰，你的後端、網站或自動化工具，都可以帶著金鑰把使用者的輸入送過去，拿回模型的回應。這代表你可以在 Dify 裡專心把 AI 應用的邏輯與知識庫調好，再把它當成一個「會回答的服務」接進你原本的產品裡。

要安全地發佈成 API，有一段設定值得照做。以下是一段可放進你呼叫端的請求設定範本，把該帶的欄位都規範清楚：

【目標】呼叫 Dify 應用的對話 API，取得模型回應。
【需帶的】
  授權金鑰：放在請求標頭，妥善保管別寫死在前端。
  使用者輸入：把使用者的問題或內容放進 inputs/query 欄位。
  使用者識別：帶一個代表這位使用者的識別字串，方便分流與查紀錄。
【回應處理】
  成功時取出回答欄位顯示給使用者。
  失敗時記錄錯誤碼與訊息，給使用者一個友善的退路提示，別把原始錯誤直接丟出去。
【規則】金鑰絕不外露到前端；對外回應前先過濾敏感欄位。

這段設定沒有任何框線字元，是一段乾淨的可用設定。它的精神是：把 API 呼叫的授權、輸入、識別與錯誤處理都先想清楚，尤其是金鑰絕不能放到前端被人看到，這樣你把 Dify 應用接進產品時，才會穩定又安全。

六、導入 SOP：從一個小應用開始，調穩了再擴張

知道怎麼用各塊功能後，導入順序很重要。以下這套 SOP 可以直接照做。第一步，先把環境跑起來，決定用官方雲端版（省維運）還是自架（資料留在自己這邊），把最基本的應用建出來。第二步，挑一個範圍小、價值明確的需求當起點，例如「讓客服能問內部文件」這種，先別想著一次做出無所不能的助手。第三步，建知識庫並掛上應用，上傳幾份核心文件，把檢索段數與門檻試到答得準。第四步，在小範圍內找幾位實際使用者試用，看著真實的對話紀錄調提示詞與知識庫——這一步最容易發現你原本沒想到的問法。第五步，調穩之後再發佈成 API、接進系統、擴大涵蓋的範圍，每擴一步都重新看紀錄、重新調。

這套順序的精神跟所有自動化導入一樣：先讓一個小應用穩定運作、建立信心，再逐步把它養成涵蓋更多場景的服務。Dify 把對話紀錄與用量都攤在你眼前，正是為了讓這個「邊用邊調」的循環跑得起來。

七、ROI 評估：導入 Dify 划不划算，要看省下的開發與人力

判斷 Dify 值不值得導入，我習慣從兩條線一起算。第一條是「省下的開發成本」：如果不用 Dify，你要自己接模型、寫對話管理、做知識庫檢索、建後端 API，這些工程要花多少人天？把這些原本得自己造的輪子折算成時間，就是 Dify 直接幫你省下的部分。第二條是「省下的人力時間」：這個 AI 應用上線後，原本由人來回答的問題、由人來處理的任務，每天有多少量、每件花多少分鐘？把這些加總，就是它持續為你回收的時間。

把這兩條線的數字帶進站內的 AI ROI 計算機與自動化效益計算機跑一遍，你會得到一個比「感覺很有用」具體得多的判斷。計算的過程也會逼你誠實面對另一面：自架 Dify 有維運成本、模型呼叫本身有用量費用、調校知識庫與提示詞也要持續投入人力。把成本這一邊也老實列進去，算出來的淨效益才可信。當數字顯示某個應用省下的開發與人力，明顯蓋過建置與營運成本時，那就是該認真投入的訊號；反之，如果只是「做起來很潮」但實際用量稀少，那筆帳很可能是虧的，這種就該緩一緩。

❓ 讀完後，先問自己這幾個問題

你想用 Dify 做的第一個應用，需求範圍是不是夠小、價值是不是夠明確，小到你一兩週內就能讓它穩定運作？　引導思路：很多人第一個應用就想做「什麼都能答的萬能助手」，結果範圍太大、調不準、也看不出效益；先挑一個窄而清楚的需求，例如只回答某一類內部文件的問題，反而最快上線、最快見效。 引導思路：回頭想想這個需求背後的資料夠不夠乾淨、結構夠不夠清楚，因為知識庫答得準不準，七成取決於你餵進去的文件品質。 引導思路：也先想清楚這個應用最終要不要接進既有系統，如果要，發佈成 API 時的金鑰保管與錯誤處理就得從一開始設計好，別等接上去才補。

結語：Dify 把做 AI 應用從工程題變成設計題

Dify 最大的意義，是把「做一個 AI 應用」從一道工程題，變成一道設計題。它幫你接好了模型、管好了對話、鋪好了知識庫與 API，讓你能把心力放在真正重要的地方：這個應用要解決什麼問題、要餵它哪些資料、對話邏輯該怎麼設計。搞懂應用類型怎麼選、編排畫布怎麼拼、知識庫怎麼餵、API 怎麼發佈這幾件事，再照著「先小、調穩、再擴張」的導入順序走，你就能用相對低的成本，把一個能上線、答得準、接得進系統的 AI 應用做出來。當你開始把對話紀錄當成調校的依據，而不只是把應用做出來就放著，Dify 才真正從一個搭應用的工具，變成一個能持續長好的 AI 服務。