一条工单被自动分进了「退换货」，实际是「发票问题」。客服点了退回，重走一遍流程，前后多花四分钟。这种事在一套接了人工智能的系统里几乎天天发生，算不上事故，也就没人记录。
错误不是故障，是系统的常态输出
传统软件的错误可以复现：同样的输入，跑出同样的结果，顺着日志就能定位到那一行代码。模型不是这样。它给出的是一个倾向，倾向在边界附近会抖。同一个问题换个说法，落脚点可能就不一样。团队常常把这类现象说成「模型不稳定」，其实是把概率系统当成确定性系统在用。
所以第一个要做的决定不是换模型，而是定阈值：哪些情况允许它自己走完，哪些必须转给人。阈值调高，人工负担回来了；调低，错误就流到下游。这个取舍没有技术解，只有业务判断，得由最清楚代价的人来定，而不是交给调参的人顺手决定。
最容易出问题的是交接那道缝
人机之间的衔接，比模型本身更值得盯。转人工时信息丢没丢，人能不能看到模型依据的原文，改过的结果有没有回流。这些细节决定了人工是在「复核」还是在「重做」。见过一些项目，模型指标不差，但一线宁可不碰，原因往往不是准确率，而是它让人多干了一步活。
- 转人工时是否携带完整原始上下文
- 人工修改是否被记录，能否回灌到评估里
- 有没有一份能回放的日志，事后说得清当时发生了什么
评估集比模型更花时间
供应商给的效果说明，通常来自公开数据或自家场景。真正有用的是自己攒的那几百条，来自真实工单、真实对话，包含那些让人头疼的模糊情况。这批东西要持续维护，因为业务在变，用户说话的方式也在变。模型更新一次，评估集就得跑一遍，否则你分不清是变好了，还是只是变了。
把「它不做什么」写出来
用久了会发现，团队对人工智能的信任不是靠一次汇报建立的，而是靠一次次「这件事它确实做得不错」累积起来。反过来，一次没解释清楚的错误，能耗掉几个月的信任。所以边界要写出来，写在文档里，也写在界面上——让使用者知道它在什么情况下会犹豫，比宣称它有多能干更管用。
回到那条工单。它的价值不在于被修好，而在于有没有人把它挑出来，放进下周的评估集。系统是慢慢变准的，靠的就是这种不起眼的动作。