手里正好有一个“把一堆零散会议纪要在几分钟内变成一段干净摘要”的需求。我第一个想到的，就是直接打开 Dify，新建一个工作流应用，用“拖拽连线”把开始节点连到大模型节点，再连到结束节点，5分钟左右就拼出了一个文本摘要器。整个过程没有手写一行业务代码，调试也只需要看节点之间的输入输出。对刚入门 AI 应用开发的朋友来说，这条路比直接对着 API 写脚本要友好太多。这篇就完整记录一下：我是怎么从零搭的、每一步为什么要这么连、以及踩过哪些坑之后总结出来的调优经验。
1. 为什么是“拖拽连线”：工作流编排的设计思路
1.1 可视化工作流到底解决了什么问题
先聊一个很基础但容易被忽略的问题：既然可以直接调大模型接口，为什么还要用工作流？
我的理解是，绝大多数业务需求并不是“调一次模型”就结束的。真实场景里，文本需要先清洗、需要控制输入长度、需要把模型结果加工成特定格式，甚至还要根据结果做分支判断。这些逻辑如果全写代码，每一处都要考虑鉴权、异常重试、日志，还有后续参数调整，改一次要重新部署一次，麻烦且琐碎。
Dify 这类平台把“数据处理管线”做成了可视化画布。每一个节点就是一个处理单元，节点之间的连线就是数据流动的方向。这相当于把一整套传统代码里的“数据清洗 → 调用模型 → 格式化输出”流程，直接平铺到了桌面上。你不需要知道内部怎么跑，只需要关心“哪个环节需要什么输入、产生什么输出”就可以。这种抽象方式对非工程背景的人尤其友好，本质上是在用“组装流水线”的思路做应用。
我用一个类比来解释：写代码调模型，像是自己去菜市场买齐食材、回家自己洗切炒；用工作流画布，则像是站在一条配好的流水线旁边，只需要把物料倒进入口，看它在哪个环节做了什么事，再调整某个环节的参数。后者更快，也更好定位问题。
1.2 把“文本摘要”拆解成工作流的最小单元
搭建之前，先想清楚一个文本摘要器最简链路是长什么样的。
我拆了三块：输入获取、模型生成、结果返回。对应到工作流里，就是开始节点、LLM 节点、结束节点。如果你处理的文本不需要额外清洗，这三个节点就够了；如果要做长文本截断、去空格、统一格式，中间再插一个模板节点或文本处理节点。
把任务拆开的好处，在调试时体现得最明显。比如你运行一次之后发现结果不对，如果只有一个“黑盒”式的大模型调用，你很难判断是文本传错、Prompt 写错还是模型输出被截断。但在工作流里，你可以点击任意节点的运行记录，查看它的输入输出，一步步定位问题出在哪一环。这也是后面排查部分的核心思路。
对一个入门项目来说，不要一上来就追求复杂结构。先把最小链路跑通，看到结果能从“开始”流到“结束”，再去考虑分支、迭代这些高级节点，学习曲线会平缓很多。
2. 环境准备：模型接入与关键参数配置
2.1 模型选择：摘要任务对模型能力的三点要求
很多人忽略模型选择这个环节，其实它对摘要效果的直接影响可能比 Prompt 还大。以我的经验，摘要场景至少要关注三点：
第一是上下文长度。你要摘要的目标文本有多长，模型的上下文窗口就要能装下多长。如果文本太长，模型根本读不完整段内容，摘要自然残缺不全。所以刚开始做摘要器，建议选上下文窗口大一些的模型，宁可容量余量多一点，也别卡在“装不下”的边界上。
第二是指令跟随能力。摘要任务需要模型严格遵循“提取关键信息、不要编造、控制字数”这类指令，而不是自由发挥。能力弱的模型经常会在摘要里加入自己的联想内容，这就产生了所谓“幻觉”问题。实测下来，当前主流的大模型基本都能胜任，但如果你用的模型响应质量波动大，优先换一个指令跟随表现好的模型再重新测。
第三是中文处理能力。做中文摘要时，模型对中文语义、成语、行业词汇的理解深度会直接影响结果。优先级排序大致是：中文语料质量高的模型 > 具备长上下文能力的通用模型 > 能力普通的小模型。
在平台的“模型供应商”页面填入你已有的 API 密钥就可以了。第一次配置可能需要花两三分钟，配完之后整个工作流内部都能复用，后续做其他应用不用再重复配置。
2.2 关键参数调整：温度与最大 Token 的取舍
工作流的 LLM 节点里，有几个参数会直接影响摘要质量。我建议重点关注两个：温度和最大 Token。
温度（Temperature）控制的是内容随机性。温度越高，模型越敢“发挥”；温度越低，输出越保守、越贴近原文。摘要任务和写文案不一样，我们最怕的是模型脑补出原文不存在的内容。所以这个场景的温度我一般直接设在 0 到 0.3 之间。你可以理解为：写营销文案时温度高一点是加分项，但做文本浓缩时温度越低越可信。
最大 Token 则是限制模型输出长度的开关。它的大小要参考你输入的文本量和想要输出的摘要长度。举例来说，一段 2000 字的文章，摘要想控制在 300 字以内，那模型输出 Token 设置 500 左右就够用。如果输入文本本身很长，而你发现输出经常被截断，不要只调大最大 Token，还要检查是不是输入已经超出模型上下文限制。那这种问题不是调参能解决的，要回到文本切片策略上（后面会专门讲）。
其他参数，比如 Top P、频率惩罚等，摘要场景保持默认即可，不需要过度调节，避免给自己增加无关变量。
3. 5分钟实操：搭建文本摘要器的完整流程
3.1 新建工作流应用
登录平台之后，在应用列表页面点击“创建空白应用”。这里有两个入口要分清：一个是聊天助手，一个是工作流。我们要做的是“输入一段文本返回一段摘要”的批处理式应用，用户不需要跟它来回对话，所以选择“工作流”类型。
创建完成之后，你会看到一张几乎空白的画布，上面默认放着两个节点：“开始”和“结束”。所有内容都在这两个节点之间搭建。
我建议从第一步就养成给节点取清晰名字的习惯。默认的节点名称在节点多了以后会让人一头雾水，比如“LLM 节点 1”“LLM 节点 2”。直接改成“文本摘要_主模型”“结果格式化”这类名称，后面调试时从节点名就能快速判断它在干什么。
3.2 配置输入变量并接入 LLM 节点
点击开始节点，在“输入变量”区域添加一个字段，名字随意，我一般用text，类型选择“多行文本”或者“段落”，因为要接收整段文章内容。
然后从开始节点的右侧圆圈拖一条连线到 LLM 节点的左侧输入位置。画布上的连线本质就是变量的传递关系，这意味着后续你可以在任意位置插入新的处理节点，只要把连线重新接一下就行，不需要改动其他节点。
接下来点击 LLM 节点，在配置面板里完成三件事。
第一，选择模型。从已接入的模型列表里选择一个上下文长度足够、中文效果稳定的模型。第二，调整模型参数，把温度改为 0，最大 Token 根据预估输出长度设置。第三，填写系统 Prompt。这里给出一个我实测下来比较稳的默认模板，中文场景可以直接用：
你是一个专业的文本摘要助手。请阅读用户输入的内容，提炼出核心观点，输出简洁摘要。 要求： 1. 保留原文中出现的关键实体、数字和明确结论； 2. 摘要控制在 200 字以内； 3. 使用通顺简洁的中文表述； 4. 如果输入内容信息不足，直接回复“原文信息不足”，不要补充想象内容； 5. 不得添加原文中没有的事实。 输入内容： {{text}} 摘要：上面的{{text}}就是工作流里的变量占位符，运行时它会自动替换为开始节点传入的文本。这里有一个入门阶段常见的误区：在 Prompt 里直接写死测试内容，就会导致每次运行结果都一样。正确做法是用变量占位符引用上游节点输出。
3.3 配置结束节点并运行测试
回到结束节点，把它的“输出类型”改成“变量”，然后选择 LLM 节点的输出结果。这个动作的意思，是把 LLM 节点生成的摘要作为整个工作流的最终返回值。
配置完成之后，点击画布右上角的“运行”按钮。在弹出的测试窗口里，粘贴一段真实的测试文本，比如一篇新闻稿或会议纪要，点击运行。稍微等待几秒，右侧就会显示运行结果。
这里我要特别强调调试面板的用法。很多人只会看最终结果，而中间某个节点出了问题就会被忽略。实际上工作流的每次运行记录里，都保留了每个节点的输入和输出。你可以依次点开不同节点，查看它接收到的内容是否正确、输出的内容是否符合预期。我用下来的体会是：这种逐级可见的调试方式，比写 print 日志再定位问题要直观得多，也是工作流编排最大的隐藏福利。
3.4 踩坑记录：一次“模型看似没工作”的排查
分享一个我真实踩过的坑。第一次做一个摘要工作流时，我运行之后发现输出文本非常短，只有一句话，内容也完全不像是摘要。当时我第一反应是“模型效果太差”，差点就要换模型。
后来把运行记录逐层点开，才发现问题根本不在于模型。我的最大 Token 设置的是 50，这个数字太小了，模型还没来得及输出完整摘要就被截断了。把最大 Token 调到 500 之后，效果立刻正常。
从那之后我养成了一个习惯：任何异常先看节点中间输出，再下结论。实践证明，很多看起来像“模型有问题”的情况，只是输入、参数或连线的问题。这个排查思路比盲目换模型能节省大量时间。
4. 进阶技巧：把简单摘要器变成真正能用的工具
4.1 在 LLM 节点前插入文本处理节点
当输入文本的质量参差不齐时，摘要效果会很不稳定。最典型的情况是：从网页或 Word 文档里复制的文本，带有大量空行、多余空格，甚至杂乱的制表符。这些内容进入模型后，一方面浪费上下文窗口，另一方面也可能干扰模型对语义的判断。
解决办法是在开始节点和 LLM 节点之间插入一个“模板”或“文本处理”节点，先把原始文本做一次清洗。比如去掉连续空行、压缩多余空格、清理特殊符号等。如果你使用的平台版本带有专门的文本处理节点，可以直接用；如果没有，用模板节点配合变量替换也能达到类似效果。
这块细节说明一下：不同平台版本对文本处理函数的支持不一样。我在实操中比较常用的方式是——在清洗节点的输出变量里重新赋值，然后 LLM 节点里的 Prompt 占位符改为引用清洗后的变量。这样一来，原始文本保留在开始节点，模型读取的是清洗后的版本，发生问题时两边可以对照排查。
4.2 超长文本处理：分段摘要与再合成的思路
如果输入文本超长，超过模型上下文窗口，直接单次摘要就会失败。传统编程里我们可能会写循环分批处理，而在可视化工作流里，同样有对应的思路，核心逻辑很像编程里的“Map-Reduce”思想。
先把长文本按段落或章节拆成若干片段，每个片段生成一个局部摘要，这是“Map”阶段；再把所有局部摘要合并起来，生成一个全局摘要，这是“Reduce”阶段。如果你用的平台支持迭代节点或批处理节点，可以用它们来实现自动分段；如果暂不熟悉这些高级节点，也可以用最朴素的方法：在 Prompt 里要求模型“分步骤处理”，或者手动把文本分成几段，分别调用摘要后再合并。
我会这么建议：能上批处理节点就用批处理，这样输入文本多长都能自动分段处理；如果只是为了快速验证效果，手动分段拼接也足够。演示和测试阶段用简单方案，正式投入使用再升级到自动批处理，逐步加复杂度，风险最小。
这里有一个重要的提示：
在 Prompt 中明确禁止改写和自由发散，能从机制上降低模型“脑补”的概率。把“只依据给定内容输出”这句话直接写进模板里，效果远好于你在说明书外反复口头强调。
4.3 效果评估：摘要质量怎么判断
搭建完成之后，怎么判断摘要做得好不好？我从三个维度去检查。
第一，关键信息覆盖率。原文中的核心结论、关键人物、具体数字，摘要里是否保留了？如果丢失，要检查是否输入截断、Prompt 里没有强调“保留关键实体和数字”。
第二，内容一致性。摘要内容是否都能在原文中找到依据？有没有出现原文没有的观点或数据？出现这种情况，大概率是温度设置偏高或 Prompt 没有约束“不得添加原文中没有的事实”。把温度降到 0 是最直接的改善手段。
第三，语义连贯度。摘要读起来是否通顺、像一段自然的文字，而不是关键词堆砌或重复句子。如果摘要出现明显的语句重复，可以在 Prompt 里加一句“用不同的语句表达，避免重复”。如果太散，可以要求模型“按逻辑顺序组织内容”。
我自己每次调整参数都会保存一次版本并记录当时的运行结果。这样测试几轮之后，你能看到“到底是哪一次改动让效果变好的”，而不是凭感觉反复试。这个习惯对调优效率帮助极大。
5. 常见问题速查表与排查思路
5.1 运行报错：这四类问题最常见
接触工作流一段时间后，我总结出四类最高频的报错场景。遇到问题时，先对照表格快速定位，比漫无目的地试要高效得多。
| 报错现象 | 可能原因 | 排查重点 |
|---|---|---|
| 运行后提示变量未赋值 | 开始节点的字段没有和 LLM 节点连线 | 检查连线是否连接成功，Prompt 里的变量名是否一致 |
| 模型没有输出 | 模型服务未正确配置，或密钥状态异常 | 在模型供应商页面检查接入状态，测试单独调用模型是否正常 |
| 输出被截断成一两句话 | 最大 Token 设置过小 | 调大最大 Token，结合输入文本量估算合适的输出上限 |
| 输出内容为空 | Prompt 占位符写错，或结束节点没正确选择输出变量 | 核对 LLM 节点的输出变量名，检查结束节点的映射关系 |
排查的第一原则是：先在运行记录里点开每个节点，看到底是哪一层输出的内容不对，而不是一上来就动参数。通常这一两步操作就能把问题范围缩小一大半。
5.2 摘要质量不佳：按症状对症下药
如果运行没有报错，但摘要结果不合预期，问题就更偏“质量”而非“故障”。表里整理了几种常见表现和调整方向。
| 表现 | 原因分析 | 调整建议 |
|---|---|---|
| 摘要内容过长 | 缺少长度约束 | 在 Prompt 中明确“控制在 N 字以内”，或调入最大 Token |
| 摘要过短、内容空洞 | 模型没有充分读取原文 | 检查输入文本是否被截断，适当增大上下文或改用长上下文模型 |
| 摘要中出现原文没有的信息 | 温度过高或 Prompt 约束不足 | 温度调为 0，Prompt 中添加“只依据输入内容”的硬约束 |
| 摘要丢失关键数字和结论 | 没有在 Prompt 中强调保留要素 | 在要求中加入“保留关键实体、数字和结论” |
| 内容重复啰嗦 | 模型生成策略问题 | 增加“避免重复表达”，或降低最高输出 Token 限制 |
遇到质量问题时，我建议一次只改一个变量。比如这一轮只改温度、下一轮只改 Prompt。同时改好几个参数，最后效果改善了你也不知道是哪个变量起了作用，后续也没法稳定复现。
5.3 我对工作流编排的几句心里话
做了几个完整应用之后，我对“拖拽连线替代代码”这件事的看法有了一些变化。它确实替代了很大一部分重复的胶水代码，比如密钥管理、接口调用、参数传入、结果解析。但它并没有替代“逻辑设计”本身——你依然需要想清楚每个环节应该做什么、数据从哪里来到哪里去、异常情况怎么处理。换句话说，它降低的是编程门槛，不是思考门槛。
我的建议是，入门阶段保持最简单的结构：开始 → LLM → 结束。不要一开始就堆叠各种高级节点。跑通最小链路，再逐步增加文本处理、分支判断、批处理，每一步都能通过运行记录验证效果，整个过程会非常踏实。
最后分享一个小技巧：我在每次调试时都会把“运行记录”里生成的中间结果复制一份，单独建文档保存。这样一来，参数改坏了还能直接回退到之前的表现，而不是靠记忆盲调。这套“先留底、再修改、逐步对比”的节奏，我用了很久，效果比凭感觉反复试靠谱太多。
