当谷歌说 AI 应用广泛但深度不足，我们到底在造什么？

谷歌首席经济学家 Fabien Curto Millet 扔出的 ATLAS 报告，基于 1500 万条去标识化交互数据，得出一个看似平淡的结论：AI 普及范围广，但深度不足。我盯着这个结论想了三天，脑子里反复出现一个画面——Hackathon 现场，几十个团队围坐，每个人都在调 OpenAI 的 API，最后 demo 展示时，连 prompt 模板都惊人相似。这不是巧合，这是整个行业的结构性镜像。

我们正在用 AI 做最无聊的事

ATLAS 报告没有公开完整的交互类别分布，但从已知信息推断，大部分 AI 交互集中在三类场景：内容生成（邮件、文案、代码段）、信息检索（替代传统搜索引擎）、以及简单的任务自动化（调度、翻译）。这些任务本质上都是“单次调用”模式——用户输入一个 prompt，拿到一个输出，然后结束。

短期看，这种模式是合理的。 成本极低，上手门槛为零，任何拥有浏览器的人都能在 30 秒内体验“AI 魔法”。Hackathon 里最流行的 demo 类型是“ChatGPT wrapper”，因为 48 小时内从零搭建一个 AI 应用，最稳妥的路径就是套壳。你会看到产品经理兴奋地展示“用 AI 生成周报”，技术负责人骄傲地演示“AI 自动写邮件回复”。这些 demo 确实解决了“有没有”的问题，用户也愿意用——数据显示使用率在涨，但单次会话长度和交互轮次并没有同步增长。

但长期看，这恰恰是深度陷阱。 真正的 AI 能力突破发生在多轮交互、复杂推理、以及持续学习场景中。比如一个医疗诊断助手，需要理解病历上下文，询问多个症状，结合历史数据做推理，再输出建议。这需要多轮对话状态管理、知识图谱嵌入、以及结果可信度验证。而目前的绝大多数应用，本质上是“一次性问答”的变体——把复杂任务拆解成单次 prompt 的拼凑。用户没有养成“和 AI 对话解决问题的习惯”，而是把它当成更智能的搜索引擎或文本生成器。

从 Hackathon 到 ATLAS：技术栈的浅层化

我在 50 多场 Hackathon 里观察到一个现象：80% 的 AI 项目使用了相同的技术栈——前端+LLM API+向量数据库（通常是 Pinecone 或 Weaviate）。这三点构成了一个稳定的“浅层三角”。ATLAS 报告揭示的“深度不足”，本质上就是这个三角的映射。

• 前端：没有交互创新。大部分应用是聊天界面，输入框+输出框，最多加个文件上传。
• LLM API：调用链单一。几乎没有人做复杂的 chain-of-thought 或多模型路由，理由是“48 小时做不完”。
• 向量数据库：文档检索，仅此而已。没有图数据库、没有时序推理、没有因果推断。

短期看，这个技术栈能快速出 demo，满足“AI 应用”的标签。但长期看，它限制了 AI 的演化路径。当用户习惯了“问一句得一句”的交互模式，他们不会主动要求更复杂的推理。而开发者被“快速交付”的 Hackathon 文化驯化，也没有动力去探索更深的架构。ATLAS 的数据只是把这种相互锁定的浅层循环量化了。

深度不足的本质是“数据集”和“评估”的缺失

谷歌的报告只说了现象，没说原因。作为一个做过 50+ demo 的老黑客，我判断核心瓶颈不在模型能力，而在真实场景的深度交互数据匮乏。目前所有开源或闭源模型，训练数据主要来自公开互联网——文本、代码、对话记录。但多轮复杂推理的交互数据，尤其是包含错误恢复、中间状态显式表示、用户意图修正的对话，几乎不存在公开数据集。

这就导致了一个鸡生蛋问题：没有深度交互数据，模型无法学会深度交互；模型不会深度交互，用户就不会尝试深度交互。ATLAS 报告只是观测到了这个循环的稳态，而非例外。

技术实现上的可行性判断：要打破这个循环，需要在应用层做两件事。第一，设计隐性深度交互激励——比如在用户完成一次简单问答后，主动追问“是否需要更详细的分析”或“是否要对比不同方案”，从而收集多轮数据。第二，构建面向评估的沙盒——就像 Hackathon 里我们给评委演示 demo 时，必须设计好“如果用户问这个问题，模型应该怎么回答”的黄金路径。这些黄金路径本身就可以作为训练数据，反向优化模型。

短期 demo 和长期工程的分水岭

短期看，当前的 AI 应用广度足够覆盖 80% 的日常需求，这解释了为什么产品能获得用户。一个能用 AI 写周报的团队，生产效率提升是实打实的。但长期看，**广度

原文链接：https://www.ithome.com/0/981/498.htm