零代码搭建文本摘要器：Dify Workflow可视化编排实战

这个系列写到第七篇，有个很有意思的现象：前几篇内容发布之后，后台收到最多的提问不是"哪个模型更强"，而是"我不写代码到底能做成什么"。今天这篇就专门解决这个问题——用 Dify 的 Workflow 能力，把一台"文本摘要器"从零到一拖出来。整个过程不需要写一行业务代码，要做的只是往画布上放节点、拉连线、填配置，最后点一下运行，摘要自己就出来了。

如果你是运营、产品、编辑这类每天要和大量文档、文章、聊天记录打交道的角色，这个能力可以直接帮你省掉一项重复劳动。如果你是工程师，看完之后也会对"可视化编排到底是不是靠谱的范式"有一个更务实的判断。文本摘要器恰好是最适合入门工作流的场景：输入一段文本，输出一段摘要，路径单一，反馈直接，5分钟真的能跑通。

1. 为什么"拖拽连线"能替代代码：工作流不是玩具，是另一套编程范式

很多人第一次听说"拖拽连线"时，第一反应是"这无非是给非程序员做的玩具"。我一开始也这么想，直到真的把一个摘要器的开发、测试、上线全套走了一遍，才意识到这种认知偏差来自哪里：我们把"写代码"和"做软件"画了等号，但实际上一大类AI应用的核心工作根本不是工程实现，而是流程编排和prompt设计。

传统方式做一个文本摘要器，你得先搞定Python环境、安装依赖、处理API鉴权、写好调用逻辑、处理超时和重试、再写一层Web服务把结果暴露出去。这套链路对专业开发不算难，但对一个只想"把文章批量变成摘要"的运营同学来说，光环境配置就能劝退。而可视化工作流做的事情，是把这条链路抽象成一张图：

把两张表摆在一起，你会发现：传统代码里的"函数"对应了画布上的"节点"，函数的入参和返回值对应了节点的输入输出字段，函数之间的调用关系对应了"连线"。这根本不是玩具，而是把编程思维换了一种载体。文本摘要这个需求，恰好完美匹配工作流擅长的形态：输入明确（一段文本）、处理明确（压缩信息）、输出明确（一篇摘要），三个环节连起来就是一条笔直的生产线。

另一个容易被忽略的点是：拖拽工作流让"调试"从"看日志猜状态"变成了"看画布上的数据流"。每个节点执行完，你都能直接看到它吐出来的中间结果。这个体验在传统开发里要专门搭一组观测工具才能实现，在可视化画布里是天然的。

所以我的结论是：不要纠结"拖拽是不是编程"，而应该问"我的任务是不是流程型任务"。如果是，工作流的效率就是碾压级的。摘要器、翻译器、内容审核、日报生成、信息抽取，这一类"输入-处理-输出"结构清晰的场景，拿工作流做就是降维打击。

1.1 摘要器这个场景，到底在解决什么问题

文本摘要的本质是信息压缩。同一篇五千字的行业报告，给老板汇报只需要三百字；给写作同事参考可能需要一千字的要点摘录；给领导做决策甚至只需要三句话结论。所以"做摘要器"这个需求，第一件要想清楚的事其实不是技术，而是：你希望它按照谁的标准压缩？

工作流天然适合解决这个问题，因为它把"压缩标准"拆成了几个可配置的环节。输入什么文本、用哪个模型来理解、通过什么prompt约束模型按什么视角压缩、最后输出多长的摘要，这些都是画布上的节点参数。想调整口径，不用改代码，改配置就行。

对第一次接触工作流的人来说，摘要器还是最好的教学场景。它不涉及Agent那种复杂的工具调用和决策循环，也不涉及知识库检索、多轮对话管理，你只需要盯着一条最简流水线。跑通这一条线，你就理解了变量、节点、引用、输出这些核心概念，后面再去碰更复杂的结构就有了地基。

1.2 拖出来的"代码"：节点、连线和变量到底对应什么

为了照顾完全没写过代码的读者，我再用最直白的方式解释一下画布上这三样东西。

• 节点：一个独立的功能单元。把它想成一台小机器，放进原料，吐出货品。摘要器最少需要三台小机器：负责接料的"开始"、负责干活的"大模型"、负责交出货的"结束"。
• 连线：节点之间的传送带。只有连起来的两个节点才有数据流动关系，没连线的节点再漂亮也不会执行。
• 变量：传送带上流动的箱子。箱子里装的可能是一段文本、一个数字或一组列表。你在"开始"节点定义箱子里装什么，在后面节点的配置里把箱子里的内容引进来用。

"Dify"平台的画布里，变量引用通常是{{#节点ID.字段名#}}这样的模板语法。你不需要记语法，因为配置面板里可以直接点击选择变量，系统会自动帮你插入。但理解这个机制很重要——它对应的就是传统代码里result = process(input)这一步：上一个函数的返回值，正好作为下一个函数的入参。

搞清楚这三点，你已经具备搭建任何简单工作流的基础了。接下来就动手。

2. 开工前的三件事：模型准备、平台入口和最小节点清单

动手前先做三件准备工作。别嫌简单，我在带人上手时发现，出问题的大多数情况都出在准备阶段。

第一，确认Dify环境可用。我用的是自己部署的版本，部署方式不复杂，一条常用的容器编排命令就能把整个平台拉起来，然后通过浏览器访问管理界面。如果你不想自己维护，也可以用官方提供的在线版本。无论哪种方式，只要你能正常登录平台控制台就行。需要注意的点是版本不要太旧，工作流功能在近两年迭代很快，旧版本缺少一些顺手的功能。

第二，准备一个可用的模型API Key。这是最容易卡住新手的地方。Dify本身不生产模型，它只是模型能力的调度层，所以你需要有自己的模型服务凭证。在平台的"设置-模型供应商"页面填好Key并完成校验即可。摘要这个任务不需要顶配模型，选一个速度和成本都均衡的中小规模模型就够用，等跑通之后再拿两三个模型做横向对比，看谁摘得准。

第三，想清楚你要做的摘要器接收什么、输出什么。我这次做的版本接收"单段长文本"，输出"300字以内的要点摘要"。如果你想批量处理文章，可以在开始节点接收"多行文本"；如果你想直接让用户上传文件，再接一个文档解析节点。第一次做建议从一个最简单的输入形态开始，别一上来就搞复杂架构。

准备工作的判断标准只有一个：你能不能在平台上手动运行一次模型对话。能，就说明模型链路是通的；不能，先解决这个，别急着进画布。

2.1 最小节点清单：为什么三个节点就够了

回到这个摘要器。最简流程只需要三个节点：

1. 开始节点：定义工作流的输入字段，相当于给外部使用者一个"投料口"。我定义了一个文本字段，用来接收原始文章内容。
2. 大模型节点：核心加工环节。配置模型、温度、最大长度和摘要prompt。
3. 结束节点：把大模型节点的输出暴露给调用方。没有它，外面的人就看不到结果。

三个节点首尾相连，就是一条完整的生产流水线。有人可能会问：不需要一个节点来做文本预处理吗？比如清洗格式、过滤空行。我的回答是：第一版不要加。做得越少，排查问题的范围就越小。三节点跑通之后，你再按需往中间塞节点，这才是健康的迭代方式。

2.2 对大模型节点的一个常见误解

补一个容易踩的误区。有读者以为"Dify有个摘要专用节点"，拖出来就能用。实际上没有这样一个黑盒节点。真正干活的是"大模型节点"——你通过prompt告诉模型"你是个摘要助手，请按以下要求输出摘要"，模型才变成摘要器。这个设计其实是刻意的：Dify给你的是通用积木，业务能力靠prompt注入。这反而说明，摘要质量的好与坏，很大程度取决于你的prompt写得好不好，而不是平台功能缺不缺。

3. 五步搭出摘要器：从空白画布到第一次运行成功

准备工作完成后，进入正式搭建。整个过程我拆成五步，每一步都很直观，跟着做就能跑通。

3.1 第一步：新建工作流并配置开始节点

在Dify控制台进入"工作流"页面，新建一个空白工作流。命名随意，我习惯叫它"文本摘要器-基础版"。创建后画布上会自动出现一个"开始"节点。

点开开始节点的配置面板，设置输入字段。字段类型很重要，我选了"段落"（多行文本），因为文章内容不可能是一行。字段名建议用英文或拼音，比如article，后面引用变量时会更顺。如果你想做一个对外直接可用的工具，可以再加一个"需要输出的摘要长度"字段，让使用的人自己控制压缩力度。第一版先不加，把所有复杂度藏在prompt里面。

3.2 第二步：添加大模型节点并组装摘要提示词

从画布左侧的节点列表里拖一个"大模型"节点放到开始节点右侧，然后从开始节点拉一根连线过来。这根线代表数据流向：文本从开始节点流入大模型节点。

接下来是整个流程的核心配置。模型选择你准备好的那个均衡型模型；在大模型节点的"系统Prompt"和"用户Prompt"里，我把摘要指令这样写：

系统Prompt： 你是一名专业的中文内容编辑，擅长提炼长文核心信息。请用简洁、客观、结构化的方式输出摘要。 用户Prompt： 请对用户输入的文章进行摘要，输出格式要求如下： 1. 总字数控制在300字以内 2. 先给出的一句话核心观点开头 3. 之后按"观点1/观点2/观点3"的方式列出关键要点 4. 只基于原文内容，不补充原文没有的信息 文章内容： {{#start.article#}}

注意最后一行，{{#start.article#}}就是引用开始节点里article字段的值。在配置面板里不需要手敲，点提示词输入框右侧的变量插入按钮，先选"开始"节点，再选它的article字段，系统会自动生成这行引用。这行引用相当于告诉模型：把用户投进来的文章内容填到这个位置。

3.3 第三步：配置模型参数：温度与最大长度

很多人会忽略大模型节点下方的参数区，这里其实藏着重要的控制项。

温度我设为0.2。摘要是一个"信息压缩"任务，要求准确、稳定、可复现，不需要创意的随机发挥。温度越高模型越"放飞"，同一个文本跑两次可能得到两种风格的摘要，这对工具型应用是大忌。0.1到0.3之间都是合理的区间。

最大Token数我设为500。300字的中文摘要加上可能的换行结构，500个token余量足够。这里要注意：最大Token数是对模型这次输出长度的硬性上限，一旦触顶输出会被截断，所以宁可设大一点。控制摘要长度的工作，应该交给prompt里的"300字以内"来完成，而不是靠硬截断。

3.4 第四步：配置结束节点，把结果送出去

拖一个"结束"节点放到大模型节点右侧，连上线。结束节点的作用是把内部的产出暴露给外部。在结束节点的输出配置里，选择大模型节点的文本输出，并把这个输出命名为summary。这样调用方拿到的结果就是一个字段清晰的JSON：{"summary": "摘要内容"}。

3.5 第五步：运行调试并验证输出

右上角找到"运行"按钮，填入一篇测试文章。建议准备两篇测试文本：一篇500字左右的短文看基本效果；一篇2000字以上的长文看稳定性和截断风险。点运行后，画布上会高亮显示节点执行链路，每一步节点上都会出现实际的输入输出数据，这正是可视化调试最舒服的地方。

第一次跑通时，我建议盯着两个地方：大模型节点中间输出的完整摘要内容，和结束节点的最终输出。如果中间摘要正常但结束节点输出为空，多半是结束节点里的字段映射配错了；如果中间输出就乱七八糟，回去改prompt。

4. 每一个配置背后都有原因：模型、参数与提示词的设计思路

三节点跑通之后，别急着封装上线，先停下来想清楚几个"为什么"。理解这些，才算真正掌握工作流，而不是只会按按钮。

4.1 摘要任务为什么用"低温度"：稳定压倒一切

温度这个参数，模型厂商定义它的时候叫"随机性"。值为0时，模型每次对同样输入的输出倾向完全确定；值越高，输出越多样。创意文案、营销标题可以往高处调，因为它需要意外惊喜；摘要不行，它是工具型任务，同一个文档今天跑和明天跑应该得到内容一致的摘要，否则下游用起来会乱套。

我实际测试过一组对比：同一篇三千字的行业分析，温度设为0.2时，三次运行的核心要点完全一致，只是措辞顺序略不同；温度设为0.9时，三次结果居然有一个要点被换成了另一个次要信息。摘要器是给人做判断依据的，丢掉关键信息是绝对不能接受的事，所以温度必须压低。 同理，如果你发现输出的摘要偏离了原文重点，先别急着换大模型，检查一下温度是不是被调高了。

4.2 提示词三段式：角色、任务、输出约束

这个提示词模板看着简单，但其实包含了三个必要组件，缺一个都会影响效果。

• 角色设定："你是一名专业的中文内容编辑"这句不是废话。模型训练数据里，"内容编辑"这个角色通常关联了一整套职业化的语言习惯，角色先行能让模型自动切换语言风格。
• 任务描述："对文章进行摘要"是任务，但"提炼核心信息"才是真正的动作方向。把要做什么说得越具体，模型越不容易跑偏。
• 输出约束："300字以内""按要点列出""只基于原文"——这些约束直接决定了结果的可用性。没有这些，模型可能给你一段抒情式总结，洋洋洒洒但不解决问题。

其中"只基于原文，不补充原文没有的信息"这条特别关键。摘要最常见的翻车不是摘不全，而是模型自己脑补了原文不存在的结论。在prompt里明确限制，能大幅降低幻觉出现的概率。

4.3 为什么说"中间件节点"是工作流的灵魂

我前文强调先做三节点版本，但真正体现工作流威力的是在中间加节点。举个实际例子：你希望支持用户直接上传PDF自动做摘要，传统做法要写PDF解析代码。而工作流里，你只需要在开始节点和大模型节点之间插入一个"文档提取器"节点，连线、配置字段，它就能自动把PDF内容抽取成文本喂给大模型。

这个思路叫"模板化处理"。每种节点都是一台专用的小机器，你不需要知道PDF解析内部怎么做的，就像你不需要知道HTTP协议怎么实现也能在浏览器里打开网站。工作流的性价比就体现在这里：把工程能力封装成积木，让业务逻辑通过连线自由组合。

我后来用这套结构改造过一个内部工具，做的事完全不是摘要，而是把客户反馈分类并生成周报。结构却是同一个：开始接收文本，大模型按prompt分类，再加一个判断节点分流，结束输出。你只要掌握一种结构，就能横向复制到很多场景。

4.4 模型选择：不是越贵越好，是越合适越好

不少初学者一上来就挑最贵的模型，觉得摘要效果一定更好。实测下来，对于"提取要点、压缩信息"这类任务，主流的中小尺寸模型和旗舰模型的差距远没有价格差距那么大。真正决定摘要质量的变量是：prompt是否讲清楚了要求、输入文本是否完整无损失、输出后是否做了格式校验。这三件事都做到位，中端模型已经能交出90分的答卷。

我会在跑通后再保留一两个备选模型，用同一篇测试文本对比输出，谁稳就上线谁。这就引出了工作流相比代码的另一个优势：换模型在画布里是一次下拉框选择，在代码里要改配置改测试改部署。低成本试错，让"多模型对比"从一个正经项目变成随手操作。

5. 实际跑起来之后会遇到的五个问题：完整排查链路

跑通是入门，跑稳是进阶。我把自己踩过和帮别人排除过的坑整理成五个高频问题，每个问题都按"症状-原因-排查-解决"来展开。

5.1 问题一：变量引用报错，输出全是空

症状：运行时报错提示找不到变量，或者大模型节点的输入里{{#start.article#}}原样显示没有被替换。

原因：多半是你把开始节点的字段重命名了，或者开始节点的节点ID变了，旧引用没跟着变。另一个常见原因是连线断了，大模型节点没有接收到上游数据。

排查链路：先在画布上点开始节点，确认它的字段名是什么样；再检查大模型节点和大模型节点之间的连线是否完好；最后看变量面板里可选的字段列表，对比引用文本有没有差异。如果中途改过字段名，最稳妥的做法是删掉旧的变量引用，重新从变量面板插入一次。关于变量的排查经历我先提个醒：不要相信记忆里的字段名，以变量面板里的实时列表为准。

5.2 问题二：摘要输出被截断，尾部缺内容

症状：摘要内容在某个词突然中断，经常是句子写到一半戛然而止。

原因：最大Token数设小了，模型的输出还没写完就被强制掐停了。注意这不是prompt的控制问题，而是平台层面的硬截断。

排查链路：看一眼输出摘要的最后一段是不是"话说到一半"；再看大模型节点的实际生成token数量是不是逼近了上限；如果逼近了，调大最大Token数，并把prompt里的输出长度要求从"300字以内"改成"250字左右"——留出缓冲空间。

5.3 问题三：长篇文本超上下文，运行报错

症状：粘贴一篇上万字的文章，运行后大模型节点直接报错，提示内容长度超限。

原因：没有哪个模型的上下文是无限的。文档太长，超过了当前模型的上下文窗口。

排查链路：两套解法。简单方案是换上下文更大的模型，治标不治本；根本方案是在工作流里加"文本拆分"环节，把长文切成多段，分别做摘要，再把多个小摘要合并成最终摘要。这个场景正好用上工作流的"迭代"节点：输入一个切好的文本块列表，循环执行子工作流，最后统一汇总。我建议第一次做长文本摘要时，先用一段不超过模型上下文一半的文本做验证，确认逻辑正确后再扩展到完整长文，不然报错信息会掩盖逻辑问题。

5.4 问题四：摘要内容出现原文没有的信息

症状：摘要里出现了一个看起来很有道理但原文根本没说过的数字或观点。

原因：模型在试图"补全"原文的未尽之意，本质是你对模型的约束不够强。

排查链路：先确认prompt里是否写了"只基于原文、不补充外部知识"；再检查温度是不是偏高；如果都正常，换用指令遵循能力更强的模型做一次A/B对比。摘要器对忠实度要求极高，宁可摘得保守一点，不能摘出虚假内容。这类问题如果频繁出现，可以加一个校验节点：把摘要和原文一起再喂给模型，让它检查摘要中的每个事实是否都有原文依据。虽然增加了token消耗，但这是高可靠场景值得付出的成本。

5.5 问题五：调试效率低，每改一次就跑全流程

症状：每次改完prompt都要重新粘贴测试文本、跑整个工作流才能看到效果，时间都浪费在重复操作上。

原因：对Dify的调试机制不够熟悉。

排查链路：利用画布上的单节点调试/运行记录功能，把常用的测试文章保存下来，测试时直接用历史输入，不用重新粘贴；改完大模型节点就只针对大模型节点做单点调试，确认这一节点的输入输出都正常后，再跑全流程。这样把调试粒度从"整条流程"缩小到"单个节点"，反馈速度能快一个量级。

6. 从摘要器到通用内容流水线：三种低成本扩展方向

三个节点能做出第一版，但工作流的真正价值是扩展性。还是回到摘要器这个底座，我给你三个已经验证过的升级方向，每个都可以在半小时内完成改造。

6.1 方向一：长文档多级摘要

基础版一次只能处理中等长度的文本，升级方向是在大模型节点之前加入"文档提取器"和"文本拆分"环节，在大模型之后加入"迭代"节点。结构变成：原始文档 → 提取文本 → 按固定长度切块 → 循环摘要每个文本块 → 把多段小摘要合并 → 最终输出大摘要。

这套"分而治之"的结构，我测试过一万字的行业报告，输出效果稳定，缺点是token消耗变大、耗时变长。但它解决了一个真实痛点：长文摘要不再是API的上下文限制问题，而是由你的工作流架构决定。你甚至可以把这个结构复制到"多章节会议纪要合并""多篇竞品分析汇总"上，都属于同一个模板的变体。

6.2 方向二：条件分支，让工作流自己决定路径

在Dify的节点列表里有一个"条件分支"节点。把它插到开始节点之后，配置一条规则：当输入的文本长度大于某个阈值时，走"长文本摘要"路径；小于阈值时，走"直接摘要"短路径。这样同一个工作流入口，既照顾了短文本的低延迟需求，也保障了长文本的完整处理。

条件分支让我意识到工作流和代码的关系又一次被拉近：它本质上就是if/else，只是通过可视化卡片呈现。写代码时你会随手加一个参数判断来决定走哪条函数链路，在画布里同样可以做，而且更直观——不同路径的节点颜色都能区分，维护的人一眼看懂。

6.3 方向三：把摘要器变成对外API服务

这个工作流画完不是终点。Dify允许把工作流发布为API服务和网页应用。我发布之后做了一次实际调用测试：POST一个JSON请求，传入文章文本，几秒后返回结构化摘要结果。这意味着它可以被任何系统集成——填进自己内部的CMS后台、接进IM机器人、甚至作为另一个更大工作流的子节点。

到这里，文本摘要器就不再是一个教学演示，而是一个真正融进业务系统的生产工具。这也是我反复强调"先跑通再扩展"的原因：基础链路像地基，地基稳了，上面盖再多的楼层都不会慌。

最后说两句实在话

搭建这套摘要器，我最大的体会是：不要被"工作流"这个名字唬住，它的本质就是"给AI装配流水线"。你先用最少的节点跑通主线，再根据实际需要往中间加环节，而不是一开始就在画布上堆满各种功能节点——节点越多，排查问题越痛苦。

使用建议上，给三个实操层面的提醒：第一，prompt是摘要器的灵魂，值得反复打磨，别舍不得花时间调整措辞和格式约束；第二，测试集要固定，准备两三篇代表不同长度和不同文风的文章，每次改动都拿同一组文本跑对比，效果差异才能看得清；第三，如果发现某个模型做摘要总是不听话，先别急着换模型，把温度降到0.1再观察一轮，很多问题纯粹是随机度过高导致的。

等这三节点版本用得顺手了，再回头试长文档多级摘要和条件分支，你会发现整个思维方式已经变了：不再想"这段代码怎么写"，而是想"这个环节应该用哪个节点、这条线怎么连"。这个转变，就是做AI应用最值钱的能力。