不想写代码就想让 AI 用上公司文档Dify 是目前国内落地率最高的那条路。这篇讲清知识库怎么建才准、工作流怎么编排才不答非所问、私有模型怎么接、以及 Dify 做不了的事该用什么补。文章目录一、先定位Dify 适合什么、不适合什么二、部署三分钟起一个私有实例三、接入私有模型以 vLLM/Ollama 为例四、建知识库准不准全看这一步4.1 分段设置决定检索质量4.2 索引方式怎么选4.3 文档预处理技巧五、应用编排三种模式怎么选六、工作流编排实战客服问答流水线七、Prompt 编排的四个细节八、上线与运维九、Dify 的天花板在哪十、上线前检查清单一、先定位Dify 适合什么、不适合什么需求Dify直接写代码快速验证某个 AI 应用想法★★★★★★★非技术同事要自己维护 Prompt/知识库★★★★★★流程有复杂分支、循环、外部系统耦合★★★工作流可做但会有天花板★★★★★极致性能、精细控制 token 与并发★★★★★★★私有化部署、数据不出内网★★★★支持私有部署★★★★★结论Dify 是「把验证周期从两周压到两小时」的工具。它替代不了代码但能让你先跑出可用的原型再决定哪部分值得用代码重写。二、部署三分钟起一个私有实例gitclone https://github.com/langgenius/dify.gitcddify/dockercp.env.example .envdockercompose up-d访问http://localhost:80首次进入让你设管理员账号。生产必改三项都在.env里配置项默认建议SECRET_KEY随机生成换成自己的长随机串备份好改了这个所有会话失效DB_PASSWORD/REDIS_PASSWORD弱密码改成强密码CONSOLE_API_URL/APP_WEB_URL空填公网域名否则分享链接会指向 localhost踩坑docker compose up -d卡在拉镜像配一下 Docker 国内镜像源80 端口冲突就改.env里的EXPOSE_NGINX_PORT。三、接入私有模型以 vLLM/Ollama 为例Dify 自带模型供应商里没有「本地模型」这一项走「OpenAI-API-compatible」这条通用通道右上角头像 → 设置 → 模型供应商 → 找到OpenAI-API-compatible→ 添加模型填写字段值说明模型名称qwen-local自定义随便起你在 Dify 里看到的模型名API Base URLhttp://宿主机IP:8000/v1必须带/v1模型类型LLM嵌入模型选 Text EmbeddingAPI Key随便填非空值vLLM 无鉴权时不校验但 Dify 强制要求非空保存后在「系统模型设置」里把默认 LLM 和 Embedding 都切到本地模型。最容易踩的两个坑Dify 跑在 Docker 里localhost指的是容器自己。填localhost:8000必然连不上要用宿主机真实 IP或host.docker.internalEmbedding 模型和 LLM 是两回事。本地只起了 LLM知识库还是调不通——要么再起一个嵌入服务可用 Ollama 的bge-m3要么知识库用云端嵌入。# 用 Ollama 起一个本地嵌入服务供 Dify 知识库使用ollama pull bge-m3# 然后在 Dify 里再添加一个 OpenAI-API-compatible 供应商类型选 Text Embedding# Base URL 填 http://宿主机IP:11434/v1模型名填 bge-m3四、建知识库准不准全看这一步4.1 分段设置决定检索质量新建知识库 → 上传文档 → 选择分段模式模式适用关键参数通用分段大部分文档分段标识符\n\n最大长度 500-1000重叠 50-100父子分段长文档、技术手册子段 300-500 检索父段完整喂给模型QA 分段已有 FAQ 表CSV 两列问题 / 答案命中率最高经验值中文文档最大分段长度 500 字左右、重叠 50-80 字与昨天那篇《RAG 从零到生产》的结论一致——分段太长噪声多太短上下文断。4.2 索引方式怎么选索引检索方式特点高质量向量检索语义理解好慢一些、耗 token经济关键词快、便宜、专有名词准混合检索推荐向量 关键词 Rerank效果最好生产首选开混合检索后记得把 Rerank 模型配上Dify 内置了几个可选也可以接本地 reranker 服务。这一步的收益通常比换更好的 LLM 更大。4.3 文档预处理技巧表格类文档直接传 Excel 比传 PDF 效果好得多PDF 表格解析后往往错行扫描件Dify 不负责 OCR先用 OCR 工具转成文本再传大文档分批传一个 500 页的手册一次性上传解析容易失败按章节拆成几个文件传完做验证用知识库自带的「召回测试」输入几个真实用户问题看召回片段的命中情况——这是上线前必做的一步。五、应用编排三种模式怎么选Dify 提供四类应用用途完全不同类型结构适合聊天助手一问一答 知识库简单客服问答Agent模型自主决定调哪个工具需要多工具协作、灵活推理工作流Chatflow / Workflow你画流程图节点固定业务流程明确、要可控文本生成单次输入输出文案批量生成、摘要关键判断流程固定的用工作流不确定的用 Agent。企业场景 90% 属于前者——因为可控、可审计、成本可预测。六、工作流编排实战客服问答流水线一个能打的客服工作流长这样节点顺序即数据流向开始 └→ 问题分类LLM判断咨询 / 投诉 / 退换货 / 其他 ├─ 退换货 → 知识库检索 → LLM 生成 → 条件判断是否有答案 │ ├─ 有 → 直接回复 │ └─ 无 → 转人工 ├─ 投诉 → 情绪安抚 Prompt → LLM 生成 → 转人工工单节点 └─ 其他 → 知识库检索 → LLM 生成 → 回复 └→ 结束每个节点的关键配置问题分类节点用一个小模型便宜 分类 Prompt要求只输出类别名。分类 Prompt 里把四类的判定标准和例子写清楚准确率能到 95%你是意图分类器。只输出以下之一不要任何其他文字 咨询 / 投诉 / 退换货 / 其他 判定标准 - 退换货涉及退货、换货、退款、物流破损 - 投诉含不满情绪、要求上级处理、威胁差评 ...知识库检索节点开启「Rerank 模型」召回条数设 3-5score 阈值 0.5 起调LLM 生成节点System Prompt 里强制约束只依据【知识库内容】回答没有就直接输出「__NO_ANSWER__」。然后在条件分支里判断这个特殊标记走「转人工」——这是防幻觉最简洁的兜底手段兜底节点转人工或用固定话术绝不允许模型自由发挥。变量传递要点每个节点输出要给它起个明确变量名category、retrieved_docs、answer下游节点用{{#节点名.变量名#}}引用。工作流调试 80% 的时间花在变量名对不上。七、Prompt 编排的四个细节开场白与建议问题别写「你好有什么可以帮你」——写具体场景如「我是 XX 产品客服可以帮你查订单、退货政策、发票问题」直接提升用户提问质量上下文变量把用户昵称、会员等级、历史订单作为变量注入回答立刻「有人味」引用与归属开启「引用归属」答案带来源文档链接企业场景里能建立信任、减少责任风险降级话术给每个可能失败的环节写兜底文案用户看到「我暂时没查到已为你转人工」远好于看到报错。八、上线与运维发布为 WebApp / 嵌入网站Dify 直接给 iframe 代码粘到官网即可API 方式接入已有系统用「API 访问」拿到 key按 OpenAI 格式调用日志与标注聊天日志里可以人工标注「回答好/差」这些标注数据就是未来微调见昨日《微调实战》的种子数据——Dify 用久了天然攒出一份微调数据集成本与限流在「模型设置」里配好 token 上限对外暴露的应用务必加访问频次限制防止被刷备份Dify 全套数据在 Docker volume 里定期备份dify/docker/volumes尤其是db与storage。九、Dify 的天花板在哪用了半年后的几个诚实结论复杂分支逻辑会很难维护。工作流画到 30 个节点以后改一处怕踩十处这时该用代码重写成 LangGraph见《LangGraph 多智能体编排实战》精细的成本控制做不到。你想按用户等级走不同模型得靠多个应用实例拼性能上限有限。高并发场景 Dify 单实例会成为瓶颈需要多副本 网关分流。最佳实践是组合拳Dify 负责「快速验证 非技术同事可维护的部分」等某个流程稳定且流量变大再用代码重写那一段两者通过 HTTP API 互相调用。别硬扛也别一开始就上代码。十、上线前检查清单知识库做过「召回测试」真实问题命中率达标应用已切换到私有/自建模型数据不出内网兜底话术与转人工路径都走通故意问一个知识库里没有的问题测一遍每个节点变量名检查过无undefined引用归属已开启访问已加频次限制.env里敏感项已改过volumes 已纳入备份。Dify 最大的价值不是省代码而是把「AI 能不能解决这个业务问题」的验证成本压到几乎为零。
