凌晨的客服后台，一张关于账号权限的工单先被分到售后，又被转到技术，最后落到一个并不处理此事的队列。值班同事把记录翻出来看，模型给出的理由前后并不一致。类似的小事故，在实施复盘里并不罕见。它不戏剧化，却足够说明一件事：人工智能进入业务流程后，麻烦常常不在“能不能识别”，而在“识别之后由谁接住”。
先看模型这一侧。工单文本短、口语多，还夹杂截图和内部简称。训练时见过的表达，到了真实渠道就变了形。模型可能抓住“账号”这个词，却忽略“权限”背后的系统归属；也可能被一句“急”带偏，把优先级放到了业务类型前面。这类错误未必是能力不足，更像是任务定义没有收窄：到底要分的是部门、问题类型，还是处理时限？如果三件事混在一个标签体系里，输出看起来像分类，实际却是在猜。
流程里的空白，模型填不上
另一侧是流程。很多团队把人工智能当成一个前置分拣器，指望它把入口清理干净。可工单进入系统之前，往往已经经过群聊、电话、邮件几道转述，信息在传递中损耗。模型看到的是一段被压缩过的文本，却要承担完整判断。此时再高的准确率，也可能被一个缺失的字段拖住。我的判断是，先补流程里的空白，比继续调模型更划算：入口字段是否强制，内部简称有没有对照表，转派规则是否明确到可执行，这些工作不显眼，却直接决定模型输出有没有落点。
还有例外。正常工单容易处理，真正消耗人力的是那些边界模糊的请求：既像咨询又像投诉，既涉及产品又涉及权限。模型倾向于给出一个确定答案，因为分类任务要求它这么做；业务现场却需要保留“不确定”的出口。比较稳妥的做法，是让模型在置信度不足时主动交回人工，而不是硬分。这个动作听起来简单，落地时却常被忽略，因为团队更愿意看自动分派的量，而不愿意看被退回的量。可后者恰恰是系统是否可信的信号。
评估不能只看分对了多少
评估环节也容易走偏。只看整体准确率，会掩盖长尾问题的集中出现；只看单次结果，又看不到错误在流程里如何被放大。更实用的评估，可能要把“分错之后多久被纠正”“纠正成本由谁承担”“同一类错误是否重复出现”一起看。它们不漂亮，却接近真实运营。人工智能在这里更像一个需要持续校准的协作者，而不是一次上线就固定的工具。团队若没有固定的复核样本和复盘节奏，模型的表现会随着业务变化慢慢漂移，而人未必及时察觉。
- 入口信息是否足够完整，模型能否拿到判断所需的最小字段；
- 分类体系是否互斥，避免一个工单同时落入多个语义区间；
- 低置信度是否有明确的人工接管路径，而不是继续自动流转；
- 复核样本是否覆盖长尾场景，复盘是否形成可执行的规则调整。
回到那张被分错三次的工单。问题不只在模型，也在任务拆解、流程补位和评估口径。把人工智能放进企业流程，真正的门槛往往不是演示时的效果，而是日常运行中的缝隙有没有人负责。承认这些缝隙，再决定哪些交给模型、哪些留给人，可能比追求一次漂亮的自动分派更接近可用。