昨天我們快速瀏覽了 Dify 的核心介面，今天我們要直接進入實戰！

在軟體開發團隊中，最讓資深工程師頭痛的往往不是寫程式，而是每當有新人加入時，總要花大量時間協助他們處理環境建置、解釋 .env 參數或是 Docker 部署的報錯。如果我們能把龐大的專案 README 與開發者文件 (Developer Documentation) 餵給 AI，打造一個專屬的「新人 Onboarding 助手」，就能大幅解放團隊的生產力。

今天，我們就來體驗 Dify 如何將 Day 8 與 Day 9 探討的底層邏輯，轉化為優雅的視覺化操作。

Step 1：準備你的知識糧草
首先，準備一份具有一定複雜度的專案說明文件（例如 Markdown 格式的 README.md 或 PDF）。這份文件裡面應該包含：

專案的架構簡介與依賴套件 (Prerequisites)。

本地端 (如 Windows 環境) 透過 Docker 啟動的 CLI 指令。

環境變數 (.env) 的詳細說明與預設值。

Step 2：在 Dify 建立知識庫 (Knowledge Base)
登入 Dify 後，點擊上方的「知識庫」並選擇「建立知識庫」。將你的 README 檔案拖曳上傳。接下來的畫面，就是展現 Low-code 魅力的時刻：

分段與清洗 (Chunking & Cleaning)： 還記得我們在 Day 9 辛苦討論的字串切割邏輯嗎？在 Dify 裡，你只需要選擇「自動分段與清洗」。系統會自動辨識 Markdown 的標題 (##) 與段落進行語意切塊 (Semantic Chunking)，確保程式碼區塊不會被硬生生切斷。

索引方式選擇： 選擇「高品質 (High Quality)」。這會呼叫我們設定好的 Embedding 模型（如 OpenAI 的 text-embedding-3-small），在背景將所有切塊轉換為向量，並存入 Dify 內建的向量資料庫中，完全不需要我們手刻 Faiss 的連線程式碼。

Step 3：召回測試 (Hit Testing) 的驗證時刻
資料庫建好後，千萬不要急著去寫對話介面。身為工程師，我們必須先進行單元測試。
進入知識庫的「召回測試」面板，這其實就是在測試我們 Day 8 提到的向量搜尋精準度。
輸入一個具體的問題，例如：「我在 Windows 本地端用 Docker 部署時，一直連不到資料庫，請問我的 .env 檔應該檢查哪些參數？」

按下測試，如果設定正確，你應該會看到 Dify 瞬間從龐大的 README 中，精準撈取包含 .env 設定 與 Docker troubleshooting 的那幾個 Chunk，並顯示它們的相似度分數。

走到這一步，我們的 AI 已經不再是只會講幹話的通用模型，而是熟讀你專案規格的資深架構師了！

然而，知識庫本身只是被動的「資料庫」，它還無法主動跟使用者對話。明天 [Day 13]，我們將進入 Dify 的「工作室 (Studio)」，把今天建好的知識庫掛載到 Chatbot 應用程式上，讓這個新人 Onboarding 助手正式上線服役！