做了这么多年后端最烦的一件事就是明明一个简单的功能非得写一堆胶水代码才能把流程跑通。直到我试着用 Dify 的 AI 工作流搭了一个文本摘要器才意识到很多重复性工作确实可以交给“拖拽连线”来解决——不需要改业务代码不涉及复杂的中间件只要把节点拽到画布上连好线配好 Prompt5 分钟就能跑出一个像模像样的摘要应用。这篇文章就记录一下我从零到一搭建的过程适合还没上手过 AI 工作流、想快速做内部工具或 MVP 验证的同学参考。先说清楚这东西能干什么。Dify 本质上是个开源的大型语言模型应用开发平台里面最核心的一块是工作流Workflow编排。你不需要写代码只需要把大模型、输入输出、条件判断、数据处理这些模块当成积木拖到画布上按顺序连起来就能得到一个完整的 AI 应用。文本摘要器只是其中一个最简单的场景但麻雀虽小五脏俱全跑通这一遍后面再去搭客服助手、文章分类器、报告生成器逻辑都是一样的。1. 为什么用“拖拽连线”而不是写代码Dify 工作流的思路拆解1.1 工作流到底解决了我什么问题传统写代码实现文本摘要至少要经历这几步先选一个后端框架然后封装大模型 API 调用再设计输入报文和返回报文最后处理超时、重试、Token 超限这些边界问题。如果摘要需求变了比如从摘要 200 字改成提取 5 个关键词你还要改代码、改接口、重新部署。整个过程里真正花在“摘要算法”上的时间可能只有 20%剩下 80% 都在做工程杂活。Dify 工作流把这一堆杂活变成了可视化的节点连接。开始节点负责接收外部输入LLM 节点负责调用模型生成摘要结束节点负责把结果返回给调用方。所有节点之间通过连线传递数据顺序就是从上到下。改动需求时不需要改代码直接在工作流里调 Prompt 模板、加节点、改连接关系点一下运行就能看到新效果。对于团队来说这种模式的另一个好处是协作门槛降了。业务同学虽然不会写 Python但能看懂流程图能理解“文章文本进 LLM 节点出来是摘要”。这比让业务同学读懂 lambda 表达式容易得多。所以我在做内部工具时首选就是用工作流把逻辑显式化让所有人都能参与迭代。1.2 拖拽连线背后的核心概念节点、连线、变量Dify 工作流里没有“函数”和“返回值”这种说法取而代之的是“节点”和“变量”。一个节点就是一个小功能块比如 LLM 节点是调用大模型条件分支节点是 if/else代码节点是跑 Python 脚本。连线决定了数据流动方向而变量则是节点输入输出的“接口名”。用一个生活类比来理解工作流就像一条快递分拣线。包裹从传送带入口进来第一站是“称重节点”要读取包裹的尺寸第二站是“分拣节点”根据尺寸判断走大件通道还是小件通道第三站是“装车节点”把包裹送到对应车上。Dify 里的开始节点就是传送带入口LLM 节点就是分拣员结束节点就是最后交货的出口。每个节点要处理哪个字段就等于你在包裹单上填了什么标签。变量这个概念特别重要。你在开始节点里定义了一个变量叫text后面 LLM 节点的 Prompt 里引用{{#start.text#}}运行时就能把用户输入的那个文本替换进去。很多新手一上来就卡在变量引用上其实逻辑很简单先看这个变量是在哪个节点定义的再看引用路径是否和节点 ID 对应最后确认字段名没拼错。把这三点记住工作流里 90% 的引报错都能解决。1.3 为什么文本摘要器最适合当入门案例文本摘要器的处理链路短只有“输入文本 - 调用模型生成摘要 - 输出结果”三段没有复杂的循环和分支非常适合拿来建立工作流的基本认知。但它又不是简单到无聊因为摘要质量的好坏完全取决于 Prompt 设计和模型参数调整这里面的经验可以直接迁移到更复杂的工作流上。另外文本摘要是高频刚需。无论是处理客服对话记录、整理会议纪要还是给长文档生成简介都能直接用到。我搭好之后立刻让团队里几个同事试用反应都很积极。与其做一个不知道用在哪的 Demo不如做一个明天上班就能用的工具这种正反馈对学习新东西很关键。2. 搭建文本摘要器之前先搞懂这几个核心节点2.1 开始节点的输入设计字段越少越好别过度设计开始节点是整个工作流的入口相当于函数的参数定义。我建摘要器时只加了一个输入字段text类型选“段落文本”。为什么不拆成“标题”和“正文”两个字段因为实际使用时用户往往是直接把一篇文章粘进来让他们分开填反而增加成本。工作流的输入设计原则应该是字段少语义明确先满足核心场景不够再扩展。字段类型也要注意。Dify 里常见的类型有文本、段落文本、下拉选择、文件等。摘要器最常用的是“段落文本”说明它能容纳换行和较长的内容。如果你选了“文本”类型有些版本会限制长度这就会导致长文章传进去被截断。实际操作中我建议你打开“多行”还是“段落”看具体版本类型选宽松的那个后面少踩很多坑。2.2 LLM 节点模型选择和参数设置会影响摘要质量LLM 节点是工作流的大脑需要配置三样东西模型、Prompt、参数。模型方面一般推荐选你想要测试的那个大模型供应商稳定起见可以直接用主流对话模型。Prompt 是摘要器的灵魂我在后面单独说。参数里最常调整的是“温度”温度越低输出越确定摘要任务建议设置在 0.1 到 0.3 之间避免模型自由发挥编内容。很多人忽略的一点是“系统 Prompt”和“用户 Prompt”是两个不同的东西。系统 Prompt 定义角色和约束条件比如“你是专业的文本摘要助手必须输出简洁准确的中文摘要”用户 Prompt 是具体任务指令和输入内容比如“请根据下面这篇文章生成 200 字以内的摘要{{#start.text#}}”。把两者拆开效果比全塞在用户 Prompt 里好得多因为模型能更清楚地区分“你是谁”和“你要做什么”。2.3 结束节点并不简单它是输出格式最后一道关结束节点决定工作流的返回值是什么也是调用方最终拿到的数据结构。在文本摘要器里你只需要把 LLM 节点的输出变量映射到结束节点的输出字段即可。但如果你想返回多个信息比如摘要和关键词就要在结束节点里定义多个输出字段。这里有个很实用的技巧结束节点的输出字段名一定要起得对调用方友好比如用summary、keywords而不是result1、result2。因为后面通过 API 对接其他系统时字段名直接体现在返回报文里起得规范能让对接同事少问几句。另外有些版本支持给输出字段设置别名理想情况下别名也翻译成业务语言比如“文章摘要”“核心关键词”方便非技术同事用前端页面查看。3. 5 分钟实操从零到一搭出文本摘要器全流程3.1 第一步创建工作流应用并认识画布布局登录 Dify 控制台后跟着默认引导走创建一个新应用。应用类型里选择“工作流”而不是“聊天助手”因为我们要做的是一个单次处理的任务不是多轮对话。创建完之后会进入工作流画布你会看到左边是节点列表中间是画布右侧是配置面板。第一次进画布别慌Dify 会自带一个简易模板通常包括开始节点、LLM 节点和结束节点。你要做的是把模板清空从零开始搭这样能理解每个节点的作用。清空之后画布上还会有一个“开始”节点这是固定的入口删不掉的。你只需要从 LLM 节点列表里把一个“LLM”节点拖到画布上再从节点列表里找到“结束”节点拖到后面即可。3.2 第二步配置开始节点的输入变量单击画布上的“开始”节点右边会弹出配置面板。找到“输入字段”区域点击添加字段。字段名我建议直接写成text字段类型选“段落文本”注意看看是否有“必填”开关把它打开。因为如果用户在调用 API 时没传 text后面 LLM 节点引用变量就会变成空字符串模型可能生成一段莫名其妙的空泛内容。还可以在“节点标题”里给它起个中文名比如“接收原始文本”。中文名只是辅助识别不会影响变量名。这一点对团队协作很重要因为过两周你自己再看工作流看到一个节点叫“节点 1”完全想不起来它干嘛的叫“接收原始文本”一目了然。我习惯给每个节点都改个有业务含义的名字这算是低成本高回报的习惯。3.3 第三步配置 LLM 节点的模型与 Prompt点击画布上的 LLM 节点配置面板一般分模型、Prompt 节点输入、参数设置这几块。模型选择你的供应商和具体模型比如常用对话模型。如果之前没添加过供应商需要先在控制台的“模型供应商”页面里填好 API Key。第一次跑工作流前务必先在模型供应商页面测试一下连通性否则后面所有报错都会让你一头雾水。Prompt 配置里我给出一个可以直接抄的模板系统 Prompt 你是专业的文本摘要助手。请阅读用户提供的文章提炼出核心内容和主要观点输出简洁、准确、结构清晰的中文摘要。不要在摘要中添加原文没有的信息不要分点列表保持自然段落叙述。 用户 Prompt 请帮我将下面的文章生成一段约 200 字的中文摘要 {{#start.text#}}注意变量引用格式{{#start.text#}}表示“开始节点 text 字段”。如果你的开始节点节点 ID 不叫start引用的时候以节点上的实际 ID 为准。保存后在画布上看到 LLM 节点下方出现“已引用 start.text”之类提示就说明绑定没问题。如果不确定可以先运行一次看看调试日志里的引用是否正确。3.4 第四步连接结束节点并设置输出参数把 LLM 节点的输出连到结束节点。点开结束节点添加一个输出变量名称建议叫summary数据类型通常选“字符串”值引用 LLM 节点的输出文本。在 Dify 里LLM 节点的文本输出变量一般叫text所以在结束节点里要填{{#llm.text#}}这种格式。同样节点 ID 要对上。这里我要提醒一个很多人会忽略的问题结束节点可以有多个输出但这不是必须的。如果你只做摘要输出就只配一个summary字段。配多了每次调用返回的数据副本通知都要重新解析反而给下游增加复杂度。后续当你需要同时返回“摘要”和“生成耗时”时再在结束节点加字段也不晚。3.5 第五步调试运行并排查变量问题在工作流画布的右上角一般会有一个“运行”按钮点开后会出现测试输入框。把你准备好的示例文章粘到text字段里点击运行等待几秒钟下方会显示工作流的运行日志和最终输出。第一次跑通时特别有成就感但如果你是第一次用在这里遇到变量未引用或模型调用报错的概率也不低。调试日志里你会看到每个节点的输入输出详情。比如 LLM 节点报错日志会显示是模型供应商返回错误还是 Prompt 里的变量被解析成了空值。遇到这类问题先看日志里的变量快照再检查 Prompt 模板中的引用路径。跑通之后随手保存版本然后点击“发布”。发布后工作流会变成一个可以调用 API 的服务或者可以嵌入到前端页面里。3.6 发布后的使用方式API 调用与页面嵌入发布不是终点而是真正开始用的起点。Dify 工作流发布后会生成一个访问地址可以通过 API 调用方便你集成到已有系统。如果你不熟悉 API也可以直接使用工作流页面自带的预览界面或者嵌入到团队内部的知识库里。我个人更推荐先把 API 对接文档打印出来理清 POST 地址和请求体结构。请求体里一般要带上工作流 ID 和你定义的开始节点字段比如{inputs: {text: 这是一段很长的文章...}}。拿到响应后找到data.outputs.summary字段就是摘要结果。这个过程 5 分钟能搞定但很多人卡在这一步是因为没分清“无罪”的发送参数和返回结构所以建议你发布后用测试工具 mock 一次调用熟悉报文格式再交给业务方。4. 我踩过的坑工作流运行报错与效果不佳的排查实录4.1 模型调用失败九成是 API Key 或服务商没配好AI 工作流跑不通最常见的问题是模型节点报错“调用失败”。我一开始就犯过这个错在 LLM 节点里选了一个模型但其实控制台根本没添加该模型供应商的 API Key或者 Key 已经过期。排查顺序是先去模型供应商页面看状态是不是正常再测试一次连通性最后检查模型节点里选的模型名是否真实存在。另一个隐蔽问题是模型名选错。有些供应商的模型标识带有日期或版本后缀复制过来时容易多带空格或换行。Dify 的模型配置文件如果识别不出来会直接报“model not found”。解决方法就是在模型供应商页面下拉列表里重新选择不要在文本输入框里手动粘贴。这种问题通常花费 1 分钟解决但如果不知道原因能折腾一小时。4.2 摘要输出全是废话Prompt 指令不够具体模型能跑通输出的摘要却像在“复读”原文甚至出现“本文主要介绍了……接下来……最后……”这种模板味极重的文字。问题基本出在 Prompt 上。你需要给模型设置更明确的约束比如必须输出多少字以内、不能出现“本文”开头、不要使用列表符号、只提取关键结论信息。我自己常用的优化技巧是在系统 Prompt 里增加“输出风格参考”和“负面约束”。比如“摘要要用通俗易懂的口语化表达避免书面辞藻堆积”“不要包含具体数字细节除非该数字是核心结论”。每加一次约束运行一次测试对比输出差异很快就能找到最合适的 Prompt。另外温度参数从默认 0.7 调到 0.2也能明显减少模型天马行空的情况。4.3 长文本处理超时设置 Token 上限和分段策略当输入文章超过 8000 字时LLM 节点可能直接超时或者报 Token 超限。Token 超限不是说你的设置不对而是模型上下文窗口有物理上限。解决办法有两个维度一是降低输入长度二是增加输出限制。输入侧可以先用“文本处理”节点截断前 N 个字符或者在开始节点入口处就限制用户只能传 2000 字以内的文本。输出侧要注意在 LLM 节点的参数里设置最大 Token 数比如 500避免模型无限生成下去既浪费额度又拖慢响应。如果业务确实需要摘要超长文档建议在输入端使用分段摘要策略先用代码节点或文本处理节点把文章按段落切成多块每一块分别生成摘要再用一个 LLM 节点把所有小节摘要合并成最终摘要。这个改造思路放之四海而皆准凡是遇到“长文本”都可以往这个方向上想。4.4 常见问题速查表照着排就行这里我把实际操作中遇到的高频问题整理成一张表建议你收藏到笔记里下次直接用 CtrlF 搜症状。症状可能原因排查与解决办法节点一直转圈没有输出模型调用超时或因 Token 超限被中断检查输入文本长度降低模型最大 Token 数或对输入进行分段处理日志提示变量不存在Prompt 中引用了错误的节点 ID 或字段名打开节点配置面板对比开始节点/LLM 节点里的实际变量名输出是英文或夹杂英文Prompt 中没有明确要求输出中文在系统 Prompt 里直接写“只用中文输出”并给出示例摘要内容包含原文没有的观点温度过高或 Prompt 约束不足温度调到 0.2 以下增加“保持忠实原文不要推测”等约束API 调用返回 404工作流未发布或访问路径拼写错误先确认工作流已发布再对比文档里的 API 路径结束节点没有返回值输出字段未引用 LLM 节点的任何变量检查结束节点里输出变量的值是否为“文本”类型的变量引用这张表给不了万能答案因为不同版本的 Dify 界面有所差异但基本方向都一致。按症状定位到节点再按原因调整配置90% 的问题 10 分钟内能解决。4.5 调试技巧善用“运行历史”和版本对比Dify 工作流画布上有“运行历史”功能每次测试都会留下记录。很多新手只点运行看结果忽略了历史记录的作用。其实每次运行记录里都包含了各个节点的输入快照和输出结果你可以逐节点展开看数据到底是在哪一步丢失或者变形的。这个能力比在代码里打日志好用多了毕竟可视化的页面已经帮你把链路日志展示出来了。我习惯在工作流改完 Prompt 后保留一组“固定测试文本”。不管怎么调参都用同一篇文章去验证效果这样才能横向比较不同版本之间的输出差异。否则你这次用 A 文章下次用 B 文章根本分不清效果变化是 Prompt 调整带来的还是输入文本不同导致的。固定测试集是 AI 应用开发里很值得养成的习惯。5. 从文本摘要器再往前走一步工作流的扩展思路5.1 加一个“关键词抽取”分支从单节点变并行节点搭完摘要器以后你可以很自然地扩展它在 LLM 节点后面再接一个“文本处理”或“LLM 节点”专门用来抽取关键词然后在结束节点里同时返回摘要和关键词。更进一步可以用“条件分支”节点判断输入文本长度如果超过 3000 字就走分段摘要分支否则走快速直接摘要分支。这种按条件分流的设计在 Dify 里实现成本极低但效果提升很明显。我建议你在改完摘要器后先加一个并行分支一个 LLM 节点生成摘要另一个 LLM 节点抽取三个核心关键词。因为两个节点互不依赖可以同时运行总耗时不会叠加。最后在结束节点里同时输出这两个字段一个工作流就变成了“摘要关键词”双功能工具。5.2 把常用工作流封装成模板沉淀团队经验有个体会是一旦你调好一个工作流一定要及时保存成模板或复制成多个版本。Dify 支持将应用一键复制你可以把当前的“基础摘要器”复制一份命名为“会议纪要摘要器”再调整 Prompt 里的措辞让输出更适配会议场景。这样下次同事需要类似功能时直接复制你的版本改两句话就能跑不用再从头拖节点。这是我觉得 Dify 工作流最吸引人的地方它不只是一个执行工具更像一个团队的知识库。节点怎么连Prompt 怎么写输出字段怎么命名这些经验都会沉淀在应用模板里。新同学接手时不需要问老同学“摘要逻辑在哪”打开工作流一眼就能看清处理链条。我个人在实际操作中的体会是5 分钟做出文本摘要器一点都不夸张真正花时间的反而是调 Prompt 和排查看起来不起眼的节点配置。但恰恰是这些“不起眼”的细节决定了工作流能不能从 Demo 变成真正稳定可用的工具。如果你也是第一次接触这类无代码 AI 工作流我建议你动手跑一遍遇到问题就对着第 4 部分那张表排查。阻力没你想的那么大。