90%的企业AI项目死在了上线之前

我见过太多这样的项目：立项时PPT做得无比精良，老板拍桌子说“这是公司战略级方向”；三个月后，团队开始静悄悄地把排期往后挪；半年后，项目群里只剩下偶尔的一条“正在推进中”；一年后，没有人再提起它。

这不是某一家公司的故事。这几乎是当下大多数企业AI项目的标准死亡路径。失败不是因为技术选错了，也不是因为预算不够。真正的死因，藏在项目启动那一天就种下的根里。

不是技术不行，是死法太相似。

一、把“我们要做AI”当成需求

很多项目从一开始就错了。老板在某个论坛听了一场分享，回来说：“我们也要做智能客服，做知识库问答，做AI助手。”于是项目立项，需求文档洋洋洒洒写了几十页，但通篇没有回答一个最基本的问题：

这个AI，要替代谁现在在做的什么事？

“提升效率”不是需求。“用AI赋能业务”不是需求。“让员工更智能地工作”更不是需求。

真正的需求，应该精确到：“现在每天有XX个客服坐席，平均每人处理YY条重复咨询，我们希望AI能接管其中ZZ%，把坐席从这些低价值问题里解放出来。”

需求模糊，一切后续都是沙滩上盖楼。评审时没人能说清楚“做成了”是什么样子，上线后也没人知道该怎么算成功。项目最终在一片“方向是对的，但效果还需要打磨”的安慰中悄然搁置。

可以做的事： 项目立项前，先用一周时间和一线业务人员坐在一起，把他们每天重复做的、最烦的、最耗时的事情列出来，再从里面挑AI真正能解决的那一个。只挑一个，做透。

二、用“先进”替代“合适”

技术团队有个通病：喜欢用最新的。

大模型刚火的时候，很多团队不管三七二十一，把所有场景都往大模型上套。结果是：一个只需要关键词匹配就能搞定的工单分类需求，被包装成了RAG+向量检索+LLM重排序的完整链路，延迟高、成本贵、效果还不如原来的规则系统。

技术选型的核心逻辑只有一句话：用刚好够用的技术，不用过度设计的技术。

问问自己：这个需求，规则系统能不能做到80分？如果能，先做规则，把那20分留给后面迭代。AI不是银弹，它擅长处理模糊、非结构化、海量的内容，但如果你的场景是结构化、规则清晰、量不大，用AI反而是给自己找麻烦。

另一个常见误区是把技术选型和供应商绑定混为一谈。某云厂商的销售包装得很好，演示时效果惊艳——但那是在他们精心准备的数据集上跑的，不是在你乱七八糟的历史数据上。签合同之前，一定要用自己的真实数据做一轮评测，哪怕只是小样本的。

三、低估了“脏数据”的破坏力

AI项目有一个听起来老生常谈、但每次都被低估的问题：数据。

不是没有数据。大多数企业其实数据不少，几年的订单、工单、日志、聊天记录，存了一大堆。问题是，这些数据从来不是为了训练AI而生的。

你打开一看：字段缺失、格式不统一、同一个意思十几种写法、历史数据里混着大量测试数据、甚至有些标注根本就是错的。

团队在立项时预估数据清洗需要两周，实际上两个月还没做完。这还不是最惨的，最惨的是：清洗完才发现，有效数据根本不够训练一个像样的模型。

数据阶段的三个血泪教训：

1. 先做数据摸底，再立项。 把有多少数据、质量如何、标注覆盖率是多少，作为项目可行性判断的前置条件，而不是立项后再去摸。
2. 数据清洗的工作量，至少乘以3倍估算。 这不是在开玩笑，这是无数项目踩坑后的经验系数。
3. 没有足够数据，先做规则+小样本，别硬上全量微调。 现在的大模型few-shot能力很强，在数据不足的阶段，精心设计的prompt往往比草率的微调效果更好。

四、用“感觉还不错”代替真实指标

项目跑了两个月，老板问效果怎么样，负责人说：“整体感觉还不错，准确率挺高的。”

多少？不知道。和基线比提升了多少？没有基线。误召回率是多少？没测过。

这不是在批评团队不专业，这是在指出一个系统性问题：很多企业AI项目，从来没有定义过“好”是什么。

没有评估体系，就没有迭代方向。每次优化都是凭感觉，改了一个地方，也不知道是变好了还是变差了。最终项目陷入“测试说好、上线翻车”的怪圈。

评估体系不需要很复杂，但必须在项目启动时就确定好，至少包括：

• 自动化指标：Precision、Recall、F1，或者你这个场景对应的业务指标
• 业务指标：转化率、处理时长、人工干预率——这些才是老板真正关心的
• 对比基线：现有系统或人工的表现是多少，AI要超过多少才算有价值

有了这些，项目才有客观的推进依据，而不是靠汇报PPT上的“进展顺利”撑着。

五、一次性全量上线，赌命式部署

终于到了上线，团队憋了大半年，恨不得一次性把所有功能都推上去，给老板一个惊喜。

结果往往是另一种惊喜：线上流量一来，各种边界情况全出现了；模型在测试集上表现很好，但遇到真实用户的输入就开始抽风；某个没有覆盖到的场景大量出现，误回复被截图发到了社交媒体上。

灰度发布不是可选项，是标配。

正确的上线姿势是：先用1%的流量跑，盯着错误日志和用户反馈，跑稳了再放5%、10%、50%，最后才是全量。每一个阶段都要有明确的通过标准，达标了才往下走。

另一个容易被忽视的点是回退预案。万一上线后出了严重问题，能不能在10分钟内切回旧系统？这个问题，很多团队直到出了事故才开始想。

上线不是终点，是另一种开始。模型上线后，线上数据会源源不断地产生，哪些case模型处理得好、哪些case还在翻车，都需要有人持续盯着，定期把这些数据回流到训练和优化里。没有这个闭环，模型只会越来越落后于真实业务的变化。

六、AI团队和业务团队各干各的

这是最隐蔽、也最致命的一种死法。

技术团队关在自己的屋子里做模型，业务团队继续用原来的方式工作。两边偶尔开一次对齐会，说说进展，然后各回各的岗位继续干。

等到AI系统做出来，推给业务用，才发现：业务根本不愿意改变现有工作流程来配合AI；AI的输出和业务实际使用的格式对不上；业务最熟的几个高频场景，AI根本没覆盖到。

这不是业务的问题，也不是技术的问题，这是协作模式的问题。

成功的AI项目，几乎都有一个共同点：业务人员深度参与了整个过程，而不只是在立项时提需求、上线时做验收。他们应该参与数据标注的质量审核，应该在测试阶段给出真实的使用反馈，应该在灰度阶段作为第一批用户。

如果你的项目里，业务侧只有一个“对接人”，每周来开一次会，其他时间都是技术团队在闭门造车，那这个项目大概率做不出来什么真正有用的东西。

七、把AI当魔法，而不是工具

最后说一个软性的问题，但它往往是压垮项目的最后一根稻草。

很多企业对AI有不切实际的期待：以为上了AI就能一劳永逸，以为准确率能到99%，以为上线后就不需要人工维护了。

这种期待本质上是把AI当成了魔法——买一个神器，插上电，问题自动解决。

但AI是工具，不是魔法。它的边界很清晰：擅长的场景它能做得很好，不擅长的场景它会很稳定地犯错。它需要持续的数据喂养、持续的模型迭代、持续的人工审核兜底。这不是缺陷，这是它的工作方式。

真正能落地的AI项目，背后一定有人在默默做这些“不性感”的工作：清洗数据、审核bad case、写测试用例、更新评估集。这些事做好了，AI才能真正变成业务的一部分，而不是汇报材料里的一个亮点。

结尾

AI项目为什么死？不是因为大模型不够强，不是因为GPU不够多，不是因为竞争对手太厉害。

是因为需求没想清楚就动手了，是因为数据问题被严重低估了，是因为评估体系从来没建过，是因为上线方式太激进，是因为业务和技术两张皮，是因为把一个需要持续投入的工程项目，当成了一锤子买卖。

这些问题，每一条都不稀奇，每一条都曾经有人提醒过，但每一条都还在被一批又一批的项目反复踩。

差别只在于：踩坑之前就知道，还是踩进去之后才想起来。