做客服周报时，你是不是也遇到过这种场景：后台导出几百条"物流问题"工单，全被归在一个分类下。点开看，有的是包裹在中转站停了三天，有的是商家点了发货但运单号没同步，还有的是客户地址写错、快递员派送失败。它们在系统里长得一样，周报只能写"物流类投诉增加20%"，但哪个环节出了故障，没人能说清。
问题不能全怪数据，分类字段本来就不够细。客服在后台点分类时，通常只有几个选项，忙起来只能随手选一个。要找到改进方向，得回到用户原始描述里重新归类。
2026年，用大模型做这件事不需要算法工程师。下面这套流程适合几百条工单的团队；如果数据到几千条，把执行环节换到Dify或扣子这类平台上自动跑，思路不变。
开始前需要准备什么
- 能用联网的AI助手即可：文心一言、通义千问、Kimi、DeepSeek都行；工单量大就再准备一个Dify或扣子账号
- 一份最近30天已关闭工单的导出文件
- 一份一线客服确认过的最常见问题列表，用来校准分类
第一步：导工单，先做瘦身
从客服系统导出时，字段控制在五个以内：工单编号、渠道、用户原始描述、处理结果、处理人。别把整段会话记录直接扔给AI。用户和客服来回聊十几条，中间混着复制粘贴的话术和内部备忘，会让AI跑偏。
清洗动作：
- 只保留用户原话，客服的客套话删掉
- 姓名、手机号、地址等信息脱敏，地址保留到城市级
- 会话超过500字就把用户描述问题和客服答复之间的部分截出来
- 同一用户同一问题反复跟进的，只留第一张工单
第二步：分批喂给大模型
工单在100条以内，直接用AI对话窗口分批处理，每批30条左右。单条工单即使截断后也有几十上百字，一次塞太多会碰到上下文窗口上限，后半段内容被截断，分类就不准了。
工单在几百条以上，手动分批非常耗神。把Excel接到Dify或扣子的工作流里，按行读取，让大模型节点逐条处理。两个平台都有个人免费额度，跑一次月度分析基本够用，超出后的计费看官方价格页。如果团队对数据敏感，可以用Dify开源版自托管，模型换成可本地部署的开源模型，代价是需要一台带GPU的服务器。
提示词模板：
你是负责客服质检的数据分析师。下面每一条都是用户的原始问题描述。
请逐条处理：
- 从给定分类中选一个最合适的，不要新造分类
- 用不超过15个字的话概括客户说到的直接原因
- 原文信息不足时，分类填"其他-信息不足"，原因填"原文未说明"
分类：
物流-发货延迟，物流-中转停滞，物流-派送异常，物流-丢件，
售后-退换货操作困难，售后-退款到账慢，产品-质量问题，
产品-规格不匹配，账号-登录异常，其他
输出JSON数组，字段为id、category、reason，不要输出解释。
输入前给每条工单编上序号，AI输出的JSON里会带上id，合并时才不会乱。批次之间保持同一个提示词，不然格式容易变。如果AI把JSON包在解释性文字里，就在提示词末尾补一句"直接输出JSON，不要用markdown代码块"；有些模型对格式的服从度高，也可以换一个再试。
第三步：把标签合并成问题清单
AI输出的category标签只是入口，原因在reason里。以"物流-中转停滞"为例，里面可能混着两种原因：中转站超过48小时没有扫描，和运单号在揽收后就没更新。前者是转运中心的问题，后者是订单同步的问题，处理方式完全不一样。
这步建议人工完成，速度快，也保留判断力：
- 把每批AI输出的JSON粘贴到Excel，按id和原始工单合并
- 用数据透视表统计每个分类的数量
- 挑数量最多的三到五个分类，逐条看reason，把意思相近的归成一组
- 每组选一条最典型的原文，作为证据
- 分类：物流-中转停滞
- 共性问题：包裹在某个中转站超过两天没有扫描记录
- 典型原文（脱敏）："物流单从郑州发出后就一直停在中转站，到今天三天没更新"
如果你把满意度评分一起导出来，可以多做一个交叉观察：低分工单集中在哪几个根因上。有些原因数量不大但破坏性很强，这类问题更容易被平均值掩盖。
第四步：让结果落地成动作
分析做完，当场分配三件事，不然下周还是老样子：
- 高频共性问题写进客服知识库，附上统一话术，当天完成
- 占比最高的原因同步给对应业务负责人，一周内回复是否可调整
- 质检表里加一个检查项，下月抽检确认客服是否按新话术处理
整个流程跑熟后，把分类清单和提示词保存成模板，每月复用。下个月只需要更新导出文件。
如果这周只做一件事
抽半小时，选最头疼的那个分类，把最近30天的工单原文从头读一遍，按原因分成3到5组。你会发现自己能说出"问题主要出在哪个环节"，这已经比只盯着周报数字往前一步了。