如果你习惯了用代码拼AI应用第一次看到Dify的工作流画布可能会产生一种“这也太简单了吧”的错觉——把节点拖到画布上用线连起来再填几段提示词一个能自动做文本摘要的AI应用就跑起来了。这是“Dify 入门系列”的第七篇不聊空泛的理论直接用一个“文本摘要器”例子带你把AI工作流从零搭出来。整个过程不需要写一行代码也不需要熟背提示词工程技巧只靠一个开始节点、一个LLM节点、一个结束节点五分钟内就能跑通。适合谁来参考如果你已经知道Dify是什么但是还没上手搭过工作流如果你平时是写代码调接口的人厌倦了每次都要处理参数拼接和响应解析又或者你只是有一个“输入长文本、输出摘要”的想法想快速验证可行性这篇内容都适合你。沿着这条路径走完你不但能拿到一个能直接用作API的应用还能理解Dify工作流最核心的一件事——节点之间的变量是怎么流动的。1. 拖拽连线到底解决了我的什么痛点1.1 从写代码到“画”应用的思路转变以前我做一个文本摘要小工具通常是Python脚本读文件、拼prompt、调模型接口、解析返回结果、写回文件。每一步都清晰但一旦prompt要改一下或者要加一个“摘要太长就重新生成”的逻辑就得往代码里插一堆if-else。更麻烦的是这类脚本基本是给自己用的同事拿到手以后根本看不懂跑依赖、配环境、改参数每件事都要重新解释一遍。Dify工作流的思路是把“逻辑编排”和“具体实现”分开。我只需要告诉它第一步接收什么数据第二步调用哪个模型第三步输出到哪。真正执行的时候平台负责把数据传给模型、处理错误、记录日志。连线表达的不是“函数调用顺序”而是“数据从哪里流向哪里”。对于文本摘要这种单线任务直观得不能再直观。1.2 什么场景值得用工作流而不是写代码我整理过一个对比方便你判断什么时候该用Dify工作流什么时候还是老老实实写代码维度直接写代码Dify工作流修改成本每次都要重新改代码、跑测试改节点配置即可秒级生效可视化无靠日志想象执行流程节点连线一目了然协作门槛需要代码能力和环境配置业务同事也能看懂基本逻辑调试方式打印日志反复重启单节点运行点击查看输入输出复杂算法灵活自由度最高有代码节点补足但仍有边界部署运维自己管服务、鉴权、并发平台统一处理发布即API从这张表能看出来Dify工作流特别适合三类场景快速原型期、需要交付给非技术团队使用的内部工具、以及以“数据处理管道”为核心而不是以“复杂算法”为核心的业务逻辑。反过来如果你要写一个高性能的自定义排序算法或者要对海量日志做底层过滤那还是撞到代码里更合适。但对于“调模型、传参数、拿结果”这种LLM应用的主流形态可视化工作流的效率和可维护性都非常高。1.3 为什么文本摘要作为入门案例最好选文本摘要器作为入门案例是因为它足够小又足够完整。它的输入是一段长文本输出是一段短文本逻辑上天然就是“开始 → 处理 → 结束”三个节点能表达的最小闭环。同时摘要任务能清楚展现“提示词”和“模型参数”的影响方便你在搭建过程中体会到变量传递、模型选择、输出解析这些知识。学会了这个后面再做文章分类、会议纪要抽取、客服工单总结都是同一套玩法的延展。2. 开工前要准备的两件事部署Dify和配置模型2.1 本地部署Dify的几种方式Dify支持本地部署我最常用的是Docker Compose方式步骤很直接从Dify官方仓库或文档获取最新版的docker-compose.yaml配置文件。确保本机已经安装Docker和Docker Compose插件。在配置文件所在目录执行docker compose up -d等待容器启动。浏览器访问默认端口第一次进入会要求创建管理员账号。完成后进入工作台开始创建应用。我这里写文章时已经用到了1.17.x的版本界面细节与旧版可能会有点差异但工作流的核心逻辑保持一致。如果你用的是社区版建议保持版本更新像1.17.1这个版本就修复了不少插件和工作流运行时的问题实际体验会稳很多。如果不想本地安装Dify也提供官方云版本注册后在线就能创建应用流程几乎一样。但考虑到团队内部数据隐私或者需要把应用部署在内网环境本地部署始终是更稳妥的方案。2.2 模型配置工作流真正的大脑Dify本身不产生模型能力它需要通过“模型供应商”去调用大模型。进入“设置” → “模型供应商”你能看到OpenAI、Anthropic、通义千问、智谱AI等选项也可以添加自定义模型。每个供应商都需要配置对应的API Key后续工作流节点才能选到模型。这里有一个实用技巧如果你用的是国内模型厂商的服务通常可以选择“OpenAI兼容接口”的方式接入把Base URL改成对应网关地址再把模型名改成对方提供的模型标识即可。这种方式非常灵活尤其是当你有多个供应商、需要随时横向对比生成效果时省去了来回切换平台的麻烦。还有一个选择是用本地模型比如通过Ollama启动一个开源模型然后在Dify中添加Ollama类型填入本地API地址。因为模型只运行在自己机器上所以对于演示环境和断网环境特别友好。不过本地模型的摘要质量通常比不上云端大模型如果对效果要求高建议至少使用7B以上参数的模型或者选择量化版本。2.3 开一个测试模型就够了刚开始入门不需要配太多模型选一个效果相对稳定的就行。比如配置一个支持较长上下文的模型因为摘要任务经常要吞下一整篇文章上下文窗口太小的话后半段会被截掉。我的建议是主要用同一个模型把第一个工作流跑通跑通之后再慢慢增加其他模型做对比不要一开始就把选择困难留给自己。3. 实操用三个节点搭一个文本摘要工作流现在进入正题。打开Dify控制台从“工作室”创建一个空白应用应用类型选“工作流”而不是“聊天助手”。聊天助手的交互方式不同它自带多轮对话记录而我们这里只想要“输入一段文本输出一段摘要”的管道型应用普通工作流更合适。3.1 新建工作流先认识左侧节点面板进入工作流编排页面后你会看到画布和左侧的节点面板。节点面板大致分为几类输入类开始节点。逻辑类条件分支、迭代、变量聚合等。AI类LLM、知识检索、问题分类器等。工具类HTTP请求、代码执行、自定义工具等。变换类模板转换、变量赋值等。对于文本摘要器真正需要关注的只有开始、LLM、结束这三个。如果你以前没用过可视化编排工具可以把它简单理解为流程图节点是操作步骤连线是数据流向。节点从面板拖到画布上把鼠标放在节点边缘出现圆点之后拖到另一个节点上就完成了连线。3.2 开始节点把待摘要文本变成入口变量拖入一个开始节点双击打开配置面板。默认情况下Dify会给你一个sys.query字段对应应用运行时用户输入的Query。但对于摘要器来说用户输入的可能是一大段文章或会议纪要我建议自定义一个语义清晰的输入字段。点击“输入” → 添加输入字段名填input_text类型选择“段落”。段落类型可以完整保留换行和空格适合存长文本。你可以给它一个默认值比如一段产品介绍后面测试时就不用反复粘贴。这里有一个命名建议变量名尽量只用英文字母和下划线。如果你命名成中文“用户输入文本”后续在节点里引用时会生成一串编码格式的变量路径既不美观也容易出错。3.3 LLM节点写好提示词连上数据线从节点面板拖入一个LLM节点连一条线从开始节点指向LLM节点。当然你也可以不连物理线直接在下游节点里引用上游变量Dify会通过引用关系自动判断依赖但连上线以后整套流程的阅读体验会更好任何人打开画布都能一眼看出数据从哪来。LLM节点需要配置的要点选择你刚配置好的模型。把温度调到0.3左右。摘要任务需要忠实于原文温度太高模型容易自己发挥太低又可能过于僵硬。System Prompt写清楚角色和任务。User Prompt里通过变量引用把开始节点的输入文本传进来。配置示例System Prompt: 你是专业文本摘要助手。请对用户输入的文本进行概括保留核心信息忽略无关细节输出不超过200字的中文摘要。 User Prompt: 以下是需要摘要的文本 {{#start.input_text#}}连线的本质在于它建立了“数据依赖关系”。运行工作流时Dify会先收集开始节点的输出作为LLM节点提示词的上下文如果开始节点里没有input_text字段整个链路就会直接报错。3.4 结束节点把摘要结果暴露给外部拖入结束节点从LLM节点拉一条线到结束节点。结束节点里选择输出变量为LLM节点的text字段。这一步相当于告诉平台等LLM跑完之后text字段的结果就是这个应用最终返回的内容。配置完成后点击右上角的“运行”按钮Dify会弹出一个参数填写面板让你输入开始节点中定义的字段。这里粘贴一段比较长的文本比如把一篇新闻稿粘进去点运行。你会看到画布上的节点依次点亮开始节点先执行然后LLM节点最后结束节点。点每个节点还能分别查看它的输入和输出如果模型返回的内容不满意直接改提示词再跑一次。跑通之后可以在应用概览页发布为API拿到一个独立的API端点。以后任何系统都可以通过HTTP POST来调用这个摘要接口这就是“拖拽连线替代代码”最直接的价值——你完全不需要自己实现模型调用部分。4. 节点帮你做了什么变量引用与提示词设计的底层逻辑4.1 连线本质上游输出变量如何被下游引用很多人第一次用Dify会有一个困惑明明节点之间连了线为什么有时候改节点名会导致下游报错原因在于Dify工作流的运行依赖引用关系而引用关系靠的是节点ID和变量名。比如在LLM节点里写{{#start.input_text#}}这里的start是开始节点的节点ID不是画布上展示的中文名。你可以在画布上把节点改名为“入口”节点ID通常不会变但如果你进入节点配置页修改了“节点ID”下游所有引用这个变量位置的文本都要跟着改。所以我的习惯是所有节点设置好后先跑一次确认无误再改节点ID改完ID后再打开所有引用该节点变量的下游节点检查一遍。这样设计其实有它的好处。Dify可以把变量依赖识别成一棵依赖树从而判断哪些节点可以并行执行。比如你有两个LLM节点同时依赖开始节点它们之间没有连线Dify就会尝试并行运行节省整体耗时。这是手写串行代码时很难天然得到的优化。4.2 提示词不是随便写好的摘要提示词要考虑什么文本摘要看起来很容易但提示词写得好不好结果天差地别。我见过不少用户只写一句“帮我总结”结果模型返回一堆正确的废话。一个合格的摘要提示词至少要包含这些信息角色与任务你是专业文本摘要助手负责从用户输入文本中提取核心信息。内容范围只基于输入文本不要引入外部常识或个人观点。长度限制不超过200字或者不超过5个要点。输出风格中文、口语化、书面语明确约定。处理边界输入文本为空或极短时应该怎么办。把这些约束写进System Prompt比在User Prompt里临时堆砌更容易得到稳定输出。输入文本放在User Prompt并用明确的标记包裹比如“以下是需要摘要的文本”这样模型可以清晰区分“指令”和“数据”。还有一个被很多人忽略的点是温度参数。对于摘要器温度设在0.2到0.4比较合理。温度过高模型倾向于“创作”摘要里可能出现原文没有的结论温度过低输出可能过于机械把列表原样复述。理解这一点排查结果不稳定问题时也会更有方向。5. 文本摘要器的两个进阶改造思路5分钟版本的摘要器只是最小闭环。用起来以后你会发现现实中的文本往往比想象中长或者希望摘要结果能直接进入下一个系统。这里分享两个我实际改造过的方向。5.1 长文本分块摘要加上迭代节点单次LLM调用能处理的文本量有限。即使模型支持很大的上下文窗口一次性塞入几十万字的文稿也可能中途截断、响应变慢、费用飙升。更稳的做法是先把文本切成块每块做局部摘要最后把所有局部摘要合并成总摘要。在Dify里第一步可以用“模板节点”或“代码执行节点”把长文本按字符数切成数组第二步用“迭代”节点把数组逐项传给LLM节点第三步把每次迭代输出的摘要收集起来再用一个LLM节点做最终合并。做这个改造的核心是理解迭代节点里“内部变量”和“外部变量”的差别迭代内部每次循环会把当前项赋值给你指定的变量累计结果需要存到一个外部变量里。这个改造会稍微费些心思但效果实打实。尤其是处理会议纪要、论文、年度报告这类内容时分块摘要比一次性摘要准确因为它避免了模型“中间忘掉前文”的问题。5.2 多格式输出与结构化摘要加模板和条件分支另一个常见需求是摘要结果不只是一段文字而要同时输出标题、要点列表和关键词列表。这时可以用一个“模板节点”把LLM节点的输出和原始文本一起组装成结构化Markdown或JSON再交给结束节点。模板节点示例# {{#llm.title#}} ## 摘要 {{#llm.summary#}} ## 要点 - {{#llm.bullets#}}如果想要JSON输出在模板节点里手写JSON结构再用变量占位符填充即可。这比让模型直接输出JSON更可控因为模板节点不依赖模型遵循复杂指令填充过程是可预期的。条件分支也有它的用途如果输入文本小于1000字直接用LLM节点一次性摘要如果超过1000字先走分块逻辑。通过一个“条件分支”节点判断input_text长度把两条路径汇合到结束节点。这种“路由”能力几乎是可视化工作流区别于单次提示词调用的最大优势——你不需要在代码里写if-else了。6. 我在实测中踩过的坑和几个小建议6.1 模型输出不稳定是常态提前定好评估口径我搭好摘要器之后第一次测试是用同一段新闻连续跑了三次三次结果居然每次都不一样有些细节时有时无。这很正常因为大模型本质上是概率采样不是确定性函数。为了让输出尽量稳定我后来做了两件事一是把温度调低到0.2二是在提示词里加了一条“严格基于原文不要补充背景信息”的约束。真正的稳定性评估还是要靠测试集。你可以准备三到五段不同风格的文本每一段都跑一遍检查摘要是否覆盖原文核心信息、有没有编造内容、长度是否超限。Dify每次运行都会留下记录方便你反复对照同一提示词下不同模型、不同参数的输出这比在脚本里打日志方便多了。6.2 变量引用错误是最常见的失败原因在没跑通之前我最常遇到的报错是“变量不存在”。原因通常是节点ID被修改后旧引用还留在提示词里。所以有一个经验不要在画布上随意修改节点ID更不要在引用变量后随手改输入字段名。如果真的改了用全局搜索把旧变量名全部找出来替换掉。另外开始节点里的sys.query字段和新增的input_text字段虽然都能在下游引用但建议不要混用。如果你把sys.query留空又把input_text填得满满的运行时会让人搞不清到底传的是哪个。我通常在开始节点中把用不到的默认字段删掉只保留必须的字段这样节点面板更简洁下游引用也不容易出错。6.3 发布API之后别忘了做输入校验和限流摘要器的接口一旦发布就可能被外部系统调用。如果调用方传了一个超长字段模型调用成本会直接翻倍甚至可能触发供应商限流。我一般会在开始节点后面接一个“代码执行节点”做保护检查输入长度超过阈值就截断或直接返回错误。代码执行节点支持Python写一小段片段很快。还有一点API Key不要写死在业务系统里。Dify应用发布后生成的API端点调用时可以带Authorization头建议通过后端服务转发不要在浏览器、小程序前端直接暴露避免密钥泄露。6.4 从一个小工具变成业务底座这个文本摘要器搭完以后它最好的角色不是终点而是一个模板。我后来在它基础上扩展了文章分类、会议待办提取、客户反馈情绪识别等工作流基本都是复用同一个模式开始节点接收原始数据LLM节点负责知识加工结束节点输出结构化结果。每次新建应用时我会先把最简链路搭出来跑通再逐步加条件、加迭代、加知识库。这种“先跑通再迭代”的思路是可视化工作流给你的最大红利复杂度可以慢慢增加但每一步都能被看见、被验证。这一点是传统写代码方式不容易做到的。