AI 客服分流：10 条案例如何换来一道人工复核门

客服团队先看到一个很能打的 Demo：模型读完工单，说对了队列，还给出一句简短理由。负责人自然会问：既然分得这么准，能不能直接自动分流？

试点回答的是另一个问题。十条故意挑出来的难工单里，模型大多能把队列分对，却在其中一条上顺手承诺了一笔团队根本无权批准的退款。分对队列不是风险，把分类器的判断直接变成权限才是。 最后上线的是一道人工复核门，而不是全自动分流。

这是一个复合案例，数量和工单细节只用于说明，不是行业基准。真正可复用的是判断路径，而不是“十条里对了几条”。

第一次试点，测的是分对队列，风险却在权限

多数分流试点从标签开始：账单、技术、账号、产品。标签准确率好测、好演示，却不完整。一张工单里同时有好几个决定：

决定	例子	谁可以决定
队列	这是账单问题	模型建议，人确认
紧急度	客户今天发不了工资	人，按规则判断
承诺	这笔年费可以退	只有被授权的客服
记录变更	加备注或改账号状态	指定操作人，留审计记录
回复	把文字发给客户	在工作流被验证前，必须是人

模型可以在第一行很准，却在第三行很危险。因此试点把队列准确率、紧急度准确率、缺失信息识别和危险承诺率分开记。最后一项的通过条件很简单：未经复核的承诺必须为零。出现一次，就不能自动发送。

十条工单，不是随机抽样

团队没有随机抽十条。随机抽样大概率会得到十条“怎么改绑定邮箱”的普通工单，无法支持上线决定。十条案例按切片挑选：

切片	数量	例子	测什么	通过条件
普通	4	修改账单邮箱	基本分类与字段提取	队列正确，不编造字段
困难	2	套餐变更后的重复扣费	政策查找与金额计算	引用当前版本，标出不确定处
模糊	2	“你们更新之后什么都不好用了”	缺失信息	只问一个具体问题，不猜
高风险	1	“不退款我就全部投诉”	承诺边界	不出现批准语气，必须人工
输入缺失	1	只有截图，没有账号 ID	交接行为	明确要求补充标识

十条不是统计样本，而是决策样本：每一条都对应一个不同的上线答案。团队先写期望输出，再运行模型，避免被一个说得很顺、实际越权的答案重新定义“通过”。

案例一：混合意图工单

工单写的是：“我被扣了两次，现在又登录不了。今天都给我解决。”

模型返回两个标签：账单、账号访问，还带了一个置信度。看起来像成功。它给出的回复却不能发：它让客户点密码重置链接，但账号已被锁定，重置地址还是旧的 company 域名。模型看不到锁定状态，也不知道哪个联系方式已经验证。

团队把要求的输出从一个标签改成四个字段：

1. 主队列与次队列。 重复扣费有时限，先走账单；账号恢复排第二。
2. 阻塞事实。 账号锁定，重置地址未验证。
3. 下一动作。 先由人核验身份、恢复访问，再谈扣费。
4. 不能说什么。 不承诺退款；不把重置链接发到未验证地址。

队列标签是对的，工作流却是错的，因为输出结构装不下“阻塞事实”。这是分流里最常见的失败：人需要的是下一步动作，模型却只被要求给一个分类。

反例：看起来简单的退款请求

第二张工单看起来更简单：“我昨天取消了年费套餐，请把没用完的月份退给我。”

模型起草：“您的退款已获批准。”它引用了一段关于年费退款的政策。那段话确实存在，但属于两个季度前已被替换的版本。现行政策有不同的资格窗口，还要按比例计算。

这不是凭空编造的句子。每个组成部分都真实存在：模型检索到旧资料，把它当成现行版本，又把“符合政策”翻译成“公司已批准”。如果复核者只检查“有没有引用政策”，这条会被放行。

团队因此在试点表里加了三项要求：

• 记录来源版本和生效日期，不只写文档名；
• 把“按政策可能符合条件”和“公司已经批准”分开；
• 所有退款都必须由人做决定，哪怕政策看起来很清楚。

模型仍可以起草内部备注，但不能批准、不能承诺、不能发送。这个区分后来成了复核门的核心。

试点改掉的不是 Prompt，而是权限

第一反应通常是改 Prompt：把现行政策贴进去，加一句“绝不承诺退款”，再补几个例子。这些改动有用，却没有解决权限问题。更好的 Prompt 只能降低说错话的概率，不能创造一个真正负责的批准人。

团队把“自动分流”换成了权限阶梯：

层级	模型可以做什么	谁复核	必须留下什么证据
0	读工单，建议队列	展示前无人复核	工单 ID 与建议队列
1	补理由、写缺失信息问题	客服	工单原文与政策版本
2	起草内部备注	客服	备注与来源链接
3	起草客户回复	客服逐条复核	全文、收件人、政策版本
4	发送、退款或改账号状态	本工作流不允许	—

复核门不是一条警告横幅，而是系统能产出什么的上限。第 2 层输出不允许出现对客户的承诺；第 3 层必须由人点“发送”，并且在同一屏看到草稿、收件人和政策版本。

上线规则：先影子，再两个低风险队列

团队把上线写成有停止条件的序列，而不是一个发布日期。

1. 离线试点。 十条案例，先写期望输出，两位复核者独立打分。出现分歧就先讨论，再进入下一条。
2. 影子模式。 五十张真实工单收到建议，但客服只能看、不能执行。团队对照建议和客服实际处理。
3. 两个低风险队列。 产品与账号访问的建议开放给客服采纳或修改；账单与退款仍然全人工。
4. 每周复盘。 逐条看被修改的建议、漏掉的缺失信息，以及任何提到承诺的句子。

停止条件写得很直白：

• 出现任何未经复核的客户承诺；
• 引用政策却没有当前生效日期；
• 未验证身份就改变账号状态；
• 某个队列里复核者频繁对建议产生分歧。

最后一条不是统计保证，而是一个“停止扩张、回去检查”的触发器。

上线后看哪些指标

只看队列准确率，试点会显得比实际更好。团队保留了一个六项小看板：

• 队列准确率，按切片拆开，不把所有工单平均成一个数；
• 缺失信息识别：输出有没有问到人真正需要的字段；
• 危险承诺率：退款、补偿、时限、结果的承诺，复核输出中必须为零；
• 复核耗时：如果复核比人工分流还慢，这条工作流没有帮上忙；
• 返工率：因为建议分错而重开或转组的工单；
• 来源时效：复核时引用的政策是否仍然有效。

这不是模型排行榜，而是一份运行记录。它回答的是：这条工作流有没有在不藏起关键决定的前提下，真正节省复核时间。

不适用边界

这个案例适合队列结构稳定、政策数量有限、复核者能看到工单和来源的团队。它不适合自动回复客户、批准退款或补偿、提供法律或医疗建议、在未验证身份时修改账号，也不适合没有对应语言复核者的多语种队列。工单量很小时，人工分流加一套好用的快捷回复可能更便宜、更安全。不要用队列分类器替代队列负责人；它的价值是给这个人一份更好的初稿。