做了大半年 Dify 工作流我最大的感受是以前想做一个“把长文自动提炼成摘要”的小工具至少要写一坨调用大模型 API 的脚本还得处理重试、Token 截断、输出解析这些破事。现在在 Dify 里开一个空白工作流拖上“开始、LLM、结束”三个节点连两条线填一段提示词5 分钟就能跑通顺手还能发布成一个带鉴权的 API 接口。这篇入门系列第七篇就用“文本摘要器”这个最小但完整的例子把 Dify AI工作流从零到一的搭建过程完整走一遍顺便聊聊那些文档里不会写、但实操一定会踩的坑。1. 先想明白为什么用“拖拽连线”做摘要器1.1 工作流不是万能药它最适合“流程确定”的事Dify 里一个应用可以做成三种形态聊天助手、Agent、工作流。刚接触的人容易把这三个混在一起选错形态后面会绕很多弯路。聊天助手适合单轮或多轮对话比如问答、闲聊类的产品Agent 是给大模型一堆工具让它自己决定先调哪个再调哪个路径完全由模型临场发挥而工作流不一样编排逻辑由你定死每一步做什么固定下来不靠模型自由发挥。文本摘要器天然适合工作流。因为它的输入和输出都非常确定喂一段长文本产出一段短摘要中间就是一次大模型推理。这种任务如果丢给 Agent 去做反而要担心它“自由发挥”时是不是插入了一些无关步骤。拿流水线来类比工作流就是一条装配线每个工位做什么都写在图纸上Agent 更像一个只领了目标的实习生能力强但路径不可控。摘要这种高重复、高标准的活交给装配线最稳。1.2 拖拽连线消除了哪些“手写代码”的痛有人会问这种单次调用大模型的逻辑自己写个脚本也不难为什么非要用可视化工作流我第一次用代码调大模型 API 时真正的成本不在那几行请求代码在于边界情况文本超长怎么截断调用失败要不要重试响应格式不稳定怎么解析换了模型供应商是不是得重写一遍模型 API 的认证方式变了怎么办这些细节堆起来一个“简单摘要工具”也能耗掉一整天。Dify 工作流把这些底层问题全部封装了。节点负责数据流转模型供应商统一管理提示词随便改运行时还能一步步看每个节点的输入和输出。等于你把“怎么调用模型”的脏活外包给了平台自己只保留业务逻辑。第二个隐藏收益是维护成本拖拽出来的流程图天然就是文档过三个月回头看仍然秒懂而脚本类代码哪怕当时注释写得再全再打开也要重新读一遍。1.3 为什么拿文本摘要器当入门案例因为它是“麻雀虽小、五脏俱全”的典型。完整的 Dify 工作流通常包含开始节点、LLM 节点、结束节点、变量传递、参数调优、API 发布这套流程和做任何一个复杂工作流的流程完全一样。只是它没有条件分支、没有知识检索、没有迭代循环非常适合新手建立全局手感。你把这些最小环节跑明白了后面再去玩“联网搜索 写周报 抄送钉钉”这类复杂编排会发现思路完全一致只是节点多了几张。这也是我在这个系列里反复强调的先从一个最小闭环开始再逐步加复杂度比一上来就模仿别人的复杂模板要高效得多。2. 动手前准备环境、模型和一段测试文本2.1 确认 Dify 环境与模型供应商开始之前你至少要有一个能访问的 Dify 实例。这里不展开完整的安装教程只提醒一句如果还没装找一台 Linux 机器按官方文档用 Docker Compose 一条命令就能拉起来如果你在 Windows 机器上装好 Docker Desktop 后同样可以跑但新版镜像变化比较多升级前一定先看一眼 Release Note。版本不要太老有些节点是最近几个版本才完善的旧版工作流 UI 和变量引用语法也不太一样。然后确认“模型供应商”菜单里至少有一个可用的模型。国内用户最省事的是配置 DeepSeek、通义千问这类 API密钥在对应官网申请填进去点“测试”通过就能用。想省钱或者数据不想出内网可以用 Ollama 接本地模型但摘要这种对中文理解要求高的活本地 7B 模型和在线大模型的输出质量差距比较大尤其是千字以上的长文。我日常测试一般用 DeepSeek 或 Qwen性价比好摘要结果稳定。2.2 设计最小工作流的结构准备工作流之前先在纸上把节点画出来这是老生常谈但总是被跳过的步骤。文本摘要器只需要三个节点开始节点接收用户粘贴的长文LLM 节点基于提示词做总结结束节点把结果返回给调用方。你可能会觉得“这也太简单了”。对但入门阶段就是要学会控制节点数量。很多新手上手就加一堆节点结果数据流还没搞清排查问题先花掉半天。先用最简结构跑通再逐层加复杂度这是做工作流最省时间的路。2.3 准备测试文本和“预期摘要”测试文本别随便拿一两句话糊弄。建议准备一段 800 到 1500 字左右的新闻稿、产品介绍或技术文章自己先读一遍在心里或文档里写个“理想摘要”出来。为什么因为摘要器好不好用判断标准就是“模型输出离你的预期差多远”。先有预期才能判断模型是跑偏还是正常也方便后面调提示词做对比。3. 5 分钟实操从新建空白工作流到发布 API3.1 新建空白工作流登录 Dify 控制台在“应用”页面点“创建应用”。应用类型选择“空白工作流”给应用起个名字我一般叫它“长文摘要器”描述随便写一句“输入长文本输出结构化摘要”。点创建之后你就进入了一个空白的画布左边是节点面板中间是画布区右边会随着选中节点显示配置面板。这个界面刚进来可能觉得花哨但你只需要记住核心操作从左边节点面板拖出节点放到画布上再从一个节点右侧的圆点拖线到另一个节点左侧的接口。节点之间的连线就是数据流的方向。3.2 配置开始节点定义输入字段点击画布上的“开始”节点右侧面板会显示输入字段配置。点“添加变量”字段类型选择“文本段落”这个很关键——不要选“文本框”。文本段落适合长文本输入框更大内容里的换行符也能保留模型读起来结构更清晰。变量名我设为 document显示名称写“待摘要文本”。你可能会问变量名为什么不用中文。因为后面在提示词里插入变量时英文名不容易出错而且如果将来用 API 调用inputs 里的字段名也是这个变量名英文兼容性更好。3.3 配置 LLM 节点整个摘要器的灵魂把“LLM”节点拖到开始节点右侧然后从开始节点右侧圆点拖一条线连到 LLM 节点的左侧。选中 LLM 节点右侧面板开始配置。第一项是模型供应商和具体模型。工作流里每个 LLM 节点都要单独选一次模型这是设计如此方便你在一个工作流里组合不同模型。摘要场景我通常选中文能力强一点的模型DeepSeek 或 Qwen 都好使。第二项是提示词。LLM 节点一般会有系统提示词和用户提示词两个输入框。系统提示词负责定角色、定规则用户提示词里放真正要处理的内容。下面这套是我在多个场景里改过很多次之后沉淀下来的模板可以直接抄系统提示词你是一名资深的内容编辑擅长把冗长的文本提炼成简洁、准确、信息完整的摘要。 请严格按照用户的写作要求输出不要添加原文没有的信息不要输出与摘要无关的客套话。用户提示词请阅读下面的文本生成一段约300字的中文摘要。 要求 1. 保留核心观点、关键数据和最终结论 2. 移除重复表达、修饰性内容和无意义的过渡句 3. 按“背景、做法、结果、意义”的逻辑组织摘要但不是机械套用 4. 只输出摘要正文不要使用列表符号也不要输出“以下是摘要”这类开场白。 文本内容 {{#start.document#}}这里有个操作要点{{#start.document#}}这段变量引用实际上不用手敲。你只需要把光标放到“文本内容”后面然后在输入框上方找到变量插入按钮Dify 会列出当前画布上所有可用的上游变量选中“开始节点”的 document 字段它会自动插入对应语法。不同小版本的 Dify 显示格式可能稍有不同都以画布界面实际插入的为准。第三项是模型参数。温度Temperature是摘要任务里最重要的旋钮它控制输出的随机性。温度太高模型容易自由发挥摘要里冒出原文没有的“感悟”温度太低偶尔会显得僵化。摘要属于事实压缩型任务我实测 0.1 到 0.3 之间效果最好。最大 TokenMax Tokens决定输出长度的上限摘要输出一般在 300 到 500 字所以我习惯设 512给足空间。如果你想让摘要更长或更短再按需调整。3.4 连接结束节点把结果送出去接下来拖一个“结束”节点到画布放到 LLM 节点右侧从 LLM 节点右侧圆点拉一条线到结束节点左侧接口。结束节点的作用是把工作流的最终结果返回给调用方。点开结束节点配置面板添加一个输出变量变量类型选择文本然后在值那一栏点变量插入按钮选中 LLM 节点的文本输出字段也就是上一步产生的那段摘要。这样整个链路就闭环了开始 → LLM → 结束。如果画布上方出现黄色警告条说明还有节点没连好或者某个节点缺少必要配置。这时候不用慌挨个点开节点看右侧面板里还带红点的字段就是没填完整的填好黄条自然消失。3.5 运行测试看一遍真实数据流点击画布右上角的“运行”按钮弹窗里会要求填写开始节点定义的输入字段。把准备好的测试文本粘贴到 document 一栏点“开始运行”。Dify 会按顺序执行每个节点执行完可以在调试面板里看到整个工作流一共跑了几步每步耗时多少点开任何一个节点能看到它的输入、输出和详细日志如果某一步报错错误信息会直接显示不用去翻系统日志。我第一次跑的时候模型输出的摘要确实抓住了大意但把原文里一个重要的对比数据给丢了而且开头多了一句“好的以下是这段文本的摘要”。后来我做了两件事一是把温度从默认的 1.0 降到 0.2输出立刻规矩了很多二是在系统提示词里加了一条“不要输出客套话和开场白”这个问题就再也没出现。这两条经验算是我这个案例里最有价值的调参心得。3.6 发布并接入 API一分钟让工作流变成接口工作流调通之后点击页面上的“发布”Dify 会生成正式版本。之后进入应用的“访问 API”页面能看到工作流 API 的完整地址和 API 密钥。用任意支持 HTTP 的工具都能调用curl 示例大概是这样curl --location --request POST http://你的dify域名/v1/workflows/run \ --header Authorization: Bearer app-xxxxxx \ --header Content-Type: application/json \ --data-raw { inputs: { document: 这里放你的长文本 }, response_mode: blocking, user: demo-user }返回结果里会有整个工作流的执行记录和最终输出把 output 字段取出来就是摘要。需要注意API 密钥相当于这个工作流的钥匙不要把它提交到 Git 仓库也不要直接写进前端页面。团队人多的情况下建议在 Dify 后台按成员和空间权限把应用分开管理生产环境密钥单独维护。4. 从“能跑”到“好用”三个必做的进阶优化4.1 输入文本超长怎么办入门案例只适合千字以内的文本。把一段上万字的内容直接塞进开始节点模型会直接投诉上下文窗口不够或者静默丢失中间段落。很多搜“Dify 工作流上下文超长”的人基本都卡在这一关。最简单的应急办法是入口截断在外部把文本截断成前 4000 个字符再传进来。但这是钝刀子能撑一阵不解决根本问题。真正规范的解法是分段摘要也叫 MapReduce 式摘要。思路是先按固定字符数把长文本切成多个片段用迭代节点循环调用 LLM 分别生成小摘要最后再让 LLM 把所有小摘要汇总成一篇总摘要。Dify 的迭代节点就是为这种场景准备的。这个内容展开讲能单独写一篇今天先记住思路单一 LLM 节点的容量是有限的遇到超长文本就去拆分成多段再聚合成最终结果。4.2 输出格式统一别靠运气靠规则约束摘要器如果只给自己看格式乱一点无所谓。一旦要接业务系统你最好让输出稳定在某种格式上。在系统提示词里定义一套固定模板比如输出格式 【摘要】 正文段落 【核心数据】 逐条列出原文中的关键数字和结论这样下游拿到结果后按分隔符解析就行比让模型输出 JSON 更省心也不容易出现 JSON 转义错误。这个思路在所有 AI 工作流里都通用给模型划好“答案的格子”它才会听话地在格子里答题。4.3 从“单段文本”升级到“知识库流水线”很多人的摘要需求其实不是对一段临时粘贴的文本而是对知识库里某一批文档做批量总结。Dify 里常见的做法是在开始节点和 LLM 节点之间插入一个“知识检索”节点把问题或文档 ID 传进去节点会从知识库中召回相关片段再拼到 LLM 上下文里。这时候你会遇到一个典型现象知识库文档入库是异步的导入量大的时候文档状态会一直显示“排队中”。大多数原因是 Embedding 模型的并发额度被打满或者文档太大。检查模型供应商里的 Embedding 配置或者把文档拆小一点队列自然就消了。5. 新手最容易踩的坑问题速查表5.1 一张表解决 90% 的启动问题我把新手做摘要器最常遇到的几个问题整理成一张速查表遇到问题先看表能省不少时间现象大概率原因排查/解决办法配置模型 API 密钥时报凭据验证错误API Key 填错、供应商 URL 填错、账户余额不足检查密钥是否漏字符到模型官网控制台确认余额重新测试连接摘要跑偏加入原文没有的信息温度设太高模型在“自由发挥”把 Temperature 降到 0.1~0.3摘要被截断结尾不完整最大 Token 设太小Max Tokens 调到 512 或更高画布顶部一直黄色警告无法运行有节点未连线或变量引用缺失逐个点开节点把红色提示项补齐输出格式混杂有时列表有时段落提示词约束不够明确写“只输出摘要正文不要使用列表符号”文本一长模型直接拒答超过上下文窗口截断输入或换成更大上下文的模型发布后调用 API 返回缺少字段inputs 里的字段名和开始节点变量名不一致检查 POST 参数里的 key 是否和开始节点变量名完全一致知识库导入文档长期排队Embedding 模型并发或文档过大检查 Embedding 队列和文档拆分这张表我建议截图保存。很多问题都不是模型“笨”而是配置细节没对齐。5.2 提示词里的三个真实教训第一别只说“帮我总结”。指令越模糊模型越自由结果就是每跑一次一个风格。你要告诉它角色、字数、保留什么、舍弃什么、用什么格式输出五条要求缺一不可。第二别高估模型的“字数感”。你写“300 字”它可能给你 200也可能给 400。写“约 300 字”然后设好最大 Token比精确数字更有效。第三规则放在文本前面。用户提示词里如果先贴大段文本再说要求模型对“要求”的关注度会明显下降所以把约束条件写在前面文本放最后实测效果更稳定。5.3 版本升级和迁移前的保命操作Dify 是个迭代非常快的项目社区版版本号之间改动不小和“Dify 迁移”“Dify 在线升级”相关的搜索量一直很高。我的建议是升级前一定备份两样东西docker-compose 配置文件和数据卷。升级完成后把生产环境里的工作流重新跑一遍回归测试别直接切流量。至于 Windows 用户用 Docker Desktop 部署的升级时多留意镜像拉取失败的问题多半是镜像源或本机磁盘空间不足清理一下旧镜像再试。这些操作看起来琐碎但能避免很多“升级后工作流悄悄变样”的尴尬时刻。另外经常看到有人想把 Dify 工作流“翻译”成 Java 代码。我的建议是先想清楚你的诉求是什么。如果是为了和现有系统集成Dify 本来就提供了工作流 API系统之间调 HTTP 接口即可如果是为了彻底脱离 Dify 做二次开发那你其实是在重写一个工作流引擎和画布里的这些节点已经完全没关系了。对于绝大多数业务场景直接开放 API 是投入产出比最高的做法。6. 一点实际操作体会文本摘要器虽然简单却是我每次给别人演示 Dify 工作流时最喜欢用的例子因为它把“工作流”这个概念里最核心的几件事——变量如何流动、节点如何协作、提示词如何控制输出、调试如何定位问题——全串起来了。我个人习惯是给这个摘要器留一份“回归文本”。我会维护一个固定的测试文本和对应的预期要点每次改提示词、换模型或者升级 Dify 之后都拿同一份文本跑一遍对比输出有没有变差。这个小习惯帮我免受了好几次“升级后效果微妙下降但说不清哪里变了”的折磨。如果你刚开始接触 Dify建议就按这个节奏走先做能跑的简单工作流再尝试加条件分支然后学习知识检索和迭代节点。把所有节点都玩过一遍之后再去捣鼓 Agent 和 Chatflow会发现那些复杂功能其实都是这些基础节点搭出来的积木。这篇入门系列写到这里希望你能把第一块积木搭稳。