AI 明明听懂了，为什么用户的事情还是办不了？
做 AI 智能客服项目时，遇到过一类很有意思的问题。
用户明明已经把话说得很清楚了，AI 也明明听懂了，但最后事情就是办不了。
比如一个商户进来问：
“帮我查一下昨天那笔交易。”
从模型表现来看，好像一点问题都没有。
它知道用户要查交易，也知道时间是昨天，甚至还能很自然地回复一句：
“好的，我帮您查询。”
但再往下走，问题来了。
它查不到。
一开始看到这种问题，很容易怀疑是模型理解错了。
是不是意图识别不准？
是不是提示词写得不好？
是不是模型没有把“昨天”解析成正确的日期？
但我把整条链路拆开以后发现，这几个地方其实都没问题。
模型已经正确识别出：
用户要做的是“交易查询”。
真正断掉的地方，发生在后面。
系统要查交易，光知道“用户想查交易”是不够的。
它还必须知道：
到底是谁在查。
用户虽然已经登录了，前面的系统其实知道这个商户是谁，但是当请求进入 AI 的处理链路之后，这个身份上下文没有完整传递下来。
于是就出现了一个很典型的现象：
AI 知道你要干什么，
但它不知道该拿谁的数据去执行。
这时候我才意识到，这类问题如果只盯着模型，很容易越优化越偏。
因为问题根本不是“AI 有没有听懂”。
而是：
听懂之后，它有没有条件把这件事继续做下去。
后来我把这类 AI 客服能力重新拆了一遍。
以前很容易把它理解成：
用户说一句话 → AI 理解 → AI 回答。
但对于真正要“办事”的 AI，这条链路远远不够。
更完整的过程应该是：
用户先进入一个确定的登录状态；
系统确认他的身份；
把身份、账户、权限这些上下文带进当前任务；
AI 再判断用户想做什么；
确认完成这个任务还需要哪些参数；
然后调用后面的查询或者业务能力；
拿到结果；
最后再把结果解释给用户。
也就是说，模型理解意图，只是其中一步。
比如用户说：
“查一下昨天的交易。”
AI 即使百分之百识别出了“交易查询”，后面仍然可能因为很多原因失败。
身份没有带过来，查不了。
账户信息缺失，查不了。
用户没有对应权限，查不了。
查询参数不完整，查不了。
后面的工具调用失败，也查不了。
甚至工具已经返回结果了，如果结果没有正确回到对话这一层，用户依然会觉得：
AI 什么都没做。
所以后来在项目里，我不再把所有“没办成”的问题都归到模型准确率上。
而是先判断：
这一次任务，到底断在了哪一层。
如果意图识别错了，那才去看模型。
如果意图是对的，就继续往后检查身份、上下文、参数和工具调用。
这一步非常重要。
因为它会直接改变团队解决问题的方式。
以前看到 AI 没有完成任务，第一反应可能是继续改 Prompt、加样本、换模型。
但如果真正的问题是身份上下文根本没有传下来，那么模型再聪明也没有用。
就像一个客服人员已经完全听懂客户说什么了，但你不给他客户账号，也不给他查询系统权限，他一样什么都办不了。
所以我们后来重点补的，不只是模型能力，而是模型前后的执行链路。
比如登录用户进入对话以后，先建立可信的身份上下文；
涉及具体账户数据时，不再让模型自己猜用户是谁；
模型判断出任务之后，再检查执行这个任务所需要的参数是不是齐全；
进入查询环节以后，还要能够看到请求到底有没有真正发出去、在哪一步失败、返回了什么。
还有一个很容易忽略的地方：
“没有查到结果”和“根本没有成功查询”，必须分开。
这两个状态对用户来说完全不是一回事。
第一种是：
系统查过了，但确实没有符合条件的数据。
第二种是：
因为身份、权限、参数或者系统异常，这次查询压根没有正常完成。
如果把第二种也回复成“没有查到相关记录”，表面上回答很自然，实际上是在用一个假的业务结论掩盖系统故障。
这也是为什么我后来越来越觉得，做这种任务型 AI，不能只看它“会不会回答”。
真正重要的是：
它能不能把一次用户任务跑成闭环。
从这个角度再回头看，很多所谓的“模型问题”，其实并不是模型问题。
AI 已经听懂了。
真正没有准备好的，是它身后的系统。
身份有没有接上？
上下文有没有传下来？
执行参数够不够？
工具能不能调用？
结果能不能返回？
失败以后有没有明确的兜底？
这些环节只要有一个断掉，用户看到的最终结果都只有一句话：
“这个 AI 不好用。”
所以如果现在再让我判断一个 AI 产品到底有没有真正具备“办事能力”，我不会先问：
“它的意图识别准确率有多高？”
我会先看另一件事：
从用户说出需求，到事情真正完成，中间这条链路是不是闭环的。
因为对用户来说，他并不关心 AI 到底有没有正确理解自己的意图。
他只关心一件事：
我的事情，到底办成没有。
听懂的是一句话，办成的是一条链路。
