Dify：从 RAG 原型到可交付 AI 应用，关键不是低代码，而是工程化边界

Dify：从 RAG 原型到可交付 AI 应用，关键不是低代码，而是工程化边界

摘要：Dify 的价值不只是“拖拽做一个聊天机器人”。它更适合把知识库、RAG、Agent、Workflow、模型供应商、API 发布和日志观测串成一个可交付系统。本文基于 Dify 官方文档和 GitHub 仓库，梳理如何用 Dify 搭建一个真正能上线的 AI 应用，以及团队在发布前必须补上的治理边界。

很多团队第一次接触 Dify，是因为它看起来足够“低代码”：上传文档，接入大模型，拖几个节点，一个智能客服或知识库问答应用就能跑起来。但如果只把 Dify 理解成低代码工具，很容易低估它的真正价值，也容易把项目做成一个不可维护的演示品。

Dify 更适合被理解为 AI 应用工程平台。它把几类原本分散的能力放到一起：模型接入、Prompt 编排、知识库、Workflow、Agent、工具调用、API 发布、日志与分析、自托管部署。对开发者来说，它减少了从零搭建 RAG 和 Agent 应用的基础工作；对产品和运营团队来说，它提供了一个可以共同调试、复盘和迭代的工作台。

但这不代表“不会写代码也能随便上线 AI 系统”。真正可交付的 AI 应用，不只是模型能回答，还要回答得准、出错可查、成本可控、权限清楚、有人兜底。Dify 降低了构建门槛，却没有取消工程治理。

先把知识整理好，再谈智能问答

做 RAG 应用最常见的错误，是把一堆 PDF、网页、FAQ 和内部文档直接丢进知识库，然后期待模型自动变聪明。Dify 的知识库文档提供了创建知识、导入文档、分段清洗、索引方式、测试检索等能力；这些能力的核心不是“上传越多越好”，而是让资料变成模型能稳定检索的结构化上下文。

一个靠谱的知识库项目，应该先整理资料来源。哪些文档是最新版本？哪些文档已经过期？产品政策、价格、售后规则是否存在互相矛盾的版本？如果源资料本身混乱，RAG 只会更快地把混乱暴露给用户。

其次是分段和检索策略。过长的分段会让回答混杂，过短的分段会丢失上下文。Top K、相似度阈值、重排模型、元数据过滤，都影响最终答案。团队不应该只看一次问答是否命中，而要建立测试问题集：常见问题、边界问题、故意误导问题、过期政策问题都要测。