一句“改地址”卡住之后
用户在下单后想起地址写错，打开对话框输入：“刚下的单，还没发货，能改地址吗？”屏幕那头的智能客服回复：“请提供订单号。”用户补上订单号，又问了一遍。它继续提示“您可以在订单详情页修改地址”。用户点进去发现按钮是灰的，再问，得到的还是同一句。几分钟后，对话被转给人工，问题两句话解决。
这个场景不复杂，却暴露出一个常见错位：系统识别到了“地址”，也识别到了“订单”，但没有理解“还没发货”和“修改”之间的关系。它把一句带条件、带情绪的请求，拆成了几个关键词。于是回答看似相关，实际没有落到用户要办的事上。
问题往往不只在模型
讨论智能客服时，人们容易把注意力放在模型身上：参数、语料、回答是否流畅。真正进入业务现场，影响体验的环节要琐碎得多。意图边界是否清楚，槽位设计是否贴合流程，知识库有没有人持续维护，转人工的触发条件是否合理，都会改变一次对话的走向。
比如“改地址”并不是一个孤立意图。它依赖订单状态，也依赖支付状态和履约阶段。用户说“还没发货”，系统如果没有接入相应状态，只能按通用话术回应。再比如同一句“我要退款”，在不同商品、不同时间点对应不同路径。把这些差异交给一句万能回复，用户自然会觉得对方在绕圈子。
- 意图识别要能处理条件句，而不是只抓名词。
- 知识库要跟着业务规则更新，过期话术会制造新的误会。
- 转人工不是失败，而是复杂问题的正常出口。
把“答不上来”设计进去
我倾向于把智能客服看成一个需要长期维护的服务系统，而不是一次上线的功能。它的价值不在于把所有问题都挡在人工之前，而在于让简单问题顺畅完成，让复杂问题带着上下文抵达合适的人。用户不必重复描述，坐席也能看到前因后果。
这要求团队在设计时就承认边界：哪些问题必须问清条件，哪些状态必须实时查询，哪些表达容易触发误解，哪些情况下应该尽早交给人。对话日志也不只是用来统计解决率，它应该回到知识维护和流程调整里。否则，智能客服会变成一层礼貌的隔板，话说得客气，事情却没往前走。
回到开头那位用户，他需要的不是一段礼貌的解释，而是一个能判断“未发货可修改”的系统动作。智能客服要解决的，终究是这件事。