很多人搭 Dify 工作流时，一开始会把所有用户问题都丢给同一个 LLM 节点：客户问价格、问售后、问合作、问投诉，最后都走同一套提示词。这样做上线很快，但一到真实使用就容易出问题：简单问题回答太重，重要线索没有提醒人工，敏感问题也没有兜底。
Dify 条件分支的价值，不是让流程图看起来更复杂，而是把不同意图的问题送到不同路径。官方文档里，If-Else 节点的作用是根据变量和条件，把工作流路由到 IF、ELIF 或 ELSE 分支；实际交付时，我们要做的是先把业务分流规则想清楚，再决定节点怎么连。
如果你还没有搭过完整工作流，可以先看 AI智能体与自动化专题 和 AI工具评测专题。如果已经用过 Dify 知识库、变量或 HTTP 请求节点，本文就是下一步：让流程开始具备稳定的判断能力。
Dify 条件分支适合解决什么问题
条件分支最适合处理“同一个入口，不同处理方式”的场景。例如一个本地商家客服入口，用户可能输入：
- “你们营业时间是几点？”这是常规问答，直接查知识库回答即可。
- “我想做一个月内容代运营，多少钱？”这是销售线索，应该提取预算、行业、联系方式。
- “上次服务没有按约定完成。”这是售后或投诉，最好进入人工审核。
- “帮我批量导出客户手机号。”这类请求可能涉及隐私或权限，应该拒绝或转人工。
如果这四类问题都走同一个提示词，LLM 可能会勉强回答，但业务动作会混在一起。条件分支的目标，是把“回答问题”和“决定下一步”拆开：先识别变量，再按规则分流。
先设计变量，不要先拖节点
很多 Dify 工作流不稳定，是因为变量设计太随意。Dify 的工作流变量可以来自用户输入、LLM 输出、API 返回或前面节点的结果，If-Else 节点再根据这些变量做判断。也就是说，条件分支不是凭空判断，它依赖前面节点给出的结构化信息。
一个客户咨询分流工作流，建议先准备这些变量：
intent_type：用户意图，例如 faq、quote、after_sales、complaint、unsafe。urgency：紧急程度，例如 low、normal、high。has_contact：是否留下手机号、微信、邮箱等联系方式。budget_range：报价场景下的预算区间。manual_review_reason：为什么需要人工确认。
这些变量可以由 LLM 节点先做分类，也可以通过表单字段、Webhook、HTTP 请求节点传入。老达建议新手先用“少量枚举值”开始，不要一上来让模型输出一大段自然语言解释。条件分支判断的是稳定值，不是作文。
一个可交付的分流结构
下面这个结构适合给本地商家、小团队知识库、AI客服副业项目做第一版交付：
- 开始节点收集用户问题、来源渠道和联系方式。
- LLM 分类节点输出
intent_type、urgency、has_contact。 - If-Else 节点按意图分流。
- FAQ 分支走知识库检索和标准回答。
- 报价分支走需求补全、预算判断和线索记录。
- 售后或投诉分支生成摘要，进入人工审核。
- 无法识别或高风险请求进入 ELSE 兜底路径。
这里有一个关键点：ELSE 不是失败路径，而是兜底路径。真实客户不会按你的表单说话，也不会每次都输入完整信息。只要没有命中明确条件，就应该给出保守回答，例如“我先帮你记录问题，请补充联系方式或等待人工处理”。
If、ELIF 和 ELSE 怎么分配
Dify If-Else 节点支持 IF、多个 ELIF 和 ELSE。实际使用时，不建议把所有条件都写成并列判断，而应该按业务优先级排序。
我的常用顺序是：
- 第一层先拦截风险：隐私、越权、投诉、需要人工确认的请求。
- 第二层处理高价值线索：报价、合作、预约、采购。
- 第三层处理标准问答：营业时间、服务范围、常见问题。
- 最后用 ELSE 承接模糊问题，要求用户补充信息。
这样做的好处是，重要问题不会被普通问答吞掉。比如用户说“你们上次没交付好，这次还想继续做要多少钱”，它同时包含投诉和报价。如果你先判断 quote，可能会直接进入报价分支；如果先判断 complaint 或 manual_review，就能把风险先交给人工。
条件不要写得太聪明
条件分支最常见的坑，是试图用一句复杂条件解决所有情况。例如：
intent_type contains 报价并且budget_range is not empty并且has_contact equals true。urgency equals high或manual_review_reason is not empty或intent_type contains 投诉。
这些条件不是不能用，但第一版最好保持可读。一个条件只承担一个判断，分支命名清楚，比把所有规则塞进一个节点更容易维护。客户后续改需求时，你也能快速解释“为什么这条咨询走了人工审核”。
如果你正在做 Dify 知识库问答，可以结合 Dify 知识库怎么搭 和 Dify 工作流变量怎么设计 两篇文章一起看。知识库解决“答什么”，变量和条件分支解决“该走哪条路”。
客户咨询场景示例
假设你给一家本地摄影工作室做 AI 客服，用户从网站表单进入 Dify。第一版可以这样配置：
- 用户输入：问题内容、服务类型、预计日期、联系方式。
- 分类节点：判断是套餐咨询、档期确认、售后问题还是其他。
- 套餐咨询分支：检索价格表和案例，回答后提醒留下日期。
- 档期确认分支：通过 HTTP 请求查询可预约日期，必要时转人工。
- 售后问题分支：生成问题摘要，不直接承诺赔偿，提醒人工跟进。
- 其他分支：给出简短回复，并引导用户补充服务类型和时间。
这类流程不需要一开始就做成庞大的 Agent。先把三四个高频分支跑通，再逐步增加外部 API、消息通知和人工审核。关于外部接口接入，可以继续看 Dify HTTP 请求节点教程；如果后面要和自动化工具组合，可以看 Dify 和 n8n 怎么一起用。
上线前怎么测试条件分支
Dify 条件分支上线前，至少要做四类测试。
第一类是正常命中测试。每个分支至少准备 3 条真实问题，确认它能进入正确路径。不要只测“我要报价”这种标准句，要加入口语表达，例如“做一个月大概要花多少”“能不能先给我个套餐”。
第二类是边界测试。让问题同时包含两个意图，观察优先级是否符合业务规则。比如“我要投诉，也想问续费价格”，应该先进入人工审核，而不是自动报价。
第三类是缺字段测试。用户没有联系方式、没有预算、没有具体服务类型时，工作流应该引导补充，而不是编造答案。
第四类是异常测试。分类节点输出空值、API 超时、知识库没有召回结果时，ELSE 路径要能给出稳妥回复。AI 自动化要交付给客户，最怕的不是分支少，而是异常时没有人接住。
交付时给客户看的检查清单
如果你把 Dify 条件分支作为 AI 自动化项目交付，建议附上这份清单：
- 每个分支的业务含义是否写清楚。
- 每个条件使用的变量是否有来源节点。
- ELSE 路径是否有兜底话术。
- 人工审核分支是否包含摘要、原始问题和联系方式。
- 高风险请求是否不会直接执行敏感动作。
- 客户是否知道后续新增分支的维护成本。
这也是 AI 副业项目和普通工具演示的区别。演示只要跑通一次，交付要保证客户明天、下周、下个月都能理解和维护。想继续做成可收费服务，可以参考 AI副业专题 里的交付思路。
老达建议：先做少分支，再做强分支
很多人一开始搭 Dify，会忍不住把流程图做得很大：十几个分类、几十条条件、多个外部系统。我的建议相反，第一版只做 3 到 5 个分支，但每个分支都要能解释、能测试、能兜底。
一个稳定的 Dify 条件分支工作流，应该让你很清楚地回答三个问题：这个变量从哪里来？这个条件为什么这样判断？没有命中时谁来接住？只要这三个问题能回答清楚，工作流就比“全靠一个大提示词”的方案可靠很多。
最后再补一句：条件分支不是替代 LLM，而是约束 LLM。让模型负责理解语义，让规则负责业务路径，这才是 Dify 工作流更适合交付的用法。
