Dify工作流入门：5分钟搭建AI文本摘要器-北京尧图网络

如果你和我一样吃过“写完代码还要改提示词”这种亏那你大概率会对 Dify 工作流这种“拖拽连线代替代码”的方式产生兴趣。这篇是 Dify 入门系列的第七篇不聊安装注册、账号绑定这些皮毛而是用一个非常具体的任务——文本摘要器带你走一遍从零到一搭建 AI 工作流的完整过程。你会看到为什么我最终放弃了手写 Python 脚本调模型接口的老路子也会看到工作流里每一个节点之间到底是怎么接起来的以及 5 分钟跑通之后还有哪些参数和扩展值得折腾。先说结论文本摘要器是学习工作流最合适的“练习场”。它节点少、流程短、结果一眼能看出好坏非常适合理解 Dify 中“开始节点—LLM 节点—结束节点”这条主干。哪怕你之前完全没碰过 Dify跟着下面的步骤走也能在当前版本里复现整个流程。要是你已经被各种“老牌大厂 AI 开发框架”绕晕了这篇会是一个足够清爽的重新开始。1. 为什么我最终向“拖拽连线”低了头——聊聊工作流比代码更顺手的地方1.1 我最早写文本摘要器的样子先说段旧事。半年前我做过一个小组内部用的摘要工具需求很朴素把一篇会议纪要、产品文档或者访谈记录丢进去自动压缩成几百字的要点。听起来简单但我用传统方式实现时写了差不多三百行 Python。逻辑大概是先检查文本长度按字符切段逐段调用模型接口把所有分段摘要聚拢之后再来一轮汇总。这还没完接口超时要重试返回内容可能有空值某一段文本刚好卡在上下文上限时还得单独处理提示词模板里的特殊字符偶尔还会把字符串搞坏。最让我崩溃的不是写代码本身而是改提示词。产品经理一句“摘要风格再口语化一点”我就要去改代码里的提示词常量重新部署再填一遍测试样例看看输出有没有符合预期。这个过程重复了几次之后我开始怀疑人生内容生成的逻辑本来就不该藏在代码里。1.2 工作流的本质把数据流动画出来后来接触了 Dify 工作流我才意识到这类需求的痛点不在于“代码写不好”而在于“数据流向不透明”。工作流把整个过程画成了一张图输入从开始节点进来通过连线流到 LLM 节点模型处理完再流到结束节点返回给调用方。节点就是函数连线就是数据流。你在画布上看到的每一条线本质就是一段函数调用链。它让我最舒服的一点是中间结果可见。传统代码调试你要么 print 变量要么断点查看。工作流面板直接把每一步的输入输出摆在右侧哪个节点产出了什么哪个环节出了问题一眼就能定位。这种“所见即所得”的调试体验对 AI 应用这种不确定性很强的场景尤其珍贵。1.3 别神化工作流也别低估它我也要泼一点冷水。工作流不是万能的。如果你的需求涉及非常复杂的并发控制、定制化程度很高的数据清洗、或者要深度嵌入一个重量级内部系统那手写代码依然是更合适的选择。但如果你要做的是“把大模型能力融入现有业务流程”这件事工作流的效率优势非常明显。很多业务场景本质上就是链路固定的输入文本经过某种处理和模型推理输出结果。这类场景恰恰是工作流的甜区。文本摘要就是典型代表。它没有多轮对话的状态管理没有复杂的工具调用也没有动态规划路由的烦恼。整个链路固定成一条线你能清楚地看着数据从一端流到另一端。拿它当工作流的第一课再合适不过。2. 环境准备把 Dify 跑起来绕开前半小时的安装坑2.1 本地部署用 Docker Compose 最省心用 Dify 之前你得先有一个能访问的实例。如果你只想快速体验也可以用官方提供的云端服务但自己本地部署的好处是数据不出内网而且折腾坏了随便重来。我是直接用 Docker Compose 方式部署的这是当前最主流的路径。部署前确认机器上有 Docker 和 Docker Compose。现在的机器配置建议至少 2 核 4G低于这个配置平台本体能启动但跑模型推理时会明显卡顿尤其是同时开了多个服务的情况下。部署步骤大概是这样准备好 docker-compose.yaml 文件确认环境变量里的版本号和密钥项然后执行docker compose up -d启动。第一次启动要拉取不少镜像耐心等一会儿。启动完成后通过浏览器访问面板。默认端口是 80如果你机器上 80 被占用了记得先改映射端口再启动比如把端口映射改成8080:80访问地址随之变成http://localhost:8080。2.2 初始化管理员账号先别急着建应用首次打开面板会让你创建管理员账号设置邮箱和密码。这一步我不多说了重点说之后的事。登录后你会进入工作台。界面里主要的入口有应用列表、知识库、工具、监控、设置等等。很多人一进来就急着点“创建应用”结果到了工作流编排界面发现模型下拉框是空的又倒回来翻设置。为了避免这种反复建议第一步先去“设置”里把模型供应商配好。2.3 先把模型供应商配好免得后面抓瞎进入设置里的模型供应商页面填写对应的 API Key。不同服务商的配置项不太一样但核心思路一致填入 Key点保存然后在可用模型列表里把你要用的模型“部署”成可用状态。这里有个容易绕晕的概念系统默认模型和工作流节点里单独选择的模型是两码事。系统默认模型作用于一些平台内置功能比如对话应用里的默认回复模型工作流节点里的模型则是每个节点自己的选择。你在工作流编排时每个 LLM 节点都可以单独选择模型和参数。但如果模型供应商没配置好或者 Key 没有权限节点里就一个模型都选不到。一个容易踩的坑是 API Key 过期或配额不足。预览时报错很多时候不是工作流逻辑问题而是模型调用失败。Dify 的工作流运行记录里会显示节点级别的错误详情看到“鉴权失败”“Rate limit exceeded”这类信息先去检查模型供应商的配置状态别怀疑自己的画布逻辑。3. 五分钟搭出文本摘要器每一步操作都被我记下来了3.1 创建“工作流”类型应用而不是“聊天助手”进入应用列表点“创建应用”这时会出现两个选择聊天助手和工作流。我见过不少新手在这里纠结。简单说聊天助手带对话记忆和会话管理适合多轮交互工作流应用是一次性输入输出或者执行一段确定的流程。文本摘要器要的是“输入一段文本输出一个摘要”没有上下文记忆的需求所以选“工作流”就对了。创建之后进入“编排”页面你会看到一块空白画布。左侧是节点面板右侧是配置区。这个界面有点像设计器的感觉节点类型包括开始、LLM、知识检索、条件分支、代码执行、模板转换、HTTP 请求、工具、结束等等。3.2 开始节点定义输入变量和示例画布上默认有一个开始节点。点开它在输入变量区域添加两个变量。第一个变量建议命名为text类型选择“段落”描述写清楚“需要摘要的原文”。第二个变量可以命名为language类型选择“下拉选项”选项填“中文”和“英文”作为摘要语言的参考。这里有一个容易被忽略的细节每个变量下面都有“示例”字段。调试工作流的时候你可以在示例里预填一段测试文本每次点运行系统自动把示例作为输入值省去反复粘贴的麻烦。我第一次用的时候没注意到这个功能每测一次就粘一次长文本非常浪费时间。3.3 拖入 LLM 节点写提示词和选模型从左侧节点面板把“LLM”节点拖到画布上把开始节点右侧的连线拖到 LLM 节点左侧。点开 LLM 节点你会看到三个关键配置区域模型选择、提示词、参数调节。模型选择不用多说从下拉框里选你已经配置好的模型。提示词是这一步的核心我目前用的模板大致是这样的你是一个专业的文本摘要助手。请阅读用户提供的原文输出一份简洁清晰的中文摘要。要求 1. 保留原文的核心观点和关键结论 2. 省略重复、啰嗦的修饰内容 3. 使用简洁的陈述句避免口语化表达 4. 输出长度不超过200字原文如下 {{#start.text#}}需要注意提示词编辑器里不要手动敲变量占位符。编辑框上方有一个变量插入按钮点开之后从开始节点里选择text它会自动插入对应格式的占位符。不同版本的占位符写法可能略有差异手打不但费劲还很容易因为一个字母的拼写错误导致节点取不到值。我第一次就栽在这里后面会专门说。3.4 连接结束节点把结果输出出去再拖一个“结束”节点到画布上把 LLM 节点的输出连过去。点开结束节点在输出变量区域添加一个变量命名为summary类型选“段落”值引用 LLM 节点的文本输出。这一步看起来简单但要注意 LLM 节点可能有多个输出字段比如文本输出、生成耗时等结束节点里只能选“文本”那一项别选成其他无关字段。配置完成之后工作流就是一条完整的单向链路开始节点 → LLM 节点 → 结束节点。3.5 运行调试与发布上线右上角有“运行”按钮点它输入面板会自动填上开始节点示例里的文本直接点“运行”。右侧会显示整个工作流的执行轨迹开始节点输入了什么、LLM 节点收到的完整提示词是什么、模型返回的结果是什么、最终输出值是什么。这一步做对了5 分钟确实能跑通。我第一次完整跑通从创建应用到看到摘要结果时间差不多也就是一根泡面的功夫。跑通之后别忘了点“发布”发布后的工作流才能通过 API 和外部页面访问。工作流类型的应用发布后可以生成 API 调用地址。这个后续可以接进自己的业务系统也可以嵌入到网页里。发布这一步很容易被忽略但不做这一步前面的编排只是停留在草稿状态。4. 只要“跑通”不算完摘要质量靠的是这几个参数4.1 temperature要稳定还是要有趣很多初学者不理解 temperature 参数我试着用一句话说清楚它控制模型输出的随机性。值越高每次生成结果的差异越大可能蹦出“灵光一现”的句子但也可能偏离原文事实值越低输出越稳定、越保守适合做摘要、分类、信息提取这类任务。我在文本摘要器里习惯把 temperature 调到 0.2 左右。如果你用的模型对参数范围有自己的一套定义可以从 0.1 开始往上试超过 0.5 基本不建议。摘要这种场景稳定和忠实远大于“文采”。4.2 max tokens 和上下文长度限制LLM 节点里还有一个“最大 Token 数”的参数。摘要器的输出通常不会太长但输入文本可能很长。这里的原理是模型能接收的上下文长度有限你不能把无限长的文本都塞进一次调用里。如果原文超过了模型的上下文上限运行就会报错。对于入门阶段最简单的解决办法是选一个支持超长上下文的模型。等后面遇到真正很长的文档再考虑分段处理。不要一上来就追求处理百万字长文那是进阶玩法基础跑通更重要。4.3 提示词里的格式约束直接影响可用性一个让我印象深刻的经验是提示词里必须写明输出格式。只写“请帮我把这篇文章总结一下”得到的输出时好时坏有时是列表有时是带表情的段落有时还会冒出一句“当然可以”。这不是模型笨而是你给它的指令不够精确。想要稳定输出就在提示词里把格式要求写清楚。比如要求“输出三个要点每个要点不超过一句话”或者“输出 JSON 格式包含 summary 字段”。如果要求模型输出 JSON最好在提示词里给出一个示例结构它照着填就行。我后来用的一个参考模板是提取以下文本的核心事实按这种格式返回结果 - 背景一句话 - 关键信息最多三句话 - 结论一句话文本 {{#start.text#}}这样出来的结果格式统一还能直接复用进其他流程。4.4 模型之间的差异比想象中更大不同模型在指令跟随、长文本理解、语言表达上的差异很大。同一个提示词同一个输入换一个模型跑摘要的侧重点可能完全不一样。我做过一个简单对比用同一个提示词和同一段产品评测文章分别用两个模型跑摘要一个输出偏重参数罗列另一个输出偏重使用体验总结。没有谁对谁错只看哪个更贴合你的业务目标。建议在工作流搭建阶段用 Dify 的模型切换功能多测几个候选模型。每次切换后跑同一段测试文本对比输出质量和稳定性。一次对比跑完你对模型的认知会比看十篇评测文更准确。5. 当文本变成长文、多来源、多格式——工作流进阶节点组合5.1 用条件分支处理“文本太长”的挑战入门版摘要器跑通之后现实会立马给你出难题丢进来的文本越来越长。单次 LLM 调用的上下文窗口是有限的超长文本要么报错要么被截断摘要质量明显下降。一个比“换个超长上下文模型”更通用的方案是在流程里加条件分支判断。在 LLM 节点前面加一个“条件分支”节点判断输入文本的字符数是否超过某个阈值。如果没超过直接走单次摘要路径如果超过走一条专门处理长文本的路径。这样一来同一个工作流既能处理短文本也能处理长文。5.2 分段摘要再合并摘要长文本路径的核心做法是“分段摘要再合并摘要”。首先用模板转换节点或代码执行节点把长文按段落或者按固定长度切分成数组。然后对每个片段分别调用 LLM 节点做初步摘要。这一步如果你的 Dify 版本带迭代节点可以把 LLM 节点放进迭代循环里让每个片段依次通过同一个 LLM 处理不用手动拖出一堆重复节点。所有片段都生成摘要之后用模板转换节点把多个小结拼接在一起再交给一个 LLM 节点做最终汇总。最终汇总这一步非常关键它负责把零散的小结重新组织成一篇连贯的总体摘要。每个中间结果都能在工作流面板里单独查看一旦某个片段摘要质量不对你能精确找到是哪一个片段出了问题。5.3 用模板转换节点做输入清洗另一个常见情况是输入文档带格式。Markdown 文档、HTML 页面、爬下来的网页正文直接丢进 LLM 也不是不行但效果不可控。你可能在处理一篇文章时模型输出的摘要里混进了链接、标签符或者导航栏的文字。模板转换节点在这里派上用场。它本质上是一个“用模板拼接变量并生成新文本”的节点很多人只把它当输出格式化工具但它做输入清洗同样顺手。比如你可以配置一个模板只保留原文中的正文段落、标题和列表把冗余信息和特殊符号过滤掉再交给 LLM 节点。这样摘要器对输入格式的鲁棒性会提高不少。5.4 加一个知识检索节点摘要器瞬间升级如果你要处理的不是用户临时粘贴的一段文本而是一堆文档那摘要器的形态就需要改变了。可以在开始节点之后加一个知识检索节点把用户的查询词作为检索输入从知识库里召回相关片段再把这些片段和查询词一起交给 LLM 节点让它基于召回结果生成答案式摘要。这个组合其实就是 RAG 应用的常见形态。Dify 里知识检索节点提供可视化的相关性配置和召回数量设置你完全不用手写向量检索和排序逻辑。原先那个简单的“文本摘要器”就此升级成了“基于自有资料的问答摘要入口”。把一个单点工具扩展成完整应用整个过程不需要写代码只是把新增节点接进来。6. 踩过的坑位地图以及三个值得尝试的扩展方向6.1 我踩过的四个坑第一个坑变量引用错误。我在早期版本里尝试手动敲变量占位符结果一个字母拼写错误节点直接取不到值报错信息也不够直观。现在的习惯是任何需要引用变量的时候都通过编辑器里的变量选择器插入绝对不手打。第二个坑提示词里的花括号冲突。如果你想在提示词里要求模型输出 JSON 示例比如“返回格式{summary: 这里填摘要}”这类花括号很容易和 Dify 模板变量的语法冲突导致解析异常。解决方案是不要在提示词里手写花括号包裹的 JSON如果确实需要 JSON 输出可以用 Dify 内置的结构化输出能力或者在提示词里说清楚字段名让模型自己生成 JSON而不是把模板示例暴露在提示词里。第三个坑切换模型后参数不兼容。不同模型对某些参数的支持范围不一致比如有的模型 temperature 上限是 1.0有的是 1.5有的不支持某些采样方式。用上一份配置直接跑新模型有时会冒出参数不匹配的报错。换模型之后建议顺手检查一下 LLM 节点里的参数面板。第四个坑API Key 过期或配额不足。这种错误在运行记录里往往不是业务逻辑错误而是模型调用层的错误。我习惯在工作流报错时先看运行历史里失败节点的具体错误信息分清是节点逻辑问题、模型调用问题还是输入数据问题再决定从哪里下手排查。下表可以当作快速排查参考报错现象优先检查的位置节点取不到变量值变量插入方式、变量名拼写提示词解析异常是否手写了花括号包裹的 JSON 示例切换模型后偶发报错LLM 节点参数兼容性预览时报鉴权或配额错误模型供应商的 API Key 状态长文本输入报错模型上下文窗口上限6.2 两个提升效率的使用习惯每新建一个节点顺手把默认的“LLM 节点 1”改成能看懂的名字比如“长文判断”“分段摘要”“最终合并”。一开始我觉得这样很啰嗦等画布上节点超过十个你会非常感激自己这个随手动作。另一个习惯是调试时先用短文本跑通再接真实长文。短文本和短报错信息能让问题快速定位等主链路没问题了再上真实语料做质量测试。6.3 三个扩展方向不是终点是入口方向一把摘要输出接到其他节点。工作流发布之后可以在输出节点后面再接一个 HTTP 请求节点把摘要结果自动发送到企业群机器人、邮件接口或者其他系统。Dify 对这类 HTTP 请求的支持比较完整配置好请求地址和参数即可。方向二把摘要器包装成 API 服务。工作流发布后在 API 访问页面可以拿到专属的 API 地址和密钥。外部系统只要通过标准 HTTP 请求就能调用这个工作流把“内部玩具”变成“业务能力”。方向三让摘要结果参与多轮对话。如果你把应用类型换成对话型摘要结果可以作为一个变量保存下来后续对话直接引用它。这样用户可以先让系统总结一篇长文再就总结内容继续提问形成“先总结、再答疑”的交互体验。以我现在的习惯任何新的 AI 需求来了我都先拖一个迷你工作流试试跑通了再考虑要不要进一步工程化。工作流这个玩意的下限是“五分钟玩具”上限其实比你想象的高。别把它当成大语言模型的装饰品也别觉得可视化就低人一等。它的真正价值在于把“调用 AI”这件事重新还原成了可以调试、可以观察、可以迭代的逻辑表达。最后分享一个小技巧给开始节点的示例字段填上你真实业务里最常出现的那一类文本。下次调试时你点开运行就能看到接近真实场景的输入和输出比随手找一段范文去测试要有用得多。你在 Dify 里拖出的每一条线最终都会变成对业务逻辑的一次重新梳理。

Dify工作流入门：5分钟搭建AI文本摘要器

相关推荐

基于SpringBoot+Vue+MySQL的高校商铺管理系统设计与实现

空间域统计排序滤波全解析：中值、极值滤波的Python实现与去噪实战

Flink DataStream核心机制拆解：状态、水位线与反压实战

更多资讯

二进制存档逆向：以字符串引用为锚点拆解XOR混淆与压缩封装

Hypit开源工具：一键提取爆款视频结构，驱动Claude Code与Codex生成脚本

家庭理财管理系统数据库课设：Access建表与VB增删改查完整实现

沿字符串引用还原存档封装：XOR校验压缩层层拆解

GMM-HMM孤立词识别：端侧轻量语音唤醒的确定性实现

Proteus仿真STM32：从点灯到定时器验证的避坑指南

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？