为什么很多 AI 应用看起来聪明，用起来却不稳定？

我这段时间做 AI 应用，一个很明显的感受是：现在大部分产品都很容易做出“它好像很聪明”的瞬间，但很难做出“我愿意一直用它”的稳定体验。

这两件事看起来很像，其实差得挺远。

一个 AI 应用要显得聪明，只需要它偶尔在某个场景下答得很好，甚至只要某几个 case 很惊艳就够了。但一个 AI 应用要真正可用，要求是它在大量普通输入、模糊输入、错误输入下，也别突然变得很离谱。

后者难太多了。

第一层问题：大家高估了模型，低估了系统

很多时候我们看到一个 AI 应用不稳定，第一反应是模型不行。

但我后来发现，模型其实经常不是最核心的原因。更常见的问题是，系统把一个本来就存在不确定性的模型，放进了一条更不受控的链路里。

比如：

• 用户意图没有先分类。
• 检索结果质量不稳定。
• 工具描述写得含糊。
• 上下文塞得又长又乱。
• 没有失败兜底。

在这种情况下，就算模型能力提升，系统也只是“平均水平上去了”，但波动还是很大。

第二层问题：AI 应用太喜欢走捷径

这是我现在很警惕的一件事。

很多功能在做第一版的时候，特别容易靠 prompt 魔法硬顶。能跑就先跑，能演示就先演示。短期看效率很高，长期看基本都会还债。

因为 prompt 可以弥补一部分结构问题，但代替不了结构本身。

举个简单例子，如果你让模型自己从一大段自然语言里判断任务类型、提取参数、选择工具、决定执行顺序、总结结果，那它当然有概率一次跑通。但只要输入稍微变形一点，这条链路就可能哪都错一点，最后你甚至很难定位错在哪。

所以我现在会更倾向于把能结构化的地方先结构化，把该由系统负责的事尽量别甩给模型。

第三层问题：没有把“稳定”当成单独目标

很多团队做 AI 应用时，目标其实是“功能做出来”。但我越来越觉得，AI 应用的稳定性不是功能附属品，它本身就是一个独立建设项。

比如你得单独思考：

• 哪些输入最容易让系统失真。
• 哪些步骤必须做校验。
• 哪些任务不适合全自动处理。
• 失败后怎么优雅退化。

如果不专门设计这些东西，系统就会呈现出一种很别扭的状态：顺的时候特别像未来，崩的时候特别像诈骗。

我自己比较看重的三个稳定性来源

1. 任务边界清楚

一个 AI 应用如果什么都想做，最后通常什么都做不稳。

我现在更认同的方法是，先把高频任务卡死一点，明确它能处理什么，不能处理什么。这样虽然“全能感”会下降，但可用性反而会上升。

2. 中间状态可见

很多产品只给用户一个最后答案，但中间过程完全黑盒。这样一旦答错，用户既不信任，开发者也不好排查。

如果系统能适度展示它用了什么信息、做了什么判断、调用了什么工具，其实会好很多。不是为了炫技，而是为了建立可理解性。

3. 错了也别装

这一点我真的很在意。

很多 AI 产品最糟糕的地方不是答不出来，而是明明不确定，还是要一本正经地往下编。尤其一接工具、一碰业务数据，这种错比普通聊天错误严重得多。

所以一个成熟一点的系统，应该允许自己保守，允许自己先追问，允许自己在证据不足时不做结论。

我现在越来越不信“万能助手”

倒不是说这个方向没价值，而是我觉得真正有用的 AI 产品，早期往往不是靠大而全做出来的，而是靠在一个具体任务上先把稳定性做出来。

用户不会因为你理论上能做十件事就留下来，用户会因为你其中一件事真的稳定、省时间、少出错，才愿意继续给你机会。

所以如果有人问我，为什么很多 AI 应用看起来聪明，用起来却不稳定，我现在的答案会比较直接：

因为大家太想证明模型有多强，却没有花同样多的精力去设计一个能约束不确定性的系统。

而 AI 应用真正难的地方，恰恰就在后者。