小雨果1号Dify做AI应用开发，最近是真火。我大概是从0.6版本开始玩的，眼看着它从一个小众工具变成现在社区里大几十万星的项目，身边不少做后端、做产品甚至做运营的朋友都在问怎么上手。这轮我把标题里的三个核心词拆开——Prompt工程、AI工作流、生产级，结合我这段时间在真实项目里用Dify踩过的坑和沉淀下来的方法论，整理成一篇偏实战的记录。你如果是刚接触Dify，或者已经搭好了环境但不知道怎么把它用到正经业务里，这篇文章应该能帮你省下不少弯路。
1. 项目认知：Dify到底解决了什么问题
1.1 为什么选Dify而不是自己写代码调API
先聊点实在的。过去我们做大模型应用，常规路径是：选一个模型（ChatGPT、Claude、文心、通义、百川都行），然后写代码调API，把Prompt写在代码里，自己维护会话状态，自己处理上下文截断，自己写前端聊天框，再自己接知识库做向量化。这套流程走一遍，光基础设施就要折腾两周。而且最头疼的是，Prompt稍微改一个字，都要改代码重新部署。
后来大家开始用LangChain这类框架，能省一部分事，但LangChain的学习曲线陡，而且抽象层级太高，出了问题排查起来非常痛苦，尤其是那些回调、链、代理的概念，新手上手真的容易劝退。
Dify走的是另一条路：它把大模型应用开发里最重复、最容易出错的那些模块（模型接入、Prompt编排、知识库、工作流、日志）全部做成了可视化界面，你只需要关注业务逻辑本身，不用关心底层请求怎么拼、消息怎么存、向量库怎么连。我用它的第一个项目，大概三天就上线了。换做纯代码方案，三周都不一定稳。
1.2 Dify的核心模块和适用边界
Dify核心有这几个模块：应用编排（聊天助手、Agent、文本生成）、知识库、工作流、工具接入、模型管理、日志与标注。
这六个模块基本覆盖了绝大多数大模型应用的开发场景。聊天助手适合做客服、陪聊、问答；Agent能调用外部工具；文本生成适合写文章、写周报、做翻译；知识库是做RAG（检索增强生成）的关键；工作流是Dify的进阶玩法，后面会重点讲。
需要说明的是，Dify不是万能的。它不适合做非常重度定制的模型训练和微调，也不适合对实时性要求特别高的场景。它是应用层面的开发平台，解决的是“模型能力如何快速变成产品能力”的问题，模型训练那层的活它不干。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 生产环境起步：部署与模型接入
2.1 单机起步：用Docker Compose把Dify跑起来
Dify最舒服的部署方式就是Docker Compose。官方仓库帮我们把编排文件准备好了，git clone下来之后，docker compose up -d就能跑起来。但有几个关键点，第一次部署的人容易掉坑里。
第一个坑是版本选择。我建议你直接用最新的release版本，不要用main分支的代码。release版本是经过测试的，main分支可能夹带一些开发中的bug。去GitHub的releases页面看最新的tag，比如1.x.x，把对应版本的代码拉下来。第二个坑是系统资源。Dify全量启动包含api、worker、web、db（PostgreSQL）、redis、weaviate（向量数据库）、nginx大概7个容器，4核8G的内存能跑，但会比较紧张。生产环境建议至少8核16G起步。第三个坑是端口冲突，默认nginx会占用80端口，如果你机器上已经跑了别的服务，记得先改掉。
启动完成之后，浏览器打开http://你的服务器IP，设置管理员账号密码，基本就完成了环境搭建。整个过程熟练的话10分钟搞定。
我用的是Docker Compose方式部署在Linux服务器上。如果你想在Windows上跑，可以用Docker Desktop，但兼容性会差一些，遇到问题优先查日志。
2.2 模型接入：不只是填一个API Key那么简单
Dify支持几十种模型接入，包括OpenAI、Azure OpenAI、Anthropic Claude、Google Gemini，也包括国内的通义千问、智谱GLM、百川，开源社区常见的Ollama、Xinference也都支持。
实操层面，模型接入分为两大类。一类是云端托管API，填个API Key和Base URL就行；另一类是本地部署模型，通过Ollama这类工具暴露一个本地接口给Dify用。
我想重点说说Ollama+Dify这套组合。这套组合特别适合不想付费调API、想私有化部署、或者网络环境不方便访问云端API的场景。
在Ollama上拉取一个模型，比如qwen2.5:7b，然后Dify的模型供应商里选择Ollama，Base URL填写http://你的宿主机IP:11434。这里有个最容易踩坑的点：如果你Dify也是跑在Docker里的，那么Base URL一定不能填localhost或者127.0.0.1，因为Docker容器里的localhost指的是容器自己，而不是宿主机。要填宿主机的局域网IP或者宿主机在Docker网络里的IP。我第一次配的时候填了localhost，折腾了半小时才发现这个细节。
模型选择上，生产环境用云端API省心，但成本不好控制；本地模型隐私好、成本低，但推理效果和云端顶级模型还是有差距。我给的建议是：核心业务逻辑尽量用强的云模型（特别是复杂推理），量大的预处理任务可以拆给本地小模型跑，两个配合着用。这个后面讲工作流的时候会再提到。
3. Prompt工程实战：别在聊天框里调Prompt
3.1 为什么说Dify里的Prompt和你在网页上聊的Prompt不一样
只要你用过ChatGPT网页版，就一定试过不断修改Prompt让回答更准确。那个过程在Dify里也是一样的逻辑，但生产环境完全不能照搬网页版的玩法。
网页版聊天是单轮对话，你自己临时想怎么调就怎么调。但生产环境里的Prompt是给所有用户共用的，你需要考虑变量、上下文、历史对话、知识库检索结果这些动态因素。换句话说，你要把Prompt写成一套“模板”，而不是一句固定的话。
Dify的Prompt编排里，最核心的概念是变量。变量外面包着大括号，比如{{query}}，在运行时会被用户的实际输入替换。这是它和网页版Prompt最大的区别。
我来展示一个生产级Prompt的写法。假设我们要做一个面向特定企业的“智能客服质检助手”，它的工作是对客服对话记录进行质检评分。
code复制你是企业的客服质检专家。你收到的内容是客服和用户的完整对话。
请从以下维度进行评分（每个维度满分为10分）：
1. 响应时效性：客服是否及时回复
2. 服务态度：语气是否礼貌、专业
3. 问题解决率：是否真正解决了用户的问题
4. 合规性：是否存在违规承诺或敏感言论
对话内容：
{{conversation_text}}
要求：
- 按JSON格式输出结果，包含total_score和每个维度的分数
- 对得分低于6分的维度，给出具体原因
- 最后给出改进建议，不超过100字
这段Prompt里{{conversation_text}}就是变量。用户输入一段对话记录进去，模型就会自动按照这个标准打分。这套Prompt不是你临时在网页上脑补出来的，而是要经过多轮测试、优化，最后固定下来变成产品逻辑的一部分。
3.2 优化Prompt的三个实操技巧
我这几年的经验，Prompt优化其实是有章法的。Dify发布功能本身也提供了调试预览窗口，每改一次Prompt，右边可以立刻跑一遍测试。这个反馈循环特别值钱，做Prompt工程一定要利用好。
第一个技巧，给模型设“人设+任务边界”双重定位。你要让模型明白它是什么角色、能做什么、不能做什么。不要让它觉得自己是个万能AI聊天机器人，否则边界感会非常差。
第二个技巧，把限制条件写清楚。很多人觉得输出不好是因为模型笨，其实是因为你没告诉它“不要做什么”。比如你想让它写文案，你就得明确告诉它“不要使用夸张的表达”“不要出现第一人称”“字数控制在200字以内”等。限制条件越具体，输出越接近你要的效果。
第三个技巧是结构化输出。上面那个例子就是典型的JSON输出。生产环境里我极度推荐这个做法，因为把大模型的输出变成结构化数据之后，你后面的代码和逻辑就完全可控了。Dify里有解析JSON的节点，模型输出JSON之后可以直接做字段提取，然后分流到不同节点做后续处理。
4. AI工作流搭建：从零到一产出可复用的业务组件
4.1 工作流节点：可视化拖拽背后的编排逻辑
Dify的工作流是目前我觉得最花功夫也最有价值的功能。它本质上是一个可视化的逻辑编排器，把大模型交互、程序逻辑、外部API调用整合成一条流水线。
核心节点有这些：开始节点、LLM节点、知识检索节点、条件分支节点、HTTP请求节点、代码执行节点、模板转换节点、变量聚合节点、结束节点。
我拿一个业务场景来讲。假设要做一个“行业竞品动态追踪助手”，每天早上自动抓取指定竞争对手官网和公众号的最新动态，做摘要，判断和我们的业务关联度，然后推送到企业微信群。
这个需求如果用代码实现，你可能要写一个定时任务，写爬虫、调大模型API、再调企业微信API，整个链路很长。但在Dify里，你只需要把工作流节点串起来。
4.2 一个完整的智能内容分发工作流实例
开始节点后面接一个HTTP请求节点，用来拉取竞品的RSS或者API返回的内容，拿到数据后传给LLM节点做摘要和关联度判断，然后走条件分支节点判断关联度高还是低。高的话，经过模板转换节点拼接好消息格式，通过HTTP请求节点发到企业微信机器人接口；低的话，直接进结束节点存档不推送。
这里面最讲究的几个点是：HTTP请求节点的超时设置、鉴权方式、返回数据结构；LLM节点的Prompt设计（通常我会要求模型输出JSON）；条件分支的判定逻辑。
实际配置里的细节很关键，比如知识检索节点的Top K召回数量和相似度阈值，直接影响回答质量。Top K太小，可能漏掉关键信息；太大，可能混入无关信息，模型容易被带偏。调优的时候要结合测试反复试，通常从Top K=3、相似度>=0.7开始起步。还要注意，知识库里的文档不能一把梭全丢进去，要先把文档拆分成分块，再做好分段大小设计，过大的分段会影响召回精度，过小的分段则召回语义不连贯。经验值大概控制在300~800个字符之间，会结合具体的文档类型微调。
代码执行节点支持Python和Node.js，Dify的代码节点有个特点：启用了代码执行会有一个沙箱环境，无法直接安装第三方库。所以复杂逻辑要么写成Python自带库能执行的样子，要么把逻辑拆到外部API调用去做。这条我在踩过坑之后才彻底明白。
4.3 工作流和Agent的边界怎么划
Dify除了工作流，还提供Agent模式。很多人会纠结这两个到底用哪个。我的理解是这样的：如果你的业务流程是确定的、规则明确的，走工作流；如果你希望让模型自己判断“下一步该调用什么”，用Agent。
举个例子。客服机器人，如果只是简单的FAQ问答，工作流就够了——用户提问，检索知识库，返回答案。但如果你希望机器人能根据用户的问题自主决定“这个需要查订单系统，那个需要转人工”，那就需要Agent能力。Dify的Agent支持接多个工具，比如搜索、计算器、自己的API，然后让模型根据用户意图动态调用。
实战上我还是建议优先工作流，因为可控。Agent更像“放养”，适合探索阶段。生产环境里，你可以把确定性的部分拿工作流锁死，把需要发散的部分交给Agent。
5. 知识库与RAG应用：精细化处理才有好效果
5.1 文档预处理：分段和清洗直接影响“命准率”
做RAG应用，最关键的从来不是向量数据库选型，而是文档预处理。LLM能检索到的只是向量近似的结果，如果你的文本分块太随意，检索到的内容就会很散，回答质量就会很差。
Dify上传文档之后会自动分段，但自动分段往往只是简单按字符数切，效果一般。我的做法是：在上传之前先把文档做一次人工/半人工清洗，去掉页眉页脚、目录、图表说明这类噪音。然后按章节结构手工拆分，每个文档块保持语义独立。这样做进去的知识库，命中率会明显提高。
分段长度怎么说呢，我建议按文档类型来。说明书类型、新闻资讯类型的文本，分段可以短一点；深度分析、论文这种逻辑缜密的，分段保持完整段落再稍长一点。原则是：一个分段尽可能表达一个完整意思。
知识库建好之后，Dify支持召回测试。这一步很多人会跳过，但我建议你一定要做。拿几个典型问题去测，看召回的分段是不是和问题真正相关，然后根据召回效果反推调整分段方式和关键词（有时Dify检索会用到混合检索配合Rerank得分来综合排序，所以召回结果是否精准，也需要看权重配置是否合理）。
5.2 RAG与模型能力如何配合
RAG（检索增强生成）解决的问题是让模型能回答“训练数据里没有的知识”。它的本质是“帮模型临时翻书”，翻到的内容就是检索结果。
但这里存在一个普遍的认知误区：以为把知识库接上了，模型就一定会用。实际操作里，模型的输出质量取决于它怎么“消化”检索到的内容。如果检索结果相关性差，模型会把无关内容也硬编进回答；如果索引内容太杂，模型可能会从错误的信息里生成答案。
所以Dify的知识检索节点，很关键的一个配置是召回模式和重排序。召回模式分向量检索、全文检索、混合检索。向量检索适合语义相关但字面不同的情况；全文检索适合关键词精确匹配；混合检索是两者结合，效果更均衡。重排序（Rerank）能对召回的多条结果做相关度二次排序，去掉杂质。生产环境里我通常开混合检索+重排序，虽然每多一层操作就多一份耗时，但准确性大幅提升，很值得。目前Dify平台还支持通过API接入第三方rerank服务（比如Cohere的Rerank模型），有预算可以考虑上。
6. 生产级发布：权限、监控、迭代与治理
6.1 发布API与接入前端
工作流和Prompt调好之后，点击“发布”就得到一个API。Dify会给每个应用生成一个独立API密钥，前端只需要调用这个API就能跑整个工作流。这意味着你可以把Dify当作一个AI后端服务，自己的前端、小程序、服务号都可以接入。
发布的时候有几个选项：公开（任何人可用）、只读、私有，这个根据业务形态选择就好。API本身的鉴权是API-Token方式，放请求头里。生产环境务必把这个密钥收好，别提交到Git仓库里。密钥管理上，建议每个环境用一套不同的密钥，线上和测试分开，哪怕test密钥泄露，也不会波及正式数据。
调用API之后，后面的Serverless函数、数据库、消息推送都靠你自己的业务系统做。Dify这边主要负责可复用的模型逻辑部分。
6.2 监控、日志与不断迭代
AI应用的迭代逻辑传统软件不一样。传统软件是逻辑确定性强的，修bug就行；AI应用往往是“Prompt就差一句”的玄学调优过程。
Dify的日志和标注功能做得不错。生产环境的每次在线调用，都能在平台里看到具体的输入输出。你可以定期回看日志，找出那些效果不佳的回答，把它们标注出来，然后去优化Prompt或补充知识库。这就是LLMOps的雏形。不少人觉得每一版Prompt都要在测试环境试过再上线，这个习惯很好，Dify支持为同一个应用保存多个版本，随时回滚。
定期的评估集也很重要。在Dify里有标注功能生成的数据可以导出，拿一批典型的测试问题，每次改Prompt或者升级模型之后，整批跑一遍，看看效果有没有明显退化。这类回归测试用代码写可能会比较复杂，但简单的切片比对判断就够日常使用。养成这个习惯，模型推理效果会稳定很多。
6.3 生产环境的资源与安全配置
生产化绕不开资源保障和安全。几个关键点都值得写在Ops手册里：
- 数据库定期备份：Dify使用了PostgreSQL和向量数据库，这两者的数据都需要备份。最简单的方案是凌晨定时把数据目录打包下来异地存储。
- 日志定期清理：容器日志如果不清理，会越堆越大，最后把磁盘搞满。建议限制Docker日志的大小，比如只保留最近7天的。
- API密钥定期轮换：密钥不能设了就忘记，建议建立轮换机制，比如每3个月换一次。
- 容器更新：新版本上线前，先做一个全套的镜像备份，以便出问题能快速回滚。
- 模型供应商状态监控：云端API偶尔也会限流或宕机，Dify本身支持多模型供应商冗余，Model Fallback配置好之后，一个模型出问题可以自动切换备用。
最后提醒一下，Dify不是部署完就一劳永逸的。它本身就是开源项目，版本迭代很快，社区也很活跃。去年用的功能版本是0.6几，现在已经是几字头的大版本，功能和体验完全不一样了。保持关注官方release notes，有选择的升级，才是长期稳定使用的保证。
从部署到发布，整个过程走下来，你会明显感觉到：大模型应用开发的门槛确实被大幅拉低了。过去需要一支工程师团队才能完成的事情，现在一个人加上Dify，两三天就能跑通一个带业务流程、知识库和监控的AI应用。这个趋势带来的变化是，真正的竞争力已经从“会不会调API”转移到了“懂不懂业务、会不会设计Prompt工作流”上。
我个人在实际操作中的体会是，Dify最值钱的地方不是它省了多少代码，而是它把“试错成本”降到了极低。你每调整一次Prompt、每增加一个节点，都能立刻在预览面板里看到结果，这种快速验证的节奏，特别适合打磨AI产品的体验。最后再分享一个小技巧：做工作流的时候，不要一口气图大求全，先把最小可用闭环跑通，再加分支、加异常处理、加多模型冗余。分步上线、每日观察日志找问题，比憋一个大而全的方案要靠谱得多。