基于Dify的电商售后投诉处理工作流：从意图识别到工单生成

简介这份PDF资料面向售后服务管理者、客服技术支持人员及对智能客服系统感兴趣的从业者围绕基于Dify平台搭建消费者投诉处理智能助手展开旨在解决投诉响应慢、人工成本高、处理流程不统一等痛点。内容完整梳理了从用户提交投诉、AI意图识别与分类、知识库方案推荐、智能分流判断到工单创建传递、状态更新、人工介入及用户反馈优化的全链路设计并结合《消费者权益保护法》相关问答数据演示了提示词设计与外部工单API调用思路。资源包共1个PDF文件大小约1.17MB便于集中阅读与存档。目前已有173人学习关注。读者可从中获得一套可落地的智能投诉处理流程框架、意图识别与知识库结合的实操方法以及工单自动生成与人工协同的排错思路适合据此调整知识库与工作流适配不同企业售后场景。1. 售后投诉处理为什么需要一套 Dify 工作流电商售后团队最怕的不是投诉本身而是投诉进来之后没人接、接错人、反复问同一句话。一个典型的场景是用户提交“收到货三天就坏了要求退货”这条信息同时包含情绪、诉求、订单信息缺失三个问题。人工客服需要先安抚、再问订单号、再判断是否符合退货政策、最后生成工单转给对应部门。整个链路走下来平均处理时长经常超过 20 分钟高峰期积压严重。基于 Dify 平台的智能投诉处理系统核心思路是把这条链路拆成可编排的节点意图识别、情绪判断、信息补全、工单生成、路由分发。Dify 本身是一个支持可视化编排大模型应用的工具它把提示词工程、知识库检索、条件分支、外部 API 调用整合在一个工作流里。这套方案适合两类人一是售后团队的技术支持人员想用低代码方式快速搭一套自动分诊系统二是正在做 AI 客服选型的开发者需要评估 Dify 在工单管理场景下的边界和落地成本。接下来我会按“怎么搭、怎么调、怎么避坑”的顺序把可复现的步骤和参数配置拆开讲。2. 用 Dify 编排投诉处理工作流从意图识别到工单生成2.1 工作流整体结构与节点职责在 Dify 里新建一个“工作流”类型的应用而不是“聊天助手”。聊天助手适合单轮问答工作流才能做多节点串联和条件分支。整个投诉处理链路我一般拆成六个节点第一个节点是“开始”接收用户输入的原始投诉文本同时预留order_id、user_id、channel三个变量方便后续节点做条件判断。第二个节点是“意图分类”用一个大模型节点对投诉内容打标签输出complaint_type取值范围限定在“退货退款、物流异常、商品质量、服务态度、其他”五类。第三个节点是“情绪判断”同样用大模型节点输出emotion_level分“低、中、高”三档高情绪优先转人工。第四个节点是“知识库检索”挂载售后政策文档用于回答“能不能退”“多久到账”这类政策问题。第五个节点是“工单生成”用代码节点把前面提取的字段拼成 JSON。第六个节点是“条件分支”根据complaint_type和emotion_level决定走自动回复还是转人工工单。这里的关键设计原则是意图分类和情绪判断必须分开做。我见过不少团队用一个提示词同时让模型输出类型和情绪结果模型在复杂文本上经常只输出一个字段另一个字段丢失。拆成两个节点后每个节点的提示词更聚焦输出稳定性明显提升。2.2 意图分类节点的提示词与参数配置意图分类节点是整个工作流的入口判断提示词写得好不好直接决定后续路由准不准。我常用的提示词结构是“角色设定 分类标准 输出格式约束 兜底规则”。具体配置如下# 意图分类节点提示词模板在 Dify 大模型节点中直接填写 你是一个电商售后投诉分类助手。请根据用户输入的投诉内容判断投诉类型。 分类标准 - 退货退款用户明确要求退货、退款、换货 - 物流异常涉及发货延迟、快递丢失、配送错误 - 商品质量商品损坏、功能故障、与描述不符 - 服务态度投诉客服、售后人员态度问题 - 其他无法归入以上四类的情况 输出要求 只输出一个 JSON 对象格式为 {complaint_type: 分类结果, confidence: 0.0-1.0} 不要输出任何解释性文字。 用户输入{{input_text}}这个提示词里有两个细节值得注意。一是confidence字段虽然模型给的概率不一定校准但在置信度低于 0.6 时触发人工复核是一个低成本兜底策略。二是“不要输出任何解释性文字”这句必须加否则模型经常在 JSON 前后加“根据分析该投诉属于……”之类的废话导致后续代码节点解析失败。模型参数方面温度建议设 0.1 到 0.3意图分类不需要创造性。最大 token 数设 200 足够因为输出只有 JSON。如果用的是支持 JSON 模式的模型在 Dify 节点设置里打开“JSON 输出”开关能进一步降低格式错误率。2.3 工单生成代码节点的字段映射工单生成节点用 Dify 内置的代码执行器语言选 Python。它的作用是把前面节点输出的变量拼成标准化工单结构同时做一些字段补全和默认值处理。代码示例如下import json from datetime import datetime def main(input_text: str, complaint_type: str, emotion_level: str, order_id: str , user_id: str ) - dict: # 生成工单编号时间戳 用户ID后四位 ticket_id fTK{datetime.now().strftime(%Y%m%d%H%M%S)}{user_id[-4:] if user_id else 0000} # 根据投诉类型映射处理部门 dept_map { 退货退款: 售后审核组, 物流异常: 物流协调组, 商品质量: 品控组, 服务态度: 客服主管, 其他: 综合处理组 } # 情绪等级映射优先级 priority_map {高: P0, 中: P1, 低: P2} ticket { ticket_id: ticket_id, complaint_type: complaint_type, emotion_level: emotion_level, priority: priority_map.get(emotion_level, P2), assigned_dept: dept_map.get(complaint_type, 综合处理组), order_id: order_id if order_id else 待补充, user_id: user_id, raw_text: input_text, created_at: datetime.now().isoformat(), status: 待处理 } return {ticket_json: json.dumps(ticket, ensure_asciiFalse)}这段代码的逻辑说明ticket_id用时间戳加用户 ID 后四位保证唯一性同时方便人工追溯。dept_map和priority_map是两个映射表把模型输出的分类结果转成具体的部门名和优先级。order_id为空时填“待补充”而不是留空这样工单系统里能直接筛选出需要补信息的单子。参数说明input_text、complaint_type、emotion_level三个参数来自前面节点的输出变量在 Dify 代码节点里通过变量选择器绑定。order_id和user_id设为可选参数默认空字符串避免因为用户没提供而报错。返回值必须是 dictDify 会把ticket_json作为后续节点的输入变量。2.4 条件分支与转人工策略条件分支节点是整套工作流的“分流阀”。我的配置逻辑是情绪等级为“高”时无论投诉类型是什么直接转人工并标记 P0情绪等级为“中”且投诉类型为“退货退款”或“商品质量”时走自动回复加人工复核其余情况走纯自动回复。在 Dify 的条件分支节点里条件表达式支持变量引用和逻辑运算。具体配置成三个分支分支一emotion_level 高走“转人工”节点同时把工单优先级设为 P0。分支二emotion_level 中 and complaint_type in [退货退款, 商品质量]走“自动回复 工单入库”节点。分支三兜底分支走“自动回复”节点工单入库但不强制人工介入。这里有一个容易翻车的地方Dify 的条件分支默认按顺序匹配第一个满足条件的分支执行后就不再往下走。所以分支顺序必须把最严格的放前面。我一般把“高情绪转人工”放第一条避免高情绪投诉被后面的自动回复分支截胡。转人工节点可以对接外部工单系统的 API也可以用 Dify 的“HTTP 请求”节点把工单 JSON POST 到内部系统。如果只是做原型验证先用“变量赋值”节点把工单存到会话变量里后续在日志里查看也能跑通流程。3. 知识库检索与售后政策问答的接入方式3.1 售后政策文档的切片与索引策略Dify 的知识库功能支持上传 PDF、Word、Markdown 等格式的文档自动切片后做向量索引。售后政策文档的切片策略直接影响检索命中率。我试过两种方式按固定字数切片和按语义段落切片。固定字数切片比如每 500 字一段在政策文档上效果一般因为一条完整的退货规则可能被切到两个片段里检索时只召回半条信息。更稳妥的做法是先把政策文档整理成问答对格式每条政策一个独立段落段落开头用一句话概括核心规则。比如“退货时限签收后 7 天内可申请无理由退货15 天内可申请质量问题退货。”这样切片后每个片段语义完整检索时不容易断章取义。在 Dify 知识库设置里分段标识符可以选“换行”或自定义符号。我一般用 Markdown 的二级标题作为分段标识这样每个政策大类自然成为一个切片。索引方式选“高质量”模式虽然构建慢一点但召回准确率比“经济”模式高不少。Top K 设 3 到 5分数阈值设 0.5 左右低于阈值的召回结果直接丢弃避免模型拿不相关政策硬答。3.2 检索节点与生成节点的串联知识库检索节点在工作流里的位置很关键。我把它放在意图分类之后、工单生成之前。原因是只有涉及政策咨询的投诉才需要检索比如“退货要几天”“运费谁承担”这类问题。如果意图分类结果是“物流异常”检索售后政策文档基本没用反而增加延迟。具体串联方式是意图分类节点输出complaint_type后接一个条件分支判断complaint_type是否属于“退货退款”或“其他”。如果是走知识库检索节点把召回内容拼进提示词让模型生成回复如果不是跳过检索直接走工单生成。检索节点的查询语句不要直接用用户原始输入而是用意图分类节点提取的关键词。比如用户说“我买的鞋子穿了两次就开胶了能退吗”直接拿整句去检索可能召回一堆不相关文档。我一般让意图分类节点额外输出一个search_keywords字段把“开胶、退货、质量问题”这几个词提取出来用关键词去检索命中率更高。3.3 回复生成节点的提示词约束回复生成节点的提示词要同时约束三件事语气、信息准确性、不能承诺超出政策范围的内容。我常用的模板是# 回复生成节点提示词 你是售后客服助手。根据以下政策依据回答用户问题。 政策依据 {{knowledge_context}} 用户问题{{input_text}} 回答要求 1. 语气友好先回应用户情绪 2. 只依据政策依据回答不要编造政策 3. 如果政策依据中没有相关信息回复“这个问题需要人工核实已为您转接” 4. 回答控制在 150 字以内 回答这里knowledge_context是知识库检索节点的输出变量。第 3 条约束非常重要没有这条兜底模型在检索不到相关内容时会自己编一个“7 天无理由退货”之类的答案一旦和政策不符就是客诉升级。第 4 条控制字数是为了适配大部分客服渠道的回复框限制超过 150 字在手机端显示会被截断。4. 避坑与排查Dify 工作流落地时最容易翻车的五个点4.1 模型输出 JSON 格式不稳定导致代码节点报错现象代码节点执行失败日志显示json.loads解析错误模型返回的内容里混入了“好的以下是分类结果”之类的自然语言前缀。原因大模型在温度参数偏高或提示词约束不够强时会习惯性加解释性文字。Dify 的代码节点默认按 JSON 解析输入变量格式不对直接抛异常。解决三个措施叠加。第一提示词末尾加“只输出 JSON不要输出任何其他文字”。第二模型温度降到 0.1。第三在代码节点里加一层容错解析用正则提取第一个{到最后一个}之间的内容再解析。我一般会在代码节点开头加一段re.search(r\{.*\}, input_text, re.DOTALL)做兜底。4.2 知识库检索召回不相关内容导致答非所问现象用户问“退货运费谁出”模型回答“我们支持 7 天无理由退货”答非所问。原因知识库切片粒度太粗一个切片里混了多条政策检索时整段召回模型从里面挑了一句不相关的。或者 Top K 设太大召回了低分片段。解决把政策文档按“一条政策一个段落”重新整理切片粒度控制在 200 到 400 字。Top K 从 5 降到 3分数阈值从 0.3 提到 0.5。如果还是不准在检索节点前加一个“查询改写”节点用模型把用户口语化问题改写成标准政策查询语句。4.3 条件分支顺序错误导致高优先级投诉被自动回复现象用户明确说“我要投诉你们客服”情绪明显激动但系统走了自动回复分支没有转人工。原因条件分支的匹配顺序把“自动回复”放在了“转人工”前面或者情绪判断节点的输出值域和分支条件里的值不一致比如模型输出“高情绪”而分支判断写的是“高”。解决分支顺序强制把“转人工”放第一条。情绪判断节点的提示词里明确限定输出值为“高、中、低”三个字不要用“高情绪”“非常生气”这类变体。在分支条件里用精确匹配而不是模糊匹配。4.4 工单编号重复导致入库冲突现象同一秒内多个投诉进来工单编号后四位相同入库时主键冲突。原因ticket_id生成规则用时间戳到秒级高并发下会重复。解决在时间戳后加一个随机数或自增序列。我一般用datetime.now().strftime(%Y%m%d%H%M%S%f)取到微秒再加用户 ID 后四位重复概率极低。如果工单系统支持 UUID直接用 UUID 更省事。4.5 工作流节点过多导致响应超时现象用户提交投诉后等待超过 30 秒才收到回复体验比人工还差。原因工作流里串了太多大模型节点每个节点调用一次模型累加延迟。知识库检索如果索引构建质量不高检索本身也要几秒。解决合并同类节点。意图分类和情绪判断如果用的是同一个模型可以合并成一个节点输出两个字段虽然稳定性略降但延迟减半。知识库检索只在必要时触发不要每个投诉都走检索。另外在 Dify 应用设置里把超时时间从默认 60 秒调到 30 秒超时后直接走兜底回复避免用户干等。5. 进阶技巧用会话变量做多轮补全与效果验证5.1 用会话变量补全缺失的订单号投诉处理里最常见的情况是用户第一句话不带订单号。如果直接生成工单order_id字段是“待补充”后续人工还得再问一遍。用 Dify 的会话变量可以做到多轮补全在开始节点定义一个session_order_id变量工单生成节点检查这个变量是否为空为空时走一个“追问订单号”的分支把用户回复写入变量后再重新走工单生成。具体配置在“开始”节点添加会话变量session_order_id默认空字符串。工单生成节点前加一个条件分支判断session_order_id and order_id 。如果成立走“追问”节点输出“请提供订单号以便我们更快处理”。用户回复后用“变量赋值”节点把回复内容写入session_order_id然后连回工单生成节点。这样两轮对话内就能补全订单信息不需要人工介入。5.2 用日志和标注做效果验证Dify 自带日志功能每次工作流执行的输入、输出、各节点耗时都能看到。我一般每周抽 50 条日志做人工标注重点看三个指标意图分类准确率、情绪判断准确率、工单路由正确率。意图分类准确率低于 85% 时回去改提示词里的分类标准把容易混淆的案例加进去。情绪判断准确率低于 90% 时考虑换一个更大的模型或者加 few-shot 示例。标注数据积累到 200 条以上后可以在 Dify 的“标注”功能里把这些数据关联到应用上后续模型迭代时作为参考。这个习惯我坚持了半年意图分类准确率从最初的 72% 提到了 91%。没有标注数据提示词优化就是凭感觉调今天改好了明天又翻车。5.3 一个容易被忽略的参数最大迭代次数Dify 工作流里如果用了循环节点比如多轮追问一定要设最大迭代次数。默认值可能偏大用户如果一直不提供订单号工作流会反复追问既浪费 token 又惹恼用户。我一般设 2 次两次追问后还没拿到订单号就直接生成工单标记“信息待补”转人工处理。这个参数在循环节点的设置里叫“最大循环次数”设 2 到 3 比较合理。从那以后我每次搭 Dify 工作流都会先把超时时间、最大迭代次数、JSON 容错解析这三项配好再跑测试不然调试阶段能把你磨到没脾气。希望帮到你。本文还有配套的精品资源点击获取