最近在给团队做技术分享的时候我拿 Dify 的 AI 工作流玩了一把“拖拽连线替代代码”的实战。任务是做一个文本摘要器传统写法是调模型 API、拼接 prompt、处理超时、写异常逻辑。结果用 Dify 工作流半小时内做了三个版本其中最简单的一个从创建空白画布到第一次成功输出摘要真的没超过五分钟。这个系列前面聊过 Dify 的基础功能这次就专门拆一下工作流的设计思路和完整实操重点讲清楚“不用写代码”这句话到底是不是真的以及哪些坑值得提前避开。这篇内容适合两类人一是刚接触 Dify、还停留在“会聊天”阶段想试试可视化工作流的入门者二是写过不少 Python 调大模型脚本想知道这类可视化编排能不能真正接手实际需求的人。先把结论放这Dify 工作流不是把代码方块化那么简单它本质上是把“数据流”作为核心抽象你不需要懂函数和变量作用域但必须理解数据从哪个节点进来、经过什么变换、最终从哪个出口离开。1. 为什么说 Dify 工作流是“不用写代码”的编程1.1 先搞清楚 Dify 工作流到底解决什么问题Dify 是一个开源的大模型应用开发平台除了聊天机器人之外它的工作流模块允许你把一次完整的“模型调用”拆成一系列节点用可视化方式编排。真正的代码方案里一个文本摘要器至少需要这些逻辑读取文本、裁剪超长内容、构造 prompt、调用模型接口、处理流式返回、处理异常重试、格式化输出。每个环节都是真实的代码量而且一旦要改提示词或换模型就得翻代码重新部署。Dify 工作流把这一套抽象成了“开始节点 → LLM 节点 → 结束节点”这样一组卡片。你在画布上连接它们配置每个节点需要的数据平台自然负责调度、传参和结果收集。这个抽象的价值不在于省掉十个函数而在于把“业务逻辑”和“工程实现”彻底分离。你可以像搭积木一样先画出一条数据通路再逐个节点填充细节。调试的时候每个节点也能单独查看输入输出出问题一眼就能定位。从我的实际体验看Dify 工作流最适合的是“流程固定、步骤清晰”的文本处理类任务。摘要、翻译、分类、信息抽取、文章润色这些任务天然可以用“输入 → 处理 → 输出”来描述。相反如果你的应用有极其复杂的自定义逻辑、特殊的数据结构、或者要与遗留系统深度集成那还是得靠代码Dify 工作流不适合硬套。1.2 拖拽连线和传统代码的对比我专门拿一个真实的摘要脚本和 Dify 工作流做过对比。那个脚本大概 150 行 Python里面有一半是异常处理和参数拼接。而 Dify 这边就是三个节点加几段提示词文本。这里我列一个直接点的对比方便你判断什么场景选什么方案。对比维度传统代码方案Dify 工作流开发速度新手要几个小时含调试顺手的十分钟新手半小时改 prompt 成本改代码、重新部署画布上直接改即时生效调试体验打日志、看堆栈单节点查看输入输出图形化追踪异常处理能力自由写 try-except非常灵活用条件分支和错误机制灵活性有限与外部系统集成各类 SDK 都能用需要 HTTP 节点能力受限适合团队有工程师维护运营、产品也能参与修改这个对比不是要贬低代码方案。真正上生产、需要大规模并发或复杂定制的场景代码方案依然是首选。但如果你要快速验证想法、频繁调整提示词、或者让非技术人员也能维护Dify 工作流的优势非常明显。我们团队现在很多内部工具都优先用工作流做原型确定逻辑后再决定要不要抽成代码服务。1.3 文本摘要器为什么适合当第一个实战案例第一次尝试工作流我不建议直接做复杂的客服 Agent 或知识库问答而是从文本摘要器入手。原因很简单摘要任务的输入输出边界清晰输入一篇文章输出一段总结没有多轮对话没有状态管理也不涉及工具调用。它能把工作流最基本的几个概念完整走一遍开始节点定义输入、LLM 节点构造调用、提示词节点传递变量、结束节点输出结果。而且摘要任务非常适合用来理解 Dify 的变量引用机制。你需要搞清楚“我怎么把开始节点的文本传到 LLM 节点的 prompt 里”这一个知识点掌握了后面做任何工作流都不会慌。再加上摘要器本身就有实用价值发布出来可以直接给团队当“长文章压缩工具”用不是那种学完就扔的 demo。2. 搭摘要器之前的准备工作2.1 Dify 从哪里来云端版与本地部署的选择在开始拖拽之前你得先有一个能用的 Dify 环境。目前主要是两条路用官方云端版或者本地部署开源社区版。云端版的好处是零部署成本注册完就能用适合快速验证社区版的好处是数据完全在自己手里支持二次开发适合对隐私和定制有要求的团队。如果你选择本地部署我建议直接看官方文档用 Docker Compose 一键启动。机器至少需要 4GB 内存推荐 8GB磁盘 50GB 以上。部署时留意端口映射和磁盘挂载很多人在这一步遇到“服务起来但页面打不开”的问题大多是端口被占用或者容器没起来。想了解 Windows 上怎么装的话基本思路是装好 Docker Desktop再照官方 docker-compose.yml 执行Windows 下网络和文件权限要多花点心思。不过这篇文章的重点在工作流本身环境问题可以后面单开一篇。2.2 工作流界面的几个核心概念进入工作流编辑页后你会看到左侧节点面板、中间大面积画布、右上角“运行”和“发布”按钮。第一次打开的同学通常会愣住觉得节点类型太多不知道从哪下手。其实你只需要先记住六个节点开始、LLM、模板转换、条件分支、代码执行、结束。开始节点是工作流的入口负责声明外部传入的变量LLM 节点是核心负责调用大模型完成生成任务模板转换节点用来拼接字符串、重组格式条件分支节点做 if-else 逻辑代码执行节点允许你嵌入 Python/JavaScript 片段处理复杂逻辑结束节点则定义工作流的最终输出。节点之间用连线传递数据每条线代表前一个节点的输出可以作为后一个节点的输入。还有一个非常关键但容易被忽略的地方节点输出的数据是结构化的不是简单的一串文字。比如 LLM 节点的输出可能包含文本内容、token 用量等字段。你需要在配置后续节点时精确引用“哪个节点的哪个字段”这就是 Dify 的变量引用语法后面实操部分我会详细讲。2.3 提前准备好模型服务Dify 本身不提供模型它只负责编排。你需要在“模型供应商”页面配置一个可用的模型服务比如 OpenAI 兼容接口、DeepSeek、通义千问等。文本摘要任务对模型能力要求不算极端但如果经常处理长文本务必选上下文窗口够大的模型建议至少 32K 上下文低于 16K 的话大段文章很容易被截断。配置模型时记住一点在 Dify 后台填入的 API Key 要能正常通过校验否则工作流运行时会直接报错。摘要场景里temperature 参数建议调低至 0 到 0.2因为摘要需要忠实于原文不需要太多发散。还有要注意模型供应商的调用频率限制发布成多人使用的应用后被限流是早晚的事。3. 从零到一搭出文本摘要器完整实操3.1 第一步创建空白工作流并理清输入输出登录 Dify 后从“工作流”入口进入点击“创建空白工作流”。这里不要选“聊天助手”模板我们要做的是偏向后台处理的流程型工作流。给工作流起个名字比如“文本摘要器”描述一句用途即可。创建之前先把输入输出想清楚这是很多人上来就拖节点然后翻车的原因。我们的输入只有一个用户要摘要的文章正文用一个变量接收它。输出也只有一个完成摘要的字符串。这个“先想清楚进出”的习惯在 Dify 工作流里比在写代码时更重要因为可视化编排里你不太容易写单元测试全靠流程设计保证正确性。3.2 第二步配置开始节点定义摘要的“原材料”双击画布上的开始节点进入配置面板。点击“添加变量”变量名填写 text类型选择“段落”。段落类型是多行文本适合承载完整文章。如果你想处理多篇文章也可以在这里添加一个数组类型的变量但我们先做单篇。这里有一个新手必踩的细节变量名只接受英文字母、数字和下划线且不能以数字开头。不要觉得用中文变量名“亲切”后面在提示词里拼引用时会有各种编码问题。命名统一用 text、article、summary 这类见名知义的词就好。另外开始节点的变量会暴露给外部调用者如果做 Web 应用页面会自动生成一个输入框类型对应关系就靠这一步建立。3.3 第三步拖入 LLM 节点写摘要提示词从左侧节点面板拖一个“LLM”节点到画布上把开始节点的右侧锚点连到 LLM 节点的左侧锚点。连线完成后打开 LLM 节点配置你会看到几个关键配置项模型选择、上下文、提示词、模型参数。模型下拉框里选择你已经配置好的摘要模型。上下文这一项是重点点击输入框后在出现的变量列表里选中 start.text系统会自动生成类似{{#start.text#}}的引用。这个过程尽量不要手打让 Dify 帮你插入可以避免引用路径错误。提示词部分我们用下面这段模板适配大多数中文摘要场景你是一名资深编辑擅长提炼信息。请阅读用户提供的文章生成一段简洁、忠实的中文摘要。 要求 1. 摘要必须基于原文不得添加原文没有的信息。 2. 控制字数在200字以内。 3. 保留核心结论、关键数据、重要人名和事件。 4. 使用客观中立的表述不要出现“我觉得”“据说”等主观词汇。 5. 直接输出摘要内容不要添加“以下是摘要”之类的前缀。 文章内容 {{#start.text#}}这段提示词里最后一行用尖括号括起来的就是开始节点传入的文章变量。LLM 节点会把这个提示词拼进请求交给模型处理。模型参数里把 temperature 设置成 0.1 或 0并选择一个偏保守的采样策略摘要会更稳定。3.4 第四步配置结束节点把结果交给用户LLM 节点配置完后先把它的输出字段也确认一下。在 LLM 节点配置面板里系统默认会有一个输出变量通常叫 text你可以改成 summary方便后续引用。这个名字逻辑上代表“LLM 生成的结果”。拖入结束节点从 LLM 节点连一条线过来。打开结束节点配置添加一个输出变量 summary类型选择“文本”引用 LLM 节点的 summary 字段。这一步的意义是把工作流内部的数据“出口”明确下来。如果没有结束节点工作流运行完可能没有任何返回值。在这个节点里你也可以输出结构化 JSON把摘要、字数、年份等字段打包返回后面扩展功能会很方便。3.5 第五步调试、运行与发布点击右上角的“运行”Dify 会弹出测试输入面板里面正是我们在开始节点声明的 text 字段。给它粘贴一段测试文章至少三四百字点运行。运行结束后画布上的每个节点都会有一个状态标识点击 LLM 节点可以看到完整的输入提示词和模型输出摘要。如果摘要结果不满意回到 LLM 节点调整提示词即可然后再次运行。工作流的调试不像代码那样需要打断点它每一步都是可见的这是可视化编排最大的优势。调试顺手之后点击“发布”你会看到工作流状态从“草稿”变成“已发布”。发布后可以创建 Web 应用让别人通过网页输入文章拿摘要也可以生成 API 凭证让第三方系统调用它。到这里一个能用的文本摘要器已经完工。从创建到发布我给团队演示时去掉模型配置时间确实不到五分钟。但别急着用真正影响摘要质量的是提示词设计下一节重点讲。4. 摘要提示词的设计决定效果好坏的关键4.1 一个能用的摘要提示词模板你可能会说上面已经给过模板了。没错但那只是“能跑”的版本。真正要把摘要质量调到位提示词里每一句话都有讲究。我把模板拆开讲讲为什么这么写。角色设定那行“你是资深编辑”不是废话。大模型在收到明确角色后输出风格会自动向这个角色靠拢更结构化、更精炼。“擅长提炼信息”进一步限定了它的行为倾向避免它变成百科全书的复读机。要求列表里的每一条都是在做“输出约束”不得添加原文没有的信息这是对付模型幻觉最直接的约束控制字数防止摘要变成全文复述保留关键数据、人名、事件则是在给模型规定“信息优先级”。最后一句“直接输出摘要内容不要添加前缀”也很关键。不加这一句很多模型会输出“好的下面为您生成摘要”之类的废话在自动化流程里这种前缀非常讨厌。这段模板你可以直接拿去用后续再根据自己的文章类型微调。4.2 提示词里的几个关键变量除了将文章文本作为变量传入你还可以在提示词里设计其他动态参数让摘要器更灵活。比如增加一个“摘要字数”变量让调用者自己决定输出 100 字还是 500 字增加一个“语言偏好”变量输入“英文”摘要自动生成英文增加一个“摘要风格”变量输入“知乎体”或“官方新闻”输出风格随之变化。在 Dify 工作流里实现这个也很简单在开始节点多定义几个非必填变量然后在 LLM 节点的提示词对应位置引用它们。这样做的好处是把“摘要器”从一个固定功能变成一个可配置的通用工具。我实际做了一个版本开始节点里有 text、max_words、language、tone 四个变量发布后团队用起来非常顺手。注意提示词里的变量越多模型的注意力越分散所以给每个变量都加一句明确的说明不要让它猜。4.3 控制摘要长度的几种方式让模型严格输出 200 字不像写代码设置 number 200 那么可靠。模型对“字数”的把握是概率性的有时 180有时 240。要更精确地控制长度我有几个层次的做法。最直接的就是在提示词里把约束写细比如“控制在 200 字左右不少于 150 字不超过 250 字”。如果还是不稳定可以给出一个示例输出也就是 few-shot 提示。例如在提示词里给出“原文示例 摘要示例”模型会模仿示例的输出风格和长度。这是成本最低、效果最明显的方式。如果对长度要求非常严格工作流可以再加一个代码执行节点用 Python 统计摘要字符数超过阈值就重新调用模型或截断。这种“提示词 确定性校验”的组合是工作流优于纯提示词调用的一点。不过要注意摘要不是压缩强行截断可能会切断信息流所以一般情况我建议追求“区间内波动”而不是“精确数字”。5. 踩坑记录与常见问题排查5.1 模型不可用或 API 校验失败这一类报错在 Dify 里非常常见典型的提示包括An error occurred during credentials validation或Invalid API key。出现这类问题九成是模型供应商配置环节出了差错API Key 复制多了一个空格、模型名写错、额度用完了。排查路径很简单去“模型供应商”页面找到对应服务商重新提交密钥看看是否有“校验成功”的提示。如果校验一直失败需要考虑网络环境和 Key 是否有访问权限。另外本地部署 Dify 的用户偶尔会看到 SSL 相关错误这通常发生在 HTTPS 访问场景下平台在回调模型服务时的根证书不受信任。遇到这类问题不要急着改代码先检查部署机器的证书链是否完整或升级一下 Dify 版本。这类排查比较耗时间我建议新建环境时就把证书配置固定下来别等项目上线再处理。5.2 变量引用不生效、输出空白新手最容易踩的坑就是在 LLM 节点提示词里手动打{{text}}但 Dify 的变量引用必须包含节点路径比如{{#start.text#}}。直接打裸变量名系统不会把它解析成任何值模型看到的就是一串奇怪的字符串。解决办法是不要把变量名当普通文本输入而是用输入框右侧的变量选择功能插入。如果已经写了可以手动改成带节点路径的完整格式。输出空白还有另一层原因模型返回了内容但结束节点没有正确引用 LLM 节点输出。检查结束节点里变量的“来源”确保是从上一个节点映射过来的。还有一次我遇到输出为空是因为 LLM 节点的上下文输入框只拖入了变量但提示词模板里没有引用它相当于模型什么材料都没拿到只能给出一句“无内容”。这种问题在调试页面点开 LLM 节点看“输入”就能发现。5.3 长文本截断与多文档摘要怎么办模型上下文有限摘要一个几万字的报告时超出上下文的文本会直接被截掉摘要结果自然不完整。我给出两套方案。第一套是分段摘要先把长文本按章节或固定长度切成块每一块先做一个片段摘要最后把所有片段摘要拼接在一起再做一次总摘要。这个过程在 Dify 里可以用“模板转换”和“变量聚合器”协作完成具体网上有不少教程但核心思想就是分而治之。第二套是多文档批量摘要。如果开始节点传来的是多篇文章不要直接塞给一个 LLM 节点Dify 新版支持数组和迭代节点可以把数组元素一个个取出交给 LLM 节点循环处理最后再用“变量聚合器”收集结果。记住一点批量场景下提示词要增加“第几篇”之类的索引信息否则模型容易把多篇文章的内容混淆。如果实在搞不定迭代节点也可以写一个 Python 节点用 requests 循环调用模型 API这属于工作流里的“妥协操作”关键时刻能救命。5.4 发布之后还能修改工作流吗可以而且不会造成灾难。Dify 的发布机制更像“发布新版本”你随时可以在草稿状态下修改节点、调试完成后再次“发布”最新版本会生效。已经对外创建 API 凭证的调用方不会因为你在改草稿而中断只有再次发布后它们才会拿到新逻辑。这里有一个值得注意的细节发布前先在“运行”面板覆盖测试几个典型输入尤其是边界用例比如空文本、超长文本、纯英文文章。Dify 工作流的版本管理虽然不会丢数据但是一个没测试过的新版本发布出去可能在排障上多花很多时间。我们团队现在定了一个规矩工作流发布必须至少跑通三类测试样本再对外切换。5.5 常见问题速查表问题现象原因处理方式模型校验失败/API错误Key 错误或额度不足去模型供应商页重新配置并校验SSL 相关报错证书链不完整检查部署环境证书升级 Dify 版本摘要输出空白变量引用错误或提示词没引用上下文检查 LLM 节点输入与结束节点映射长文本结果不完整模型上下文截断分段摘要或用迭代节点分块处理调试通过但线上不生效未重新发布再次发布新版并确认 API 引用多人并发被限流模型调用频率超限加错误重试、限流或更换高配额模型6. 从摘要器出发工作流还能怎么扩展6.1 把单篇摘要变成批量摘要单篇摘要跑通后第一个自然的扩展就是批量处理。在开始节点把 text 的类型改成数组然后用迭代节点逐个处理。你没看错Dify 工作流支持迭代结构。在 YouTube 上看过相关演示实际配置时迭代节点的子流程里塞一个 LLM 节点子流程处理的是数组当前元素。最后出来的结果是一个数组这样你就可以一次性给系统丢二十篇文章得到二十段摘要。听起来美好但批量摘要对成本控制提出新要求。二十篇文章就是二十次模型调用token 消耗会直线上升。我建议在流程入口加一个“最大处理数量”参数并在代码节点里限制数组长度防止有人一次丢一千篇进来。同时把并发数控制在一个合理范围避免触发服务商限流。6.2 加入条件分支做质量判断工作流里最有意思的节点不是 LLM而是条件分支。你可以在 LLM 节点之后接一个条件分支判断摘要结果的字数。如果字数少于原文长度的 10%直接输出如果超过阈值说明模型在“复述”可以再生成一遍或者改用更激进的压缩指令。这种“判断-回流”的思路在代码里是 if-else 加 while 循环在 Dify 里用条件分支和节点连线也能模拟出来只是要注意防止死循环链。条件分支还可以做语言检测。用一个小模型判断输入文章是中文还是英文再决定后续 LLM 节点使用哪套提示词。这就是工作流相对于单次 prompt 的优势你可以根据中间结果动态调整后续处理策略而不仅仅是把一次调用做到最好。6.3 和知识库、消息平台联动摘要器最自然的落地场景是把摘要推给团队。在结束节点之前插一个 HTTP 节点调用企业内部机器人接口把 summary 字段 POST 过去。这样每来一篇文章团队群里自动收到摘要完全不依赖人工复制。同理你也可以把摘要结果写入知识库或者配合定时任务生成日报。Dify 工作流的 HTTP 节点也很容易再串联一个“下一步”动作比如把原文和摘要组合成一条结构化记录调用 Notion API 创建新页面。我实测下来HTTP 节点对 JSON 格式要求比较严格调试时要先在输出里确认字段名别想当然。可以说工作流的边界不在于它“能做什么”而在于你多熟悉节点组合。从摘要器这个起点往前一步它就能长成自动情报助手、客户反馈聚合器甚至日常汇报生成器。我个人做下来最大的体会是Dify 工作流最值钱的不是省掉了写代码的时间而是逼你把 AI 应用拆成一条看得见的数据流。你看得见文本从哪里进来、在哪个节点被改写、最后以什么结构出去这种掌控感是直接写脚本时很难得到的。做摘要器只是第一个小目标真正上手后你会发现以前觉得只有程序员能碰的模型应用现在一个能梳理流程、写清楚提示词的人也能做出来。如果再给我一次机会我可能会把提示词调整得更细一点但那已经不重要了关键是你第一步已经在画布上把线连起来了后面的事自然水到渠成。