95% AI 试点失败的根本原因是架构问题而非模型

企业 AI 中被引用最多的数字，以及它实际在衡量什么

你肯定见过这个说法："95% 的 AI 试点项目都失败了。"这个数据来自 MIT Project NANDA 于 2025 年 7 月发布的报告《The GenAI Divide: State of AI in Business 2025》。该报告显示，只有 5% 的组织能够将 AI 试点转化为实际的运营或财务成效。

大多数人的解读是"模型还不够好"。但这并非报告的原意。用报告的话说，这种差距"似乎并非由模型质量或监管驱动，而是由方法论决定"。关于工具本身，报告指出它们"失败不是因为模型差，而是因为它们不会学习、适应或整合。缺乏记忆和反馈回路使得 GenAI 停留在生产力提升工具的层面，而无法成为工作流转型的引擎。"

这就把整个问题重新定义为了一个架构问题。如果你是那个负责构建的人，这意味着什么？以下是具体的解读。

隐藏在"试点失败了"背后的三大架构失败

1. 决策点没有反馈捕获

大多数部署只是生成一个输出，人工接受或拒绝它，然后这个判断就消失了。关于人工修改了什么、为什么修改，没有任何信息被存储下来。你构建的系统无法变得更好，因为你从未记录下它是否正确。

解决方案并不光鲜：将人工审批步骤视为一个结构化的数据捕获事件，而不是一个 UI 关卡。记录原始输出、最终输出、差异，以及（在能够获取的情况下）一个原因代码。这一行数据既是训练信号，也是审计记录。

2. 运行之间没有持久记忆

无状态的调用每次都会重新推导上下文，无法积累任何东西。会话记忆不同于组织记忆——你真正需要的是一个持久的、可查询的过往决策记录，未来的运行可以基于此进行条件化处理。

3. 独立运行而非集成

工作流旁边的聊天窗口并不等于在工作流内部。如果一个人必须离开他们所在的队列、切换上下文、输入 prompt、再把结果粘贴回来，那你就不是减少了一个步骤，而是增加了一个步骤。那些能够量化 ROI 的部署，往往是 Agent 在现有记录系统中运行的那些。

几乎没人引用的发现

同样是那份报告：后台自动化比前台业务功能带来了更强的 ROI，尽管 50% 以上的 AI 预算流向了销售和市场营销。如果你在选择投入构建工作的地方，这是一个有用的先验知识。后台工作通常量大、重复性高、更容易衡量——这使得自动化和 ROI 论证都是可操作的。

在医疗领域，具体来说就是：理赔处理、事先授权、拒付和申诉、欺诈审查。不是那些花哨的演示——而是那些队列。

为什么人在回路（Human-in-the-loop）设计阴差阳错地避开了这个问题

值得指出：MIT 广泛研究了企业级 GenAI，并不为任何特定方法或供应商背书。但如果你仔细看他们的失败模式——没有记忆、没有反馈、没有集成——一个受治理的 Agent 设计几乎是无意间同时避开了这三个问题。审批步骤就是你的反馈捕获。审计追踪就是你的持久记忆。而一个必须将工作路由到指定审核人的 Agent，自然是存在于工作流内部，而不是旁边。

我们在 IntelliBooks Studio 为医疗后台工作流构建了这个模式。非常乐意在评论中深入讨论反馈模式设计或决策日志的结构方式。