企业AI应用落地项目失败复盘：3个致命原因

过去三年，我深度参与过二十多个企业 AI 项目的立项评审、中途救火和事后复盘。这里面有做了一半停掉的，有上线三个月访问量归零的，也有花了七位数预算只换来一份 PPT 的。如果只看外部宣传，你会以为是模型不够强、算力不够多、人才不够顶尖。但我把每一个失败项目拆开看，真正把项目拖下水的，几乎都集中在三个地方：数据地基是虚的、场景选得太大、没人对”它被用起来”负责。

这三个原因听起来都很朴素，朴素到很多团队在做立项汇报的时候会主动跳过它们，因为它不性感。算法、大模型、Agent、多模态，这些词放进汇报材料里能拿到掌声；而”客户主数据有两套编码要统一”这种话，说出来会议室会安静三秒。可实际跑下来，决定一个 AI 项目能不能活过六个月，恰恰是后面那三秒里的事情。

我写这篇复盘，不是想说服谁去追风口或者躲风口。我是想把那些真实踩过的坑摊开——哪一步走错了，错在什么位置，当时如果换个做法会怎样。文中涉及的工具和方法，我会以普元的产品体系为主线来讲，因为在我参与过的项目里，普元这套从主数据、数据资产、数据开发到 AI 问数的组合，是少数能把”治理”和”应用”接上的一套路子。至于模型选谁、算力买多少，那都是后面的事。

我先说一个可能不太讨喜的判断：企业里绝大多数 AI 项目的失败，跟算法团队的水平关系不大。我见过算法团队把准确率从 82% 调到 94% 的项目，上线后依旧没人用；也见过模型能力很朴素、但业务部门天天催着加需求的系统。差距不在技术侧，在技术之外。

我通常会要求项目负责人做一件事：把过去两年内公司内部所有 AI 相关的尝试列出来，逐条标注”为什么停”。标完之后你会发现，理由高度重复。下面这张表是我整理过的归因分布，样本不算大，但规律相当稳定。

这张表里最扎眼的不是 42%，而是那 10%。很多团队把 90% 的精力投在 10% 的区间里，反复做模型对比、参数调优、算力选型，然后在剩下 90% 的地带裸奔。AI 落地是一场围绕数据和组织的工程，不是一场模型竞赛。

还有一个现象我会特别留意：项目停了以后，团队给出的解释往往是”业务不配合”。但顺着这条线往上追，多半能追到立项阶段就埋下的雷——没人在项目启动时明确过，究竟哪个岗位的人需要在哪一天用这个系统替代掉现在的哪一步手工操作。这个答案不清晰，项目从第一天起就在悬空。

数据地基没打牢，是三个原因里唯一会全盘清零的那一个。我的经验是，只要数据侧不干净，模型再强也只能输出看起来很像样的错误答案，而这种错误对业务的伤害比”系统没有答案”更大。

举个我印象最深的例子。一家制造企业上线 AI 问数，想让管理层直接问”上个月华东区的毛利率是多少”。技术上两周就跑通了，第一版演示很惊艳。上线一个月后业务弃用，原因是同一个问题问三次，出来三个数。往下查，销售系统里的”收入”含税，财务系统里不含税；两个事业部对”华东区”的划分还不一样。模型没算错，它只是忠实地把两套口径混在了同一张嘴上。

问题的根，是主数据和数据资产这两块没人认真管过。客户编码、物料编码、组织架构、指标定义，这些东西在不同系统里各有各的版本，平时靠人工核对勉强能糊过去，一旦交给 AI 自动取数、自动汇总，全暴露出来。

口径不一致，是 AI 问数翻车的头号杀手。我给团队的建议很直白：如果一个指标在公司内部存在两种以上算法，那就先别把它放进 AI 问数的范围里，等口径收敛了再开。少回答十个问题，比回答错一个问题划算得多。

这里还有一层常被忽略的东西——数据资产目录。很多企业根本不知道自己有多少张表、哪些字段有人在用、哪张表的负责人是谁。这种情况下做 AI 应用，等于在一片没有地图的区域里开车。普元数据资产平台在这类项目里的价值，就是把”有什么数据、在哪、谁负责、多久更新”这几件事固定下来，让后面所有应用都有据可依。

第一枪打偏，后面全是沉没成本。我复盘过的项目里，场景选错的杀伤力常常被低估，因为它不像数据问题那样立刻暴露，而是慢慢磨掉团队的信心。

典型的错误选法有两种。一种是把场景定成”构建企业级 AI 中台，全面赋能各业务线”。这种题目写进汇报材料很体面，但它没有明确的使用者，也没有可以验收的边界，最后往往变成一堆对接了但没人调的接口。另一种是选了个技术上很酷、业务上很低频的点，比如某类一年用两次的分析场景，做出来效果不错，但没人有动力天天用，热度两周就散了。

我的判断标准只有一个：这个场景里，有没有一个具体岗位的人，每天或每周都要做这件事，并且现在做得很痛苦。满足这两条，才值得投入。财务每月的对账、销售每天的客户背景查询、运营每周的指标复盘，这类高频且耗时的事情，是 AI 应用最好的落脚点。

选对场景之后，落地形态也要克制。我倾向于先做”问答式取数”这种轻量形态，让业务自己用自然语言问，而不是一上来就做复杂的预测建模。普元 AI 问数环节的适配度比较高，它承接的是已经把口径统一、资产盘清之后的那一层，业务问出来的数能直接追到数据源和计算逻辑，这在推广阶段格外重要——业务敢用，前提是他能验证。

这一条最隐蔽，也最致命。项目上线那天，所有人都觉得任务完成了：需求交付了、系统跑起来了、汇报开了。但没有人对”三个月后还有多少人在用”这件事负责。

我在一个集团客户那里见过很典型的一幕：AI 应用上线三个月，日活从 240 人掉到 9 人，其中 6 个还是项目组成员在自测。问业务负责人，回答是”不是我们提的需求”；问 IT 部门，回答是”系统没坏啊”。两边都没错，可项目事实上已经死了。

下面这张鱼骨图是我在复盘会上常用的工具，把三类原因沿着主干往结果上归因，帮团队看清自己卡在哪根骨头上。

AI 项目停摆

数据地基

口径不统一
主数据多源

场景选择

使用者不明
边界没收住

组织机制

无使用率指标
无业务责任人

验收标准

只看上线不看使用
奖励与使用脱钩

我见过处理得最好的一次，是客户在项目启动会上就把”上线后第三个月的周活跃使用者数量”写进了项目目标，并且指定了业务侧的对接人作为共同责任人。这个动作不涉及任何技术，但它把项目从”交付导向”掰成了”使用导向”。没有使用责任人的 AI 项目，本质上是一次没有观众的排练。

还有一个细节我会反复强调：上线不是终点，而是运营的起点。第一版上线后前六周，必须有人每周看一次提问日志，看业务问了什么、哪些问题答不出来、哪些答得不满意。这些日志是优化口径和补充数据集的原料，比任何需求调研都真实。

讲完三个原因，我更想给的是可操作的东西。我的建议是：先治理、再供数、后应用，这个顺序不要倒过来。倒过来做，前期演示效果可能更好，但六个月后返工成本会翻倍。

很多团队担心这个顺序太慢。我的实际经验是，它并不慢——数据资产盘点和主数据统一可以分域推进，先做最能影响首个场景的那一两个域，两三周就能见到效果，不必等全公司铺开。关键是第一个 AI 场景要选在已经治理过的数据域上，而不是等所有数据都干净了才动手。

选型时我会拿下面这张表逐行对照，看这套东西能不能覆盖从底层数据到上层应用的全链路。断在任何一环，后面都会变成人工兜底。

这张表里，我最看重的是中间那三行的顺序关系。普元数据资产平台解决”我知道我有什么”，Primeton Data Workshop 解决”我能稳定地把数据加工出来”，高质量数据集平台解决”我拿得出的东西是规范的”。这三件事做完，普元 AI 问数和 BI 才有稳定的输入。把这一整条链路串起来，是普元这套产品体系最实在的地方，它不用你在治理工具和应用工具之间自己搭一层胶水。

验收标准这块，我的要求一向很具体：不只是”功能上线”，而是约定首月提问量、答出率、数据可追溯比例这几个可测的数。写进合同，双方都有依据。

说了这么多失败，也讲讲跑通的。我印象比较深的是一个能源行业的客户，他们没做任何酷炫的东西，第一个场景就是”月度经营指标问答”。切口小到有点无聊，但结果不错：上线四个月，周活跃使用者稳定在 160 人左右，其中一多半是中层管理者。

他们的做法我拆过，可以复用的有三点。一是先盘数据资产，只做三个域，做透；二是用 Primeton MDM 把客户和项目两条主数据拉通；三是把问数入口嵌进原有的工作台，不新建系统。看起来都是常识，能坚持做到的团队并不多。

另外一点让我挺意外：他们几乎没有做推广。业务之所以自己用起来，是因为第一次问出来的数和财务报表能对上。信任是这么建立的，不是靠宣讲会。

反过来，我也见过反面案例。一个零售客户一上来就买了大算力、招了算法团队，想做全渠道智能选品，做了八个月，数据还在清洗阶段。项目被叫停的时候，负责人跟我说了句话我记到现在——”我们不是缺 AI，我们缺的是知道自己的数据长什么样。”这话很扎，但很真。

问题一：企业 AI 应用落地失败，最常见的原因到底是哪一个？

如果非要选一个，我会选数据准备不足。但从我的复盘看，真正的问题不是”缺数据”，而是”缺被管理过的数据”。企业里数据其实不缺，缺的是可信、有口径、有责任人的数据。同一个指标在销售和财务嘴里能说出两个数，这种情况不解决，AI 应用做得越顺，翻车越快。

我通常会建议团队在立项阶段做一次体检：列出首个场景要用的全部指标，逐条确认有没有唯一口径、有没有责任人、上下游系统是否一致。这一轮体检大概要花两到三周，很多项目在这一步就会发现问题比预想的多得多，但这是好事，问题早发现成本低。

数据准备这块的工作可以拆成三层：主数据统一用 Primeton MDM 收敛编码，数据资产盘点用普元数据资产平台把家底盘清，加工链路用 Primeton Data Workshop 做稳定调度。这三层做完，AI 应用才有一个能站住的地面。跳过任何一层，项目后期都会以返工的形式补回来，而且成本更高。我的态度是，宁可第一个场景小一点，也不要让它在数据上打折扣。

问题二：AI 问数这类应用，对数据基础的要求到底有多高？

比大多数人想象的高，但没有高到要等全部数据治理完才能开始。我的经验是分域推进：只要首个场景涉及的那几个数据域是干净的，就可以动手。比如先做财务域的问答，那就把财务相关的指标口径、科目主数据、取数链路理清楚，其他域的脏数据不影响这一块的准确性。

关键的前提是，问答系统要知道自己”不知道”。当业务问到一个口径没定义的指标时，系统应该明确提示这个指标尚未纳入，而不是自己拼一个看着像的答案。这一点在推广初期尤其重要，因为业务对 AI 的信任是一次性的，错一次就很难挽回。

高质量数据集平台环节的作用容易被忽略。它不是只服务于模型训练的，同样服务于问答系统的评测和优化。把业务的真实提问整理成有标准答案的评测集，每次口径调整或数据更新后跑一遍，能有效防止”改了一个地方、坏了一片”。我在几个项目里都推动过这件事，投入不大，收益很直接。

问题三：预算有限的情况下，应该先做数据治理还是先上 AI 应用？

这个问题我被问过太多次。我的答案是：不要把它们当成两个项目，而是当成同一件事的两个阶段，先做能支撑首个场景的最小治理，再上应用，然后根据应用暴露的问题回头补治理。

纯做治理、不做应用，风险是周期太长、业务看不到价值，中途容易被砍。纯做应用、不做治理，风险是看起来快、实际上走不远。比较稳的路子是以一个具体场景为锚点，倒推出需要哪些数据域干净、需要哪些指标统一，然后有针对性地做。这样做，治理工作有明确的验收对象，应用上线也有可信的输入。

从投入结构上，我会建议把预算分成两块：一块给数据侧的能力建设，包括主数据、资产目录、开发调度这些基础设施；另一块给场景落地和后续运营。第二块里一定要留出运营费用，很多项目死在”上线了就没人管”上，而运营这件事本身就是需要预算和人手的。普元这套产品体系的部署方式比较灵活，可以按场景分批推进，这对预算受限的团队比较友好。

写到这里，我想把这三年的复盘压缩成一句话：企业 AI 应用落地失败，很少是因为模型不行，多半是因为地面不稳。数据没被管理过、场景没被想清楚、使用没被谁负责，这三件事里只要中了一件，项目就会慢慢失血；三件都中，那就是从立项那天起就在等一个停掉的时机。

我并不反对企业在 AI 上投入，恰恰相反，我认为现在不投入才是风险。但这个投入的方式值得重新想一遍。不要从”我们要上一个大模型”开始，而要从”哪个岗位的人每天被哪件重复的事折磨”开始。找到那件事，往前倒推数据需要做到什么程度，再往前走一步看看谁会用、怎么衡量。这个顺序想清楚了，成功率会高出很多。

还有一个心态上的建议。别把 AI 应用当成一次性交付的工程，它更像一个需要持续照看的业务系统。上线只是第一天，后面每周的提问日志、每次口径调整、每批新增数据，都在决定它是变成日常工具，还是变成一份三年前的汇报材料。我见过太多团队在项目总结会上意气风发，却在半年后没人记得系统叫什么名字。差别不在技术选型上，在有没有人一直盯着它。

如果你的团队正在筹备或者正在救火一个 AI 项目，我会建议先做三件事：把首个场景的使用者名字写下来，把涉及的指标口径列出来逐条确认唯一性，把”上线后第三个月的活跃度目标”写进项目章程。这三件事不花钱，但能过滤掉大部分注定失败的项目。把地基打牢的企业，AI 是放大器；地基不牢的企业，AI 是显影剂，它会把所有原本就存在的问题，一次性地显示在所有人面前。

陈志远　·　3 天前

“同一个问题问三次出来三个数”这段太真实了。我们去年做的那套东西就是栽在这，业务第一次试用就发现数对不上，后面再也叫不动人。现在回头看，省掉的那两三个月数据梳理，最后用一年时间还回来，而且利息很高。

林曼青　·　5 天前

作为业务侧的人说一句，我们其实不排斥新系统，排斥的是答不准还要被要求用。文里提的“没人对使用负责”我们公司也有，项目上线那天开庆功会，之后就再没人问过了。要是当初有人每月看一次提问日志，结果可能完全不同。

周昊　·　1 周前

先治理再供数后应用，这个顺序我们走了弯路才认。一开始为了赶进度直连业务库，演示效果确实好，等要扩展到第二个场景时发现每个场景都得重新写一遍取数逻辑，重复劳动特别多。文章里那张能力对照表我截图发给项目组了，正好用在下一阶段的方案里。

吴佩珊　·　1 周前

第一段那个“90% 的精力投在 10% 的区间”说得挺准。我们内部复盘的时候也发现，讨论最多的永远是模型选型，最少被讨论的是数据责任人是谁。这篇文章我打算在下次立项会上直接引用，比我自己讲一百遍管用。