Dify工作流保姆级教程：从黑盒Prompt到可视化AI流水线-北京尧图网络

前几天有位读者留言问我Dify 在基础对话里已经能干活了为什么还要专门搞一个“工作流”我把所有要求写在一个大 Prompt 里让模型自己去判断不是更快吗这个问题几乎每个刚接触 Dify 工作流的人都会问。当时我回了一句你自己写 Prompt 靠的是“感觉”而工作流把这种“感觉”拆成了画布上看得见的节点与连线每一步都确定、可见、可改。这篇是 Dify 系列教程的第 6 篇。前面几篇我们已经把最基础的对话应用、Prompt 编排、知识库接入都过了一遍今天专门来啃“工作流Workflow”。这篇不讲高深概念就讲清楚三件事工作流到底解决了什么问题、它的心智模型是什么、怎么亲手搭一个能跑通的工作流。我还会把调试方法和实际项目里踩过的坑一并写出来照着走就行。1. 为什么要把 AI 逻辑搬上画布1.1 “一个 Prompt 搞定一切”的幻觉先把话说透我不是说大 Prompt 完全不行。如果你只是做一个“帮我润色这段文字”的小工具一个 Prompt 完全足够。但一旦任务开始变复杂情况就不一样了。想象一个典型的内部工具客户发来一条消息你需要先判断这是咨询、投诉还是售后问题然后根据判断决定是否查知识库查完还要把答案按固定格式回复同时把整个会话落库。如果你把这个过程全部写进一个 Prompt让大模型一次完成你会遇到几个很现实的问题第一模型自由度太高。它会自由发挥判断意图可能错“要不要查知识库”可能多此一举甚至输出格式偶尔不符合要求。你明明写清楚了“必须输出 JSON”它偏偏偶尔给你包一段 Markdown 代码块下游解析直接崩。第二改一处等于重写。某天业务方说“回复里再加一个产品链接”你得在长 Prompt 里找到对应位置小心修改然后还要担心改动了其他地方的行为。改完之后你根本无法确定这次修改影响了哪个环节。第三出了问题极难定位。同样一段输入跑两次结果可能不同。你分不清是模型理解错了、知识库没召回还是 Prompt 某个词写得不清楚。这种“黑盒”式开发在小 demo 里没问题在生产环境里会让人头皮发麻。我见过一些团队把几十条业务规则全部塞在一个 Prompt 里跑起来完全看命。稍微有点工程经验的人都会意识到大模型擅长的是“理解与生成”不适合承担“可控的流程编排”。这两件事得分家。1.2 工作流把一个“黑盒”变成了一条“流水线”Dify 工作流做的事情就是把原本让大模型自由发挥的整段流程拆成一个一个职责明确的节点。这些节点有些会调用大模型比如 LLM 节点有些完全不碰模型比如条件分支、模板转换、HTTP 请求。节点之间用连线串联数据通过变量在节点间流动。这个设计有一个很关键的价值确定性逻辑回归代码创造性逻辑交给模型。举个例子。在“客户消息处理”这个场景里“识别消息类型”这个环节存在天然的不确定性适合交给 LLM 节点但“如果是投诉消息就走 A 分支是咨询消息就走 B 分支”这条规则是确定的应该由条件分支节点来写死。你不应该指望大模型每次都能准确执行你说的“如果……那么……”但你可以自己在画布上把这条规则画出来让流程必然按它走。可视化的另一个好处是可观测。每一次运行工作流里每个节点都会留下输入输出记录。你一眼就能看到问题出在 LLM 生成环节还是知识库检索环节还是最后模板拼接环节。这种“哪一步都能查”的能力在传统 Prompt 模式里几乎做不到。再往大了说工作流把 AI 逻辑变成了一张团队可以共同讨论的图。业务同事不再需要读懂复杂的代码他看着画布就能说出“这里我认为应该先查知识库再生成”。这种协作价值在项目落地时比想象中更重要。1.3 先搞清楚Workflow 和 Chatflow 不是一回事开始动手之前必须先把概念掰清楚。在 Dify 里你新建应用时会看到不同类型的应用选项其中涉及工作流的主要有两种Workflow 和 Chatflow。很多人第一次听到“工作流”就以为是把聊天应用换成流程图其实不完全对。Workflow 面向的是“一次性运行的后端任务”你给它一组输入它跑完整个流程返回一个结果运行结束。它没有对话上下文适合定时生成报表、批量处理文本、调用内部 API 这类自动化场景。Chatflow 则是聊天助手类应用支持多轮对话但在内部也可以按工作流方式编排。客服机器人、问答助理这类需要聊天上下文的应用属于这类。Chatflow 里也有画布、也有节点但多了一些对话相关的能力比如“直接回复”节点。为了不让入门读者混淆这篇教程聚焦 Workflow。你先把 Workflow 的工作方式吃透再去碰 Chatflow 会轻松很多。维度WorkflowChatflow运行方式一次运行拿到最终结果多轮对话保留上下文典型场景报表生成、数据清洗、API 编排客服问答、智能助理结束方式结束节点输出结果直接回复给用户学习难度相对简单线性为主多轮分支较复杂2. 先建立心智模型节点、连线和变量2.1 一张工作流就是一张流程图打开 Dify 的工作流编辑器你看到的就是一块画布、几个初始节点以及左侧的节点库。很多人第一次进来有点懵因为这不像是写代码的界面。但其实它的心智模型非常简单一张从左到右读的流程图。画布上有节点节点之间有连线。执行时从“开始”节点出发一个节点跑完自动把结果给到下一个节点。连线不是“数据的箭头”更准确的理解是“我执行到了这一步并且被引用的上游输出已经就绪”。所以你在下游节点里只能引用当前节点之前已经执行过的节点输出。新手最常见的错误心态是把工作流想象成“每个节点自动获得前面所有节点的全部信息”。并不是。节点 A 的输出不会自动出现在节点 B 里除非你在节点 B 的配置里显式引用变量。数据流动是被你的引用动作“拉”过去的而不是连线主动“推”过去的。这个差别很微妙但理解之后调试的时候会少走很多弯路。还有一个点时要注意当一个节点后面有多个无条件连线的下游分支时这些分支会并行执行。但入门阶段先把流程画成单线加上一个条件分支就够用。并行、迭代这些进阶玩法后面再说。2.2 入门必须认识的几个核心节点Dify 工作流节点类型不少但入门阶段真正要熟练掌握的就五六个。我把它们从“最强需求”到“进阶可选”整理成一张速查表你对着看就行。节点作用是否需要模型入门掌握程度开始定义工作流的输入字段否必学LLM调用大模型生成内容是必学知识检索从知识库召回文本片段否强烈推荐条件分支按条件走不同分支否必学模板转换用模板拼接、格式化文本否必学代码执行 Python / JS 做计算或转换否进阶HTTP 请求调用外部接口否进阶迭代循环处理一个数组否进阶结束定义工作流输出结果否必学我的建议是先学会用“开始、LLM、条件分支、模板转换、结束”这五个节点搭通一条最简流程之后再逐步加别的。这几个节点几乎覆盖了日常 80% 的需求把它们练熟比贪多嚼不烂重要得多。2.3 变量的流动系统变量与节点输出工作流里数据全靠变量流动。初学阶段你只需要分清两类变量。第一类是系统变量。Dify 平台运行时会自动带上一些环境信息比如当前用户 ID某些场景下的会话 ID。在工作流里你可以在配置里找到以sys.开头的变量。这类变量不用你自己定义直接用就行。第二类是节点输出变量。每个节点执行完都会产生自己的输出。比如“开始”节点输出你填的姓名、工作要点“LLM”节点输出大模型生成的文本“模板转换”节点输出拼接好的字符串。这些输出变量可以在后续节点里被引用。在 Dify 的配置界面里不需要背变量名。凡是能写 Prompt、能填参数的输入框旁边通常会有变量选择器点一下就能看到当前可引用的变量列表。选完后内容里会生成类似{{#node_id.output_name#}}的标记。这就是变量引用的语法。举个例子在 LLM 节点的 Prompt 里我常常这样拼你是一位团队助理请根据以下工作要点撰写周报初稿。汇报人{{#start.name#}} 本周工作要点{{#start.weekly_points#}}运行时Dify 会把实际的字段值替换进去。刚入门不要手写这些标记养成用变量选择器插入的习惯能避免一大半低级错误。3. 实战搭一个“周报生成助手”工作流光讲概念没用直接动手。这一节我们从头搭一个工作流场景叫“周报生成助手”输入汇报人、本周工作要点和目标完成率工作流自动生成一份结构化的周报初稿如果目标的完成率不足 80%再自动追加一段风险说明。这个场景很简单但完整覆盖了开始、LLM、条件分支、模板转换、结束五个核心节点。3.1 创建应用先把输入定义清楚登录 Dify 控制台在应用列表页点击“创建应用”选择“工作流”类型名字随意起一个“周报生成助手”。创建完成后你会进入画布。画布上默认已经有“开始”和“结束”两个节点中间是空的。第一步点击“开始”节点在右侧配置输入字段。这里的工作是定义“这个工作流接收哪些外部输入”。我建议第一个版本只加三个字段姓名类型选“文本”变量名起为name本周工作要点类型选“段落”变量名weekly_points目标完成率类型选“数字”变量名completion_rate。为什么“本周工作要点”用段落而不是文本因为段落能容纳多行内容更适合用户粘贴大段工作记录不会因为换行被截断或压缩。这里有个小提示输入字段的变量名最好用英文因为在变量引用和 API 调用时都会用到。界面上的“显示名称”可以用中文不影响内部逻辑。养成这个习惯后面接 API 会省很多事。3.2 LLM 节点让模型整理初稿接着从左侧节点库拖一个“LLM”节点到画布上把“开始”节点的输出端连到它的输入端。LLM 节点是工作流的“大脑”负责生成初稿。点击 LLM 节点右侧配置区会有一堆选项模型、温度、Prompt 等。模型按你自己的账号可用模型选即可很多场景下对话类模型就很稳。温度这个参数值得留意周报、公文、会议纪要这类任务我不喜欢太高温度0.7 左右就够太高会显得内容飘。Prompt 我直接给一段可用的你是一位有 5 年经验的团队助理。请根据以下工作要点生成一份结构清晰、语气专业的周报初稿。要求包含三个部分本周工作概述、关键成果、问题与风险。如果信息不足直接写“暂无补充说明”不要编造内容。汇报人{{#start.name#}} 本周工作要点{{#start.weekly_points#}}注意问候语都用变量选择器插入确保引用的正是开始节点里的输入字段。写完 Prompt 后LLM 节点的输出默认是一段文本我们在后面直接用这个输出继续加工。这一步要给新手提个醒LLM 节点的输入来源不只是开始节点。你完全可以先接知识检索节点把检索结果再喂给 LLM形成 RAG 流程。这只是延伸核心逻辑是“先拿到上游数据再作为变量引用进来”。3.3 条件分支和模板转换给流程加判断接下来是重点环节。再拖一个“条件分支”节点和“模板转换”节点。当前链路是LLM 节点 → 条件分支节点条件分支的其中一个出力口连接模板转换节点模板转换节点再走向结束节点条件分支的另一个出口也直接走向结束节点。点击条件分支节点配置判断条件。我们要判断“本周目标完成率是否低于 80%”。条件配置里变量选择开始节点的completion_rate运算符选“小于”值填 80。逻辑就是如果完成率小于 80走“是”这个出口否则走“否”出口直接结束。为什么不直接用 LLM 判断因为这是一条确定规则。完成率低于 80% 就得提醒这个逻辑完全是确定性的交给大模型判断就是浪费还可能偶尔判断错。条件分支节点是工作流里最值得用的确定性逻辑务必把它练熟。再配置模板转换节点。模板转换做的事很简单把上一段 LLM 生成的周报初稿和一段固定格式的“风险说明”拼接起来。以下是本周周报初稿 {{#llm_node.text#}} ### 风险与待支持说明当前目标完成率为 {{#start.completion_rate#}}%未达到 80%。请在下一周重点跟进资源协调、优先级调整、风险防控。同样模板里的变量用选择器插入不要手写节点 id。模板转换节点就是一个纯字符串拼接的“格式工厂”它不需要调用大模型因此执行快、结果稳定。凡是你希望“固定格式始终一致”的内容都尽量放在模板节点里而不是让 LLM 去自由发挥。3.4 结束节点与整条链路串联最后把两个分支都接到“结束”节点。点击结束节点配置输出。这里可以选择输出模式我建议入门阶段先选“文本”输出变量选你最终想要的结果。在这个例子里如果完成率大于等于 80最终输出就是 LLM 节点生成的初稿如果完成率小于 80最终输出就是经过模板转换拼接后的完整周报。结束节点每次只能输出一个结果但你可以通过条件分支决定最终走哪一路结果。这里有一个常见疑问为什么两个分支能接到同一个结束节点因为工作流对结束节点的要求是“无论走哪个分支最终都要汇聚到结束”。Dify 允许不同分支接到统一个结束节点运行时只会执行其中一条路径所以不会出现“两个结果都输出”的情况。如果你希望同时输出多个变量可以切换结束节点的输出模式组合多个变量然后输出为结构化内容但入门阶段先用一个文本输出把流程跑通再说。整条链路到这里就闭环了开始 → LLM → 条件分支 → 模板转换/直接 → 结束。画布上的图已经可以完整阅读看一眼就知道这个 AI 逻辑是怎么走的。4. 调试与运行把工作流真正跑通4.1 点开运行一个动作开始调试配置完节点先别急着发布要在这个画布上直接试运行。画布右上角有“运行”按钮点开后会弹出一个“运行预览”面板。这个面板会展示你在“开始”节点定义的所有输入字段你可以填一组测试数据进去。我第一次用的时候很兴奋但运行完却被一大片绿色红色节点闪花了眼。后来才明白这是个非常强大的调试功能运行结束后每个节点旁边会出现执行状态绿色是成功红色是失败。点任意一个节点都能看到它的输入和输出。打个比方这就像给一条流水线的每个工位都装了一块屏幕传送带走到哪个工位屏幕上就显示这个工位吃了什么、吐出了什么。哪里不对点到哪个工位看屏幕就清楚了。这比传统方式“打印日志”直观太多。4.2 三个调试心法调试时我有三个固定心法每次都能帮我快速定位问题。心法一从“开始”往“结束”看先确认上游有没有输出。如果 LLM 节点的输入里某个变量显示为空多半是变量引用错了位置或者开始节点根本没填这个字段。先从上游排查省得在下游瞎猜。心法二节点标红不代表一定是模型的问题。点开失败节点右侧会有错误信息。常见的有模型账号没有配置、上下文长度超限、接口超时。很多时候是资源或配置问题而不是你的流程逻辑错了。心法三分支判断不按预期去条件分支节点里看运行时的实际值。我踩过一个很典型的坑开始节点里输入的数字是 85但用户填的时候带了百分号“85%”导致类型变成字符串和条件里的数字 80 比较时永远不匹配。运行日志里能直接看到变量值是这个样子的一眼就能发现问题。4.3 用固定测试输入反复验证一个工作流从搭好到敢接进业务系统必须经过多组测试输入验证。我的习惯是准备两组“边界数据”一组是正常完成率比如 95%确认它走直接结束分支另一组是低完成率比如 60%确认它走模板转换分支并输出风险说明。按“运行”时你会发现即使输入完全一样LLM 节点的输出文本每次可能会略有不同这是正常的大模型天生有随机性。你需要检查的不是“每次文字是否一样”而是“结构是否稳定、关键信息是否齐全”。如果文字结构时好时坏说明 Prompt 的指令还不够明确此时才需要回到 LLM 节点强化要求。还有一个小细节运行面板的历史记录会保留每次运行结果。不要只盯最新一次翻翻历史记录对比不同输入条件下的执行路径能帮你更完整地判断工作流是否稳定。5. 常见问题与避坑速查5.1 问题排查速查表工作流用多了你会发现问题都长得很像。我整理了一张速查表遇到问题先照着查一遍。现象常见原因处理办法LLM 节点报上下文超限输入内容太长压缩输入文本或在前面加知识检索限制召回数量条件分支永远不匹配变量类型不一致点开条件分支核对变量实际值是字符串还是数字下游引用不到上游变量引用了未执行节点的输出确认引用的是当前节点之前已执行过的上游变量模板转换输出出现莫名字符Jinja2 语法写错检查模板里变量名大小写和括号是否匹配改了画布但运行没变化改的是草稿没发布确认发布到最新版本后再外部调用运行失败但不知道在哪没有看节点状态点运行历史逐个节点查日志和错误信息5.2 三条不建议这几条是带团队后总结的实战心得每条后面都是踩过坑换来的。第一条不建议让 LLM 直接输出 JSON 然后交给代码节点硬解析。大模型输出的 JSON 偶尔会夹带解释文字或格式漂移一解析就崩。如果你确实需要结构化输出用 Dify 提供的参数提取节点或者要求模型严格输出 JSON 后再在代码节点里做好异常兜底。新手阶段干脆先避开这个组合。第二条不建议把一个应用做成几十个节点的巨型工作流。工作流适合表达总流程不适合把企业全部业务规则塞进一张图。节点太多以后调试成本呈指数级上升。建议把复杂任务拆成多个工作流通过 API 互相调用。第三条不建议把密钥、Token 明文写在代码节点或 HTTP 请求里。工作流做出来是要发布给团队用的明文凭据一旦跟着日志流出就是安全事故。敏感信息走平台的密钥管理或环境变量。5.3 运行历史与版本发布Dify 工作流里的运行历史是一个非常实用的功能。每次试运行都会留档包括节点执行顺序、每个节点的输入输出、耗时和 Token 消耗。我当时排查一个“慢工作流”就是靠运行历史里各节点的耗时发现耗时都卡在知识检索节点上后续调整了检索配置速度才降下来。发布这个动作也很重要。你改完画布后并没有真正影响正在外部调用中的工作流必须点“发布”才会成为新版本。发布之后外部 API 调用才会切到最新版本。我的工作习惯是改小功能后频繁发布但每次发布前一定先跑测试输入确认两条分支、关键节点都没问题。哪怕只改一个 Prompt 措辞我也会跑一遍再发。6. 工作流用熟了之后还能往哪走6.1 发布成 API接进你的业务系统很多教程到“画布跑通”就结束了。但工作流真正的价值在接入业务系统的那一刻才显现。在 Dify 的“访问 API”菜单里创建工作流对应的 API 密钥后你就能获得一个接口地址和密钥。外部系统只需要把开始节点定义的输入字段作为参数POST 到接口就能拿到结束节点输出的结果。这里给一个简单的调用示意方便你理解形状curl -X POST \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { inputs: { name: 张三, weekly_points: 完成需求评审上线了订单模块修复 3 个线上问题, completion_rate: 65 } } \ https://your-dify-host/v1/workflows/YOUR_WORKFLOW_ID/run实际部署时这股信息会从公司内部的工单系统、客服系统甚至定时任务里发送过来。工作流从“画布上的一个玩具”变成了“业务系统里一个可调用的 AI 程序”这一步是质变。6.2 往后扩展的三个方向入门篇最后给你三个扩展方向都是真实项目中用得最多的。第一个方向是知识检索节点。把业务资料接入知识库然后在工作流里加一个知识检索节点把召回结果作为上下文传给 LLM 节点。这是目前最主流的企业落地形态适合做“内部知识问答助手”。第二个方向是迭代节点。当你面对一个数组比如几十篇文本需要逐个打标签手动拖一串节点显然不现实。迭代节点能让同一套处理逻辑循环执行适合批量场景。第三个方向是 HTTP 请求节点和代码节点。HTTP 请求可以对接内部的外部接口代码节点可以处理复杂的格式转换、数据清洗。这两个节点让工作流不再局限在 Dify 平台内部而是能真正和现有系统联动。这三个方向建议你先把基础节点熟练之后再一个一个尝试。入门阶段最重要的是把“输入 → 处理 → 输出”这个循环刻在脑子里。6.3 一点个人体会最后说几句实在话。我做 Dify 工作流也有一段时间了最大的感受是可视化编排真正改变的不是“写代码的方式”而是团队讨论 AI 逻辑的方式。以前讨论一个 AI 功能大家只能盯着 Prompt 文本争论谁改了哪里、为什么改全靠口头沟通。现在大家盯着一张画布业务说“这里应该先查知识库再生成”开发说“这个分支条件写错了”完全是在用同一个语言沟通。这种变化在项目协作里太重要了。如果你也想上手我的建议是不要一上来就做复杂的客服机器人先从手边一个重复性任务开始。比如周报生成、日报整理、会议纪要提炼先搭一个“小而美”的工作流跑通、发布、接 API然后自然就会冒出更多想法。我自己的感觉是理解工作流的那天你才真正开始把大模型当成一个可以“安排”的同事而不是一个偶尔靠谱的聊天机器人。

Dify工作流保姆级教程：从黑盒Prompt到可视化AI流水线

相关推荐

Wireshark实战指南：从抓包到解密，快速定位网络故障

YOLOv3实时目标检测：危化品车辆货物识别工程实践

众筹平台开发实战：基于SpringBoot和Vue3的完整设计与部署指南

更多资讯

Hive函数实战大全：场景分类、核心用法与避坑指南

基于YOLO的苹果采摘点识别：从果实检测到枝条分割的完整算法链路

PLC灌装系统实操指南：I/O映射、梯形图逻辑与联调避坑

基于S7-1200的桥式起重机PLC控制系统工程实践

单片机教学闭环试卷：从寄存器操作到硬件时序验证

OpenHarmony上RN滑动删除：GestureResponder完整实践指南

今日更新

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？