手搓一个客户评价处理工作流：让 Dify 把差评自动送到对的部门
用「两级分类 + 多路分流 + 变量聚合」的工作流，把散落在映美云打印平台各渠道的客户评价，自动分诊到品牌宣传、售后、运输 / 产品体验等对应部门。
引言：差评不可怕，"差评没人管"才可怕
做电商的都懂一个道理：客户评价不是给人看的，是给流程用的。
我所在的映美云打印平台，客户评价系统覆盖了线上线下、自营与经销的全渠道，评价从六个地方同时涌进来：
| 评价来源 | 评价类型 |
|---|---|
| 映美官方开放平台 | 开发者 / 集成商的对接反馈 |
| 映美官网售后服务 | 官网售后工单与回访评价 |
| SAP 系统 | 经销商评价 |
| 京东 | 店铺商品评价 |
| 淘宝 | 店铺商品评价 |
| 抖音商户平台 | 店铺商品评价 |
这六个渠道，其实对应三种完全不同的业务视角：自营电商（京东 / 淘宝 / 抖音商户平台）、经销体系（SAP 经销商评价）、开发者生态（开放平台）。它们本就该由不同的部门去接——这也正是这个工作流要解决的核心问题。
但现实往往是这样：
- 评价散在六个渠道，没有一个统一的入口
- 客户在评价里写了一大段话，没人第一时间看
- 等运营看到时，已经过了最佳处理时间
- 更糟的是，一个"物流太慢了，包裹被压扁了"的评价，被运营当成了"产品不好用"转给了产品部，转错了部门
- 或者一堆好评和差评混在一起，需要人工一条条筛
传统做法是"客服每天定时翻评价 → 人工判断 → 手动发到群里/系统"。本质还是人肉分诊。
而用 Dify 搭一个客户评价处理工作流，核心就是把"读懂评价 → 判断类型 → 分发给对应部门"这三步交给大模型和流程编排完成，人只需要处理那些真正需要判断的例外。
这篇文章完整记录我"手搓"这个工作流的过程——从整体架构到每个节点的设计取舍。它的链路很清晰，但里面藏着一个很多人第一次搭多分支工作流都会踩的坑（见第四节）。
一、整体架构：分类 → 分流 → 聚合
这是一个 Dify Workflow（不是 Chatflow）。工作流画布全貌如下：
为便于在纯文本环境快速理解，附一张文字版链路图：
用户评价（review）
│
▼
┌────────────────────────┐
│ QUESTION CLASSIFIER │ ← 一级分类
│ 正面评价 / 负面评价 │
└───────┬────────────┬───┘
│ 正面 │ 负面
▼ ▼
┌─────────────┐ ┌────────────────────────┐
│ HTTP REQUEST │ │ QUESTION CLASSIFIER 2 │ ← 二级分类
│ → 品牌宣传部门│ │ 售后 / 运输 / 其他 │
└──────┬──────┘ └──┬────────┬────────┬───┘
│ │ 售后 │ 运输 │ 其他
│ ▼ ▼ ▼
│ ┌───────────┐┌───────────┐┌───────────────┐
│ │HTTP REQUEST2││HTTP REQUEST3││HTTP REQUEST3(1)│
│ │→ 售后部门 ││→运输/产品体验││→ 人工介入 │
│ └─────┬─────┘└─────┬─────┘└──────┬────────┘
└────────────┴────────────┴─────────────┘
▼
┌──────────────────────────┐ ┌────────┐
│ VARIABLE AGGREGATOR │──▶│ 结束 │
└──────────────────────────┘ │ result │
└────────┘
核心思路只有一句话：先用大模型把评价分类，再根据分类结果分流到不同处理路径，最后把所有分支的响应汇流成一个结果输出。
这条链路有三个关键设计：
| 设计 | 作用 |
|---|---|
| 两级分类 | 先粗分（正面/负面），负面再细分（售后/运输/其他），避免一次分太多类导致误判 |
| 多路 HTTP 请求 | 每个类型对应一个部门系统接口，实现"自动转发" |
| 变量聚合器 | 把多个分支的输出合并成一个变量，让单一结束节点能接住所有路径 |
二、逐节点拆解
2.1 开始节点：只接一个变量
工作流入口只定义一个变量就够了：
review（String）——客户提交的、关于产品的评价内容
不额外设计复杂变量，因为这是个纯处理型工作流：输入就是一段评价文本，后面所有节点都基于 review 做文章。保持入口简洁，是这类工作流的通用原则。
2.2 一级分类：QUESTION CLASSIFIER（正面 / 负面）
这是整个工作流的"分诊台"，用的是 QUESTION CLASSIFIER 节点（模型选 gpt-3.5-turbo）。
它做的事情很纯粹：读 review，输出一个分类。分类定义如下：
| 分类 | 判定标准 |
|---|---|
| 正面评价 | 无明确抱怨，产品或服务体验正常或正面 |
| 负面评价 | 表达了不满、抱怨、投诉，或明确指出了问题 |
节点描述里有一句话很关键——"定义了一个用户问题的主题分类，主题定义了对应的处理方式"。也就是说，分类本身就是路由标签，分类结果直接决定后面走哪条路。
为什么用 Classifier 而不是让 LLM 自由输出？
很多人第一反应是"让大模型判断一下类型，输出一句话我再解析"。问题是：大模型的自由文本不稳定——它可能输出"我认为这是一条负面评价"，也可能输出"这条评价偏负面"，格式千变万化，下游根本没法可靠地做条件判断。
Classifier 节点的价值，就是把"分类"这件事变成结构化的、可枚举的输出。你把分类定义好，它只会输出你在列表里定义的类目之一。省事、稳定、还能省钱（分类任务不需要长输出）。
2.3 二级分类：负面评价再细分（售后 / 运输 / 其他）
负面评价不能一概而论——"售后处理慢""物流太慢""其他杂项"是三拨不同的人要管的事。所以负面评价会进入第二个 QUESTION CLASSIFIER 节点，再分一次：
| 分类 | 判定标准 | 去向 |
|---|---|---|
| 售后问题 | 抱怨售后服务、响应速度、处理结果等服务问题 | 售后部门 |
| 运输问题 | 抱怨物流速度、包裹破损、配送错误等物流问题 | 运输部门 / 产品体验部门 |
| 其他问题 | 无法归入以上两类、或情况复杂需要人工判断的评价 | 人工介入（问题汇总） |
为什么要分两级，而不是一次分五类？
如果一级分类就同时列出"正面/负面/售后/运输/其他"，模型在一个选择题里要同时权衡五件事，误判率会明显上升。分两级之后，第二级只需在"售后、运输、其他"里选一个，判断更聚焦、更准。
这也是分类任务的一个通用经验：类目越多，越应该分层。
2.4 四个 HTTP 请求节点：把反馈送到对的部门
这是工作流从"判断"走向"行动"的关键一步。每个分类分支后面，都挂着一个 HTTP Request 节点（GET 请求，均配置了失败重试 3 次），把结构化的反馈推送到对应部门/人员的系统：
| 节点 | 承接分类 | 推送目标 |
|---|---|---|
| HTTP REQUEST | 正面评价 | 品牌宣传部门 |
| HTTP REQUEST 2 | 售后问题 | 售后部门 |
| HTTP REQUEST 3 | 运输问题 | 运输部门 / 产品体验部门 |
| HTTP REQUEST 3 (1) | 其他问题 | 人工介入（问题汇总） |
这里有两个要点：
① 失败重试要配置。 外部接口难免抖动，统一设置"失败重试 3 次"，能有效降低因网络波动导致的漏处理。这是生产环境的基本要求。
② 请求参数最好带上原评价内容。 部门收到的不该只是一个"标签"，而应该是标签 + 原始评价文本，这样才能直接跟进处理。
③ "其他问题"留了人工兜底。 这是整个设计里很务实的一笔——不是所有评价都能被机器干净地分类。与其强行归到某一类里误伤，不如单独留一路"其他问题"汇总给人工，让兜底路径始终存在。
2.5 变量聚合器：多分支工作流的"汇流阀"（重点）
这是整个工作流里最容易被忽略、但最不能省的节点。
它要解决什么问题？——Dify 的结束节点（END）只能接收一条明确的输入。但我们的工作流分了四条支：正面评价、售后问题、运输问题、其他问题，各自走了一个 HTTP 请求。这四条分支的输出，怎么同时汇到一个结束节点？
答案是 VARIABLE AGGREGATOR（变量聚合器）。
它把各分支 HTTP 请求的响应聚合起来，统一输出为一个变量 result（String）。配置大致如下：
变量聚合器
├── 变量输入（各分支 HTTP 请求的响应体）
│ ├── HTTP REQUEST 的响应
│ ├── HTTP REQUEST 2 的响应
│ ├── HTTP REQUEST 3 的响应
│ └── HTTP REQUEST 3 (1) 的响应
└── 输出
└── result (String)
它的作用机制是：哪个分支真正执行了，就聚合哪个分支的输出——因为同一时刻只会有一条分支被激活，聚合器最终只会拿到一条有效响应。
一句话记住：分支越多，越需要一个聚合器在终点前"收口"。 没有它，多分支工作流根本无法合法连到结束节点。
这是很多人第一次搭多分支 Workflow 时必踩的坑：画了半天分支，最后发现结束节点接不上。
2.6 结束节点：输出处理结果
工作流以 END 节点收尾，输出一个 result 变量（String）——即前面聚合器汇总的处理响应。
到这里，"收到评价 → 分类 → 分发 → 返回结果"整个闭环就完成了。
三、分类节点的配置细节
Classifier 节点的效果，八成取决于分类定义的文案。这里给一份可直接参考的写法：
一级分类定义：
分类1：正面评价
判定标准：客户没有表达明确的不满或抱怨，评价内容为中性描述或正面肯定。
分类2：负面评价
判定标准：客户表达了对产品、服务、物流等方面的不满、抱怨或投诉，
或明确指出了存在的问题。
二级分类定义（仅对负面评价）：
分类1：售后问题
判定标准：不满或抱怨主要针对售后服务，如态度差、响应慢、沟通不畅、
话术敷衍、未解决问题、退换货处理不当等。
分类2：运输问题
判定标准：不满或抱怨主要针对物流运输，如配送慢、包裹破损、配送错误、
包装不当、丢件等。
分类3：其他问题
判定标准：不属于以上两类，或信息不足、情况复杂、无法明确归类的评价。
三条写法经验：
- 判定标准要写"包含什么"，而不是只写类目名。只写"售后问题"四个字，模型容易凭感觉猜；写清楚"抱怨售后态度、响应、处理结果……"，准确率会明显提升。
- 把易混情况写进标准。比如"包裹破损"到底算运输问题还是产品问题？提前在标准里明确，能减少摇摆。
- 分类之间要互斥。如果两个分类的判定标准有重叠，模型就会在边界案例上不稳定。
四、几个关键设计决策复盘
① 用 Classifier，不用自由生成的 LLM
前面说过，分类要的是可枚举、可判断的结构化输出。Classifier 天生为此设计——它把"分类"从一个开放问题变成了一个选择题。能把流程收敛成枚举的，就别留给自由文本。
② 分级分类，不搞"一次分四类"
每一步只做"二选一"，判断更聚焦。类目越多，越要分层——这是分类任务的通用经验，不只是 Dify 的技巧。
③ 分支必须有终点汇流
这是本篇最想强调的一点。多分支工作流在 END 之前统一经过变量聚合器，是所有多分支 Workflow 的标准结构。没有它，链路在终点会"散架"。
④ 重试是生产环境的底线
HTTP 节点全部配置"失败重试 3 次"。外部接口不稳定是常态，重试不是优化，是必需。
⑤ 输入极简，输出归一
入口只有一个 review，出口只有一个 result。中间再复杂，两端的接口都保持干净——这让工作流易于被其他系统调用（比如接在表单提交、工单系统之后）。
五、踩过的坑
| 坑 | 现象 | 解决 |
|---|---|---|
| 分类定义太笼统 | 模型在一级分类上摇摆，时对时错 | 判定标准写清"包含哪些表现"，把易混情况写明 |
| 类别不互斥 | "包裹破损"一会儿归运输、一会儿归售后 | 在分类标准里预先明确边界归属（并保留"其他问题"兜底） |
| 结束节点接不上 | 画完多分支后，发现 END 只能接一条线 | 在 END 前加变量聚合器统一收口 |
| HTTP 偶发失败 | 个别评价没推送到部门，且无感知 | 配置失败重试（3 次），必要时加重试上限告警 |
| 只推标签不推原文 | 部门收到"运输问题"，但不知道是哪条评价 | 请求参数带上原始 review 文本 |
| 三级以上分类 | 想一次分到"具体子问题"，类目爆炸、误判率高 | 坚持两级，需要更细时再按需增加层级 |
六、下一步可以怎么扩展
这套工作流跑通后，扩展空间很大：
- 回写与留痕：把分类结果和分发记录写入数据库/表格，形成"评价处理台账"，方便追踪每条差评是否闭环
- 情感强度分级：在负面评价里再加一层"严重程度"判断（轻微抱怨 / 严重投诉），让最紧急的先处理
- 自动生成回复草稿：分类之后，顺手让 LLM 生成一段针对性的回复话术，交给客服确认后发送
- 异常兜底分支：给"无法分类""空内容""含敏感词"等情况单独留一个兜底分支，转人工或标记待处理
- 定时汇总：结合定时触发，每天把当日评价的分类分布、未处理项汇总成一份日报
- 六个渠道统一入口：把开放平台、官网售后、SAP 经销商评价、京东、淘宝、抖音商户平台的评价汇聚到一个入口，统一走这条分诊链路——这也是映美这套评价系统下一步最该做的事
七、总结
回头看，这个客户评价处理工作流的精髓，就三句话：
- 分类即路由——把评价"读懂并归类"，分类结果直接决定它去哪
- 分级才准——每一步只做小范围选择，比"一次分五类"稳定得多
- 分支必汇流——多分支工作流在终点前一定要有变量聚合器收口
整个工作流只有一个入口变量、一个出口变量，中间是"一级分类 → 二级分类 → 多路 HTTP → 聚合"。结构不复杂，但该有的严谨都有：分类可枚举、边界可界定、失败可重试、终点可汇流。
先用最少的节点跑通"分类—分流—聚合"的闭环，再一点点把它变聪明——这就是"手搓"一个客户评价处理工作流的全部方法论。
本文工作流基于 Dify Workflow 搭建，两级分类均使用 QUESTION CLASSIFIER（gpt-3.5-turbo），四条分支通过 HTTP REQUEST 分别推送至品牌宣传、售后、运输 / 产品体验部门及人工处置流程，最终由 VARIABLE AGGREGATOR 聚合后经 END 节点输出。工作流服务于映美云打印平台的客户评价系统。 **：分类可枚举、边界可界定、失败可重试、终点可汇流。
先用最少的节点跑通"分类—分流—聚合"的闭环，再一点点把它变聪明——这就是"手搓"一个客户评价处理工作流的全部方法论。
本文工作流基于 Dify Workflow 搭建，两级分类均使用 QUESTION CLASSIFIER（gpt-3.5-turbo），四条分支通过 HTTP REQUEST 分别推送至品牌宣传、售后、运输 / 产品体验部门及人工处置流程，最终由 VARIABLE AGGREGATOR 聚合后经 END 节点输出。工作流服务于映美云打印平台的客户评价系统。
