Dify 工作流实战：用 Workflow 编排一个可控的 AI 自动化处理流程

公众号：码海寻道

在前面的文章中，我们已经介绍了 Dify 的平台能力、应用类型选择，以及如何用知识库搭建 RAG 问答应用。

如果说 RAG 解决的是"让模型基于企业知识回答问题"，那么 Workflow 解决的就是另一个更工程化的问题：

复制代码

如何把大模型能力放进一个可控、可观测、可复用的自动化流程里？

很多 AI 应用并不是简单问答，而是由多个步骤组成。例如先接收一段文本，再判断类型，然后提取关键信息，接着生成摘要，最后输出结构化结果。如果全部依赖一次 Prompt，流程会越来越难维护。

Dify Workflow 的价值就在于：用可视化节点把 AI 任务拆成多个明确步骤，让每一步的输入、输出、条件和异常都更加清晰。

这篇文章就以一个"用户反馈自动分析流程"为例，讲清楚如何使用 Dify Workflow 编排一个可控的 AI 自动化处理流程。

1. 为什么需要 Workflow

在大模型应用早期，很多需求都可以用一个 Prompt 快速完成。

例如：

复制代码

请总结下面这段用户反馈，并判断它属于功能建议、Bug 反馈还是投诉。

这种方式适合原型验证，但当业务要求变复杂后，单 Prompt 会暴露出很多问题：

• 流程不清晰：所有逻辑都写在一段提示词里，后期难以维护。
• 中间结果不可见：不知道模型在哪一步判断错了。
• 异常不好处理：输入为空、内容无关、分类失败时缺少兜底路径。
• 输出不稳定：模型可能没有严格按照预期格式返回。
• 难以复用：某个步骤无法单独复用到其他流程中。

Workflow 的核心思路是把复杂任务拆成多个节点，每个节点只负责一件相对明确的事情。

例如：

复制代码

输入用户反馈
→ 判断是否有效反馈
→ 提取关键信息
→ 分类反馈类型
→ 判断优先级
→ 生成处理建议
→ 输出结构化结果

这样一来，流程更容易调试，也更适合接入生产系统。

2. Workflow 与 Chatflow 的区别

在 Dify 中，Workflow 和 Chatflow 都属于可视化编排能力，但它们的侧重点不同。

能力	Chatflow	Workflow
主要场景	多轮对话	单轮自动化流程
是否强调会话记忆	是	否，通常一次执行完成
用户交互	多轮输入与引导	一次输入或系统调用
流程目标	管理对话路径	管理任务处理链路
典型用途	分支客服、问诊、交互式表单	报告生成、数据分析、批处理、后端 AI 流水线

简单来说：

复制代码

需要和用户来回对话，用 Chatflow。
需要把一个任务自动处理完，用 Workflow。

如果你的应用更像"用户问一句，系统内部跑一套处理流程，然后返回结果"，通常更适合 Workflow。

3. 本文实战目标

我们要设计一个"用户反馈自动分析流程"。

输入是一段用户反馈文本，例如：

复制代码

最近更新后，导出报表经常失败，页面提示网络异常，但我换了网络也不行。这个问题影响月底汇总，希望尽快修复。

Workflow 需要输出：

• 反馈摘要。
• 反馈类型。
• 影响程度。
• 优先级。
• 建议处理部门。
• 建议回复话术。
• 结构化 JSON 结果。

这个场景很适合 Workflow，因为它有明确的处理步骤，而且结果通常要进入后续系统，例如工单系统、客服系统或运营后台。

4. 整体流程设计

可以把流程设计为以下节点：

复制代码

Start 开始节点
→ 输入校验节点
→ LLM 信息提取节点
→ LLM 分类节点
→ IF/ELSE 优先级判断节点
→ LLM 回复建议节点
→ 模板整理节点
→ End 结束节点

每个节点的职责如下：

节点	作用
Start	接收用户反馈文本
输入校验	判断输入是否为空或无意义
信息提取	提取产品、问题、影响范围、用户诉求
分类节点	判断反馈属于 Bug、功能建议、投诉或咨询
优先级判断	根据影响程度判断 P0/P1/P2/P3
回复建议	生成客服或运营可用的回复话术
模板整理	统一输出格式
End	返回最终结果

Workflow 的关键不是把节点堆得越多越好，而是让每个节点承担清晰职责。

5. 第一步：创建 Workflow 应用

进入 Dify 后，可以新建一个 Workflow 类型应用。

建议命名为：

复制代码

用户反馈自动分析 Workflow

命名最好体现业务对象和流程目标，而不是只叫"测试工作流"。后续应用多了之后，清晰命名会非常重要。

创建后，首先关注三个部分：

• 输入变量：流程需要接收哪些数据。
• 节点编排：每一步如何处理。
• 输出结果：最终给调用方返回什么。

6. 第二步：设计 Start 输入变量

Start 节点负责接收流程输入。

对于本文示例，可以设计以下变量：

变量名	类型	说明
feedback_text	String	用户反馈原文
user_type	String	用户类型，例如免费用户、付费用户、企业客户
product_module	String	反馈所属模块，可选
source_channel	String	来源渠道，例如客服、表单、社群

最核心的是 feedback_text。其他字段可以帮助模型更准确判断优先级和处理建议。

例如企业客户反馈的问题，可能需要比普通用户反馈更高优先级。

输入设计要遵循一个原则：

复制代码

后续节点需要用到的信息，尽量在 Start 节点明确接收，不要让模型凭空猜。

7. 第三步：输入校验节点

很多自动化流程忽略输入校验，直接把原始内容交给大模型。这样容易产生无意义输出。

输入校验可以处理以下情况：

• 内容为空。
• 文本过短。
• 明显不是用户反馈。
• 包含无关内容。
• 缺少可分析信息。

如果 Dify Workflow 中使用条件判断节点，可以设计类似规则：

复制代码

如果 feedback_text 为空或长度小于 10：
返回"反馈内容过短，无法分析"。

否则：
进入信息提取节点。

输入校验的价值是把明显无效的请求挡在前面，避免浪费模型调用成本。

8. 第四步：信息提取节点

信息提取节点可以使用 LLM 节点完成。

这个节点的目标不是生成完整回答，而是从反馈中提取结构化信息。

Prompt 可以这样设计：

复制代码

你是一个用户反馈分析助手。
请从用户反馈中提取关键信息，并严格按照 JSON 格式输出。

需要提取的字段：
- summary：一句话总结反馈内容
- product_module：涉及的产品模块，如果无法判断则输出 unknown
- problem_description：具体问题描述
- user_impact：对用户造成的影响
- user_expectation：用户希望得到的结果

用户反馈：
{{feedback_text}}

期望输出示例：

复制代码

{
  "summary": "用户反馈报表导出经常失败，影响月底汇总",
  "product_module": "报表导出",
  "problem_description": "导出报表时提示网络异常，切换网络后仍无法解决",
  "user_impact": "影响月底数据汇总工作",
  "user_expectation": "希望尽快修复导出失败问题"
}

这里建议强制模型输出 JSON，因为后续节点可以基于字段继续判断，而不是从一段自然语言中再次解析。

9. 第五步：反馈分类节点

分类节点同样可以使用 LLM 节点，也可以结合规则判断。

常见反馈类型包括：

• Bug 反馈。
• 功能建议。
• 使用咨询。
• 体验投诉。
• 账号或权限问题。
• 其他。

Prompt 示例：

复制代码

请根据用户反馈内容判断反馈类型。

可选类型：
- bug：功能异常或错误
- feature_request：希望增加或改进功能
- consultation：使用咨询
- complaint：负面体验或投诉
- account_permission：账号、登录、权限相关问题
- other：无法归类

请只输出 JSON：
{
  "category": "类型编码",
  "reason": "分类原因"
}

用户反馈：
{{feedback_text}}
已提取信息：
{{extracted_info}}

对于生产流程，分类结果最好使用固定枚举值，方便后续系统处理。

不要让模型自由输出"这个问题看起来像是比较严重的导出异常"这种无法稳定解析的句子。

10. 第六步：优先级判断节点

优先级判断可以由规则和模型共同完成。

例如可以先定义一套优先级规则：

优先级	判断标准
P0	大面积不可用、核心链路中断、数据安全问题
P1	重要功能不可用，影响付费客户或关键业务
P2	局部功能异常，有临时替代方案
P3	体验问题、轻微建议、低频问题

可以让 LLM 根据规则输出建议优先级：

复制代码

你是一个产品支持优先级判断助手。
请根据反馈内容、用户类型和影响范围判断优先级。

优先级规则：
P0：大面积不可用、核心链路中断、数据安全问题
P1：重要功能不可用，影响付费客户或关键业务
P2：局部功能异常，有临时替代方案
P3：体验问题、轻微建议、低频问题

请只输出 JSON：
{
  "priority": "P0/P1/P2/P3",
  "reason": "判断原因"
}

用户类型：{{user_type}}
反馈内容：{{feedback_text}}
提取信息：{{extracted_info}}
分类结果：{{category_result}}

如果 Dify Workflow 支持 IF/ELSE 分支，可以在优先级之后加入条件判断：

复制代码

如果 priority 为 P0 或 P1：
进入高优先级处理路径。

否则：
进入普通处理路径。

这样可以把关键问题和普通问题分流。

11. 第七步：回复建议节点

自动化流程不仅要分析问题，还可以生成客服或运营人员可直接使用的回复建议。

Prompt 可以这样写：

复制代码

你是一个专业客服支持助手。
请根据用户反馈和分析结果，生成一段回复建议。

要求：
1. 语气礼貌、专业。
2. 不承诺无法确认的修复时间。
3. 如果是高优先级问题，说明会尽快同步技术团队排查。
4. 如果信息不足，引导用户补充必要信息。
5. 字数控制在 120 字以内。

用户反馈：{{feedback_text}}
分类结果：{{category_result}}
优先级：{{priority_result}}
提取信息：{{extracted_info}}

示例输出：

复制代码

您好，已收到您关于报表导出失败的反馈。该问题可能影响月底数据汇总，我们会尽快同步技术团队排查。为便于定位，请补充导出时间、报表类型以及是否所有报表均失败。感谢您的反馈。

这个节点的输出可以给客服人员参考，而不是直接自动发送。生产环境中，是否自动发送要看业务风险。

12. 第八步：统一输出结构

Workflow 最终输出建议使用结构化格式，方便被外部系统调用。

例如：

复制代码

{
  "summary": "用户反馈报表导出经常失败，影响月底汇总",
  "category": "bug",
  "priority": "P1",
  "product_module": "报表导出",
  "user_impact": "影响月底数据汇总工作",
  "suggested_owner": "技术支持/产品研发团队",
  "reply_suggestion": "您好，已收到您关于报表导出失败的反馈......",
  "need_human_review": true
}

这里有一个关键字段：need_human_review。

对于高优先级问题、敏感问题或模型不确定的问题，建议进入人工审核，而不是完全自动处理。

结构化输出的好处是：

• 后端系统容易解析。
• 可以直接生成工单。
• 可以用于数据统计。
• 可以作为后续流程的输入。
• 更容易做自动化测试。

13. 第九步：加入异常兜底

可靠的 Workflow 不能只考虑正常路径，还要考虑异常路径。

常见异常包括：

• 用户输入为空。
• 模型输出不是合法 JSON。
• 分类结果不在枚举范围内。
• 优先级判断缺失。
• 外部工具或 API 调用失败。
• 知识库检索无结果。

可以设计兜底策略：

异常情况	处理方式
输入为空	直接返回输入无效
JSON 解析失败	要求模型重试或进入人工处理
分类未知	标记为 other，并进入人工审核
高风险内容	设置 need_human_review 为 true
工具调用失败	返回错误状态并记录日志

自动化不是不需要人工，而是把人工放在最需要判断的节点上。

14. 第十步：测试 Workflow

Workflow 搭建完成后，需要准备测试用例。

建议覆盖以下输入：

14.1 正常 Bug 反馈

复制代码

导出报表一直失败，提示网络异常，影响月底汇总。

期望结果：

复制代码

category = bug
priority = P1 或 P2
need_human_review = true

14.2 功能建议

复制代码

希望报表支持按部门批量导出，现在只能一个个导出，效率比较低。

期望结果：

复制代码

category = feature_request
priority = P3 或 P2

14.3 使用咨询

复制代码

请问在哪里可以修改账号绑定的手机号？

期望结果：

复制代码

category = consultation 或 account_permission
priority = P3

14.4 无效输入

复制代码

你好

期望结果：

复制代码

返回输入信息不足，提示补充具体反馈。

14.5 敏感或高风险问题

复制代码

我们公司的所有客户数据都看不到了，后台页面一直报错。

期望结果：

复制代码

priority = P0 或 P1
need_human_review = true

测试时不要只看最终回答，还要检查每个节点的中间输出。Workflow 的优势就在于可以定位到底是哪一步出了问题。

15. 第十一步：发布为 API

Workflow 很适合作为后端 AI 流水线使用。

当流程稳定后，可以通过 API 方式被外部系统调用，例如：

复制代码

用户反馈表单
→ 后端服务
→ Dify Workflow API
→ 返回分析结果
→ 创建工单或写入数据库

API 集成时建议关注：

• 鉴权 Token 不要暴露在前端。
• 请求参数要在业务后端先校验。
• 记录请求 ID，方便追踪日志。
• 对失败响应做重试或降级处理。
• 高优先级结果不要直接自动执行高风险动作。

在生产环境中，Dify Workflow 更适合作为 AI 能力编排层，而不是替代全部业务系统。

16. Workflow 设计原则

结合上面的实战案例，可以总结几条设计原则。

16.1 一个节点只做一类事情

不要把信息提取、分类、优先级判断和回复生成全部塞进一个 LLM 节点。节点职责越清晰，越容易调试和复用。

16.2 中间结果尽量结构化

后续节点需要消费的内容，尽量使用 JSON 或固定字段。自然语言适合给人看，结构化数据适合给系统用。

16.3 关键判断要有规则

不要把所有判断都交给模型。优先级、权限、风险等级这类关键逻辑，应该有明确规则，模型只是在规则范围内辅助判断。

16.4 高风险动作要人工确认

涉及资金、权限、删除、通知客户、修改业务数据等操作时，不建议让 AI 自动执行。应该设置人工审核节点或业务系统确认。

16.5 先跑通小流程，再扩展复杂度

不要一开始就设计十几个节点。建议先跑通最小闭环，再逐步增加分支、工具和异常处理。

17. Workflow 适合哪些场景

Dify Workflow 适合以下类型的任务：

• 文档摘要生成。
• 用户反馈分析。
• 工单自动分类。
• 数据清洗与标签生成。
• 简历筛选与候选人摘要。
• 舆情分析与风险分级。
• 定时报告生成。
• 业务表单智能审核。
• RAG 检索后的结构化回答生成。

这些场景都有一个共同特点：流程相对明确，输入输出可以定义，结果需要被系统或人继续处理。

如果任务需要持续多轮交流，更适合 Chatflow。如果任务需要模型自主探索和调用工具，更适合 Agent。

18. 总结

Dify Workflow 的核心价值，是把大模型从"单次问答能力"变成"可编排的流程节点"。

通过 Workflow，我们可以把复杂任务拆成多个清晰步骤，并在每一步设计输入、输出、规则、分支和异常处理。

对于企业级 AI 应用来说，可控性往往比炫技更重要。

一个好的 Workflow 不一定节点很多，但一定要满足三个要求：

复制代码

流程清晰；
输出稳定；
异常可控。

当你需要把 AI 能力接入业务系统、自动化任务或后台流程时，Workflow 往往是比普通聊天助手和 Agent 更稳妥的选择。

这也是 Dify 从"快速搭应用"走向"工程化落地"的关键能力之一。