AI工单分错了，先改分类口径、补上下文，还是查路由？

先沿这张单保留五段记录：当时的标签定义、用户原始描述、业务参考判定、模型候选标签、实际进入的队列。哪两段开始出现差异，决定下一步该找谁处理。只保存最终分类名称，会把中间的问题压成同一种错误。

先看分类口径能否让人作出一致判断

下面的六条工单、标签规则与故意设置的输出均为编辑演示，没有调用模型。设本期只受理开票、账号访问、设备售后三类业务：开票处理发票申请与补发；账号访问处理登录和账号使用；设备售后处理设备运行问题。涉及多个诉求、信息不足或范围外的问题，另有处理状态。

标签字典最好同时写“包含什么”“容易与哪类混淆”“遇到什么先补信息”。例如把“其他问题”既当账号兜底类，又当所有未知事项的去向，人工标注就容易摇摆。先请业务人员分别判同一组输入，再核分歧；若两个人依据同一份规则仍给出不同类别，应先修改规则或明确例外。

微软的自定义文本分类生命周期文档将类别歧义、范围外数据和样本来源列为设计事项，并区分单标签与多标签任务。这里值得借鉴的是先确定要识别什么，再准备对应材料；企业自己的分类边界仍需业务负责人确认。

标签判对后，还要沿队列查下去

T02可以把排查范围明显缩小。核对当时送给模型的文字和返回标签后，再查标签怎样转换成队列：是否沿用旧名称，规则优先级是否改变，某条兜底规则是否先命中，人工改过标签后有没有重新路由。

Dynamics 365分类规则说明展示了一种具体机制：先依次执行分类规则集，再执行路由到队列的规则；前面写入的属性可被后面的规则使用。使用其他工单产品时，应找到对应配置与执行记录，按实际顺序复查。

修正队列映射后，继续核目标队列是否受理、是否有人接手。分类正确、路由正确和处理结束是三个不同的观察点；队列长期无人接收，应由服务负责人处理，而不是继续调分类提示。

把错分、缺信息和多诉求分别交给人处理

T01的参考类别明确，接下来要核模型实际收到的输入。若原文在传递时被截断，先修输入；若完整输入和规则都已送达，再检查提示、示例或模型输出。没有日志的地方保留待查，避免把修复动作建立在猜测上。

T05先需要上下文。补到了前一条“无法登录”之后，它才有条件进入账号访问分类。把这类短句全部归为模型错分，容易催出一种有害修正：系统开始对信息不足的工单大胆猜测。

T04则是任务设计问题。业务可选择拆成两张关联工单，或保留一个主任务加一个待办。无论采用哪种方式，都应让接手人看到另一个诉求及其去向，避免只处理登录后就关闭整单。

复查时看错往哪里分，别只看一个总数

固定输入、标签规则和参考判定，按类别汇总误分方向，才能发现开票是否常被分到账号，或者某个小类别一直被吞进兜底队列。scikit-learn混淆矩阵文档采用“行是参考类别、列是预测类别”的方向；记录时写明方向，便于复算。

多诉求、缺上下文和参考判定未决项应另列，并与全部输入数量对上。微软的分类评估说明也建议结合错分后果选择指标，尤其留意工单进入错误团队的影响。小类别里的严重错派，值得单独检查。

每项修复留下负责人和复查对象：业务修改标签边界，产品调整补问与多诉求状态，实施团队核输入和路由。修订后保留原失败例，也复看原本正常的T03这类输入，确认修错没有带来新的误分。

需要继续设计接收与交接时，可接着核对带上下文的人工接管。