Dify可视化工作流实战：5分钟拖拽搭建文本摘要器

把文本摘要器做成可视化工作流，这件事花的时间比我预想的少得多。字节、阿里、各种创业团队都在推AI工作流，但很多人一开始就卡在“从哪下手”。Dify这类平台把LLM调用、提示词管理、流程串联全部封装成了可视化的节点，你不需要写一行代码，只需要在画布上拖一个节点、拉一条连线，就能把一个真实可用的AI应用搭出来。我自己在用Dify做文本摘要器的过程中，最大的感受是：AI应用开发的门槛真的被拉低了，而且调试和迭代的速度是传统代码方式没法比的。

这篇文章是Dify入门系列的第七篇，我们聚焦一个特别适合练手的小项目——文本摘要器。它的用途很直接：把一篇几千字的会议纪要、新闻稿、论文或者产品文档，自动浓缩成几百字的摘要，保留核心信息，省掉人工阅读筛选的时间。对于运营、编辑、产品经理、开发者，这套东西都能直接用。文章会从方案选型讲到环境准备，再到完整实操，最后补上常见坑位，目标是让一个完全没碰过Dify的新手，跟着操作5分钟就能跑出一个属于自己的AI工作流。

1. 为什么用“拖拽连线”而不是直接写代码

1.1 AI应用开发方式的根本变化

以前做一个AI摘要功能，流程大概是这样的：先申请一个模型API，拿到Key，然后写代码调接口。接口返回的是流式数据，你还要处理流式拼接；输入文本太长，要考虑truncate还是分块；模型偶尔抽风返回空值，你得加异常捕获；多个用户同时用，还得考虑限流和错误重试。这些活零零散散加起来，纯代码实现一个能用的工具，怎么也得写几百行，还要花时间排查各种边界情况。

Dify出现以后，这种开发模式被明显改变了。模型调用、参数配置、结果解析都被封装成了一个个节点。你不需要理解HTTP请求底层怎么发，也不需要关心token怎么算、JSON怎么解析。画布上的一个LLM节点，就相当于把一整段“调用模型并拿回结果”的逻辑全部包好了。你只需要做两件事：告诉它用哪个模型，把输入变量放进去。

我自己还是写过不少代码再转到Dify的，说实话，刚开始会对“不写代码”这件事有点怀疑，总觉得可视化会不会不够灵活。但实际用下来会发现，Dify底层其实保留了代码节点和HTTP请求节点，真遇到复杂逻辑，完全可以在流程里嵌入代码块。它不是说“不让你写代码”，而是把那些重复的、无意义的胶水代码省掉了，把精力留给真正需要思考的部分。

1.2 拖拽连线的三层真实价值

第一层价值是看得见。传统的代码应用，逻辑散落在不同的函数和文件里，排查问题要一层层打印日志。工作流画布上，每个节点都是可见的方块，连线代表数据流动方向。哪一步输出不对，直接点开节点看输入输出，一目了然。这个体验用过一次就回不去了。

第二层价值是拆得开。把完整的业务逻辑拆成独立的节点，每个节点只负责一件事。比如文本摘要器，开始节点负责接收用户输入，LLM节点负责总结，结束节点负责输出结果。想改摘要长度，不用翻代码，直接改提示词就行；想换模型，在LLM节点上切换就行；想加一个“字数统计”的功能，在中间插一个代码节点就可以。每个节点可以单独修改、单独测试，不会影响其他部分。

第三层价值是有人用。可视化流程对非技术同事非常友好。以前运营同学提需求，开发要翻译成代码、排期、上线；现在运营同学自己就能在画布上调整提示词，或者把流程里的某个环节截图发到群里讨论。团队协作的摩擦变小了，这对小团队尤其重要。

1.3 为什么“文本摘要器”是最佳入门案例

我见过很多人第一次接触Dify就想着搭一个很复杂的智能体，结果配置了一堆节点，效果不好还找不到问题在哪里。文本摘要器这个项目，节点少、逻辑清晰、业务价值明确，是市面上所有工作流教程里最接近“Hello World”的案例，但它又不像真正的Hello World那样只能跑给你自己看。

摘要器完整覆盖了三个最基础的节点：开始节点、LLM节点、结束节点。这三个节点是后面所有复杂工作流的骨架。条件分支、知识检索、参数提取、迭代处理，本质上都是在这些节点之间插入新的控制逻辑。把摘要器的三个节点吃透，后面你再去搭客服机器人、文档问答、日报生成器，都会顺畅很多。

2. 搭建前的环境准备与核心概念

2.1 Dify版本选择与部署方式

我用的是Dify社区版，目前版本已经迭代到1.x，功能相比早期版本有了很大提升。官方提供了Docker Compose的部署方式，适合自己动手的人。如果你只是想快速体验，直接用Dify官方的云服务也行，注册账号以后就能直接创建应用，省掉本地部署的麻烦。但如果你对数据安全有要求，或者想深度定制，本地部署是更好的选择。

本地部署的步骤其实不复杂：机器上装好Docker和Docker Compose，下载官方仓库里的docker-compose.yaml，然后执行启动命令，等待容器拉起来，浏览器访问服务器IP的80端口即可进入控制台。整个安装过程对服务器配置的要求不算高，社区版在4核8G的机器上运行得很流畅，如果配置太低，推理速度和页面响应都会明显变慢。

我电脑上跑的是Dify 1.x版本，界面已经比较成熟了，左侧是应用列表，右侧是详情。如果你之前用的是0.x的老版本，升级到1.x之后会发现界面布局有调整，工作流编辑器的交互也更顺滑了。这里提醒一下，版本号不同，个别菜单位置可能会有细微差别，但核心操作逻辑基本一致，遇到界面对不上的情况，优先在左侧菜单里找“工作流”或“编排”入口。

2.2 工作流画布上的核心节点一览

Dify工作流画布可以添加多个节点类型，每个节点承担一类职责。我做摘要器之前，先花了几分钟把节点类型过了一遍，搞清楚它们各自能干什么，这对后面的流程设计帮助很大。下面把我认为最常用的几个节点列出来：

对于文本摘要器，核心只用得上开始、LLM、结束三个节点。但剩下的节点在后面扩展时几乎都会用到，尤其是条件分支和代码节点，可以说是让工作流变“聪明”的关键。

2.3 变量与连线的数据流：千万要理解这个

很多新手第一课就卡在节点配置上，问题多半出在变量引用。简单说，每个节点都有输入和输出，输入可以是用户填写的固定值，也可以是前一个节点输出的变量。在LLM节点的提示词里，如果要引用开始节点的输入，写法是{{#start.text#}}，其中start是开始节点的节点ID，text是开始节点里定义的字段名。

这个语法刚开始容易写错。我建议在配置提示词时，不要手打变量名，直接用画布上“插入变量”的功能，系统会自动生成正确的语法。节点ID在创建节点时可以自定义，我习惯把开始节点命名为start，LLM节点命名为llm，结束节点命名为end，这样在变量引用时一眼就能看清数据来自哪里。

数据流的方向也很好理解：从开始节点出发，流向LLM节点，再到结束节点。连线上的数据是“传递”的关系，而不是“覆盖”。也就是说，LLM节点处理完成后，它的输出并不会把开始节点的输入清空，整个工作流运行期间，所有节点的历史输入输出都可以在调试面板里查看，这也是工作流调试体验比传统代码日志好的原因之一。

3. 实操演示：5分钟搭建文本摘要器

3.1 创建空白工作流应用

进入Dify控制台后，在应用列表页点击“创建空白应用”，这时会弹出一个选择界面，让你选择应用类型。这里有两个选项容易混淆：一个是“聊天助手”，一个是“工作流”。聊天助手适合做对话式应用，比如客服机器人；工作流则适合做自动化任务处理，比如摘要、分类、数据加工。文本摘要器属于后者，选“工作流”就行。

创建之后，系统会进入工作流编辑页面，画布上默认已经放好了开始节点和结束节点。左边是节点类型面板，可以拖拽新的节点到画布上；右侧是节点配置面板，选中节点以后在这里配置参数；顶部是运行和调试按钮。整体布局和常见的低代码平台类似，有前端开发经验的人应该会觉得特别亲切。

建议在动手连线之前，先给应用起一个清晰的名字，比如“文本摘要器-基础版”。这个名称会显示在应用的WebApp页面上，也会出现在后台的应用列表里。取名字虽然不影响功能，但对后面的管理很有帮助，尤其是应用多了以后，辨识度高的名字能省很多找来找去的时间。

3.2 配置开始节点：定义输入字段

单击画布上的开始节点，右侧会显示该节点的配置区域。我们需要在这里定义工作流对外暴露的输入参数。点击“添加变量”，变量类型选择“段落”，字段名填text。这里需要注意区分“文本”和“段落”两个类型：文本类型适合短内容，段落类型适合长内容，而且段落类型会保留换行符，对于摘要器这种处理长文章的场景，段落类型是更合适的。

变量类型看起来很基础，但直接影响后续提示词的效果。如果选择文本类型，长文本在传递过程中可能会出现换行丢失的情况，模型接收到的内容变成了没有段落结构的文字，摘要质量会受影响。段落类型就不会有这个问题。

配置好变量后，可以先点一下“预览”，看到模型运行前用户会提交什么样的输入格式。开始节点是整个工作流的入口，配置这里的时候，一定要想到后面LLM节点会怎么引用它，字段名要规范，最好用英文小写加下划线，不要用特殊字符和中文。

3.3 配置LLM节点：模型、提示词与参数

接下来是重头戏，从左侧拖一个LLM节点到画布上，放在开始节点和结束节点之间，把开始节点和LLM节点之间的连线拉好，再把LLM节点和结束节点连起来。选中LLM节点，右侧会出现配置区，需要配置的内容有模型、系统提示词、用户提示词和模型参数。

模型选择看自己的实际情况。如果用Dify云服务，配置好模型供应商后就能直接选择对应的模型；本地部署的话，常见的选择是接入DeepSeek、通义千问、GPT系列等。我的经验是，摘要任务对模型的理解能力要求不算特别高，不必一味追求顶级模型，综合精度和成本，gpt-4o-mini、qwen-plus这类中端模型完全够用。

系统提示词解决的是“模型以什么身份和规则来工作”的问题，这里我习惯写清楚输出格式和约束。下面是我实际用的一套提示词：

text复制你是一名专业的中文文本摘要专家。
你的任务是把用户输入的文本提炼成简洁、准确的摘要。
要求：
1. 保留原文的核心观点、关键事实和结论，不要添加原文没有的信息。
2. 使用客观中立的语气，不要使用“总的来说”“综上所述”等空话。
3. 如果原文包含数据，请在摘要中保留重要数字。
4. 输出控制在150字以内，如果原文超过3000字，摘要可以适当加长到300字。

模型参数方面，把“温度”设置在0.3以下比较合适。温度值越低，输出越稳定、越不容易跑偏，摘要任务需要的是忠实于原文的内容，不是天马行空的创作，温度一定不能调高。最大Token数根据你的预期摘要长度来设，一般512足够，如果担心长文本摘要被截断，可以调到1024。

3.4 配置结束节点并发布为WebApp

LLM节点配置好以后，选中结束节点。结束节点需要定义工作流的输出内容。点击“添加变量”，类型选“段落”，变量名可以叫summary。在变量值这里，点击“插入变量”，选择LLM节点的输出文本字段。这样，LLM生成的摘要就会通过结束节点传给用户。

配置完成之后，先点击页面顶部的“运行”按钮，输入一段测试文本，看看完整流程是否能跑通。如果顺利，运行结果里会返回摘要内容，同时调试面板会展示每个节点的输入输出。第一次运行就把摘要成功生成出来的时候，那种爽感真的只有做过的人能体会——不到3分钟，一个能用的AI应用就立起来了。

测试没问题后，点击右上角的“发布”按钮，在弹出的窗口里填写应用的版本说明，然后确认发布。发布后进入应用详情页，找到“运行”入口，会看到一个标准的Web页面，用户可以在输入框里粘贴文本，点击提交就能得到摘要。把这个链接发给同事或朋友，他们不需要懂技术也能直接使用。

3.5 调试运行与效果优化

应用发布只代表“能跑”，不代表“效果好”。我每次搭完一个工作流，都会专门花时间做效果调优。摘要器的常见问题是摘要内容太泛、抓不住重点。这时优先调整系统提示词，把“重点”定义得更具体。

比如，原始文本是一份会议纪要，摘要重点应该是决策事项、责任人、截止时间，而不是寒暄和背景介绍。这时候，把系统提示词改成“重点提取决策事项、责任人和时间节点”就能明显提升可用性。另外，我还习惯在用户提示词里增加一句话：“如果原文中没有明确结论，请概括主要内容”。这句话看起来可有可无，但实际测试中，加上以后模型更愿意在原文信息不足时给出概括性描述，而不是硬编一个结论。

调试时多用不同风格的文本测试。我一般会准备产品发布新闻、会议纪要、技术文档各一份，分别测试同一套流程的摘要质量。这样能在早期暴露提示词的偏向性，避免只看一个样本就沾沾自喜。

4. 进阶扩展：让摘要器从“能跑”到“好用”

4.1 挂接知识库，增强专业摘要能力

基础版摘要器只能依赖模型本身的通用理解能力。如果摘要的文本是某个行业的内容，比如医疗文献、法律合同、公司内部制度，通用模型可能抓不住行业术语的含义。解决办法是，把相关领域的背景资料导入Dify知识库，然后在工作流中加入“知识检索”节点。

知识检索节点的作用，是在处理输入文本之前，先从知识库里召回到与该文本相关的背景资料片段，把这些片段和原文一起拼接给LLM节点，让模型带着参考资料来总结。对于垂直领域用户，这一步几乎是刚需。实现方式不复杂：先在知识库模块里上传资料文档，系统会自动做解析和向量化，然后在工作流里添加知识检索节点，选择对应的知识库，把它放在LLM节点之前，并在LLM节点提示词中引用检索到的片段即可。

这里要提醒一句：知识检索不是越多越好。检索结果过多会让上下文变得臃肿，拉高token消耗，还可能干扰核心内容的摘要。一般我把TopK设置为3到5，召回片段数量控制在1000个字符以内，效果和成本比较平衡。

4.2 用条件分支实现多模式摘要

条件分支节点相当于传统编程里的if-else，它的存在让工作流可以根据输入内容走不同的路径。我给摘要器加了一个“摘要模式”的输入字段，用户可以选择“简洁模式”“详细模式”或“数据重点模式”，工作流根据用户选择的模式，把文本交给不同的提示词分支去处理。

具体配置方法是：在开始节点新增一个下拉列表类型的变量，选项设为“简洁模式”“详细模式”“数据重点模式”。在画布上添加条件分支节点，配置三个分支条件，每个分支对应一个LLM节点，分别配置不同的系统提示词。最后在结束节点里，把三个LLM节点的输出变量都加进来，哪个分支被执行，对应的输出就会传给结束节点。

这个扩展让同一个工作流承担了多个职能，本质上是把重复的开发工作一次做完。后续如果还想增加“英文模式”“标题生成模式”，只需要复制一个分支、改改提示词就行，不需要动其他节点。

4.3 用代码节点完成文本预处理

模型对输入长度是有上限的，虽然摘要器处理的大多数文本不会超限，但遇到特别长的文章，最好先做截断或分段。Dify的代码节点支持Python和JavaScript，我习惯用JavaScript写一个简单的预处理逻辑：统计输入字符数，如果超过8000字，就截取前8000字。

示例代码如下：

javascript复制function main({ text }) {
  if (!text || typeof text !== 'string') {
    return { processedText: '', charCount: 0, truncated: false };
  }
  const maxLength = 8000;
  const truncated = text.length > maxLength;
  const processedText = truncated ? text.slice(0, maxLength) : text;
  return {
    processedText: processedText,
    charCount: text.length,
    truncated: truncated
  };
}

把这个节点插在开始节点和LLM节点之间，代码节点的输出变量就会替代原来的原始文本，传给后续的LLM节点。同时，代码节点还能输出字符数、是否截断等信息，有条件分支需求时可以直接引用这些字段做判断。代码节点能做的事很多，数据清洗、格式转换、统计计算都没有问题，有了这个“逃生舱”，工作流的灵活性基本不会比纯代码差。

5. 常见问题与排查技巧实录

5.1 运行报错和变量引用问题，先看调试面板

新手最容易遇到的是运行时报错。常见的错误包括：提示词里手写的变量名和节点字段名不一致，导致运行时找不到变量；某个节点没有正确连线，导致上游数据没有传下来；模型供应商的API Key配置有问题，导致模型调用失败。

排查方法是看运行面板里每个节点的状态。Dify调试面板会标注每个节点的输入输出和错误信息。如果某个节点报红，点进去看错误详情，八成能定位到问题。这里我特别想强调：变量引用一定要用编辑器里的“插入变量”功能，手写{{#...}}很容易出错，尤其是字段名一长就容易拼错，这个坑我自己踩过不止一次。

5.2 输出摘要效果不理想，优先调提示词而不是换模型

输出内容太长、太短、抓不住重点，这类问题不属于“报错”，系统不会提示你，只能靠人工判断。我的排查顺序是：先看模型是否理解了任务。把用户提示词里的指令写得更具体一点，比如明确说“必须控制在100字以内”，比让模型自行判断可靠得多。然后检查温度参数，摘要任务温度太高会“放飞自我”，输出一些原文没有的信息，压到0.3以下通常能改善。

如果提示词和参数都调过了，效果仍然不行，再考虑换一个更强的模型。很多人在基础模型上反复调提示词，效果不明显，结果换一个理解能力更强的模型，同样的提示词，效果立竿见影。工具选型要灵活，不要一开始就把自己锁死。

5.3 运行速度慢、超时，先看文本长度和模型延迟

工作流运行慢，通常和两个因素有关：文本输入太长、模型推理速度慢。文本太长会导致模型处理时间增加，也容易触发超时限制。解决方案是在工作流入口做文本长度校验，超长文本先截断或用代码节点分段处理。模型延迟这块，可以换一个响应更快的模型，摘要任务不是非要用最强模型不可。

本地部署的朋友还得多留意部署机器性能。Dify本身的资源占用并不算大，但模型推理如果是本地跑，对GPU和内存的要求会高很多。如果用的还是CPU推理，文本稍长就会明显卡顿。如果摘要器是给团队用的，建议把模型调用切换到云端API，延迟和稳定性会好很多。

5.4 发布后WebApp无法访问的排查思路

发布以后，应用生成的访问链接打不开，这个问题的根源通常是部署环境。本地部署时，服务器防火墙没有开放80端口，或者所在云服务商的安全组规则没有放行，外部就无法访问。网络侧确认没问题以后，还要检查Dify容器是否正常运行，用docker compose ps查看容器状态，如果某个容器意外退出，再通过docker compose logs看具体日志。

如果是Dify云服务，打不开链接的概率极低，遇到问题先检查浏览器和网络环境，多数是临时性的访问异常。手机端访问时，注意是否被某些浏览器插件拦截了，我遇到过几次都是这类原因。

5.5 几个容易被忽略的实操细节

第一，开始节点的变量，名称一旦创建并开始被后续节点引用，尽量不要轻易修改。改字段名可能导致所有引用全部失效，虽然可以逐个修复，但很浪费时间。第二，发布新版本前，一定要先跑一次完整测试。Dify支持多版本的发布记录，但线上应用默认用的是最新发布版本，不要在没有测试的情况下直接覆盖线上。第三，定期检查模型API的消耗情况。工作流跑起来以后，token消耗速度比你想象得快，尤其是挂了知识检索节点之后，每次调用会额外消耗检索片段的token，成本要提前心里有数。

我用这套方法搭摘要器的时候，前前后后改过七八版提示词，从最初“能总结出几句话”到现在“能精准提取决策事项和数据指标”，效果提升非常明显。整个过程没有写过一行业务代码，全靠拖拽、连线、改提示词完成迭代。这也是Dify工作流最打动我的地方：它把AI应用从“程序员专属”拉回到了“业务人员也能上手”的范畴。

根据我个人的经验，工作流这条路线的价值不在于彻底消灭代码，而在于让逻辑变得透明，让迭代变得轻快。你完全可以在Dify里保留自己的代码节点，去处理那些真正需要写代码的复杂计算；与此同时，把模型调用、分支控制、数据传递这些容易被细节淹没的部分，交给可视化编排来搞定。下一步我打算在这个摘要器基础上继续加东西，比如接邮件通知、定时触发，或者把它改造成一键生成日报的小工具。这些扩展在Dify里都有对应的节点支持，等做好了，再回来分享新的踩坑记录。