ARTICLE · 1112946
AI 项目 95% 未产生回报:MIT 报告解剖,失败几乎都不在技术层
AI 项目 95% 未产生回报:MIT 报告解剖,失败几乎都不在技术层
FDE · 失败解剖 失败不在技术层，在交付层 一次基于三百余个项目的结构性解剖：五大路障、三条防线，与一份诚实的口径说明 王健安 Alex Wang
FDE Echo Master · Echo 方法论发明者
幸福AGI的创造者与推动者 LEAD / 导语 我们先从一场演示讲起。那场演示在技术层面无可指摘：模型应答流畅，交互完整，现场没有出现任何可被指出的破绽。决策者在会后完成签字，合同金额达到数百万美元。九个月后，这个项目终止了。 📖 FDE 失败解剖 · 阅读约 30 分钟 这是一份解剖报告，不是一份案例集。它回答一个问题：那 95% 的 AI 项目，究竟死在哪一层。在展开之前，我先给出三个结论。它们决定了后面全部内容的走向。 结论一：失败的分布不在技术层。模型本身是合格的，部分案例中甚至表现优异。失败发生在模型与业务之间那段没有明确责任主体的区间。结论二：失败的形态是安静的。 它不表现为一次崩塌，也不表现为一次明确的叫停。它表现为使用量缓慢下降，最终在某一期汇报里以「持续推进中」的形式消失。结论三：这一层是可以被工程化的。三条防线、三关检验、一套毕业标准。这是本报告的核心内容。 01精华观点 如果你只读六句话，请读这六句。第一句。在企业投入生成式 AI 的三四百亿美元中，约 95% 未产生任何可被衡量的财务回报。第二句。但失败几乎不发生在技术层——在报告列出的五大路障中，没有一条属于模型能力层面。 第三句。失败的形态是安静的：不是崩塌，也不是叫停，而是使用量缓慢下降，最终在某一期汇报里以「持续推进中」的形式消失。第四句。这种安静的失败有一个结构性的成因：项目同时缺少期限、指标与裁判。第五句。因此有一层东西是可以被工程化的——三条防线、三关检验、一套毕业标准，它们不依赖模型进步，只依赖管理动作。 第六句。当前真正稀缺的不是模型，而是能够把模型嵌入客户真实业务的人。以下十三节，是对这六句话的展开。 02一、一场完美的演示，与九个月后的沉默终止 先把那场演示完整地描述一遍。演示在一家企业的会议室进行。大模型对答流畅，界面完整，现场没有出现任何技术故障。与会的高管提出了数个边界问题，系统都给出了合理的应答。会议结束时，决策者当场完成了签字。合同金额数百万美元，随后是合影、新闻稿、以及一次内部通报。 一切指标都指向成功。九个月后，这个项目终止了。而需要讨论的不是它的终止，是它终止的方式。 它没有被推翻，没有被叫停，也没有任何一次事故导致它停止。它只是逐渐没有人再使用。系统仍在运行，服务器仍在开机，合同中约定的每一项功能都已交付，每一笔款项都已付清。唯一没有到货的，是价值。 在那次汇报里，它的状态是「持续推进中」。而在下一期汇报里，它没有被提及。我把它称为安静终止。这是这类项目最常见的终局形态，也是最容易被统计系统遗漏的一种。因为一份死亡名单只统计明确宣告失败的项目。而安静终止的项目，从未进入过那份名单。 03二、95% 这个数字：方向可信，精确不可信 现象已经清楚。下一步，是把它放进数据。现在把这个现象放进数据里。麻省理工 NANDA 实验室在 2025 年发布了一份报告，题为《生成式人工智能的鸿沟》。研究团队访谈了 52 家组织，收回 153 份高管问卷，并核查了 300 余个公开项目。 报告的核心结论是一句话：在投入的三四百亿美元中，95% 未产生任何可被衡量的财务回报。报告同时给出两个更细的数据： 约 88% 的组织在使用 AI，但真正进入生产环境的 Agent，占比仅为个位数。仅约 6% 的企业能够说明，AI 对利润的贡献超过 5%。这里需要插入一段必要的口径说明，因为我对这组数据的使用是谨慎的。 报告将「失败」定义为：六个月内无任何可衡量的财务报表影响。按此口径，互联网与云计算的早期投资，绝大多数同样会被归入失败。它只承认利润、成本、收入三项，流程提速与员工采用率不计入。样本以大型企业为主，失败数据主要来自项目发起方一侧。这些限定条件都成立，也都不构成对该结论方向的否定。因此我引用 95% 时，取的是方向，不是精确值。 一个精确到个位数的失败率，本身即是一种伪精确。而在管理实践中，方向性的判断已经足以支撑决策。 
▲ 投入三四百亿，95% 未产生可衡量的财务回报 04三、五大路障之中，没有一条写着「模型不行」 规模确认之后，需要回答下一个问题：失败集中在哪一层。报告里有一份清单，我认为它比那个 95% 更值得反复阅读。它列出了企业 AI 项目失败的五大路障： 第一，员工不愿使用。第二，对模型质量的担忧。第三，用户界面体验不佳。 第四，缺少高层支持。第五，变革管理不到位。这五项本身并不意外。但请注意它们的性质分布： 第一、三项属于产品与用户层面；第二项属于信任层面；第四、五项属于组织层面。五项之中，没有一项属于模型能力层面。为了把这一点讲清楚，我列出那份「缺席名单」——它们同样经常被当作失败理由，但都未进入前五： 01模型不够聪明； 02算力不够便宜； 03数据完全不可用。 也就是说，在项目复盘中出现频率最高的那几个理由，在这份清单里一条都不存在。我在多个项目的复盘会上，都听到过以「模型效果未达预期」为主要结论的会议。按这份清单判断，那个结论很可能是表象。模型效果不佳，通常是因为它没有拿到应有的上下文、没有接入应接入的系统、没有被放进应走的流程。 这三件事都不属于模型问题，属于交付问题。由此得到本报告的第一个核心判断：失败几乎不发生在技术层，而发生在技术层与业务层之间那段没有责任主体的区间。 
▲ 五大路障中，没有一条属于模型能力层面 05那么，真正的问题是什么 如果失败与模型能力无关，它与什么有关？这是这份报告需要正面回答的核心问题。答案不在技术侧。它在技术侧与业务侧之间——那段没有明确责任主体的区间。 失败不是分布在这一层或那一层，而是分布在两层之间的接缝处。 06需要先处理的一个流行解释 在展开下一层之前，需要先处理一个最流行的解释：失败是因为模型能力不够。这个解释在直觉上成立，但它与三个事实相矛盾。第一，它不在那份五大路障之列。在超过三百个项目的核查结论中，它没有进入前五。 第二，模型能力在过去两年以季度为单位提升，而失败率并未同步下降。第三，同一批模型，在不同企业中的落地结果差异极大。同样的技术底座，有的企业已经进入生产，有的企业仍停在演示。如果失败的主因是模型能力，那么上述三个事实都不应该出现。 因此需要往下一层看：问题不在模型这一层，而在它上下两层之间的衔接处。而那里恰好有一个现场证词。手册原文引用如下：> 网上说一切都变了，回到我们车间，什么都没动。 > ——《FDE 工作手册 · 通用版》1.1，一家制造业公司 COO这句话的准确之处在于：它描述的既不是模型不行，也不是数据不行。它描述的是，模型没有进入那个车间。 07四、三个反常识：模型没错、自建更差、免费胜出 分布已经清楚。以下是报告中最反直觉的三条。这三条会逐层颠覆常见的归因方式，我逐条展开。 08发现一：制约不在模型本身 表现优异的模型进入生产环境后，其推理能力并未下降。它只是不接收反馈、不保存上下文、不进入工作流。用一个更准确的表述：它在功能上像一个产品，在使用上像一个展品。 我曾观察过一个客服系统接入模型的完整周期。第一周，一线反馈积极。第二周，开始出现一类重复的抱怨：每次都需要重新描述背景。 第三周，使用人数下降约一半。第四周，仅剩少数探索意愿较强的员工仍在使用。需要指出的是，在这四周里，模型自身的应答质量没有发生任何变化。 变化发生在系统层：它没有记忆，没有上下文，也不在任何业务流程之上。这是一个典型的交付层工程缺陷。 09补充：为什么「像产品」是一种误导 这里值得单独说明，因为它涉及一个常见的判断误区。一个 AI 系统在演示环境中的表现，与其在工作环境中的表现，往往存在系统性差异。演示环境包含三个理想条件：预设的问题、干净的数据、有耐心的使用者。 工作环境则包含三个相反的条件：未经整理的输入、失效的耐心、随时可能被打断的流程。演示检验的是模型的智能，工作检验的是系统的耐力。而这两者之间，隔着一整套工程能力：上下文如何供给、记忆如何保存、异常如何兜底、结果如何回写。 这些能力在演示中全部不需要。因此，「演示效果好」与「具备生产能力」之间，从来不是程度差异，而是性质差异。我见过一家企业，在评审流程中增加了一条要求： 任何 AI 项目在立项时，必须说明「它每天晚上如何运行、第二天由谁查看结果」。能回答的，继续立项。无法回答的，说明它目前仍只是一个演示。 10发现二：自建的成功率约为外购的三分之一 报告团队走访的绝大多数企业，都在尝试自建工具。而自建，恰好是失败率最高的路径。原因并不复杂：能够做出系统，与能够让它运行，是两项不同的能力。 做出系统，需要一个技术团队。让系统运行，需要有人定义口径、有人接管例外、有人承担结果、有人在上线后持续维护。我曾见过一个案例。 某企业内部团队用八个月开发了一套「智能审批助手」，功能完整，界面规范，内测评分较高。但它从未进入正式流程。原因在于：没有人负责把审批规则从三位主管的经验中提取出来，并将其转化为机器可执行的形式。 而这一步恰恰是整个链条中难度最高、最不具备展示性、也最容易被省略的环节。 11发现三：一项五万美元的采购，输给了一个免费工具 这是本报告中我引用最多的一个细节。某企业以五万美元采购了一套专业合同分析工具，功能清单相当完整。但公司内一位资深律师始终未使用它。她继续使用免费的 ChatGPT 起草合同。 她的理由是：「那个工具的摘要过于固定，无法按我的习惯定制。」需要指出的是，这不是一个情绪化判断，而是一个具体的技术判断。工具的输出形式与她的工作方式不匹配。而在采购部门的报表上，这个项目的状态是「已部署」。 真实的运行状态是：官方系统空置，员工另寻路径。 
▲ 五万美元的采购工具，输给了一个免费的对话框 这个细节的意义在于，它把一个宏观问题压缩到了一个具体的人身上。她并非抗拒新工具，她只是没有拿到那个对她有用的工具。而这五万美元的差额，不会出现在任何一份验收报告中。 验收报告只会记录：系统已部署，功能符合合同约定，项目通过。 12五、同样的条件下，什么样的项目活了下来 讲完失败，必须给出对照。否则这只是一份警告，不是一份方法。我观察过一个成功的项目。我观察过一个成功的项目。 它解决的问题很小：将每周的库存盘点报表，从人工汇总改为自动生成。技术复杂度不高，两周完成开发。它具备三个特征，我认为值得单独指出。 第一，它有明确的责任主体。责任人是一位仓储主管，他自己的考核指标中包含「盘点准确率」这一项。项目做成，属于他的成绩；项目不成，属于他的责任。第二，它的价值是可计算的。每周节省两名员工各三小时，折算为年度三百余工时。这个数字，财务部门认可。第三，它没有追求覆盖面。它只做了一件事：把一件重复性工作消除。 上线三个月后，系统因维护停机半天。仓储主管主动联系 IT 部门，询问：什么时候可以恢复，下午需要盘库。这一举动，构成了该项目成功的最直接证据。 一个被真正依赖的系统，停止服务时是会引发追问的。而一个仅用于展示的系统，停止服务时无人察觉。我把这个对照整理为三条镜像关系： 01失败的项目没有责任主体；成功的项目有一个具体的人。 02失败的项目只有技术指标；成功的项目有经营指标。 03失败的项目追求覆盖全组织；成功的项目只做一件小事。 
▲ 失败与成功的关键差异，不在技术，在这三件事 13六、坟墓不是被推倒的，是自己停下来的 对照之后，需要解释：这类项目为什么会进入那种状态。先回到那类安静终止的项目，分析它的形成机制。这类项目有一个共同的名称，在硅谷被称为概念验证坟墓。 它进入坟墓的方式有三个特征：它不会失败。因为没有明确的失败判据，它无法被判定为失败。它也不会成功。因为没有任何一项指标要求它成功。 它长期存在于汇报序列中。状态始终是同一个词：持续推进中。我曾跟踪过一个持续两年的项目。第一年验收未达标，归因于模型能力不足。 第二年仍未达标，归因于数据质量。第三年，项目组解散，系统继续运行，但已无人在意。没有任何人宣布它失败。它就这样完成了自然死亡。 那么，坟墓的结构是什么？我把它拆解为三个「没有」：没有期限。概念验证从未设定明确的截止时间。 没有指标。或者更准确地说，只有技术指标，没有经营指标。没有裁判。没有任何一个具体的人，需要在某一天回答一个问题：它究竟成了没有。一个同时缺少期限、指标与裁判的项目，结构上必然长期停滞。 这不是执行问题，是结构问题。而在结构问题被修正之前，任何执行层面的努力都会被抵消。 
▲ 没有期限、没有指标、没有裁判——这是坟墓的结构 14一个连续追问 为什么一个项目可以持续两年，而不被叫停？因为没有人叫停它。为什么没有人叫停它？ 因为没有人为它定义过「终点」。为什么没有定义终点？因为在推动它上线时，所有人的注意力都在「怎么开始」，没有人在「怎么结束」。 三个追问之后，坟墓的成因就清楚了——它不是被谁推倒的，是自己停下来的。 15七、毕业标准：给验证项目一条可退出的路 结构成因已经清楚，防线的设计方向也就明确了。既然坟墓的结构来自三个「没有」，防线的构造方向就是明确的。每一个验证项目在启动时，就应当写明：多少周之后，用什么指标，达到什么数值，项目「毕业」并进入付费部署；达不到，则双方按约定终止。 我把这条规则称为毕业标准。它包含四个要素，缺一不可：时间。第几周验收。写作「上线后第 8 周」，而不是「上线后」。因为「上线后」没有刻度。 指标。使用经营指标，不使用技术指标。即周期、错误率、复检工时、单次成本。数值。达到多少判为通过。必须有基准数，不能写「提升 30%」这类没有基线的表述。裁判。一个具体的人名，而非一个部门名称。 关于最后一项，需要特别说明。写部门名称，等于没有指定具体的人。而所有未被指认的责任，都会在困难出现时被稀释。我观察过一个正面案例。某企业的立项材料中明确写入：上线后第 8 周验收，第 12 周仍未达标则暂停并重新评估。 这条规则写入之后，项目负责人给出的反馈是：「写了这一条，我反而敢于推进。」这个反馈值得分析。它说明了一个经常被忽略的事实： 止损条件的真正作用不是终止项目，是让项目敢于推进。因为可退出，所以可投入。而一个不存在叫停机制的项目，最终通常是以预算被削减的方式，被动停止。 那一次停止，往往没有留下任何东西。 
▲ 毕业标准四要素：时间、指标、数值、裁判 16八、三类高危信号：有些项目，本就不该接 第一条防线作用于项目启动之后。而有些项目，本就不该启动。第二条防线用于项目开始之前，是一套筛选标准。有三类信号，同时出现两项以上时，应当高度警惕。 17信号一：无主之地 表现。项目在企业内部没有明确的业务方负责人，仅有信息部门对接。机理。信息部门的职责是合规与稳定，而合规与稳定从不构成启动新项目的理由。我观察过一个项目，对接方自始至终是 IT 部门。 每一次会议，IT 都高度配合，技术层面也未出现障碍。但项目推进半年，业务方始终未出面。当我询问 IT 负责人「业务方具体想要什么」时，得到的回答是： 「我也不太确定，他们没有具体说明过。」这句话基本可以判定：该项目没有责任主体。 18信号二：只许观察，不予访问 表现。客户要求先证明能力，但拒绝提供真实数据。机理。没有真实数据的验证，其成功只具有演示意义。我经历过一次这样的对话。 客户方表示：请先做一个演示版本。我询问：是否可以提供一批真实数据。客户方答复：不太方便，可以用公开数据先做。 需要指出的是，用公开数据得到的效果，与用自有数据得到的效果，是两件不同的事。而客户方通常不会区分这一点。他们只会记住那个演示表现良好。 19信号三：全域需求 表现。首次会议即提出覆盖全组织所有场景。机理。提出此类需求的客户，通常尚未准备好落地任何一个场景。我由此得到一个经验性判断：需求描述的范围越大，项目失败的概率越高。 原因在于，一个已经想清楚的客户，会与你讨论某一个具体环节中的某一个具体动作。而一个尚未想清楚的客户，会与你讨论「全面覆盖」。 
▲ 三类高危信号：无主之地、只许观察、全域需求 20翻转用法：这套筛子同时也是甲方的自检表 这里需要补充一个重要说明。上述三类信号，是写给服务方的筛选标准。将其翻转，即为甲方的自检表。因为在任何一个项目中，采购方在数量上都多于供应方。 如果你的项目在服务方眼中已经亮起「无主之地」的信号，那么作为采购方，你应当比服务方更加警惕。因为连外部供应商都能识别出这个项目没有真正的责任主体。 21九、把「不做」翻译成「什么时候做」 筛掉之后，还有一个更现实的问题：如何拒绝。前两条防线解决「如何筛选」，第三条解决「筛选之后如何处理」。方法是：把「现在不做」翻译为「什么时候做」。 我见过一次处理得较为完整的拒绝。企业方给出的表述是：「这个场景的数据基础还差三件事。我们建议先推进另一个场景，在推进过程中补齐这三件事，下个季度再评估这个场景。」 这种表述同时完成了两件事：守住了自身的产能，也维护了合作关系。它还有一个附加价值：把一次拒绝转化为一份路线图。客户收到的不是「不行」，而是一个有条件的、可执行的下一步。 三个月后，该客户重新提出了这个需求，而条件已经具备。 
▲ 把「现在不做」翻译为「什么时候做」 22三条防线的使用顺序 在进入下一部分之前，我把三条防线按使用顺序再整理一遍。第一条：毕业标准。用于项目启动时，明确终止条件。第二条：高危信号。用于项目筛选时，排除不应承接的项目。 第三条：体面退出。用于拒绝之后，维护合作关系并留下后续接口。 
▲ 三条防线的使用顺序：筛项目、验契合、留台阶 23十、从 PMF 到 PSF：视角从供给转向需求 至此解决的是「不接错项目」。但接对，不等于做成。前面的内容解决的是「如何不承接错误的项目」。但承接正确，不等于能够做成。 这里需要引入一个概念：PSF（Problem-Solution Fit），问题与方案的契合。互联网创业方法论有一个核心概念 PMF（Product-Market Fit，产品与市场契合）。在 FDE 的语境中，对应的单位不是「产品与市场」，而是「问题与方案」。 两者的视角方向相反：PMF 的视角在供给方，回答「我的产品有没有市场需求」。它适用于标准化产品与自助增长模式，可以在总部通过数据与漏斗完成判断。PSF 的视角在需求方，回答「客户这个具体问题，值不值得解决，以及能否被现有能力解决」。 而 PSF 只能在客户现场完成判断，无法在总部会议室里完成。那些判断错误，多数产生于会议室中基于二手信息所做的推演。 
▲ PMF 与 PSF 的视角方向相反 PSF 包含三关，必须同时通过。 24第一关：痛点检验 它检验的问题是：这是否是一个具体的人的一个具体的痛点？注意其中有两个「具体」。一个可用的标准是：它是否落在该企业决策者最关注的少数几个问题之内。只有达到这个量级，才能穿越内部的流程阻力。 反面例子：「提升客服效率」——这是方向，不是痛点。正面例子：「客服主管每周一上午花费三小时，从四个系统手工汇总上周升级工单」——这是痛点。一个能够被拍照记录的场景，才构成痛点。 25第二关：经济性检验 它检验的问题是：解决这个问题，价值多少？需要指出的是，很多痛点是真实的痛点，但并不构成一项值得投入的业务。一个无法计算价值的项目，即使做出来，也无法通过下一次预算评审。 可粗算四个数：该问题每周消耗多少工时；折算为多少人力成本；单次出错造成的损失；节省下来的人力的后续用途。 26第三关：可行性检验 它检验的问题是：在现有能力与客户数据现实的双重约束下，能够达到什么水平？这一关最容易被热情覆盖。数据在哪里、处于什么状态、准确率门槛是多少—— 「99%」与「90%」之间，隔着数量级的工程投入。我见过多个项目卡在这一关的误判上：以为能够达到 95%，实际为 85%，而业务要求为 98%。 
▲ PSF 三关：痛点、经济性、可行性，必须同时通过 27十一、经济性检验：最枯燥，也最致命 三关之中，有一关的省略频率远高于其他两关。三关之中，省略频率最高的是经济性检验。原因在于它最不具备展示性。痛点检验有画面，可行性检验有技术感，而经济性检验是一组枯燥的数字。 于是出现一种常见现象：团队在讨论痛点时论述充分，在讨论可行性时判断明确，一旦涉及价值核算，表述随即含糊。而这里有一组数据，恰好对应这一现象：超过半数的企业 AI 预算流向前台销售与营销，而回报集中出现在后台的合同审查、采购与风控环节。 多数团队在解决「演示效果好的问题」，而不是「值钱的问题」。这句话值得在任何一次立项评审之前重新读一遍。因为它解释了大部分项目「看起来很好，但没有人愿意为它付费」的原因。 
▲ 预算流向「演示效果好」的环节，回报出现在「不显眼」的环节 28一个方法性补充：能做到几分，是测出来的 关于可行性检验，还需补充一点方法论。多数团队在这一关依赖估算，而估算结果系统性地偏乐观。更可靠的做法是：先建立评估标准，再上线系统。 具体包含三步：第一步，先建评估集，再上线。从具体场景起步，由实际使用者逐条评分，评分结果直接进入迭代循环。把「什么叫好」的定义权，交给每天使用它的人。第二步，每日重跑历史用例。防止模型性能的隐性退化。AI 出错时通常不报错，它只是逐渐变得不可靠。 第三步，发布前评审真实案例。先与业务专家共同评审数百个真实案例，建立定制化的评估体系，再迭代模型。先定义好，再追求好。三步的共同点在于：它们都不属于技术层，而属于标准层。而标准的建立，恰恰是这件事真正的难点。 29一个可以直接回答的问题 在进入最后一节之前，请先回答一个问题：你们上一个 AI 项目，在立项时算清过这笔账吗？如果答案是否定的，那么它失败的原因，在立项那一刻就已经确定了。 30十二、拒绝本身，就是一种盈利能力 方法论至此已经完整。最后讨论一个反直觉的结论。它来自一家 FDE 服务商写在官网上的表述：它来自一家 FDE 服务商写在官网上的表述： 「场景尚未验证的，建议先参加演示活动；数据一张表即可导出的，轻量服务已经足够；仅希望了解 AI 的，使用免费方式即可。FDE 是重投入，我们宁可你晚一点开始，也不希望你在错误的时机开始。」这段表述之所以值得注意，是因为它给出了一个反销售直觉的判断：拒绝错误的项目，本身就是 FDE 模式的盈利能力。 原因在于成本结构。FDE 的成本是前置的。最优质的工程师、最长的现场投入，全部发生在回款之前。一旦进入错误的项目，问题不是损失单笔收入，而是整支工程师团队被占用一个完整季度，由此产生的机会成本。 我曾听一位前 Palantir 工程师核算过这笔账：> 我们投入数百万美元做客户试点，很多项目的利润率字面上是负无穷，因为我们是免费做的。> ——《FDE 工作手册 · 通用版》，一位前 Palantir 工程师 而更值得关注的是他随后补充的视角。Palantir 能够承受这种投入，是因为它把试点作为研发组合来投资——类似风险投资的结构：多数下注归零并不影响整体，但只要成功的部分能够覆盖全部成本即可。而如果一家企业既不具备相应的资本厚度，又不具备「把失败试点转化为产品资产」的机制，那么每一个错误的试点，都是纯粹的消耗。 
▲ 拒绝错误的项目，本身构成一种盈利能力 这个对照解释了同一个现象：为什么同样在做试点，有的企业越做越强，有的企业越做越弱。差别不在于是否敢于投入，而在于是否具备把失败转化为资产的能力。 
▲ 差别不在敢不敢投，在于能否把失败转为资产 31关于「接或不接」的两种看法 在服务方内部，关于要不要承接每一个项目，通常存在两种对立的看法。一种看法是：不宜挑客户。先把收入拿进来，规模会摊薄成本。另一种看法是：宁可少接，也不能接错。错误的项目会拖垮团队。 这两种看法都有各自的道理。而我认为，双方的争论停留在一个较浅的层面——真正的问题不是「接或不接」，而是「有没有把失败转化为资产的能力」。具备这种能力的企业，可以承接更多的试验；不具备这种能力的企业，每一次试验都是消耗。 分水岭不在胆量，在转化机制。 32一个可执行的检查清单 我把前面的内容压缩为五个问题。建议在任何 AI 项目立项之前，由业务负责人口头回答一遍。第一，这件事是谁的考核？若无法说出一个具体的人，则该项目没有责任主体。第二，这件事每年消耗多少成本？包括人力、返工、赔付与错失的机会。无法计算的，说明尚未想清楚。 第三，做成之后，谁会最先察觉？若没有人会第一时间感受到变化，则该变化可能并不存在。第四，如果三个月内未做成，如何停止？无法给出止损条件的项目，结构上不会主动停止。第五，是否可以用更简单的方式解决？能用规则解决的场景，不应当使用 Agent。 
▲ 立项五问，建议由业务负责人口头回答 33十三、稀缺的从不是模型，是让模型落地的人 最后，回到开篇的问题。这里有一个值得注意的对照。一方面，是企业 AI 项目 95% 的失败率。 另一方面，是「前沿部署工程师」这一岗位在一年内出现数倍增长。模型本身已经不再稀缺。能够把模型嵌入客户真实业务的人，才是稀缺资源。 
▲ 模型不再稀缺，能把模型嵌入业务的人才稀缺 在这里，我想回到做这件事的动机。我不想看到有人因为系统笨拙而受委屈。在这份报告所描述的图景中，最符合这一描述的有两个人：一位是继续使用免费工具的律师，一位是说「车间什么都没动」的制造企业高管。 他们并非拒绝新技术。他们只是始终没有等到那个对他们有用的系统。所以这份报告，我不把它当作一份失败名单。我把它当作一份问题清单。 它反复提出的只有一个问题：你所主张的价值，落在了谁的工作里？这个问题的答案，不在会议室中，也不在演示屏幕上。它在车间、在工位、在那个人的日常操作里。 关于这件事，我至今也没有完全想明白的一点是：为什么如此简单的判断——「它是否真的被使用」——会在如此多的项目中缺位。技术问题可以用投入解决，交付问题只能用心思解决。而判断一个 AI 项目是否真正存活，标准只有一个： 三个月后，是否还有人在使用它。在结束之前，还有一个问题，它可以由你自己回答：如果把一份方案里的技术判断全部删掉，剩下的东西还动人吗？ 如果剩下的只是流程和参数，那说明还没做完。如果剩下的是一个具体的人不再受委屈，那才是真的做完了。我想留一个问题给你。 在你负责的系统中，如果把项目组撤走，它还能运行多久？如果答案是「大约一个月」，那么它目前仍在伴舞。 “ 失败几乎不发生在技术层，而发生在技术层与业务层之间。 本文完 · AI 落地系列 王健安 Alex Wang FDE Echo Master · Echo 方法论发明者 幸福AGI的创造者与推动者 下一篇见 · 欢迎转发给你的团队 
FDE Echo Master · Echo 方法论发明者
幸福AGI的创造者与推动者