晚上十点，用户想问一笔订单为什么还没更新。对话框里，系统迅速回复：“请提供订单号。”订单号给了，它又说：“请描述您的问题。”描述完，它回到开头。速度很快，事情没往前走。
这个场景点出智能客服的常见错位：把“响应”当成“解决”。回复及时当然重要，但用户真正需要的是把问题推进到下一个状态，而不是在礼貌的循环里原地打转。
快，不等于会收尾
一套对话系统通常要处理意图识别、知识检索和对话状态管理。大模型让表达更自然，也更容易生成看似完整的回答，但对话状态并不会自动变好。用户已经说过订单号，系统是否记住？前一句确认过的条件，后一句是否还用得上？如果每次回答都孤立生成，就会礼貌地重复。
问题常卡在“下一步”
很多用户并不需要一段政策解释，而是一个可执行动作：查进度、改地址、补充材料，或者转人工。智能客服要判断的信息不只是“用户问了什么”，还包括“现有信息够不够”“这件事系统能不能办”“办不了该交给谁”。这些判断依赖权限、流程和后台数据，单靠语言模型难以完成。
- 能否记住上下文，不在同一轮里反复收集相同信息；
- 能否给出明确下一步，而不是只复述规则；
- 能否在不确定时及时交给人工，并带上已收集的信息。
这三件事看起来朴素，却决定智能客服是否像一个负责的入口，而不是自动回复器。
“转人工”不是失败
有些团队把转人工视作未解决，于是尽量拖延。但对复杂问题，及时交接反而能减少重复。人工接手时看到前文，用户不必重讲；系统也能把已确认的信息整理清楚，避免交接变成又一次盘问。智能客服的价值不只在挡掉多少问题，也在把问题送到合适的位置。
衡量方式同样需要克制。只看响应时长，系统会越来越快；只看自助解决率，可能会把难问题推回用户。更合理的观察是：同一问题是否减少重复描述，交接是否顺畅，用户是否知道接下来会发生什么。这些不容易被一张看板概括，但更接近真实体验。
语言自然之后，责任要跟上
大模型让智能客服更会说话，也会更自信地给出模糊答案。哪些话可以说，哪些承诺不能给，哪些操作需要确认，应该由业务规则兜底。它不是把常见问答换成聊天框，而是把服务流程重新梳理一遍：信息从哪里来，判断依据是什么，出错后谁接手。
回到开头那个对话。用户要的不是更快地重复“请提供订单号”，而是一句“已看到您的订单，物流信息暂未更新，我帮您转接人工核查”。前者是响应，后者才是服务。智能客服要跨过的，正是这一步。