一句话判断

要做的是一个「产品」而不是一段脚本——需要知识库、多轮对话、调用记录、效果标注这些配套设施时，自己搭不如用它。

Dify 是一个 LLMOps 平台，把做 AI 应用常用的几件事做成了产品：提示词编排（Prompt IDE，改完直接对比效果）、知识库（上传文档、切片、检索、重排）、工作流画布（串条件分支、代码、HTTP、工具）、Agent（给模型配工具让它自己规划），以及日志与标注（看每次调用的完整链路，把好答案标成高质量回复喂回去）。

它最大的价值在于「闭环」。自己做 RAG demo 很容易，但要回答「用户问了什么、检索到了什么、为什么答错」就需要可观测性，Dify 这套日志是现成的。另外它把应用直接发布成 API，前端或第三方系统接一个 endpoint 就能用，不用自己写服务层。

和直接写代码相比，它的代价是抽象层带来的限制。复杂业务逻辑在画布上会变成一张难读的网，最终还是要靠 Code 节点兜底。它的 RAG 默认配置也只能算及格：切片长度、检索模式（向量 / 全文 / 混合）、要不要加重排模型，这几项不调，效果通常不如预期。

部署上它比较重。官方 docker compose 会起十来个容器（含 Postgres、Redis、向量库、Nginx、沙箱、插件守护进程），对内存有要求，小机器会吃力。升级也需要按版本顺序走，跳版本容易出问题。

能拿它做什么

客服/问答机器人：产品文档进知识库，直接发布成 API 接进官网
内部工具：报销问答、政策查询、代码库检索
结构化抽取：从合同、简历、发票里抽字段，输出 JSON
快速验证：一个想法半天做成可点击的应用，拿去问客户要不要

怎么用起来

git clone https://github.com/langgenius/dify && cd dify/docker && cp .env.example .env && docker compose up -d
打开 http://localhost/install 设管理员账号
右上角设置里配模型供应商：可以填 OpenAI 兼容地址，也可以填本地 Ollama / Xinference
建知识库 → 上传文档 → 调切片与检索模式 → 新建 Chatflow 应用绑定知识库 → 发布为 API

官网在 dify.ai ，源码在 GitHub 仓库 ↗。

坑在哪

注意

多租户 SaaS 化转售有限制，自用没问题。