我也算是把Dify从零摸到现在的老用户了，前六篇基本都在讲应用搭建、知识库接入、提示词调优这些“单点”能力。到了第七篇，我想聊一个真正让我觉得“这工具值了”的功能——可视化工作流。就拿文本摘要器来说，以前我用代码写，又是封装API又是处理超长文本截断，折腾一天才能跑通；换成Dify的拖拽连线，五六分钟就能拼出一个能用的工作流，而且改逻辑不用改代码，直接在画布上挪节点就行。
这篇文章会从一个真实需求切入，把Dify工作流里最核心的节点、数据流动方式、参数配置逻辑都拆开讲清楚，最后带你从空白画布一步步搭出文本摘要器，再聊聊那些“官方文档不会告诉你”的坑。适合刚接触Dify、想从“单次调用大模型”进阶到“编排复杂任务”的读者，也适合被长文本整理折磨、想找个省力方案的普通用户。
1. 为什么文本摘要器适合作为你的第一个工作流
1.1 摘要需求不是小众场景，而是每个团队都绕不开的杂活
先说说我为什么拿“文本摘要器”当工作流入门案例。因为摘要这个需求太常见了——会议记录要整理、行业报告要提炼、客户反馈要归类、竞品动态要汇总。几乎每个团队每个月都得有人专门干“读一堆长文，总结三五百字”的活儿，耗时耗力不说，还容易出现“一百个人读出一百个重点”的偏差。
我最早处理这类需求，是直接写Python脚本调大模型接口。逻辑不复杂：把文本拼进提示词，调用接口，拿返回结果。但实际跑起来全是琐碎问题：文本长度超过上下文限制怎么截断？并发请求怎么控制？输出格式怎么稳定？更麻烦的是，这些逻辑都写在代码里，业务同事想调整“摘要长度”“是否包含结论”这类参数，得来找我改代码重新部署。
后来我意识到，这类“一次调用、可调参数、即时见效”的场景，本质上不需要厚重的工程代码，它需要的是一个把“输入—处理—输出”可视化串起来的编排工具。Dify工作流正好就是这个定位。文本摘要器又是其中最简单的形态——只有三个核心节点，没有条件分支、没有循环迭代，理解成本极低，非常适合当作理解Dify工作流机制的入口。
1.2 拖拽连线 vs 手写脚本：差的不是代码量，是迭代方式
有人可能会问：“既然摘要这么简单，我直接写个Prompt调模型不就行了，为什么非要套个工作流？”这个问题我实际用了两三周后才真正想明白。直接调模型是“一次性交易”：你给我文本，我返回摘要，完了。中间没有任何可以观察、调整、复用的环节。
Dify工作流提供的是“流水线思维”：我可以在不同节点依次完成“接收文本—按需切段—分批摘要—合并要点—格式化输出”。每个节点的输出都可以拉出来看，哪个环节质量不对就单独改哪个环节，而不是把全部逻辑堆在一个提示词里死磕。
这个差异在简单摘要场景里还不太明显，一旦你后面想加入“先检索资料再摘要”“先判断类型再选择摘要策略”这类逻辑，工作流的方式就完全是碾压级的了。所以我一直建议，第一个Dify工作流别做太复杂的，就做文本摘要器：节点少，逻辑直观，又能把变量引用、提示词注入、结果输出这些核心概念全部串一遍。这些概念一旦打通，后面玩条件分支、知识检索、迭代节点都会非常顺畅。
2. Dify工作流的底盘：节点、连线与数据流
2.1 先认清工作流的三种关键节点
打开Dify的工作流画布，左侧会有一排可拖拽的节点。看起来很多，但文本摘要器真正用到的只有三样：开始节点、LLM节点、结束节点。
开始节点是工作流的入口，负责声明“这个工作流的输入长什么样”。你可以在这里定义变量名、类型、是否必填。我习惯把开始节点理解成“函数的参数列表”——调用方按照这个契约传数据，工作流内部才能拿到值。
LLM节点是真正干活的地方。它负责调用大模型，你要在这个节点里指定用哪个模型、温度设为多少、把什么内容放进上下文、提示词怎么组织。这里面最核心的一个操作就是“把上游变量接到提示词里”，比如把开始节点的original_text字段通过{{#startNodeId.original_text#}}这种引用语法注入到用户提示词中。
结束节点则决定“整个工作流对外返回什么”。文本摘要器里，我希望最终拿到的是一个纯文本摘要结果，所以就在结束节点里输出LLM节点返回的summary字段。
这三种节点逗号就能覆盖绝大多数入门需求。画布上还有知识检索、条件分支、代码执行、模板转换等进阶节点，先不用管它们。把一个简单流程跑通，比一开始就追求复杂编排重要得多。
2.2 连线不是装饰，它是变量流动的管道
很多人第一次拖工作流，会把连线当成“表示先后顺序的箭头”，这其实是个误解。在Dify工作流里，连线不只是顺序关系，它更关键的作用是建立数据传递通道——下游节点只有连到上游节点，才能引用上游节点的输出变量。
为什么我强调这一点？因为我见过不止一个初学者，在LLM节点的提示词里手动输入了一个变量名（比如直接写{{original_text}}），却发现预览运行时这个变量被当成纯文本原样传给模型了，模型根本读不到真实内容。原因很简单：你没有把开始节点连到LLM节点，也没有从系统变量面板中点选引用，而是手打了引用语法，系统根本没有建立对应的数据通道。
所以正确姿势是：先连线，再在提示词编辑器右侧的“变量”面板里点击插入变量。输入输出的JSON路径、节点ID这些细节都不用记，界面点选就能生成标准引用语法。
2.3 “工作流”和“聊天助手”场景怎么选
Dify里创建应用时，会让你在“聊天助手”和“工作流”之间二选一。我把自己的使用经验总结一下：如果你需要多轮对话、上下文记忆、边聊边改需求，选聊天助手；如果你要处理的是“给定一批固定输入，产出结构化结果”的批处理任务，选工作流。
文本摘要器显然属于后者。用工作流还有一个额外好处：每个节点的输入输出都清晰可见，调试时可以单独看“LLM节点到底收到了什么、输出了什么”，这在聊天助手里很难做到。
我见过有人硬把文本摘要也做成聊天助手，结果用户问一句答一句，既没法批量处理，也没法复用流程，还白白消耗对话上下文。
3. 动手实录：从空白画布到可用的摘要工作流
3.1 开始节点：先定义输入，别急着拖模型
我第一次搭工作流时犯过一个顺序错误：先拖了LLM节点，配好Prompt，回头才发现开始节点里忘了定义输入变量，结果LLM节点里想引用原文都没得引。正确顺序应该是先做开始节点，把输入契约定清楚。
在Dify中创建一个“工作流”类型的应用后，进入编排页面，先拖一个开始节点到画布上。然后给它添加输入字段：
- 字段名：
original_text，类型选“段落（paragraph）”。这里我特别提醒一句：如果选成“文本（text）”，某些情况下你粘贴超长文字会被浏览器或表单限制，段落类型能承载更长内容。 - 字段名：
summary_length，类型选“下拉选项”，选项填短（约100字）、中（约300字）、长（约600字），默认选“中”。
第二个字段是我后来加上的。我最开始只定义了original_text一个字段，想调整摘要长度就得改提示词、改配置，特别麻烦。后来把“长度”变成一个可选项，让调用方来决定，整个工作流的复用性一下子高了很多。
你以为这就完了？还有一步不能漏：把开始节点里summary_length的“选项值”我想让它成为实际传给模型的内容。所以我在下拉选项里填的不只是展示文案，而是像“短：约100字；中：约300字；长：约600字”这样带具体字数的文本，后面LLM节点直接引用这个值就行。
3.2 LLM节点的核心动作：把上下文接到提示词里
接下来拖入LLM节点，把它跟开始节点连起来。点进LLM节点，会看到模型选择、模型参数、上下文、提示词四个主要区域。
先说模型选择。这个看你自己接入了哪个模型就选哪个，不同模型对长文本的处理能力差异还是明显的。我的建议是：优先选择上下文窗口大、中文理解稳定的模型来做摘要。不要在这个环节追求“最强智能”，因为摘要不是推理型任务，它更考验模型“读得全、抓得准、表达稳”，一个成熟的商用模型基本都够用。
模型参数第一项就是“温度”。摘要这种任务我非常建议把温度调到 0.1 - 0.3 之间。温度太高，模型容易自由发挥，出现“原文没有的内容”或者“同一篇文本两次摘要结果差十万八千里”的情况。温度低一点，输出更稳定更忠实原文。我自己的配置是 0.2。
接下来是最关键的一步：在提示词里引用上游变量。Dify的LLM节点提示词分为“系统提示词”和“用户提示词”两段。系统提示词负责设定角色、交代任务规则；用户提示词负责塞入实际要处理的内容。我的模板如下：
【系统提示词】 你是一名专业的中文内容摘要助手，擅长从长篇材料中提炼核心信息。 你需要遵守以下规则： 1. 严格基于用户提供的文本生成摘要，禁止补充原文不存在的内容。 2. 摘要需要保留关键数字、核心结论、重要转折逻辑。 3. 摘要长度按用户要求执行：短约100字，中约300字，长约600字。 4. 输出纯文本，不要使用"以下是摘要"之类的引导语，不要加Markdown标题。 【用户提示词】 需要摘要的原文如下： {{#startNodeId.original_text#}} 请按上述要求生成摘要，目标长度：{{#startNodeId.summary_length#}}写提示词时注意一个细节：为了把变量插入LLM节点，不要手打{{#startNodeId.original_text#}}，而是应该先把光标定位到需要插入的位置，在提示词输入框下方点击变量面板里的original_text，让它自动生成引用。这样生成的引用带上了正确的节点ID和字段路径，绝对不会拼错。
3.3 结束节点与第一次预览调试
LLM节点配置完后，把结束节点拖到画布上，跟LLM节点连线。结束节点要选择“输出变量”，一般直接引用LLM节点的输出字段。在Dify中，LLM节点的输出变量名叫summary（LLM节点的文本输出），我在结束节点里给它一个对外名字result。如果你还想顺便返回输入原文做对照，也可以多添加一个输出项，引用开始节点的original_text。
到这里，画布上就已经是一个完整的三节点工作流了。点击右上角的“预览”按钮，系统会弹出运行调试面板，要求你输入开始节点定义的两个字段。随便粘一段长文本，选“中（约300字）”，点击运行。
第一次运行可能会遇到几种情况：
- 运行直接报错，提示“变量不存在”，这种多半是引用语法写错或者连线没连对。
- 运行成功但输出是空的，这种大概率是提示词里让模型输出格式和实际输出错位。
- 运行成功且输出有内容，但摘要质量不佳，这就进入下一节要聊的调优环节了。
调试面板有一个特别好用的能力：运行结束后，你点任意一个节点，都能看到那一层实际收到的输入和产生的输出。我强烈建议你养成“逐节点检查”的习惯，这是排查一切工作流问题的基本功。
4. 决定摘要质量的三个关键配置：模型、提示词与参数
4.1 模型选型与成本直觉
文本摘要这类任务对模型的要求被我总结成一句话：“读得完、抓得住、不乱编”。“读得完”是指上下文窗口要能容纳你的输入文本，最好留出20%-30%的余量给输出内容；“抓得住”是指模型能从长文本里定位关键信息，这更多依赖模型本身的训练质量；“不乱编”是指模型不会在摘要里夹带私货，这点除了靠提示词约束外，模型本身的基础能力同样重要。
成本方面也值得提一句。摘要任务每跑一次都要把整篇原文发给模型，所以你处理的文本越长，Token消耗越大。我自己的经验是，如果不是特别机密或特别长的材料，优先选性价比高的供应商模型，而不是什么任务都上“天花板模型”。我实际对比过：在摘要这件事上，头部大模型之间没有拉开很多人想象中那么大的差距，但成本可能差好几倍。作为个人使用或内部工具，选择稳定、价平、上下文够用的模型完全足够。
4.2 提示词的两段式写法与输出约束
很多人用LLM节点时只写一段提示词，把所有内容混在一起，也不是不行，但效果和稳定性往往不如“系统提示词 + 用户提示词”两段式结构。
我的理解是：系统提示词解决的是“你是谁、你要做什么、你做到什么标准”这三个问题，它是模型的“岗位说明书”；用户提示词解决的则是“今天这份材料是什么、我的具体要求是什么”两个问题，是模型的“当日工单”。岗位说明书稳定不变，当日工单才需要频繁更换。这也意味着，如果你想批量处理几十篇文档，系统提示词完全不用动，只需要切换用户提示词里的原文和长度字段即可。
输出约束是另一个容易忽略的点。人类阅读摘要时，往往不希望看到一堆Markdown格式的“## 核心摘要”“## 关键结论”，反而希望拿到一段干干净净的文字，直接就能贴到周报里。所以在系统提示词里我明确写了“输出纯文本，不要Markdown格式，不要引导语”。实践下来，这一条约束能省下很多清洗后处理的功夫。
除了格式约束，我还喜欢加“数量约束”——比如“关键结论最多列三条”“保留至少两个关键数字”。这类约束能让摘要输出的结构更稳定，也方便后续机器解析或人工核对。
4.3 温度与长度参数：摘要场景不该用默认值
我开始做摘要器时，温度一直用默认的 0.7，结果发现同一个文本，跑两次摘要，句子结构差异很大，核心要点也不够收敛。后来把温度调到 0.2，输出明显稳定很多。这里我解释一下背后的逻辑：温度控制的是模型对输出概率分布的“随机采样强度”。温度越高，模型越倾向选择低概率但多样性的词；温度越低，越倾向高概率、可预估的词。摘要要求忠实和稳定，本质上应该偏向“保守选择”，所以低温是合适的。
还有一个参数是max_tokens（或“最大输出长度”）。之前我忽略过它，结果有次摘要长文，模型刚列了三个要点就戛然而止——因为输出Token上限被默认值卡住了。你需要根据选择的摘要档位来设置：如果选择“长约600字”，中文一个字大约对应1-2个Token，你要保证max_tokens至少设置到 1200 以上，最好预留到 1500。
我建议直接把摘要器里的max_tokens固定在一个偏大值，比如 2000。因为你的摘要长度本身由提示词里的“目标长度”控制，而不是由max_tokens硬性截断；把上限设大一点，可以防止模型生成到一半被切掉，而实际也不会真的每次都跑满。
5. 真实跑批中踩过的坑与调试方法
5.1 变量引用写错引发的“答非所问”
有一次我用工作流跑批量文章摘要，发现有一篇的输出完全不是摘要，而是一段像“抱歉，我无法访问原文内容……”的话。我第一反应是模型出问题了，后来点开LLM节点看实际输入，才发现“用户提示词”里粘贴的原文变成了空的。原来那天我复制别人分享的工作流JSON，开始节点定义的是document_text字段，但我在LLM节点提示词里引用的是{{#startNodeId.original_text#}}，字段名对不上，引用到的就是空变量。
这类问题在工作流开发里非常常见，因为你复制修改一个别人或之前自己的流程时，很容易出现节点ID变了、字段名变了，但提示词里的引用没跟着变。排查方法就一条：运行后点开LLM节点，看实际输入里的“用户提示词”最终渲染成了什么样子。如果某个变量位置是空的，马上就能定位到引用失效的问题。
后来我的习惯是：每次改完开始节点的字段名，立刻全局搜一遍工作流里所有引用了这个字段的地方，确认没有漏网之鱼。
5.2 提示词里的大括号陷阱
这个坑我必须单独说，因为它在Dify社区里很多人都会踩：如果你在提示词里想让模型输出JSON格式，很自然会写成“请输出 {“summary”: “...”} 这样的JSON”。但问题来了，Dify的模板语法也用大括号，它会把{“summary”}尝试解析成变量引用，解析失败就报错，或者直接吞掉这部分内容，导致发给模型的提示词缺失了格式要求，模型就随便乱输出。
我当时调了很久，还以为是模型不支持JSON格式。后来看了官方文档里关于“变量绑定与转义”的说明，才明白大括号是被模板引擎拦截了。
解决办法有这么几种：
- 尽量避免在提示词里直接写JSON大括号结构，改成纯文字描述，比如“请按
摘要：...的格式输出”。 - 如果确实需要JSON输出，可以改用代码节点或模板转换节点来组装最终格式，不依赖提示词直接输出JSON。
- 非要用大括号时，可以尝试用全角大括号
｛｝，这样模板引擎不会解析，模型也能看懂意图；不过这种方式不保证所有模型都能正确理解，最好还是用第一种。
我自己最终的方案是：让模型输出纯文本，格式相关的结构化处理全部挪到工作流的其他节点去完成。这个思路也契合工作流设计的核心理念——大模型负责“理解和生成”，确定性的格式转换交给确定性节点。
5.3 排查链路：从结束节点倒着看数据
工作流跑出来的结果不对，很多人第一反应是去改提示词，但有时候问题根本不在提示词，而在更上游。
这里分享一个我自己养成的排查习惯：从结束节点开始，倒着往前逐步检查每个节点的输入输出。
为啥倒着查？因为结束节点是最接近“用户感知结果”的地方，你可以先确认“结果到底哪里不对”。如果结束节点的输出是空的，那问题可能出在LLM节点没有产出内容；如果LLM节点输出正常，但结束节点输出为空，那问题出在结束节点的变量映射上；如果LLM节点压根没有收到正确输入，再往前查开始节点或连线是否正常。
举个真实例子：有次我发现摘要结果“结尾总是被截断”，查了LLM节点输出，模型明明生成了完整内容，但结束节点返回的内容就是少了最后几百字。后来检查发现，是LLM节点里max_tokens设置得比摘要长度还小，模型生成到一半就被截断了。而我看LLM节点输出时又被界面折叠逻辑误导，没注意输出末尾是否有截断标记。
所以说，排查工作流问题不能靠猜，要一步步看数据流经每个节点时发生了什么改变。调试面板的节点数据检查功能就是为此设计的，多花两分钟看数据，比盲目改提示词高效得多。
6. 从“能跑”到“好用”：摘要工作流的三种扩展改造
6.1 加一个知识检索节点，让摘要更“懂”你的资料
摘要器做到能用的程度后，第一个值得加的进阶功能是“知识检索”。场景是这样的：某天你需要摘要的，不只是用户粘贴进来的一段文本，而是希望结合你内部的知识库资料来补充背景信息。
操作上也很简单：在开始节点加一个可选参数enable_knowledge，然后拖一个“知识检索”节点进来。当开关打开时，检索节点会根据original_text里的关键内容去知识库检索相关资料，然后把检索结果一并并入LLM节点的上下文。这样模型做摘要时不仅能基于原文，还能参考指定资料，输出的摘要会更有“专业背景”的感觉。
这一步的关键在于，你需要用“条件分支节点”来判断开关状态，让工作流在“仅原文摘要”和“带知识库摘要”之间走不同的路径。这也是我后面想单独写一篇教程的主题——条件分支怎么玩出花来。
6.2 长文档分段摘要：先切分再聚合
普通摘要器遇到超长文档时会有一个痛点：模型上下文窗口塞不下全文。比如要处理一份两万字的合同，即使当前模型上下文够大，把全文一次性塞进去，模型对前面内容的“记忆权重”也会被稀释，容易出现抓住尾巴丢了头部的情况。
我用工作流解决这个问题的思路是“分段摘要，再合并摘要”。
具体来说：先用一个“代码节点”按固定长度（比如每3000字一段）把original_text切成多个分片，然后让工作流对每个分片分别跑一次LLM节点生成小段摘要，最后再用一个LLM节点把这些分摘要“总结到一起”。Dify提供“迭代节点”来支持循环处理列表，你可以把“摘要每个分片”的动作包在迭代节点内。
这套方案的好处是每一步都可观察、可调整：某一段原文摘要质量差，单独处理那一段就行，不会影响整体流程。不过它也有明显的复杂度，适合你玩熟单节点之后再去挑战。
6.3 接上API做批量任务
最后一种改造，是把工作流从“手工粘文本”变成“批量任务处理器”。这也是Dify工作流很强的一个点：每个工作流发布后，都会生成对应的API接口，你完全可以写个十几行的脚本，循环调用这个接口，把每篇文章的摘要结果批量拉回来。
我做过的一个实践是：把公司某个内部信息源的最近50篇文章标题和正文通过接口逐条提交给摘要器，输出的摘要直接写入表格。整个过程没有写任何摘要逻辑，最复杂的代码不过是“读文章列表、循环调用接口、写入结果”三四件事。
这种方式对非程序员也很友好，因为你可以直接用Dify内置的Web应用方式分享工作流的入口，让同事在浏览器页面里粘贴文本、选择长度、拿到摘要，根本不需要接触命令行或代码。
到这里，一个文本摘要器的从零到一就算完整走通了。从三节点最简流程，到提示词调优和参数配置，再到底层数据流的排查，最后聊了知识检索、分段摘要、API批处理三种延伸方向。如果让我总结一条最核心的经验，那就是：工作流设计里，永远让大模型只做“理解和生成”这一件事，其余确定性逻辑交给节点去编排。把这一点想透，你会发现Dify工作流真正厉害的地方不是省掉了代码，而是把AI应用从“一次调用”变成了“一条可以随时改装的流水线”。
