模型没失败，界面失败了：企业 AI 落地七成失败根因分析

三个数字，放在一起怎么看都不舒服。

一个职位名称——forward deployed engineer——在 2025 年的招聘量增长了约 800%。前沿实验室的中高级职位总薪酬稳定在 35 万至 55 万美元区间。而企业 AI 试点项目的失败率——取决于你参考哪份调查——仍然在 70% 到 90% 之间。一份被广泛引用的数据显示，在短短一年内，放弃 AI 项目的企业占比从 17% 跃升至 42%。

如果瓶颈在于模型，那解决方案就是更强大的模型。但行业给出的答案却是招聘人类员工，把他们安置在客户的办公场所。这对技术问题来说是个不寻常的应对方式——只有在技术本身并非症结所在时，才会得出这样的解决方案。

那么：到底是什么在持续失败？

FDE 的标杆成功案例——OpenAI 在摩根士丹利——大约需要 6 到 8 周的技术架构搭建，然后还需要大约四个月的时间让顾问们真正使用这个工具。报道的胜利条件是 98% 的采用率，而不是准确率，也不是延迟。

采用率不是模型指标。它衡量的是一个人是否决定信任屏幕上显示的内容。这个决策是在界面层做出的。

信任通常会在三个地方死去——隐藏的不确定性、不可见的成本、以及一个不愿展示工作过程的系统——这些全都是渲染层面的决策，而非建模层面的决策。

FDE 岗位的描述和招聘都是以后端 / ML / infra 角色来写的。读上十几份岗位说明，数数有多少提到了操作员看到的东西。失败面和招聘面并不对齐。

这不是在说后端不重要。它是在说后端只需要六周，而最后一公里需要四个月。

那个不契合的数字

每个关于 forward-deployed 模式的文章最终都会援引同一个案例：OpenAI 的工程师嵌入摩根士丹利，为财富顾问构建助手。

所有人引用的是结尾——98% 的采用率。值得仔细看的是产生这个结果的时间线形状。大约六到八周的技术架构搭建：集成、数据管道、evals。然后大约四个月与真实顾问一起运行试点。

四个月。在系统已经能正常工作之后。

在这四个月里发生的事情，不是模型训练。模型已经完成了。集成已经完成了。剩下的是一群经验丰富的专业人士，一个接一个地决定，他们是否愿意在一个机器生成的答案上署上自己的名字。

这就是最后一公里。注意它是如何被衡量的：不是"模型在我们的 eval 集上得分 0.91"，而是"98% 的人在使用它"。一个没人打开的部署和一个不工作的部署是无法区分的。

采用率是一个界面数字

这是我想提出的重新框架。

我们把采用率当作变革管理问题来处理——培训课程、 champion 、高管指令。其中有些是真实的。但决定一个专业人士是否信任一个系统的大部分因素不是一份备忘录。它是使用它时积累的体验：它向他们展示了什么，它隐藏了什么，以及它是否对这种差异保持诚实。

财富顾问不是因为有人告诉他们模型的 F1 分数才信任它。他们信任它是因为在三个星期里，它从不自信地给出错误答案而不事先警告他们——而当它不确定时，它会以他们能够采取行动的方式说出来。

这不是模型属性。这是渲染属性。这是某个人做出的决定：屏幕上在 confidence 为 0.51 而不是 0.98 时显示什么。

信任死去的三个地方——都在屏幕上

我认为 AI 驱动界面中有三种反复出现的失败模式，而且它们都不是模型缺陷。

1. 不确定性被扁平化了。模型返回它半猜的东西，格式与它确定的东西完全相同。同样的字体、同样的 confidence 、同样的语调。操作员没有办法区分。他们在事后——通常只有一次——才发现问题，之后他们会反复检查一切，这意味着系统已经不再为他们节省时间了，这意味着他们停止使用它。

修复方案是一个设计决策：给低置信度的输出不同的 affordance。不是吓人的红色横幅。而是用一种忙碌的人一眼就能真正理解的方式说"检查这个"。

2. 成本在账单出来之前是不可见的。批准续约的人不是使用工具的人。如果预算负责人唯一看到数字的时候是每月账单上，那么关于这个系统的每次对话都是关于一个意外。我写过为什么没有人衡量 prompt 缓存，以及为什么在发送 prompt 之前应该先 pre-flight 检查，这两个帖子在事后看来都是关于这个的：成本是一等一的界面状态，把它当作运营指标会让决定项目生死的人看不到它。

3. 系统不愿展示其工作过程。当输出是错误的而操作员看不到原因时，他们不会提 bug——而是对整个系统失去信心，包括那些正确的部分。一个无法被检查的系统只能被信任或被抛弃，而人们会选择抛弃。

这就是为什么我最终为 agent runs 构建了 trace replay。不是因为 traces 有趣，而是因为"它为什么那么做"是决定一个部署能否度过第一个糟糕周的问题。

这三个问题都是在界面层修复的。都不是靠更好的模型能修复的。

反驳意见的最强版本

让我好好地论证一下反面，因为弱版本的反驳很容易被驳倒，我不想那样做。

严肃的反对意见是：最后一公里不是 UI 问题，而是数据问题。客户的 schema 没有文档化。一半的工作流存在于某人的助手维护的电子表格中。承诺给你的 API 不存在。没有什么能正确渲染，因为上游就没有什么东西是正确的。OpenAI FDE 负责人在一定程度上说过这个——客户在需求阶段描述的内容与实际系统的情况 routinely 无法匹配。

这是真的，这是工作中最难的部分。我不是在争论这一点。

但再看一遍时间线。那部分工作是六周。它是必要的，但它绝对不是充分的，证据是项目没有在第八周成功——它在四个月后才成功，那是完全不同类型的工作之后。

两部分都是真实的。我的主张比"UI 才重要"更窄。它是：第二部分才是更大的部分，是项目真正死去的部分，是几乎没有人被招进来做的那部分。

去读一批 forward-deployed engineer 的岗位说明。你会看到：生产环境 LLM 经验、高级 prompt 工程、agent 框架——LangGraph、LangChain、CrewAI、DSPy——评估框架、大规模部署、多步 tool-use chains、有时候是 air-gapped 和裸机供应。

所有这些都是合法的。所有这些都是必要的。

现在数一数有多少行是关于操作员看到什么的。关于不确定性如何呈现的。关于做这项工作的人能否区分自信的答案和猜测。

这个角色是被解决问题的集成问题的人定义的，人员配备也是由擅长集成问题的人组成的。与此同时，每个人报告的胜利条件数字——采用率——完全是在另一个地方被决定的。

我不认为这是阴谋或者不认真的人的疏忽。我认为这是当一个角色在时间压力下被最早注意到这个问题的学科发明出来时会发生的事情。Palantir 在 2000 年代为那些确实无法描述自己需要什么的情报客户发明了这个模式。那时候的问题确实主要是数据和访问。问题现在有很大的面向人类的成分，而职位描述还没有跟上。

这周我真的会做的三件事

如果你正在把一个 AI 功能嵌入到他人的工作流中，三个具体的行动，按成本从低到高排列：

1. 给不确定性一个视觉身份。选取你的模型已经发出的一个信号——confidence 分数、refusal、两次采样运行中的低一致性结果——用不同的方式渲染它。一下午的工作。它把你的系统从"信任它或者不信任"转变为"在这里信任它，在那里检查它"，而这个区别就是人们保留的工具和人们悄悄停止打开的工具之间的全部区别。

2. 把成本放到签署续约合同的人看得到的屏幕上。不是在他们必须记住去打开的仪表板上。而是在他们已经在看的东西上。一个更新的数字是一个永远不会成为意外的数字，而意外才是杀死续约的东西。

3. 让一件事可被检查。选取你的系统做出的最重要的一个决定，给操作员一种看到它如何得出结论的方式。不是完整的可观测性——一条路径，一个解释。第一次出问题的时候，那条路径是 bug 报告和丢失账户之间的区别。

这些都不需要触碰模型。它们都能移动 FDE 模式所说的胜利条件的那个数字。

如果这个论点成立——最后一公里实质上是一个界面问题——那么有一个后续问题值得认真对待：在那一公里工作的工程师实际上需要具备什么？

因为约束是残酷而具体的。你在别人的环境里。没有六周的安全审查你什么也安装不了。数据不能离开他们的边界。你带来的每个依赖都是他们的安全团队要问的问题。而且你仍然需要在利益相关者注视下回答"它为什么那么做"。

我在完全相同的约束下构建工具已经一年了，直到最近我还以为我是因为美学原因才这么做的。

这就是下一篇文章的内容。

这是关于企业 AI 最后一公里的系列文章的第一部分。第二部分——"我不小心为一个 forward-deployed engineer 构建了一套 field kit"——是关于工具的，以及那个最终定义它们的约束。

这篇文章镜像自 ferhatatagun.com/blog/nobodys-model-failed——那是规范 URL。

更多来自同一来源：

Long-form blog — AI, LLM tooling, frontend at the model boundary

The five tools — browser-only, BYOK, open-source Claude API dev tools

GitHub · X · LinkedIn

Happy to discuss here or on the canonical post — both threads stay open.

For further actions, you may consider blocking this person and/or reporting abuse