昨天我們成功讓 AI 熟讀了專案的 README，打造出能回答環境設定問題的 Chatbot。然而，在企業的真實開發場景中，新人遇到的阻礙往往不僅是「不知道怎麼做」，而是「沒有系統權限」。

如果新人提問：「我連不上測試區的資料庫」，昨天的 Chatbot 只能冷冰冰地回答：「請查閱文件，並向系統管理員申請權限。」

但這並沒有真正解決痛點。身為具備系統整合思維的工程師，我們希望 AI 能更主動：「發現您遇到連線問題，判斷為權限不足。請問需要我自動發送 Slack 通知向管理員申請權限嗎？」

要讓 AI 從「只會說話的嘴巴」進化成「能執行任務的雙手」，我們今天就要踏入 Dify 的進階殿堂：工作流 (Workflow) 與 工具 (Tools)。

1. 告別黑盒子：視覺化定義 SOP
在 Dify 建立專案時，如果選擇「工作流 (Workflow)」模式，你面對的將不再是單一的提示詞對話框，而是一塊無限大的畫布。在這裡，我們不再依賴 AI 自由發揮，而是將工程上的 SOP (標準作業流程) 拆解成一個個節點 (Nodes)。

在畫布上，你可以將資料流設計為：
開始節點 (Start) -> 知識庫檢索 (Knowledge Retrieval) -> 大模型分析 (LLM) -> 結束節點 (End)。
這本質上就是把我們 Day 8 到 Day 10 手刻的 RAG 程式碼，變成了拖曳式的流程圖。

2. 意圖分類器 (Question Classifier)
為了實現剛才的情境，我們可以在流程中加入「問題分類器」節點。這是一個專門判斷條件的輕量級 LLM。
我們可以設定兩條路徑：

路徑 A (一般技術問題)： 走向 RAG 知識庫檢索，回答 README 內容。

路徑 B (權限申請)： 走向 HTTP 請求節點。

3. HTTP 請求節點：系統整合的橋樑
當流程走向路徑 B 時，重頭戲就來了。Dify 內建的 HTTP 節點允許你像使用 Postman 一樣，發送 RESTful API 請求。

Method: POST

URL: https://hooks.slack.com/services/YOUR/WEBHOOK/URL

Body (JSON): 透過變數綁定，將新人的名字與申請的權限內容，組裝成 JSON Payload 發送給 Slack。

當新人送出請求後，Dify 會在背景執行這套工作流，精準觸發企業內部的 Slack Webhook，甚至能進一步呼叫 JIRA 的 API 自動開立一張工單 (Ticket)。

透過今天的實作，我們見證了 AI 如何從一個文字生成工具，轉變為微服務架構中的「智慧型路由器 (Router)」與「觸發器 (Trigger)」。

然而，當企業內部的自動化需求越來越複雜，需要同時串接 Gmail、Google Calendar、Notion 與數十個內部 API 時，Dify 的畫布可能會變得過於龐大難以維護。

對於極度複雜的自動化任務，我們需要更專業的自動化整合工具。明天 [Day 15]，我們將介紹開源自動化界的神器：n8n，並探討它如何與我們的大模型完美搭配！