如果你已经跟完了这个系列的前六篇Dify 在你手里应该已经不是一个陌生词了装好了 Docker 版建过一两个会聊天的助手也大概摸过知识库的入口。但说实话真正让 Dify 和普通聊天框拉开身位的东西是AI工作流这个功能——一个能在画布上通过拖拽连线、把大模型能力编排成固定流程的可视化编辑器。这篇我们直接从零到一搭一个文本摘要器把一段长文章丢进去几秒钟吐出干净的中文摘要。全程不写一行代码从新建应用、拖节点、连线、调参、发布到把工作流接给外部系统一次性讲清楚。适合刚入门的同学照着重做也适合已经玩过对话应用、想了解工作流模式的开发者换个思路。1. 动手前先搭好环境两种部署形态怎么选1.1 云端版还是本地版取决于你要拿它干什么开始搭工作流之前先回答一个绕不开的问题你在哪跑 Dify如果你只是想快速验证拖拽连线到底好不好用或者准备给团队做内部工具、做个给客户演示的 Demo我建议直接用 Dify 官方提供的云服务。不需要关心服务器、Docker、域名证书这些东西注册完就有完整的编辑器模型供应商也帮你预设好了打开就能拖节点。这篇文章里的所有步骤云端版和社区版的操作路径几乎一样。但如果你是公司内部要做数据敏感的信息处理或者想完全控制模型请求的链路那自部署更合适。社区版部署不算复杂官方文档给的 Docker Compose 方式属于比较省心的路径几台有 Docker 的机器就能跑起来。大概长这样git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d看似简单但自部署的坑通常不在 Dify 本身而在于前置条件。内存建议给到 8G 以上否则多个服务同时跑起来容易把宿主机拖垮。另外很多人部署完在浏览器访问时报证书相关错误页面打不开。这时候先去检查入口层配置的证书链是否完整再看服务器系统时间是否准确——证书校验失败有一半以上是这两种原因而不是 Dify 本身的问题。第一次上手的话云端版会少踩很多这种环境坑。1.2 认识工作流编排页节点、连线和变量登录进 Dify 之后你会看到工作室或者应用列表这样的入口。工作流的编排页和搭建积木类似左侧是一堆可以拖进画布的节点中间是空白的编排区域右侧是当前选中节点的配置面板。节点可以理解为处理单元。一个节点接收上游数据做一件具体的事然后把结果交给下游。开始节点负责定义整个流程的输入参数LLM 节点负责调用大模型做推理结束节点负责把最终结果输出给用户。中间那一根根连线决定的是数据的流向而不是代码里的函数调用顺序。你在画布上把 A 节点拉到 B 节点旁边连上线A 的输出就会变成 B 的输入。这里最需要建立的心智模型是变量这回事。节点和节点之间传数据不是复制粘贴而是通过变量引用。比如你在开始节点里定义了一个叫text的输入字段在 LLM 节点的提示词里就能用类似{{#start#.text}}这种写法把它引进来。实际动手时不需要背这个语法Dify 的输入框旁边有变量选择器鼠标点选上游节点里的字段就行。但明白了这套引用逻辑你后面读别人导出的工作流模板DSL 文件时就能一眼看懂这流程到底是怎么串起来的。顺带说一下工作流支持导出和导入。设计好的流程会变成一个 DSL 文件发给同事就能在他那边复现。但很多人导入时遇到过版本不兼容的提示这个我放到最后专门讲。2. 核心三步用开始、LLM、结束节点拼出文本摘要器2.1 创建空白工作流第 1 步进入工作台点击创建空白应用。这时候系统会让你选应用类型这里选工作流而不是聊天助手。聊天助手类应用和工作流应用的区别本质上是一个偏向自由对话、一个偏向固定流程。聊天助手适合开放式问答用户问什么模型就答什么工作流则适合输入什么、做什么处理、输出什么都是可预期的这种场景。文本摘要器天然适合工作流输入是文章中间是模型摘要处理输出是摘要文本整个过程是可以被明确定义的。新建的应用可以起个简单的名字比如文本摘要器。创建完会自动进入工作流编排页页面上已经帮你放好了一个开始节点和一个结束节点中间是空白的画布等着你自己把处理逻辑补上。2.2 配置开始节点确定输入格式点击画布上的开始节点右侧会出现字段配置。在默认情况下Dify 会给开始节点预置一个查询字段sys.query和文件上传字段。但我们要做的是文本摘要器直接让用户填一大段文章所以我习惯在开始节点里新增一个输入字段名字叫text类型选段落或者长文本。之所以新增一个字段而不是直接用默认的查询字段是为了语义更清晰。sys.query这个名字在后续的流程日志、API 调试里看到时总会让人犹豫这到底传的是什么内容。你自己定义一个text字段整个流程的可读性会好很多。字段类型要注意如果打算处理长文章一定选段落或长文本类型不要选文本因为单行文本类型在部分版本里会对长度有限制粘贴一大段文章时容易出问题。配置完开始节点整个工作流的入口就定了。用户之后在 WebApp 里看到的表单、通过 API 提交过来的参数都会以这个字段为基准。2.3 配置 LLM 节点把文章交给模型从左侧节点面板里拖一个LLM节点到画布上位置放在开始节点右边然后把开始节点到 LLM 节点的线连上。点开 LLM 节点配置文件第一步是选择模型。前提是你已经在设置—模型供应商里接好了至少一个可用模型。我刚上手时用的是gpt-4o-mini这类性价比型模型摘要这种任务不需要顶配模型也能有很好的表现。接下来是提示词这是决定摘要质量的关键。我的做法是把指令放在系统提示词区域把文章内容放在用户消息区域通过变量引用把开始节点的text传进来。一段非常简洁但是够用的提示词长这样系统提示词你是一个专业的文本摘要助手。请用中文输出不超过 300 字的摘要保留原文的关键结论、核心数字和专有名词。不要添加原文没有的观点不要输出评价性语言直接输出摘要正文。用户消息请对下面的文章生成摘要 {{#start#.text}}注意那个{{#start#.text}}在编辑器里你可以直接输入也可以点输入框旁边的变量选择器从开始节点里选text字段。如果用户消息里只有一段文字没有指令模型可能不知道要干嘛如果指令和文章混在一起没做分隔模型又可能把指令本身当成文章内容。用系统提示词区分角色、用户消息里放任务和文章是最不容易出错的组合。2.4 接上结束节点把结果吐出去LLM 节点配置完成后把它和结束节点连上线。点开结束节点它的配置里有一个或多个输出字段。默认情况下结束节点会有一个输出你把它的引用指向 LLM 节点的输出字段就行。在变量选择器里选择 LLM 节点然后选它的文本输出结束节点就会把模型生成的摘要作为整个工作流的最终返回结果。到这里一个最小可用的文本摘要器已经跑通了。整个过程确实用不了 5 分钟拖一个 LLM 节点、写一段提示词、连两根线、指一下输出字段全部结束。这时候你可以点右上角的运行按钮在弹出的测试面板里粘贴一段长文运行之后就能在结束节点里看到摘要结果。3. 决定摘要质量的细节提示词模板与模型参数3.1 结构化提示词让模型知道边界很多刚开始用工作流的人会有一个误区提示词随便写写反正大模型能理解。实际跑几次你就会发现摘要质量不稳定的根源往往不是选错了模型而是提示词里没有把边界说清楚。我过一个反例如果系统提示词只有一句请帮我总结这段文章模型输出可能附带以下是这篇文章的摘要本文主要讲述了……这类废话甚至会把原文里的观点重复一遍再补一句我认为。但你把输出要求写清楚之后模型的行为会立刻收敛。我实际在用的摘要提示词模板核心是三块角色定义、处理要求、输出限制。角色定义让模型知道自己以什么身份处理任务处理要求规定它关注哪些信息比如保留关键结论、核心数字和专有名词输出限制则告诉它不该做什么比如不要输出评价性语言直接输出摘要正文。千万别小看这最后一条很多人写提示词从不写不做什么模型就会自由发挥。3.2 模型选择摘要这种活儿不需要太贵的模型文本摘要属于典型的中等难度、高频率任务不需要大模型展示太复杂的推理能力但对输出的准确性和格式稳定有要求。所以在模型选型上我会推荐一些响应快、成本可控的型号。模型优势注意点gpt-4o-mini生成稳定、速度快适合摘要任务长文本窗口一般文章太长时需要分段处理deepseek-chat成本低中文理解能力强个别情况下输出偏长需要限制最大 Token通义千问 qwen-plus中文表达自然格式控制比较听话需要在模型供应商里单独配置调用端点实际操作中你不需要把所有模型都配一遍。选一个综合表现不错的先用起来之后对质量不满意再切换对比。我个人的偏好是先配 2-3 个不同供应商的模型这样在 LLM 节点里切换对比时不需要改任何代码直接下拉框换一下就行非常方便。3.3 温度与最大 Token摘要任务的稳定开关LLM 节点的参数区域里有两个值值得花时间理解温度和最大 Token。温度控制的是模型的随机性。摘要这个任务讲究忠实于原文不需要太多创意发挥所以我一般把温度调到 0 到 0.3 之间。温度太高的话模型可能每次跑出来的摘要重点都不一样甚至自己脑补一些原文没有的内容。温度调到接近 0同一篇文章多次运行得到的结果会稳定很多。最大 Token 控制的是输出长度上限。如果你要求摘要不超过 300 字理论上 300 字换算成 Token 大约在 400 到 500 之间但考虑到模型可能用更长的表达方式我建议把最大 Token 设置在 800 以上。设得太死容易在摘要写到一半时被截断结尾会非常突兀。宁可多留一点余量也不要让结果变成半截文章。3.4 长文本怎么办第一步先把边界定清楚模型都有上下文窗口限制比如某些模型的窗口是 128K Token听起来很大但如果是几万字的文章直接丢进去仍然可能装不下或者装下了但响应速度明显变慢。文本摘要器第一步适合处理什么量级的文本以我自己的经验几千字到一万字左右的文章直接传给模型是没问题的。如果你后面需要处理更长的内容方向不是把整个文档塞给一个 LLM 节点而是先做切分分段生成摘要再把多个摘要合并成最终结果。Dify 里可以配合文本处理节点或者知识库检索来实现这个效果。这些作为进阶方向你了解到分段摘要这个词就行后面可以再展开聊。4. 跑通之后的发布测试调试、生成 WebApp、接入 API4.1 先点运行认真观察每个节点的输入输出一个常见误区是工作流只要看起来连对了就算完成结果一运行就报错。其实 Dify 的调试体验做得挺直观问题的关键是你得养成运行后看节点状态的习惯。点右上角的运行按钮会弹出一个表单表单里的字段就是你在开始节点里定义的输入。填上测试文本点执行整个工作流会从前到后依次跑一遍。每个执行过的节点上会显示输入和输出的预览你可以逐个点开查看开始节点的输出对不对LLM 节点的输入是不是正确引用了文章内容结束节点的输出是不是想要的摘要格式。如果某个节点报错画布上该节点会变成红色点进去能看到具体的错误提示。最常见的有三类一是变量引用不对系统提示找不到某个字段二是模型供应商的网络不通或者 Key 校验失败三是文章超出模型窗口导致请求失败。看到错误先不要慌顺着节点顺序一个点一个点排查大多数问题一眼就能定位。我自己的排查习惯是先看开始节点确认输入值确实传进来了再看 LLM 节点确认提示词里引用的变量没有拼写问题最后看结束节点确认输出字段引用正确。变量引用这关我强烈建议在输入框里用变量选择器点选不要手动敲双大括号手敲很容易漏一个字段名。4.2 保存并发布让工作流真正变成别人能用的东西调试通过之后别忘了点发布。这是工作流区别于对话应用的一个重要节点。发布之后Dify 会为这个工作流生成一个可访问的 WebApp 地址。打开的界面类似一个简单的表单工具用户在里面粘贴长文点击提交就能拿到摘要结果。这对于给团队内部做一个实用小工具来说已经非常够用了。你不用管前后端部署、数据库、接口鉴权Dify 全部帮你搞定了。更重要的是工作流的发布和传统软件部署不一样。你改了工作流之后再次点发布就会立即生效不需要停服、不需要重新构建镜像。实际工作中我经常是白天用 WebApp 跑着晚上改一下提示词再发布用户的访问链路完全无感知。这种改完即生效的体验是用代码自己搭一个摘要服务很难比的。4.3 API 接入把工作流变成后端接口WebApp 适合给人用但如果你的项目是要把摘要能力集成到自己的产品里那就需要走 API。Dify 的每个应用都有自己的 API 访问入口。在应用详情页的API 访问标签页里你可以创建 API 密钥。工作流应用的调用接口是/v1/workflows/run请求体大致长这样curl -X POST https://your-host/v1/workflows/run \ -H Authorization: Bearer app-xxxxxxxx \ -H Content-Type: application/json \ -d { inputs: { text: 这里放你希望摘要的文章内容 }, response_mode: blocking, user: test-user }注意inputs里的字段名要和开始节点里定义的保持一致。你定义的是text这里就传text。response_mode可以选blocking等待全部结果生成后返回也可以选streaming让摘要结果像打字机一样流式输出。前者实现简单后者用户体验更好按你的产品场景取舍。4.4 密钥管理的几个提醒API 密钥的问题值得多说一句因为我在项目里见过不少直接在前端代码里写死密钥的例子。Dify 生成的app-开头的密钥本质上是后端的访问凭证只应该存放在你自己的服务端。如果你的产品前端要直接调用摘要接口正确的做法是你自己写个后端转发层把密钥留在服务端前端只和你自己的后端通信。另外密钥也不是永久不变的。如果发现密钥疑似泄露或者团队成员离职第一时间去 API 访问页面吊销旧的、重建新的。Dify 的密钥粒度是应用级的一个应用一个密钥做权限隔离很方便。5. 再加点东西变量聚合、人工审核与高频报错排查5.1 给摘要器加个聚合输出摘要加关键词加字数如果你觉得单纯的摘要不够用还可以让工作流一次输出更多内容。这里就轮到变量聚合器上场了。变量聚合器的用法很直白接收多个变量把它们组合成一个结构化对象再交给下游节点。比如你想让摘要器的输出变成摘要 关键词 原文字数三段式结果可以这样做在 LLM 节点旁边再拖一个 LLM 节点提示词让它只输出 5 个关键词。拖一个代码执行节点用 Python 统计原文字数一个len(text)就能搞定。拖一个变量聚合器把摘要文本、关键词列表、字数统计这三路结果聚合起来。结束节点的输出不再直接引用最初的 LLM 节点而是引用变量聚合器的输出。这样在 WebApp 或者 API 返回结果里就能一次性拿到结构化数据而不是只有一段干巴巴的摘要。这个思路还可以继续扩展摘要、翻译、情感分析都可以并行跑成多个 LLM 节点最后统一聚合输出。5.2 加人工审核节点让用户在流程里填内容很多人搜索Dify 人工介入后怎么让用户填内容其实就是想在工作流执行到某一步时停下来等用户补充信息。这个需求在 Dify 里有现成的节点支持不需要写代码。在 LLM 节点之后、结束节点之前你可以插入一个人工审核类的节点。当流程执行到这个节点时WebApp 端会停住向用户展示一个表单或者确认界面用户填写完成后流程才继续往下走。这个能力在实际业务中非常实用。比如公司内部的合同摘要流程模型生成摘要初稿之后需要法务确认一下再流转。人工审核节点就是那个法务确认的闸门用户可以在界面上直接修改摘要内容把修改后的内容作为最终输出。如果你熟悉代码实现这个功能本质上是一个异步暂停、等待外部输入后再恢复的机制但 Dify 把它封装成了拖拽节点极大地降低了集成成本。5.3 汇总几个高频报错从 SSL 到插件配置最后把我在使用过程中遇到最多的几个报错集中总结一下方便你遇到类似问题时快速定位。报错类型常见表现排查方向SSL 相关错误页面打不开证书不受信任检查入口服务证书链是否完整服务器时间是否准确Credentials Validation 错误配置模型供应商时提示校验失败检查 API Key 是否复制完整模型供应商页面能否正常连通Unstructured API 报错上传 PDF、Word 文件处理时报文件解析错误需要安装或配置对应的文档解析插件或者先手动转成纯文本再传入DSL 导入版本不兼容导入工作流模板时提示版本过低或过高不要硬改版本号优先升级系统版本或在旧环境中重建流程登录尝试次数过多提示太多错误密码请稍后再试等待冷却时间本地环境可检查登录缓存配置DSL 版本不兼容是很多刚接触 Dify 的人容易卡住的地方。你导出的工作流文件里自带一个 schema 版本号如果这个版本号高于你当前系统的支持版本系统就会拒绝导入。有些教程会让你用文本编辑器把版本号改低这个操作对小版本差异可能有效但如果新旧版本之间的节点类型差异很大硬改版本号只会导致导入成功后部分节点无法解析。最稳妥的方式始终是把你自己的系统升级到和模板相同的版本或者在旧系统里照着模板结构重新搭一遍。Unstructured API 的报错主要涉及到文件类型的文档处理。Dify 本身不会直接解析 PDF 和 Word 里的内容它需要调用额外的文档解析服务来提取文本。如果你把文件直接传进工作流而没配置对应的文档解析插件就会看到这个错误。解决方案是在插件市场安装对应的文档处理插件或者更简单粗暴一点先把文件转成纯文本再传给工作流。5.4 一个排查顺序的建议工作流报错时最忌讳的是对着红色节点一顿瞎改。我自己踩过几次坑后总结出一个固定的排查顺序先确认输入再审提示词最后查模型。输入不对后面全白搭提示词写错模型再好也白搭模型本身配置有问题就回到模型供应商页面去做连通性测试。按这个顺序走90% 的报错能在两轮之内解决。最后分享一个我自己用下来的小习惯工作流越是复杂越要保留一份最新的 DSL 导出文件。每次给工作流做较大改动前先导出一份当前版本存起来。这一步的成本几乎为零但能让你在大改之后后悔时一键回到可用状态。另外LLM 节点里的模型最好指定具体的版本号不要用最新版这种自动追踪的选项否则同一条流程可能因为上游模型调整而悄悄改变行为。这不是技术难点但很多从零搭工作流的人最容易漏掉的就是可回滚这三个字。