Dify工作流教程：从零搭建客户询问分流助手，附节点配置与测试样例

完成后，你输入一条虚构询问，得到工单编号、建议队列、处理状态和下一步。负责人仍需看原始询问，决定实际交给谁。这个练习不回答产品政策，也不判断退款资格。

官方区分Workflow的一次输入处理与Chatflow的逐轮对话。这里选择Workflow，便于检查一条输入走过哪些节点；需要连续追问时再评估Chatflow。本文依据2026年11月6日核对的Dify Cloud文档，自托管旧版的节点名称和界面可能不同。

在模型供应商设置中先确认模型可用。Dify Cloud可用额度与自带供应商凭证是不同计费来源；本练习不要求购买指定模型，也不假设你的账号有免费额度。

创建Workflow空白应用，命名为“询问分流练习”。在用户输入（User Input）节点添加下面两个字段。变量名按英文填写，显示标签可以用中文；下游要选你创建的变量，不能把变量名当普通文字手打。

本例是Workflow，分类器读取自定义message。不要照抄聊天类示例中的sys.query或userinput.query；后者是Chatflow的对话输入。测试空字符串时，先在输入层拒绝，不把它送给模型。空白字符也应在正式接入前单独校验。

画布上一共是1个输入、1个分类器、3个模板、3个输出。先核对每条分支都有下游，避免某个分类运行成功却没有结果。

把问题分类器的输入变量选为“输入 / message”，模型选择你已配置的文本模型。若模型支持temperature，可先设为0，方便对比样例；这个设置不保证分类完全确定。

添加三个分类，分别填标题与描述。当前官方文档把画布标题与模型读取的分类描述分开说明；模型判断主要依靠描述。不能只改标题，留下“分类1”这样的空泛描述。下表是本站为练习制定的规则。

如果界面提供Instructions（指令）字段，粘贴以下判定说明。旧版没有该字段时，把必要的优先规则写入分类描述，并重新测试；不要假定升级前后行为一样。

混合诉求进入人工判断，是本文的业务约定。你可以另定优先级，但要同时修改描述与参考样例。提示语能表达规则，不能形成可靠的安全隔离；本练习通过不接外部动作来限制误分类的影响。

每个模板节点都添加一个名为ticket_id的输入变量，值从变量选择器绑定到“输入 / ticket_id”。模板里的{{ ticket_id }}引用的是这个绑定；只把编号写在模板里不会自动建立绑定。

Dify模板节点使用Jinja2整理文本。本例的队列和处理建议固定写在模板中，不再加一个LLM节点生成答复。这样你可以分别检查“类别选对了没有”和“对应模板接对了没有”。

售前模板：

售后模板：

人工模板：

模板只引用工单编号，不重新拼接整段原始询问。接入工单系统时，用编号找回原文，避免在多处复制敏感内容；编号本身不证明调用者有权读取对应工单。

在三个输出节点各添加一个字符串变量，绑定对应模板的output。为各分支取不同的输出名，便于直接识别走过哪条路径，也避免多输出节点重名。

官方当前文档将这个节点称为Output，旧版可能显示End（结束）。Workflow可以执行到没有输出的分支，但调用方拿不到该分支结果。本例每条路径都配置输出。

运行T-001后，先看分类器实际选中的分支，再看售前模板输出，最后看完整流程结果。按本例应出现result_sales，不要求另外两个分支产生空字符串。如果分类正确却拿到售后文字，先查连线和输出绑定。

下面是T-001按本文规则应得到的结果示例，不是实际Dify运行回执：

以下8条是虚构教学数据。除空输入外，预期分类是供你比较的参考目标；本文没有在Dify实例上调用模型，因此没有宣称它们已经分类通过。每次运行后记录实际分支、输出变量、模型名称和失败原因。

建议记录格式如下。actual_route、actual_output_key和passed必须填你的实测，不能直接复制预期：

对T-004和T-006重复运行几次，检查混合诉求与规则改写是否稳定进入人工判断。有一次错误也要保留输入和节点记录，先修改描述或缩小范围，再用同一组样例重跑。八条样例只能帮助发现明显问题，不足以估计真实业务准确率。

本文在本地使用Jinja2核对了三份模板的正常编号渲染，以及缺少ticket_id时的严格变量校验，共6项。这只覆盖模板语法与字段绑定假设；不包含Dify界面连线、模型分类、API调用或真实业务接入。

先确认变量和路径正确，再比较模型，避免把连线错误误判为模型能力问题。若业务本身有确定字段，例如“已购买”来自订单系统，优先用可信字段和条件分支完成规则判断，模型只处理需要语义理解的部分。

画布里的测试完成后，如果想让表单、客服后台或内部工具提交询问，可以调用这同一个Workflow的应用API。这里继续使用前面的ticket_id、message和三个输出名，避免另外搭一套流程。以下按2026年11月10日核对的官方API文档编写；旧版自托管请以实例内的API说明核对。

先在应用内发布当前工作流，再创建这个应用的API密钥。/workflows/run执行的是已发布版本，画布里未发布的改动不会自动变成接口行为。本例从User Input开始；官方明确说明，触发器入口的工作流不能通过这个服务API执行。

应用密钥保存在你的服务端环境变量或密钥管理中。表单页面只调用你自己的后台，由后台验证用户并映射user标识后再请求Dify。user用于应用内区分终端用户，不代替你自己系统的登录和权限检查。不要让浏览器任意指定其他人的user。

在可信的服务端环境中准备Node.js 20或更新版本，把以下代码保存为call-workflow.mjs；下一段保存为同一目录下的parse-workflow.mjs。运行前通过系统的环境变量或密钥管理设置DIFY_API_KEY，自托管再设置DIFY_BASE_URL。示例没有提供或要求你公开真实密钥。

运行命令是node call-workflow.mjs。它只请求前文的分流工作流并打印内部交办建议，没有自动发送客户消息或修改订单。45秒是本文客户端示例的等待上限，按实际耗时调整，不代表Dify服务承诺；长流程应另行设计streaming事件读取。

解析函数把HTTP传输成功与流程成功分开。本例的三条分支互斥，因此要求恰好一个已知结果字段包含非空字符串；这项约束来自本教程，不适用于会同时输出多个并行结果的其他工作流。

按API端点文档，blocking响应的外层含workflow_run_id、task_id，实际状态和输出位于data内。Output节点说明页有简化的输出结构，接真实接口时应按Run Workflow端点的完整封套读取，不能直接取顶层outputs。

上面是为解释层级缩短的虚构响应，不是Dify实测回执；真实模板文字还包含下一步和请勿承诺事项。成功解析后应拿到run_id、output_name=result_sales与text。实际模型可能选错类别，接口成功不代表业务判断正确。

本站在本地用3种成功分支和7种异常响应检查了上面的解析函数，包括空结果、多个分支、失败、暂停和部分成功。没有调用你的Dify实例，也没有测量模型准确率、真实延时或计费；这些检查只证明示例解析逻辑按约定工作。

先用T-001到T-008逐条比较画布与API的输出，记录运行编号、实际分支与负责人判断。两处结果不一致时，先核对是否调用了同一发布版本及同一模型配置，再检查输入。把重复投递控制、登录校验和费用记录补齐后，再安排真实表单的小范围试用。

如果你需要回答“退款条件是什么”，先准备经业务负责人确认的政策资料，再学习知识库检索。不要让分类器兼任政策问答，也不要把它输出的售后标签当成已满足退款条件。

如果要把结果写回CRM或推送消息，先定义调用身份、字段、可写对象、重复提交处理和失败后的查询方式。本文没有配置这些节点；保持只生成内部建议，直到实际接入验证完成。