把AI大模型接进客服工单系统，演示阶段通常很顺利：问几个常见问题，回答得体，语气也稳。等到真正上线，麻烦换了个位置——不再是“它答得对不对”，而是“谁来确认它答得对”，以及这份确认的成本能不能被分摊掉。
长尾问题并不边缘
工单里大部分是重复问题，处理起来有章可循。但决定体验的，往往是那部分说不清楚的：用户描述含糊，情绪混在字缝里，一句话里塞了三件事。模型倾向于给出一个结构完整的回答，而完整和正确并不是一回事。工程上更值得花力气的地方，是让它把“不确定”摆到明面上——承认某段信息没找到，比多写两句漂亮话难得多，也更需要设计。
检索和生成之间的衔接
常见做法是把知识库片段拼进提示词，让模型基于材料作答。问题就出在这里：检索回来的段落可能过期，可能互相矛盾，也可能只是标题相似。模型不会替你判断哪份文件更新，它只会把看到的材料组织成通顺的句子。所以真正要补的不只是模型能力，还有知识管理方面的规则——文档有版本、有责任人、有失效时间，过期内容要能下线。这块工作不显眼，却直接决定回答的可信度。
评估没法一劳永逸
上线前拿一批标注问题测一遍，看起来稳妥，但线上问题的分布会漂移，今天的测试集明天就不够用了。更实用的做法是把人工坐席的修改记录留下来：改了什么、为什么改，这些痕迹本身就是下一轮的测试素材。目标不是追求一个漂亮的准确率，而是清楚它在哪类问题上容易出错，以及出错时有没有人及时处理。
人的角色在挪位置
坐席从“回答问题”慢慢转向“校对与兜底”。这个转变听着轻，实际对岗位要求更高：要能快速判断一段看似合理的表述哪里不对。培训、权限、责任划分都得跟着调整，否则出了问题只会变成互相推诿。反过来，如果把这些配套做扎实，AI大模型在重复劳动上的分担是实打实的，人的精力可以挪到真正需要判断的地方。
所以我的判断是：这类落地值得做，但预期应放在流程改造上，而不是把它当成一台即插即用的答题机。推进的快慢，更多取决于知识管理做到了什么程度，而不是又换了哪一版模型。