晚上十一点半，你想改一下收货地址。页面上弹出对话框，第一句是“您好，请问有什么可以帮您”。你打字说明情况，对面回了一句“我理解您的心情”。你愣了一下——你要的不是被理解，是改地址。
这类瞬间，大概是今天大多数人对智能客服最直接的印象。它不算笨，甚至有点过于礼貌，但在关键的那一步上，常常接不住。
它真正解决的是“接得住”
把镜头拉回企业客服后台，事情会清楚一些。大量进线是重复的：物流到哪了、能不能改地址、发票怎么开、退换货走什么流程。这些问题边界清楚，答案相对稳定，写进知识库并不难。智能客服在这类场景里的价值，与其说是“像人一样聊天”，不如说是“不漏接”——凌晨三点也有人应，高峰期不至于一直排队。
技术上，它做的事可以拆成几层：先判断你想干什么，再补齐必要信息，比如订单号、商品、时间，然后去知识库或业务系统里找答案，最后组织成一句人话。前端的语言模型负责最后一层，前面的判断和取数，才决定成败。
卡住的地方，常不在模型
用户描述问题的方式千差万别。“东西还没到”和“你们是不是把我的件弄丢了”，指向的可能是同一件事，也可能不是。同一种语气背后，有人想催，有人想退。一句话里混着两个诉求时，机器容易只抓住其中一个。
更麻烦的是跨系统操作。改地址要改单，退款要走审批，补偿要有人授权。模型能把话说圆，但不能替企业决定给不给、给多少。于是很多体验问题不是“答错了”，而是“绕不出去”——转人工的入口藏得太深，用户在几个选项里来回打转。短期看人工量降了，长期看，不满会转移到公开渠道去。
生成式模型改变了什么
大模型进来之后，最明显的变化是话术自然了，多轮对话能接上，长尾问法的覆盖率也上来了。以前要穷举几百条相似问，现在靠语义匹配能兜住不少。另一面是风险：随口承诺赔偿、编出一个并不存在的政策、把不同订单的信息串在一起。这类错误在演示里看不出来，在真实业务里代价不小。
所以工程上常见的做法是加护栏：答案尽量从检索到的文档里出，敏感操作直接拦截，涉及金额和时效的表述走固定模板。这些做法听起来不“智能”，但正是它们让智能能上线。一个只会自由发挥的对话系统，很难被放心交给客服主管。
情绪这件事，机器做不到全部
很多系统会安排一句安抚：“我理解您的心情”。这句话本身没错，问题是它经常出现在用户最不需要的时候。用户想确认的，其实是“我的问题有没有人负责”。责任主体、处理时限、能不能追溯，这些不是语言层面的问题，而是流程和权限层面的问题。语言模型可以把这句话说得更真诚，却没法让它变成真的。
一个务实的判断
看一套智能客服好不好用，演示环节的顺畅程度参考价值有限。更值得看的是三个地方：
- 答不上来的时候，它怎么把人和上下文一起交给人工，而不是让用户重讲一遍；
- 它说出口的承诺，是否都在规则允许的范围内，事后能不能查到依据；
- 出了问题之后，能不能定位到是哪条知识、哪次检索、哪个环节的判断出了偏差。
这三件事都不性感，却决定了它是真的在分担工作，还是把麻烦往后推了一层。
“智能客服”这个词容易被理解成用机器换人。更准确的说法也许是：它把前台那一层标准化的工作接了过去，把人的时间腾给真正需要判断的部分。企业要设计的，其实不是一段多聪明的对话，而是人与机器交接的那几十秒——什么时候该接，怎么接，接过去之后信息还在不在。