麻省理工学院 2025 年那份著名的报告说：企业烧进人工智能项目的钱，95% 没有产生可衡量的财务回报。更扎心的是结论——问题不在模型。模型进了生产环境依然聪明，只是没人真的在用。
先讲一个死掉的九百万美元
《前线部署工程师》这本书开头讲了个故事：供应商的演示惊艳全场，CEO 当场拍板签约。九个月后项目死了——不是轰轰烈烈地死，是悄无声息地死。系统还在跑，服务器还开着，只是没有任何一个业务部门真的在用。供应商交付了合同里的每一项功能，企业付清了每一笔钱，唯一没到货的是「价值」。
这个故事在中国的政企市场每天都在重演。演示对答如流，进到真实环境就没人用。原因是同一个：演示环境里的智能体，和生产线上的智能体，中间隔着真实的数据、权限、合规和工作流——这段路，没人替客户走完。
杀死项目的五件事，没有一件是技术
MIT 的研究者给企业 AI 项目的失败做过解剖，按出现频率排出五大路障：员工不愿用新工具；对模型输出质量的担忧；糟糕的用户体验；缺乏高管支持；变革管理困难。
注意这份清单里缺席的东西：模型不够聪明、算力不够便宜、技术不够先进——都不在列。杀死项目的，几乎全部发生在「问题定义」和「组织现实」层面。一个细节很说明问题：一家企业花五万美元买了专业合同分析工具，资深律师却继续用免费的 ChatGPT 起草合同——「买的那个工具，摘要太死板，没法按我的习惯定制」。采购报表上写着「已部署」，真实日常是官方系统空转、员工绕道而行。
在错误的问题上，一切执行力都是浪费
这是 FDE（前线部署工程师）方法论的第一性原理。企业客户内部可能有几百个「AI 能做点什么」的机会点，但真正值得做的，必须同时过三关：
三关都过，才算摸到问题与方案的契合。这三关必须在客户现场过——坐在总部会议室里对着二手信息做判断，是大部分项目出错的总根源。这也是我们把 交付流程的第一阶段定为「场景澄清」的原因：先花时间把「正确的问题」锁定，而不是急着证明技术多厉害。
为什么外部团队反而胜率更高
MIT 报告里有一组常被忽略的对比：与外部专业供应商合作的项目，成功率约为内部自建的两倍。不是外部团队更聪明，是他们输不起——按结果收钱的人，定义错问题的代价是自己买单。
日本一家公司的内部项目是典型反面教材：抽调三四名最强工程师组成攻坚组，演示惊艳、领导点头，唯独从第一天起没人能回答「这套系统的好，由什么标准衡量」。半年后项目从汇报材料里悄悄消失，没有人宣布它失败，它就这样自然死亡了。
把「先验证再投产」变成制度
FDE 模式对抗 95% 失败率的办法，不是更努力地交付，而是从制度上保证「结果」不被稀释：收钱方式向结果靠拢、成功度量前置到开工之前、最终裁判是客户组织的行为改变。
落到项目上，就是 Palantir 那套「训练营」逻辑的简化版：客户带真实数据来，几天内做出能部署的原型，高管亲自动手用，当场决定进退。概念验证必须有「毕业标准」——多少周后、用什么指标、达到什么数值才算过；达不到，双方体面散伙。这恰恰是我们建议政企客户走的路线：先拿一两个高价值场景做试点验证（通常 4–6 周），验收达标再进入生产部署。试点不是「先试试」，是投产前的必经关卡。