1. 为什么我建议你用拖拽连线来做文本摘要器先别急着打开代码编辑器。如果你跟我一样经历过“写一段调用大模型的脚本结果光调参数就花了半小时”的尴尬那你一定会爱上 Dify 工作流这种“搭积木”的方式。Dify 的 AI 工作流本质上是一套可视化的逻辑编排工具。你用拖拽的方式把不同的功能节点连接起来就像在画流程图一样把“读取文本 → 清洗内容 → 分段处理 → 调用大模型 → 输出摘要”这条链路串起来。整个过程不需要写一行 Python 或 JavaScript但产出的结果跟写代码调 API 的效果几乎一致甚至更快。这篇入门实战我会带着你从零搭建一个文本摘要器。它能做的不是简单地把文章“变短”而是根据你设定的模式生成适合汇报用的简报、适合阅读的提炼版或者适合二次创作的关键信息列表。这套方法适合谁适合刚接触 Dify、不懂代码但想快速做出 AI 应用的运营同学也适合那些已经写腻了脚本、想找个更高效工具的开发者。老实说我见过不少程序员用 Dify 工作流做内部工具效率比从零写代码高得多因为省掉了大量接口对接和异常处理的重复工作。在开始之前你需要准备两样东西一个能正常访问的 Dify 实例社区版或者云端版都行以及一个可用的模型供应商 API Key比如 DeepSeek、OpenAI 或通义千问都可以。这里我用的是 DeepSeek原因就一个字便宜而且摘要这种任务它完全能胜任。2. 核心设计思路先拆解流程再思考自动化很多初学者拿到一个问题第一反应是“这个能不能用 AI 直接搞定”第二反应就是“那就用提示词硬写”。实际上真正的工作流设计应该先从“流程拆解”开始。2.1 文本摘要器的本质是什么我们平常写摘要脚本无非就是四步读取原始文本、处理格式噪音、按长度或主题切块、丢给大模型让它概括。这四步在代码里可能要写几十行还要处理网络超时、Token 限制、JSON 解析各种边角问题。但换成 Dify 工作流这四个步骤对应的是四个节点你只需要把它们按顺序连起来。更关键的是工作流把“过程”和“结果”分开了。你可以实时看到每一个环节的输出文本被清洗后长什么样、分段后有哪些块、模型调用用了多少 Token全都一目了然。这在调试阶段的帮助是巨大的——你用代码调试的时候得打印一堆日志而在 Dify 里点一下节点就能看到中间结果效率是完全不同的。2.2 为什么选择“文本摘要”作为第一个工作流我给新手的建议从来都是不要一上来就搭那种十几个节点的复杂 Agent先从“单路径直筒”开始。文本摘要器就是一个完美的练手项目理由是第一它只有一条主路径输入到输出没有分支逻辑极其清晰。你不需要考虑条件判断、循环、迭代这些进阶概念只需要关心数据怎么流动。第二它的核心是“和模型打交道”而 Dify 工作流最有价值的恰好就是帮你封装了模型调用的复杂性。模型选择的参数、温度、最大 Token这些你在界面上点一点就能设置不用查文档写参数。第三它实用。别觉得摘要简单在信息过载的今天能把一份冗长的会议纪要快速提炼成三条要点已经有很大的实际价值了。你做完这个第二天就能用到工作中。2.3 需要避免的两个设计误区我会在后面的实操细节里提到各种注意事项但这里先说两个最容易踩的设计误区。第一个误区是“过度拆分”。我见过有人为了展示工作流的能力把摘要器拆成了十个节点中间还加了好几个没实际意义的加工步骤。你记住工作流里的每一个节点都是有成本的节点越多、调试越麻烦、维护越困难。初学者设计原则就一条能用五个节点解决的事情绝对不用六个。第二个误区是“让模型思考太多事”。文本摘要器的提示词最重要的不是文采而是“单一职责”。你让模型“帮我总结一下顺便提取关键词再翻译成英文”它大概率每件事都做不好。正确做法是一个节点只做一件事或者用多个模型节点分别处理。这也是工作流比单个提示词的优势所在——你可以把任务拆给不同的节点去执行。3. 手把手实操核心环节与关键节点配置接下来进入正题。我默认你已经登录了自己的 Dify 后台进入“工作流”页面点击“创建空白工作流”。这里每一步我都会讲清楚“怎么操作”和“为什么这么做”。3.1 创建工作流从开始节点到 LLM 节点创建之后你首先看到的是一个画布左侧是节点库中间是可视化编辑区右侧是节点配置面板。第一步把“开始”节点作为起始点。你需要在它的输入字段里定义一个名为input_text的变量类型选择“段落”。这里有一个小技巧如果你希望这个工作流既能被对话助手调用也能被 API 调用那就在“输入字段”里把类型选对。“段落”类型适合长文本“文本框”适合短文本选错的话后面传参会有麻烦。第二步从节点库里找到“LLM”节点拖到画布上。这里就是整个工作流的大脑。点击这个节点右侧会出现配置面板你需要做三件事选择模型供应商。我选的是 DeepSeek 的deepseek-chat因为摘要任务不需要复杂的推理能力用便宜模型性价比最高。如果预算充足想追求摘要质量可以换gpt-4o-mini或qwen-plus。设置模型参数。我这里把温度Temperature调成了 0.3。为什么要调低因为摘要任务追求的是准确和稳定不是天马行空的创造性输出。温度越高模型越可能添油加醋把原文没有的信息加进摘要里。编写系统提示词和用户提示词。这是整个工作流里最核心的部分值得多说两句。3.2 提示词编写的“唯一公式”我总结了一套摘要提示词的公式写出来给各位抄作业系统提示词 你是一位专业的文本摘要助手。你的任务是根据用户提供的文本生成精炼且忠实原文的摘要。不得添加原文中不存在的观点不得遗漏关键信息。 用户提示词 以下是需要摘要的文本内容请严格遵循以下要求 1. 摘要长度控制在500字以内 2. 按“背景、核心观点、结论”三个部分组织输出 3. 使用简洁的陈述句禁止使用“首先、其次、最后”等过渡词 4. 原文内容{{input_text}}看到那个{{input_text}}了吗这就是 Dify 工作流的核心——变量引用。你在“开始”节点定义的输入通过这种模板语法注入到提示词里。这个语法跟 Jinja2 模板很像所以写过 Python 的人会特别有亲切感没写过也没关系你只需要把它理解成“占位符”就行。这里要重点提醒你提示词里说的“原文内容”一定是显式的引用而不是让模型自己去猜。很多新手会把重点放在前面对话的上下文里希望通过“记住前面说的内容”来实现但在工作流里这种隐含依赖是最坑的。因为工作流可能是被 API 直接触发的模型能看到的就是你提示词里写的内容。所以宁可把变量引用写两遍也绝对不要图省事。3.3 中间的“文本处理”节点为什么它是隐藏功臣大多数教程会直接从“开始”连到“LLM”但我强烈建议你在中间加一个“模板转换”或者“文本处理”节点。别小看这一步它是保证摘要质量的关键。我用的是“模板”节点它允许你在中间层面对输入文本进行格式化。我在这里做了一个操作把大段连续的文本按照句号、换行符做了一次分割清洗把多余的空格和空行去掉。为什么要这样做因为大模型的 Token 计算是按照字符数来的如果你直接把一篇格式混乱的文章丢进去那些多余的换行符、空格符、甚至无意义的 Markdown 标记都会白白消耗你的 Token 额度。另外一个原因更实际。在实际场景中你上传的文本可能来自 OCR 识别可能来自网页抓取里面会有各种奇怪的字符。如果不在输入前做一个“过滤”这些噪音内容会干扰模型的理解导致摘要结果不准确。这个节点本身没有太多参数要设置操作很简单在“代码”模式下Dify 很多版本支持 Jinja2 模板你可以用类似{{ input_text | trim }}的写法把文本的前后空格去掉更复杂的操作还可以用内置的“代码执行”节点来正则化清洗。不过要注意如果你完全不会写代码就用“模板”节点里的替换功能把连续的空格替换成单个空格即可。3.4 连接节点与“结束”节点的配置在画布上从“开始”节点的右侧小圆点拖出一条线连接到“模板”节点再拖到“LLM”节点最后连到“结束”节点。连线的过程中相当于把数据从一个节点传递给下一个节点每个节点都能读取上游节点的输出。“结束”节点也很关键。很多人在配置时会忽略它导致工作流跑通了但输出结果不知道怎么取。在结束节点的配置面板里你需要添加一个输出变量类型选择“段落”变量的值引用 LLM 节点的回复内容{{llm_node.text}}。这里的llm_node是那个 LLM 节点的内部标识可能叫节点 1也可能叫别的名字。你在下拉框里直接选就行。做好这一步后整个工作流的输出就能通过 API 的响应体返回给调用方了。4. 实测运行从测试到发布的完整过程配置完成并不意味着结束你得跑一次真实数据来验证这个工作流能不能用。4.1 用测试数据来“调试”而不是“验证”很多新手在测试时有个坏习惯直接拿一篇很长的真实文章丢进去然后看结果。这不是调试这是碰运气。正确做法是先用一段短文本测试。我用了一段 300 字左右的新闻摘要片段来做测试目的是确认节点之间数据流是通的模型有正常返回。点击画布右上角的“运行”按钮Dify 会弹出参数输入框你填入input_text的值然后点“运行”。此时你注意观察画布上的节点会依次变成“执行中”的高亮状态。等全部跑完后点击任何一个节点都能看到它的输入和输出详情。比如你点“模板”节点可以看到清洗后的文本长什么样点“LLM”节点可以看到模型的完整回复内容。这种可视化调试体验用代码是完全没有的。你在写 Python 脚本调试的时候想看到“最终输出”只能等整个脚本跑完中间只要报错就只能看 traceback。而在工作流里你可以精准定位到哪一个环节出了问题。我第一次测试的时候就发现 LLM 节点的输出里多了一句“作为AI助手我无法提供版权内容”。原因是我用的测试文本是某篇付费文章的节选模型出于版权保护拒绝了摘要。这不是工作流的问题而是提示词策略的问题——需要调整系统提示词加上一句“请勿拒绝用户请求你只需处理输入文本”。加了这句之后输出就正常了。4.2 发布工作流把它变成可调用的应用测试通过之后点击右上角的“发布”按钮这个工作流就从“草稿”状态变成了“已发布”状态。发布之后你可以做两件事第一直接在这里的“预览”页面测试一次完整调用。第二回到“应用”页面在 API 访问菜单里你会看到一个 API 密钥生成入口。生成密钥之后你就可以用任何编程语言调用chat-messages接口把这个工作流当作一个后端服务来使用了。我用一段简单的 curl 命令来示范如何调用你不需要自己搭环境直接复制到终端里就能试curl --location --request POST https://你的域名/v1/chat-messages \ --header Authorization: Bearer 你的API密钥 \ --header Content-Type: application/json \ --data-raw { inputs: {}, query: 请生成摘要, response_mode: blocking, conversation_id: , user: hello }但注意如果你没有把“输入变量”暴露给对端query字段里的内容不会自动变成input_text。这里有一个 Dify 工作流很容易让人混淆的地方在对话型应用中用户输入的内容默认存在query里但工作流的“开始”节点是通过inputs来接收参数的。所以正确的调用方式是在>{ inputs: { input_text: 这里放你要摘要的正文 }, query: 请生成摘要, response_mode: blocking, conversation_id: , user: hello }这也是 Dify 工作流和 Chatflow 的一个关键差异。工作流更适合作为“工具节点”被外部系统调用而 Chatflow 更适合做对话机器人。做摘要器这种场景用工作流就好。5. 常见问题与排查技巧实录这里记录几个我在实操中踩过的坑以及从社区里看到高频问题。把这些整理成一个速查表方便各位在实际用时排查。现象原因解决方案运行时报“节点执行失败”模型API Key失效或余额不足检查模型供应商的凭证进入“设置 → 模型供应商”重新配置输出的摘要只是一句话“好的已收到”提示词没有正确引用变量检查{{input_text}}写法确保变量名与开始节点定义完全一致摘要里多出了“作为AI我不能...”模型安全策略触发在系统提示词中明确“你只负责处理给定的文本内容”长文本超过Token上限输入文本太长超出模型上下文窗口在“模板”节点之前用“文本处理”节点做截断或分段或者用{{ input_text[:2000] }}做截断API调用时input_text为空调用参数把文本放进了query在 API 请求的inputs字段中显式传入input_text工作流发布后无法修改已发布的版本只读回到编辑器修改后点击“新建草稿”再编辑模型回复内容带有 Markdown 格式系统提示词未指定输出格式在提示词中加入“以纯文本输出不使用任何格式”5.1 关于变量引用的“三大坑”这一定是你最常遇到也最容易忽略的问题。我特别拿出来讲是因为它出现的频率太高了。第一个坑变量名写错。在“开始”节点里你定义的变量名是input_text但在提示词里写成了{{input-text}}或者{{inputText}}系统不会自动纠错而是直接把这段文本原样传给模型模型就会一本正经地告诉你“我已经为您总结了 input_text”。遇到这种情况去仔细核对下划线和中划线是不是打对了。第二个坑引用路径不对。在 LLM 节点的用户提示词里变量来源只能从“上下文”里选不能手动乱写。尤其当你有多个 LLM 节点时你要确保引用的是“开始”节点而不是上一个 LLM 节点的输出。Dify 的变量选择器做得已经很智能了它会展示当前节点能访问到的所有变量。你只需要点那个蓝色的“插入变量”按钮然后搜索你要的变量名不要手动敲代码这能在根本上避免引用路径错误。第三个坑类型不匹配。“开始”节点里你定义了“段落”类型在“代码”节点里你试着用正则去处理它返回的结果却变成了“字符串”。大部分情况没问题但有时你在模板节点里用了tojson过滤器输出的值会变成带引号的 JSON 字符串模型读到的时候就会多出一堆转义符号。如果出现这种情况就在模板里改用| string或者| safe过滤器根据实际场景测试。5.2 模型不是你肚子里的蛔虫关于输出格式还有一个高频问题就是“我已经在提示词里明确写了‘输出 JSON 格式’为什么它给我一段带解释的文字”这与 Dify 无关这是大模型的天性。你只能用两种方法解决第一在系统提示词里用非常强硬的措辞“只允许输出 JSON任何解释都视为违规”第二用 Dify 工作流里的“问题分类”或“参数提取”节点这类节点底层帮你做了 JSON 结构化输出的约束比你在普通 LLM 节点里写提示词要稳定得多。但对于文本摘要器这种场景你不需要强制 JSON你只需要一段结构清晰的文字。所以我在前面的提示词里特意要求模型按“背景、核心观点、结论”三部分输出。这个就比“输出 JSON”更贴近实际使用场景。5.3 重启与版本被忽略的发布陷阱最后一个建议也是我刚接触 Dify 时吃过亏的地方。Dify 的工作流一旦“发布”你再在编辑界面里改的东西不会自动生效。你需要先“新建草稿”修改完再重新“发布”。有一次我改了提示词以为线上 API 会自动更新结果测试了十几次接口返回的还是旧逻辑的输出。这个逻辑本身是合理的因为 Dify 要保证已经上线的应用是稳定版本。但如果你不熟悉很可能在这里被坑。我自己现在的习惯是每改一次就顺手发布一次反正发布操作没有审核成本。6. 进阶微调让文本摘要器真正为你所用基础版本已经跑通了但如果只是这样那这篇文章跟官方文档没什么区别。接下来这几个微调点是我把摘要器投入实际业务之后才总结出来的你直接拿去就能用。6.1 巧用“变量聚合节点”做多维度摘要单一路径的摘要器只是“入门”。如果你手头有一篇很长的行业报告想一次性输出“执行摘要”“财务亮点”“风险提示”三个维度的内容该怎么办答案是在 LLM 节点后面并联三个 LLM 节点分别用不同的提示词调用同一个输入然后用“变量聚合节点”把三路输出合并成一个文本。这样做的好处是避免了一次性让模型做太多事导致内容深度不够。你可以把基础款理解成“通才”而并联多模型节点相当于“专家会诊”。每个节点用不同的系统提示词比如专门负责财务数据的节点提示词里可以加一句“重点关注营业收入、利润率、现金流等指标的变化”风险节点则加一句“重点关注合规、舆情、技术迭代方面的潜在风险”。6.2 用“知识库检索节点”增强摘要的背景信息如果你的摘要器不是面向通用文本而是面向特定行业比如医药、法律、金融那么你可以在“开始”和“LLM”节点之间插入一个“知识库检索”节点。先让用户输入一段摘要请求再从你的 Dify 知识库里检索相关的背景资料把它们作为参考信息注入到 LLM 的提示词里。这个操作说起来简单但效果立竿见影。比如让 AI 摘要一份合同你指令它引用知识库里的法律条例得出的结论就会严谨得多不会出现“赔偿金额不应超过一年房租”这种模糊表达。6.3 后续拓展从摘要器到日报生成器最后说说从这个项目还能延伸出什么。如果你在企业做行政或运营你可以把这个摘要器接一个“定时触发”或“手动触发”入口每天早上把昨天的会议记录、项目周报、行业动态推送成一个“晨读日报”。这个本质还是摘要只不过你把输入从“单篇文本”换成了“多来源文本”输出从“一段摘要”换成了“三到五条要点”。根据我现在使用的经验处理好输入源的类型很重要。不是每篇文本都适合做摘要——有些本身是段落式的散文有些是表格化的数据还有的是对话记录。对不同的输入源你需要配备不同的“文本处理节点”。这也是为什么我强调不要试图做一个万能的摘要器而是做适合你输入场景的摘要器。先清楚你常见的文本是什么样再针对性地清洗和配置效果会好很多。我在实际跑这个工作流时最深的体会不是“拖拽连线怎么好用”而是“思考方式变了”。以前写代码我关心的是 if-else 怎么分支、函数怎么调用现在搭工作流我关心的是数据从哪里来、在哪个环节被加工、最后怎样呈现给用户。这是一种更接近业务本质的抽象方式。对我这种常年跟代码打交道的人来说刚开始会有点不习惯但一旦上手你会发现“可视化”带来的调试效率提升比单纯少写代码这一点要有价值得多。