昨天我們成功將專案的 README 與開發者文件切塊並轉換為向量，建立了一個精準的知識庫。但知識庫本身只是安靜躺在伺服器裡的資料，今天我們要進入 Dify 的「工作室 (Studio)」，為這些資料賦予靈魂，打造出能與使用者互動的 Chatbot 應用程式！

1. 建立聊天助手 (Chatbot) 應用
進入 Dify 的 Studio 介面，點選「建立空白應用」，並選擇「聊天助手」。
Dify 提供了多種應用類型，對於「新人開發環境問答」這種一問一答的單純情境，基礎的聊天助手已經非常足夠。建立完成後，我們將進入應用程式的編排畫布。

2. 撰寫系統提示詞 (System Prompt)
還記得我們在 Day 3 探討的防呆機制嗎？這裡就是發揮 Prompt Engineering 實力的地方。
在「提示詞」區塊中，我們要為這個 AI 確立嚴格的人設與行為邊界：

「你是一位友善的資深軟體工程師，負責協助新進員工熟悉專案環境。
請『嚴格遵循』上下文提供的知識庫內容來回答問題。
如果知識庫中沒有相關資訊，請直接回答：『目前文件尚未涵蓋此部分，請直接在 Slack 詢問架構師。』絕對禁止自行編造答案。」

這段 Prompt 確立了 AI 的語氣，同時設立了防止幻覺的最後一道防線。

3. 掛載知識庫 (Context Injection)
這是整個 Dify 操作中最神奇的一步。在提示詞區塊的下方，找到「上下文 (Context)」設定，點擊新增並選取我們昨天建好的 README 知識庫。
在底層，Dify 會自動幫我們完成複雜的 RAG 管線整合：當新人輸入問題時，系統會在背景呼叫 Embedding 模型、向向量資料庫檢索關聯 Chunk，並將撈出來的文件段落動態替換到 Prompt 裡，再一起送給大語言模型。過去需要寫幾百行 Java 程式碼才能串接的流程，現在只需點擊滑鼠即可完成。

4. 預覽除錯與一鍵發布
設定就緒後，直接在畫面右側的預覽視窗進行測試。輸入昨天的經典問題：「我在 Windows 部署時一直連不到資料庫，.env 檔應該檢查哪些參數？」
此時，你不僅會看到 AI 根據文件給出精準回覆，回覆氣泡框下方還會顯示一個「引用來源 (Citations)」標籤，明確標示它參考了知識庫中的哪一段文字。這對於除錯與驗證精準度來說極度重要。

測試無誤後，點擊右上角的「發布」。Dify 會立刻為你生成一個獨立的 Web 網頁連結供新人直接使用，同時也提供標準的 RESTful API Endpoint，方便後端工程師將這個助手整合到企業內部的現有系統中。

恭喜你！我們順利完成了第一套能實際上線服役的 RAG 應用程式。

然而，這個 Chatbot 目前只能「被動回答問題」。如果今天新人不僅想問問題，還希望 AI 能「自動幫他發送 GitHub 權限申請信」，或是「根據他的提問自動去查詢外部的 JIRA 系統」呢？純文字對話的 Chatbot 無法執行這些動作。

明天 [Day 14]，我們將晉升到 Dify 的最高殿堂：工作流 (Workflow) 與工具調用，讓 AI 長出雙手，開始執行多步驟的複雜任務！