客服问题别全塞进一段提示词：Dify 可以先分流，再找答案

把所有客服规则写进一段超长提示词，很快就会遇到一个麻烦：同一句“这个不能用了”，可能是在问操作方法，也可能是在申请维修。模型还没弄清问题属于哪一类，就已经开始组织回复了。

Dify 的问题分类节点提供了更直观的处理方式：先给不同类别写清描述，让模型判断用户输入应该走哪条路径，再接相应知识库或处理流程。对业务同事来说，这比把所有分支都藏在提示词里更容易讨论和修改。问题分类官方文档

分类名称短，判断条件可以写得更细

当前文档把类别标题和类别描述分开：标题用于画布上快速识别，描述才是模型选择分支时读取的规则。你可以把节点叫“售后”，同时在描述里说明它包含退货、维修和保修；“产品使用”则对应安装、操作和故障排查。

这项设计的实际价值，是让流程不必为了在画布上放得下，牺牲真正的业务边界。简短标签给人看，详细规则给模型读，两者各司其职。官方展示的客服示例也包括售后、产品使用和其他问题三类。

用一句自拟客户问题来理解：“刚收到，开机一直闪灯，想直接退掉。”它同时带着使用故障和退货意图，类别说明若只写“设备问题”，就很难分清优先路径。此时该补充的是业务处理规则，而不是只要求模型“分类更准确”。

Dify 的工作流可以把分类结果接到不同的知识检索或后续处理。使用问题需要操作手册，售后问题需要政策条件；两个分支即使共用一个大模型，也不该拿同一组资料回答。

这样设计后，流程里就多了可以具体检查的位置：问题是否分错，检索是否拿到错误版本，还是回答阶段漏了条件。Dify 还提供应用日志和观察能力，方便围绕实际请求回看，而不是只在提示词里反复补一句“不要答错”。项目核心能力

分类器输出的是一条路径，不是对退款、换货等业务动作的授权。遇到需要查订单或修改记录的流程，还要有身份、权限和相应确认安排。把“能回答退货条件”和“能替客户办理退货”分开，工作流才不会在最关键的一步模糊职责。

Dify 有云端与自部署路线，也能接不同模型服务；安装好平台仍需要配置模型和资料。其许可基于 Apache 2.0 但有附加条件，涉及多租户服务和前端标识时应读原文，不能直接称为无条件商用。许可说明

这类工具最有价值的变化，是把业务差异从一大段提示词里搬到能看见的流程上。分类、资料和回答各有自己的位置，团队才更容易对着同一个环节改同一个问题。