前阵子帮家里老人处理一笔退换货，点进在线客服，对话框先弹出一排选项：查订单、改地址、催发货、其他问题。老人想说的是“收到的锅盖裂了，但订单是别人代下的”，这句话在四个按钮里找不到落点。她点了“其他问题”，机器人回复：“请描述您的问题。”她照实打了一遍，对面回：“已为您转接人工，当前排队 12 人。”
这就是很多智能客服的真实处境。它没有答错，只是从头到尾没听懂人想问什么。
问题常常不在模型，而在问题本身
讨论智能客服时，人们习惯把注意力放在语言模型的能力上：能不能理解长句、能不能多轮对话、语气像不像人。这些当然重要，但落到企业实际部署里，决定体验的往往是更靠前的一步——业务方有没有把“要解决什么问题”说清楚。
一个常见的做法是把历史工单导出来，归类成几十个意图标签，再让系统按标签匹配答案。听起来合理，问题在于标签是按企业内部的流程切的，不是按用户的说法切的。用户说“我买的这个怎么还没到”，在系统里可能同时对应物流查询、异常件、退款咨询三条线，而分流逻辑只认关键词。于是用户被迫学习一套自己并不熟悉的语言，才能让机器给出正确回应。
更麻烦的是，意图一旦被切得太细，长尾问题就会大量漏出。有人问的不是标准问题，而是“我这个情况算不算你们说的破损”。这类带判断的提问，靠选项和关键词都接不住，最后仍然流向人工。企业看到转人工率高，以为是模型不行，于是换一版更强的模型，结果转人工率没怎么降——因为瓶颈根本不在识别精度，而在知识边界没划清。
知识边界比话术更像地基
所谓知识边界，是指这套系统明确知道自己能回答什么、不能回答什么，以及不能回答时怎么交接。很多项目上线时只准备了“标准问答对”，却没写清楚：涉及金额争议怎么办、涉及第三方责任怎么办、用户情绪激烈时怎么办。这些空白不会消失，只会在对话里变成一句生硬的“抱歉，我暂时无法理解您的问题”。
我见过一种相对务实的处理方式：把问题分成三类，能直接答的、需要查数据才能答的、必须由人判断的。第一类交给自助问答，第二类接通订单或物流接口后给出事实性回复，第三类不硬撑，直接说明“这个需要人工核实，我帮您转过去，并把刚才的对话一起带过去”。最后半句是关键。用户不介意转人工，介意的是转过去之后要把事情从头再讲一遍。
这也解释了为什么有些智能客服看起来“笨”，用起来却不烦人。它不假装无所不知，答不上来就干脆承认，交接时保留上下文。体验的好坏，很多时候取决于这种克制。
人机衔接的地方最容易掉链子
对话系统里最容易被低估的环节，是机器和人的接缝。机器人前半段收集信息，人工后半段处理，如果两边看到的信息不一致，前面做得再多也白费。现实中常见的情况是：机器人问清了订单号，转人工后客服看到的却只有一句“用户要求转接”；或者机器人承诺“稍后会有专员联系”，但工单系统里并没有生成对应任务。用户等的不是答案，是一个不存在的回电。
要让接缝顺滑，技术上并不复杂，难的是流程上的统一：机器人收集的结构化信息要写进工单，人工的处理结论要能回流成新的知识条目，用户重复提问时不该被再次要求描述。这些属于工程和运营的活，跟模型参数关系不大，却直接决定一套智能客服是省事还是添乱。
还有一个细节值得留意：转人工的触发条件不该只由系统单方面决定。用户连说两次“转人工”仍然被引导去点选项，这种设计看似在保住自助完成率，实际是在消耗耐心。把“我要找真人”当作一个明确的、优先级很高的意图来处理，成本很低，效果直接。
它应该站在什么位置
把智能客服当成“替代人工”的方案，容易走向两个极端：要么指望它包打天下，要么在几次失败后彻底否定。更合理的定位，是把它放在高频、事实明确、判断成本低的问题上，比如查进度、改信息、解释规则；把需要权衡、需要例外处理的部分留给人。这不是能力退让，而是分工。
对准备上线或正在调整这类系统的团队来说，有几个问题值得先回答：我们的用户实际是怎么描述问题的，而不是我们内部怎么分类；哪些问题系统必须承认答不了；转人工时，用户需要重复几次相同的信息。这些问题不涉及技术选型，却往往比换模型更能改变结果。
回到开头那位老人。她最后等到了人工，把情况讲了两遍，事情办成了，但对那次体验的评价只有一句：“跟机器说了半天，白说。”智能客服要跨过的，可能就是这样一句评价。