[Dify] 導入的血淚後續

 Dify 雖然介面漂亮、整合了 RAG（知識庫），但在深度自動化和本地部署的玩家眼中，它有幾個讓人崩潰的「坑」：

---

1. 記憶體食蟻獸 (Memory Hog)

這是自架玩家最大的血淚。Dify 不是一個單一程式，它是一群服務的集合：

• 前端 (Web) + 後端 (Api) + Worker (非同步處理) + Redis (快取) + PostgreSQL (資料庫) + Vector DB (向量庫) + Sandboxed Code Executor。

• 血淚點：如果你要在 Pi4 上跑 Dify，基本是「自殺行為」。即便有 8GB RAM，光啟動這堆 Docker 容器就會卡死，更別提執行時的 Swap 噴發。相較之下，n8n 一個容器就能跑完九成功能。

2. 「假」工作流的挫折感

Dify 的 Workflow 雖然看起來像 n8n，但邏輯封閉很多：

• 資料傳遞：在 n8n 你可以隨意用 JavaScript 揉捏 JSON；在 Dify，變數型態檢查極其嚴格，常常為了傳一個字串弄到整條 Flow 報錯。

• 循環與邏輯：Dify 早期版本幾乎沒辦法做複雜的 Loop（循環），如果你要批次處理 50 筆 539 的歷史數據，Dify 會讓你寫到想哭，而 n8n 的 Split In Batches 才是真正的自動化工具。

3. RAG 的「黑盒子」陷阱

Dify 強調「上傳文件就能對話」，這很吸引人，但：

• 血淚點：當 AI 回答錯誤時，你很難調試它是「檢索不到」、「切片太碎」還是「Prompt 太爛」。

• 成本：Dify 的自動切片（Chunking）會消耗大量 Embedding Token，如果你頻繁更換文件測試，帳單會讓你心痛。

4. 版本更新的「驚喜」

Dify 更新極快，這本來是好事，但：

• 血淚點：經常發生更新後 Docker Compose 啟動失敗，或是舊的 Workflow 節點突然不相容。對於追求「設定完就讓它自動跑 24 小時」的開發者（像你打算在 Pi4 上做的那樣）來說，Dify 的維護成本遠高於 n8n。