上周五下午，老板突然扔过来一个需求：给公司内部的知识库做一个智能问答助手，要求三天内上线。我原本想用LangChain + OpenAI硬撸，但一想到要写文档切分、向量化、检索排序、Prompt模板、对话管理……手就开始抖。翻GitHub时看到Dify已经15万星了，心想“不如试试这个号称十分钟搭RAG的工具”。结果一上手就停不下来，从部署到跑通第一个问答，只用了三小时。今天不吹不黑，聊聊我的真实踩坑经历和硬核对比。
一、Dify是什么？为什么选它？
Dify（langgenius/dify）是一个开源的低代码AI应用开发平台，主打构建Agent工作流、RAG流水线，支持多种大模型（OpenAI、Claude、本地模型等）。它用TypeScript写的，但通过Docker部署后，你只需要在浏览器里拖拽组件就能完成一个完整的AI应用。相比LangChain需要手写代码，Dify更像一个“可视化版LangChain”。
选择它是因为：
- Stars高（15万+），社区活跃，问题解决快
- 内置了RAG全套（文档解析、分块、向量检索、重排序）
- 支持工作流画布，可以串联多个工具和模型
- 有API接口，方便集成到现有系统
二、从零到一：我用Dify搭了一个客服问答机器人
1. 部署与初始化
官方推荐用Docker Compose一键部署。我的环境是Ubuntu 22.04 + Docker 24.0.7。直接克隆仓库并启动：
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
等30秒后访问 http://localhost:3000，注册管理员账号，完成。
⚠️ 注意：默认使用SQLite，生产环境建议用PostgreSQL，在.env里改一下DB配置即可。
2. 创建知识库
上传公司的产品文档（PDF/Word），Dify自动解析成文本。我选了“General”模式，分块大小设为500字符，重叠50字符。然后选择向量模型——我用的OpenAI Embedding（你也可以选本地模型如BGE）。
关键配置项：
- 检索策略：我选了“Top-K + 权重融合”，K=5，语义相似度阈值0.6
- 重排序模型：Dify支持Cohere Rerank，但我没有Key，就关了
3. 搭建工作流
工作流画布让我眼前一亮。拖了一个“开始”节点，连接“知识库检索”，再连“LLM”节点。在LLM节点里，我自定义了Prompt：
你是一个专业的客服助手。请根据以下知识库内容回答用户问题。
如果知识库中没有相关信息，请说“我不清楚”。
知识库内容：
{{#knowledge_retrieval.result}}
用户问题：{{#sys.query}}
模型选了Claude 3.5 Sonnet（通过OpenRouter接入），温度0.1。保存后点击“预览”，输入“退换货流程是什么？”——居然回答得和官方文档一字不差！
三、好用在哪？四个让我惊喜的点
- 可视化救星：不用写一行代码就能串联检索、模型、工具（比如可以加一个“查天气”工具）。对于非程序员同事也能快速上手。
- 多模型无缝切换：我同时测试了OpenAI和本地部署的Qwen2-7B，只需要在下拉框里选一下，不用改代码。
- 内置运维工具：日志面板能看到每次请求的耗时、Token消耗、检索命中的文档片段，方便调试。
- API覆盖全面：生成的API支持流式输出、对话历史，适合集成到钉钉/飞书/网页。
四、【我遇到的坑】
下面这些坑，我至少花了两个小时才爬出来：
坑1：中文分块导致语义丢失
默认的RecursiveCharacterTextSplitter对英文友好，但对中文，500字符一块经常把一句话切断，导致检索召回时上下文不完整。解决办法：手动把分块大小改成200，重叠80，并启用“中文字符保留”，效果好了很多。
# 在Dify后台的知识库设置中，分块参数改为：
chunk_size: 200
chunk_overlap: 80
separators: ["\n\n", "\n", "。", "！", "？", ".", " "]
坑2：向量模型选择失误
一开始用OpenAI的text-embedding-3-small，但公司数据敏感，换成本地的BGE-M3。结果Dify官方镜像里默认的向量数据库是Qdrant，需要手动配置才能支持本地模型。折腾了好久，最后在.env里加了一行VECTOR_STORE=elasticsearch并用ES的dense_vector字段才解决。
坑3：工作流中的变量引用
在自定义Prompt里，我直接写了{{knowledge_retrieval.result}}，但Dify的变量名大小写敏感。官方文档写的是{{#knowledge_retrieval.result}}，带了个#，我第一次没注意，结果LLM始终拿不到内容。后来看了社区帖子才改对。
坑4：高并发下Qdrant内存爆炸
测试时只用了1个用户并发，上线后10个用户同时问答，Qdrant容器内存占用飙到4GB，直接OOM。后来把Qdrant的memory_map改为false，并且限制了最大连接数才稳定。
建议：生产环境一定要给Qdrant分配足够的资源，或者换用Pinecone/Weaviate等云服务。
五、跟竞品比怎么样？
| 对比维度 | Dify | LangChain | Flowise | Coze（商业） |
|---|---|---|---|---|
| 上手难度 | ⭐ 极低（3小时） | ⭐⭐⭐⭐ 高 | ⭐⭐ 中 | ⭐ 低 |
| 可视化能力 | 强，支持工作流画布 | 无 | 强，但节点类型少 | 强，但工作流受限 |
| 模型支持广度 | 极广（几乎所有主流模型） | 极广 | 中（主要OpenAI/Claude） | 小（仅自家平台模型） |
| 本地部署 | 完全开源 | 官方无UI，需自行开发 | 开源 | 仅云服务 |
| RAG效果 | 良好，但中文调优需手动 | 灵活但需要代码 | 一般 | 良好，但受限于模型选择 |
| 社区生态 | ⭐ 15万星，插件丰富 | 更成熟，教程多 | 3万星，活跃 | 官方支持 |
结论：如果你不想写代码、追求快速落地，Dify是目前开源的最佳选择。LangChain更适合深度定制和学术研究，Flowise适合简单对话，Coze适合纯云端用户。
六、什么场景适合用Dify？
- 企业内部知识库问答：把公司文档、制度、FAQ喂进去，5分钟一个客服机器人。
- 自动化内容摘要：用工作流连接网页抓取工具+LLM，自动生成每日简报。
- 多工具协作Agent：比如“帮我查一下天气预报，然后安排今天的日程”——串联天气API和日历工具。
- 个人AI助手：联网搜索、写邮件、翻译……集成到Telegram或微信。
不适合：需要极致实时性（延迟>2秒）、需要自定义微调模型、需要极度复杂的多轮对话状态管理。
七、结尾：我的建议
如果你是小团队或个人开发者，想快速搭建一个靠谱的RAG应用或Agent，Dify是当前最优解。它把大部分通用逻辑封装好了，你只需要关心数据和Prompt。但别被“10分钟搭AI应用”的宣传骗了——真正生产化时，分块策略、模型选型、并发优化依然要花时间调优。
最后给几个实用Tips：
- 先用官方演示数据跑通全流程，再替换自己的数据。
- 中文场景优先选择本地向量模型（BGE/Stella）并调大重叠长度。
- 关注Dify的版本更新，V0.11之后新增了“条件分支”“循环”节点，工作流能力又上了一个台阶。
- 加入Dify的Discord社区，问题回复速度比GitHub Issue快10倍。
好了，我要去把公司的历史工单数据也导入Dify了。如果你也踩过坑，欢迎在评论区互舔伤口。