Dify 工作流上手记用拖拽连线做个文本摘要器真的可以不要代码见过太多人把 Dify 当成一个聊天机器人面板来用——在对话界面里测试各种 Prompt调来调去总觉得差点意思。其实 Dify 工作流才是整个平台的重头戏它把 AI 应用从单轮问答升级成了可控的业务逻辑编排。这次我用拖拽连线的方式搭了一个文本摘要器从零开始到跑通只花了不到 5 分钟全程没有写一行代码。这篇文章就把完整的搭建过程、节点配置思路、调试方法和几个容易踩的坑一起分享出来适合已经熟悉 Dify 基本对话操作、想更进一步玩转工作流的开发者参考。我选择文本摘要器作为入门案例是因为它足够简单——输入一段长文本输出一段摘要逻辑链路短却能把工作流里最核心的几个概念全部串起来节点、连线、变量、输入输出、模板引用。搞懂这几个东西后面再搭建复杂的 RAG 检索流程、多步 Agent 编排、条件分支处理就只剩堆节点的功夫了。1. 为什么非要用工作流直接写代码不方便吗在开始动手之前值得先花几十秒弄清楚一个问题文本摘要这么简单的任务直接调 OpenAI API 几行代码就搞定了为什么要用 Dify 工作流我的真实感受是代码方案的劣势不在功能上而在后续的维护和协作上。假设你是一个小团队的开发者产品经理今天提需求摘要结果前面要加一段免责声明明天又说超过 5000 字的文章要分两段摘后天说要接入公司内部的知识库做定向摘要。这些改动如果用代码实现每一次都要改逻辑、走发布流程、更新 API 版本来回沟通成本特别高。而工作流把逻辑变成了看得见的东西——每个节点承担一个职责节点之间用连线表示数据流向变量在节点间传递。产品经理复制一张工作流截图就能看懂流程你自己调试的时候也能一目了然地定位是哪个环节出了问题。再往深一层说Dify 工作流不等于低代码套壳它在设计上有几个明显优势编排能力可以串联大模型节点、知识检索节点、代码节点、HTTP 请求节点把复杂的业务流程拆成独立的小块每个小块可以单独调试、单独替换。变量系统节点之间传递的是结构化的变量而不是简单的字符串拼接这让工作流天然适合做条件分支、循环处理。发布管理工作流可以发布为 API也可以嵌入到聊天助手中同一个流程多处复用。所以我的结论是如果只是自己写个脚本玩用代码没问题但如果目标是做一个其他人也能维护、能快速迭代的 AI 应用工作流是性价比更高的方案。2. 节点不是积木而是电路元件很多教程喜欢把工作流比作搭积木我觉得这个类比不太准确。积木是静态的堆上去就完事但工作流里的节点更像是电路元件——每个节点都有明确的输入引脚和输出引脚电流数据从上一个元件流向下一个元件接错线或引脚类型对不上系统就会报错或者输出异常。所以动手搭之前先把 Dify 工作流编辑器里几个基础概念弄清理解它们如何协同概念作用我的理解输入节点定义工作流的起始数据相当于函数的参数入口接收外部传入的数据大模型节点LLM调用大模型执行生成任务工作流的心脏负责理解和生成知识检索节点从知识库中检索相关内容可以暂时不用但要知道有这个东西代码节点执行自定义 Python/JS 逻辑实在需要复杂操作时的保险丝模板转换节点拼接文本模板给 LLM 提供上下文把变量变成 Prompt 的关键环节应答节点输出最终结果决定工作流的返回内容结束节点结束工作流执行处理最终输出并返回响应节点之间通过连线传递数据连线的本质是声明上一个节点的输出可以供下一个节点使用。如果两个节点的数据格式对不上就像把一个变压器的 220V 输出直接接到 5V 芯片上必然出问题。理解了这层关系再去看工作流编辑器就能发现它其实不神秘——编辑器里的拖拽连线是在帮你把手写函数调用链变成一种直观的图形表达。节点之间传递数据、修改格式、条件分支这些逻辑以前要靠代码实现现在可以靠图形化配置实现。3. 搭建前你要想清楚的三件事我见过好几个人第一次搭工作流失败不是因为操作不会而是因为没在搭之前想清楚需求。磨刀不误砍柴工动手前先回答这三个问题3.1 输入输出是什么文本摘要器的输入很明确一段原始文本。输出也很明确一段摘要。但文本和摘要这两个词背后有更多的细节需要确认输入是一篇文章还是一个对话记录摘要长度有没有限制是要求一段话还是可以分条列点如果你把这些问题全部模糊处理搭出来的工作流就只能算个 Demo不能用于真实场景。我的建议是第一个版本先做最简单的版本——单段文本输入、单段摘要输出后续再逐步加长度判断、分块、多轮优化等进阶功能。3.2 用哪个模型模型选型直接决定了摘要的质量和成本。在 Dify 工作流里这一选择在 LLM 节点出配置。我的经验是如果输入文本在 1000 字以内选上下文窗口 4K 的模型就够用这类模型便宜且响应快如果是长文摘要建议选 16K 以上上下文的模型或者先走了自动分块把长文切成多段分别摘要再合并追求摘要质量、允许有几秒延迟用更高级的推理模型就合适想控制成本就要尽量避免在一次调用中塞入过多的历史对话和冗余信息。以我这次搭建为例我用的默认推荐模型上下文窗口 4K 到 8K对于摘要几百字到两三千字的文章已经完全够用跑一个请求的成本几乎可以忽略。3.3 什么时候用代码节点什么时候别用看到 Dify 工作流里有代码节点时有人会忍不住想这不还是有代码吗其实代码节点是为了处理 LLM 不擅长的确定性逻辑比如数据清洗、格式转换、类型判断、调用外部 API 等。对于纯文本摘要这个场景完全不需要代码节点——把文本扔给 LLM让它输出摘要这就是 LLM 最擅长的事。如果在一个本该纯编排的流程里塞入代码节点反而是画蛇添足。4. 手把手搭建过程从空白工作流到可运行现在进入正题。我用的 Dify 版本是常见的云版本界面差别不大你自己搭建时以实际界面为准。4.1 新建工作流并设计整体结构进入工作台点击创建空白应用应用类型选择工作流名称就叫文本摘要器。工作流编辑器的画布一开始是空的左侧有节点组件库中间是画布右侧是配置区。我第一步做的不是往画布上拖节点而是先在脑海里画一条数据流原始文本 → 输入节点 → 变量引用 → LLM 节点 → 输出变量 → 应答节点整个链路就到这了没有分支没有循环一张拓扑图就能说完。先把这条链路想清楚再拖节点就不会手忙脚乱。4.2 配置输入节点工作流创建向导里会让我们定义输入字段。这里我定义一个字段参数项配置值说明字段名article变量名供后续节点引用类型段落输入多行文本需要接收长文本默认值清空留空执行时由调用方传入这里有一个容易忽略的小细节字段名变量名不要用中文。Dify 的变量系统支持中文变量但我在后续调试和引用时用英文变量名会更顺畅尤其是在模板里拼接时需要写变量路径英文不容易出错。4.3 添加 LLM 节点并配置核心参数从左侧拖一个LLM节点到画布上把它放在输入节点后面。连线从输入节点的右侧拖到 LLM 节点的左侧连完线之后LLM 节点就能看到输入节点里的变量了。然后打开 LLM 节点的配置面板最核心的几个配置如下模型选择我选择默认推荐的模型它完全可以胜任摘要任务。如果你有更偏好的模型也可以换但建议第一版用性价比高的别一上来就上豪华模型。系统 Prompt你是一个专业的文本摘要助手。用户会给你一篇文章你需要用简洁、准确的语言提炼出文章的核心观点和关键信息。 要求 1. 摘要长度控制在 150 字以内 2. 用中文输出 3. 忽略广告、宣传性内容只提取有价值的信息 4. 如果原文包含数据、结论尽量在摘要中保留。 请直接输出摘要内容不要添加任何前言、后语或以下是摘要之类的说明文字。用户 Prompt模板引用变量请阅读下面这篇文章并按照系统提示中的要求生成摘要 【文章内容开始】 {{#article#}} 【文章内容结束】这里的{{#article#}}就是引用输入节点中定义的 article 变量这一写法也建议先动手试一遍不会的可以看界面里的变量提示。输出变量命名给 LLM 节点的输出起一个可识别的名字比如summary。后面应答节点需要用到这个名字。模型参数Temperature 设置为 0.2 左右。摘要任务对创造性要求低对准确性要求高温度越低输出越稳定不容易出现自由发挥。4.4 配置应答节点并连接最终输出拖一个应答节点到画布上把 LLM 节点的输出连接到应答节点。应答节点的内容支持模板引用直接填写{{#summary#}}这里引用的summary不是输入节点里的 article而是 LLM 节点的输出变量。连完线之后所有节点的连接状态会高亮显示保存后可以测试。到这里整个工作流只用了三个主要节点输入、LLM、应答已经能完成最基本的摘要功能。4.5 保存并运行测试点击右上角的运行按钮Dify 会弹出一个调试输入框要求你填写 article 变量的值。我随便找了一篇介绍植物养护的长文粘贴进去点击运行几秒钟后就在右侧面板看到运行结果——一段 100 多字的摘要内容准确语言通顺。测试通过。耗时大约 4 分钟。比我预期还快。5. 调试过程实录变量名错了、温度高了、格式花了第一次跑通只是开始真正有用的经验在调试环节。我这几次调试遇到的情况很典型值得展开说一说。5.1 变量名写错最常见的白痴错误第一次运行时我本来想在用户 Prompt 里写{{#Article#}}结果复制粘贴草稿时大小写对不上运行直接报错提示变量不存在。Dify 对变量名是敏感的大小写不一致就会报错。解决办法很简单从右侧变量面板里点选插入变量不要手打拼写。这个习惯能省下大量调试时间。5.2 LLM 输出不稳定把 temperature 调低第一次跑通后我把同一篇文章连续测试了三遍发现摘要结果每次都不一样。有时候开头是本文主要介绍了...有时候是文章的核心观点是...内容虽然都是对的但表述风格飘忽不定。其实不是模型的问题是我把 temperature 调到了默认的 1.0。摘要任务虽然需要一定的语言组织能力但不需要创造性发挥温度调低到 0.2 左右之后连续测试三次输出结果基本稳定。调参逻辑是生成任务写文案、写故事可以把温度调高抽取/摘要/改写任务必须调低。做完文本摘要器之后你再去玩创意生成的工作流就知道两个方向的参数怎么区分了。5.3 输出带 markdown 和引导语第一次调试时我的 Prompt 没有写直接输出摘要内容不要添加任何前言、后语结果模型的输出变成了好的以下是这篇文章的摘要 **文章摘要** 这篇文章主要介绍了...在聊天助手场景下这种格式问题不大但如果是 API 场景这段输出要直接用于业务系统就很讨厌。解决方法是把输出格式要求写清楚同时在系统 Prompt 里就明确要求不要添加任何前言、后语或以下是摘要之类的说明文字。如果你用了高级模型还会出现模型把 markdown 加粗语法 这种工具化的结构也带进摘要的情况也是同理要把输出纯文本这条要求明确写进去。这里有个小技巧如果模型的输出格式总是管不住可以把总结后置检查做成一个简单的小流程——比如用代码节点对输出做一次正则清洗把**、#等 markdown 符号去掉。虽然不想在关注的地方用代码节点但业务场景要求输出纯净时这是个兜底方案。6. 进阶与扩展在同一框架内做长文摘要、批量处理、对外发布基础版跑通之后如果你觉得这也太简单了就这么点东西那说明你已经上手了。接下来可以在同一框架上做几个方向性的扩展。6.1 长文摘要先切块再合并前面提到模型上下文窗口有限遇到几万字的长文时一次塞进去必然超出限制即使塞得进去注意力和效果也会下降。比较通用的方案是把长文按固定长度切片比如 2000 字一段加少量重叠对每一片做局部摘要再把所有局部摘要合并成三段到五段让模型生成最终的整体摘要。在 Dify 工作流里这对应一个迭代节点。迭代节点的操作方式和代码里的 for 循环很相似循环体内的节点模型调用会对每个列表元素执行一次最后聚合结果。但这个玩法有一定复杂度我建议先做好基础版第二周再动这个。6.2 把工作流发布成 API工作流编辑器的右上角有一个发布按钮点击后可以在API标签页看到工作流的 /run 接口地址。调用方式和 Dify 其他 API 一致在请求头里携带 API 密钥请求体里传入 article 字段的值就能拿到 JSON 格式的摘要结果。我实际测试过发布成 API 后摘要器就变成了一个标准的 HTTP 接口可以接入自己的前端页面、企业微信机器人、钉钉机器人等场景。这一步让工作流真正具备了生产可用的属性。6.3 接入聊天助手除了 API工作流还能作为工具被聊天助手调用。这个玩法的好处是你可以用自然语言描述摘要任务聊天助手判断需要摘要时会自动调用工作流。这种对话式触发工作流的模式在搭建复杂 Agent 应用的时候很有用。不过也要坦白说文本摘要这种纯功能型任务个人认为直接用 API 更直接高效聊天助手更适合用户说不清到底要干嘛的场景。6.4 对比表格三种使用方式的选择使用方式适用场景优点缺点直接在编辑器调试开发阶段验证逻辑直观、快速无法被外部系统调用发布为 API接入已有业务系统标准 HTTP 接口通用性高需要写少量调用代码嵌入聊天助手需要自然语言交互的复合应用可以组合多个工具灵活度高触发链路多调试成本上升7. 踩坑之后的三条经验最后分享三条我个人感受最深的经验不一定都在文档里写明了但实操中非常有用。第一变量传递链路是工作流的命门。我调试时出错概率最高的环节永远是变量引用。节点之间连了线不代表变量自动可用你必须在目标节点的配置里显式引用变量系统才能识别到数据流。这很像函数调用——你有返回值但调用方没接收那返回值就丢了。第二模型输出格式不可控不是玄学。它通常是你 Prompt 没写清楚。在系统 Prompt 里明确输出格式、长度、语言、是否允许 markdown输出就会稳定很多。这比在代码里写一堆后处理逻辑要优雅得多。模板转换节点也常用来统一拼接输入让不同来源的变量整合成固定结构再交给 LLM 节点。第三调试日志是最值得花时间看的界面。每次运行完Dify 会记录每个节点的输入输出。我遇到过摘要结果正常但应答节点返回空的情况排查时发现是 LLM 输出变量名写错了。这个信息从运行日志的每个节点里一眼就能看出来比靠猜效率高一万倍。8. 下一步往哪里走文本摘要器的意义不在于摘要本身而在于你通过它打通了工作流编排的基本心智模型。下一步的路线可以按兴趣选如果你对知识库感兴趣可以在这个工作流里加一个知识检索节点让摘要器具备先检索相关资料再生成摘要的能力这就是一个准 RAG 应用。如果你关注复杂业务处理可以考虑加上条件分支节点比如识别到输入是对话记录时走对话摘要路径输入是文章时走文章摘要路径。如果你想提升摘要质量可以做两段式摘要——第一段生成结果第二段对结果进行修正和润色。这些扩展的共同点是都不需要写代码只需要在画布上继续拖节点、连线条。就个人经验而言建议每个刚接触 Dify 工作流的人都做一个类似的一节点一用途的小项目作为起步。搭建它的过程能让你快速适应图形化逻辑编排的思维方式。等后面遇到真正的复杂需求时你就不会想着要不要回到代码了而是会自然地先在画布上把数据流画出来再逐个节点实现。这个转变其实就是低代码/AI 应用开发最有价值的部分。