晚上十点，用户在页面上问：“上周买的杯子能不能换成别的颜色？”对话框很快回复：“亲，杯子有多种颜色可选。”字面没错，问题没解。类似场景里，智能客服常被当成“模型不够聪明”的证据；但把对话拆开看，模型只是链条中的一环。
先分清“听懂”和“接住”
用户输入先被归入某个意图，系统再决定查知识、走流程还是转人工。问题常出在意图边界：换货、改地址、催发货在口语里可能长得像，如果意图库只按关键词切分，模型再强也只能在错误的轨道上作答。另一个断点是“接住”——识别出意图后，后台有没有对应动作。没有订单接口，再准确的分类也只是一句礼貌回复。
知识库不是文档堆
不少团队把产品手册、活动规则直接灌进知识库，期待系统自己会答。实际使用中，用户问的是“我这种情况怎么办”，文档写的是“一般规则”。两者之间需要有人把条件、例外、时效拆成可检索的片段，并定期清理过期内容。知识维护听起来不性感，却决定回答是否落地。智能客服的上限，往往在对话开始前就被知识结构定住了。
上下文与转人工，别让用户重复自证
多轮对话里，用户已经说过订单号，系统下一句又问“请提供订单号”，信任会迅速下降。上下文不是把历史消息全部塞回去，而是保留与当前任务有关的槽位：商品、时间、诉求、已尝试动作。转人工也一样，交接时把摘要和未决问题带过去，比让用户从头讲一遍有效。这里考验的是流程设计，不是单轮回答的漂亮程度。
把“像人”换成“说清楚”
有些产品追求拟人语气，结果用户误以为对面能处理复杂诉求，期待落空后容易失望。稳妥的做法是明确身份和能力边界：能查什么、不能改什么、什么情况下转人工。语气可以自然，但不必伪装。智能客服的价值不在于骗过用户，而在于把常见问题快速闭环，把复杂问题体面地交出去。
一个可操作的检查顺序
- 先看用户问题是否被正确归类，错分则回到意图和语料。
- 再看归类后有没有可执行动作，缺接口就补流程，不急着换模型。
- 然后查知识片段是否有时效、条件和例外，过期内容及时下线。
- 最后看转人工交接是否保留上下文，别让用户重复描述。
这些环节都不新，也不炫，但它们决定一次对话能不能结束。模型迭代当然重要，只是当智能客服答非所问时，先别把问题全推给模型；很多时候，缺的是一张把业务、知识和交接串起来的流程图。