AI 落地的 5 个死亡陷阱——以及绕过它们的代价。
5 年咨询、100 个项目，我把所有失败案例归纳成 5 类。识别陷阱比设计方案更重要。
写在前面
过去两年，我参与或复盘了将近 60 个 AI 落地项目。成功的大约占 30%——这个成功率比 IT 项目的平均水平还要低。
失败有各种各样的表面原因：工具选错了，团队抵触，数据不干净，预算不够，老板换了方向……但我越来越感觉，这些表面原因背后，有 5 种深层模式在反复出现。
我把它们叫做"AI 落地的 5 个死亡陷阱"。
不是每个项目都会踩全，但几乎每个失败的项目，都踩了其中至少两个。
陷阱一：用 AI 解决一个你自己都说不清楚的问题
这是最常见也最致命的陷阱。
表现是这样的：老板说"我们要用 AI 提升效率"。顾问问"提升哪个环节的效率"。老板说"全面提升"。顾问再问"全面提升的衡量标准是什么"。老板说"你看着做，做完了我们来评估"。
这就死了。
不是因为老板懒，而是因为"效率"是一个无限可以解释的词，它既可以是"员工人均产值提高 20%"，也可以是"某个流程的处理时间从 3 天缩短到 1 天"，也可以是"客户等待时间从 24 小时变成 1 小时"。这三件事的解决方案、所需工具、投入成本完全不一样。
更危险的是，当问题没有被说清楚时，AI 工具的供应商会帮你"说清楚"——他们会把你的模糊问题翻译成他们工具能解决的版本。这个翻译几乎一定有偏差。
绕过方法：在任何 AI 项目启动之前，先把目标写成一句话，格式固定："在[什么时候]，让[哪个指标]，从[现状数值]变成[目标数值]，从而带来[多少业务价值]。" 这句话如果写不出来，项目不启动。
陷阱二：把 AI 项目当 IT 项目管理
这个陷阱很隐蔽，因为大多数公司都没有"AI 项目管理"的经验，自然默认用 IT 项目的逻辑来套。
IT 项目的特征是：需求明确，方案固定，进度可控，验收标准清晰，最终结果是一个"上线或不上线"的二元状态。
AI 项目的特征恰恰相反：需求在实施过程中会演变，方案需要边跑边调，效果是一个连续的分布而不是一个二元结果。
一个典型的死法是这样的：项目启动，合同里写好了"6 个月上线，交付物包括 A、B、C 三个系统模块"。三个月后，A 模块的数据质量不达标，B 模块发现了更重要的业务需求，C 模块的前提假设被推翻了。但合同不能改，老板不愿意追加投入，团队只能在原来的框架里挣扎，最后拿着一个"名义上上线"但实际上没人用的系统完成了交付。
绕过方法：用"sprint + 周验证"代替"里程碑 + 月验证"。每两周有一个可以演示的、哪怕很小的结果。验证的标准是业务效果而不是功能完成。"系统上线了"不是验证，"销售用这个系统多约了 3 次客户"才是验证。
陷阱三：让最懂 AI 的人负责项目，而不是最懂业务的人
这个陷阱让我解释的时候总是有点尴尬，因为很多顾问就是这样介绍的。
逻辑是这样的："AI 是新技术，需要懂 AI 的人来主导。" 这个逻辑表面上成立，但在落地层面是反的。
AI 落地的核心挑战不是技术，是让 AI 生成的结果被业务团队信任和使用。这个挑战需要业务负责人来解决，因为只有业务负责人才有足够的权威说"这个 AI 的建议，我们下周就开始执行"。
我见过最糟糕的配置：一个聪明的 AI 技术负责人，带着一个跨部门的"AI 专项组"，在没有核心业务线 KPI 压力的情况下推进 AI 项目。三个月后，他们建了一个非常好用的内部数据平台，但没有任何一条业务线因此而改变了它的 KPI。数据平台被闲置。
绕过方法：项目负责人必须是某条业务线的核心 KPI 所有者。技术团队（无论是内部还是外部顾问）是服务者，不是主导者。"这个 AI 项目成功的标准，是我这条业务线的数字变好了"——这句话，必须由业务负责人说，而且发自内心地信。
陷阱四：在数据还不干净的时候就上 AI
这个陷阱在谈 AI 的文章里被说了很多遍，但依然是被踩得最多的一个。
"数据不干净"的表现：不同系统里同一个客户有三个 ID，历史销售数据里有大量"测试订单"没有被清洗，产品主数据里 SKU 命名规范不统一，门店数据只有线下没有联动线上……
把不干净的数据喂给 AI，结果是什么？是"非常自信地给出错误答案"。AI 的特点是它永远会给出一个答案，而且回答得非常流畅、非常自信。当这个答案基于脏数据时，它比不回答还危险。
一家连锁餐饮公司花了 6 个月上了一套 AI 供应链系统，系统不断建议降低某个城市的食材备货量，因为那个城市的"历史数据显示需求低"——而实际上，那个城市有 3 个月的数据因为系统迁移问题没有被正确导入，AI 在分析一个残缺的真相。损失了大概 200 万的备货短缺带来的营业额。
绕过方法：在 AI 项目启动前，先做一个为期两周的"数据体检"——只看三件事：数据的覆盖率、数据的一致性、数据的时效性。任何一项不达标，先修数据，再谈 AI。这两周的投入，比后来踩坑的代价小几十倍。
陷阱五：第一个 AI 项目太大
这是最后一个，也是我觉得最可惜的一个陷阱，因为它通常发生在老板最有决心的时候。
老板研究了半年 AI，确信这是不可逆的趋势，决定"要么不做，要做就做彻底"。于是启动一个大项目：全供应链 AI 化，或者全客服 AI 化，或者全员 AI 助理化。预算 500 万起，周期 18 个月。
18 个月后，公司的市场、竞争、组织结构都变了，最初的需求假设大多数已经过时。而这个大项目因为体量太大，调整一次需要几个月的重新规划，最终在一半完工、一半废弃的状态下结束。
这个结局会产生两个非常有害的后遗症：第一，"AI 没用"的组织认知会被固化，下次再推动 AI 项目会遭到更大的阻力；第二，在这 18 个月里，那些本来可以快速跑通的小场景被压制了，错过了积累 AI 能力的窗口期。
绕过方法：第一个 AI 项目的规模，预算不超过 50 万，周期不超过 3 个月，聚焦在一个有明确 KPI 的场景上。这不是因为小项目更值钱，而是因为小项目的成功能建立组织对 AI 的信任，而这个信任是后续大项目能成功的前提。没有这个信任，任何规模的项目都会死在内部阻力上。
结语：绕过陷阱的代价
文章标题里有"绕过它们的代价"。这个代价是什么？
代价是：你需要在项目启动之前，就愿意花真正的时间想清楚一些不舒服的问题。 比如"我现在最贵的问题是什么"，比如"我愿意让业务负责人把 AI 项目当作自己的 KPI 负责"，比如"我愿意先做数据体检再做 AI 系统"。
这些问题每一个都需要老板自己的决心，不是顾问能替代的。
陷阱之所以反复有人踩，不是因为不知道，而是因为绕开陷阱需要付出一些在启动时"看起来不必要"的成本。
但这笔成本，早花比晚花便宜十倍。