AI 项目失败最常见的三种死法，签字立项前就能看出来

AI 项目失败后的复盘会，三方吵的从来不是同一件事

项目停了半年，复盘会准时开。老板先开口：供应商当初吹得太狠，说什么都能做。IT 负责人接话：图纸在研发各自的电脑里、库存表在 Excel 里、订单在 ERP 和微信群里各存一份，数据从来没理顺过，神仙来做也做不好。业务部门最后发言：我们当初就说这个东西没用，是你们非要上。

三个人说的都是事实，但三个人都没说到死因。老板怪的是「选了一个没有真实数据验证的场景」；IT 怪的是「数据没理顺就开工」；业务部门的沉默，则是「上线后没人用没人维护」的另一种说法。

我们在工厂里做 AI，见过的死法基本就这三种。它们不是运气问题，而是立项时的三个决定：场景怎么选、数据怎么办、上线后谁负责。接下来把三种死法拆开摆平，再给签字前就能用的识别办法。

三种死法摆在一起：死因、早期信号和能不能救

这张表最容易被忽略的是「早期信号」这一行。三种死法在真正烧钱之前都亮过灯，区别只在于当时有没有人抬头看一眼。而最后一行解释了为什么失败总在半年后才被承认：承认失败本身要过一道心理关，拖得越久越难开口。

签字之前，用三个问题把三种死法的前兆问出来

第 1 问：能不能拿我们自己的真实数据，先试跑一次？

不用等签合同。拿 100 份你们真实的文档、真实的订单或真实的工单，让供应商一周内跑出结果，现场看准确率。对方如果只肯演示他家准备好的案例，说明这个场景还没在你的数据上被验证过——这是死法一的前兆。这一步最多花一两周，比签完合同再发现便宜得多。三个问题怎么向供应商开口、问到什么程度算过关，可以看签合同前必须问清的八个问题。

第 2 问：这个项目用到的数据，归谁管？

别问「我们数据质量好不好」这种谁也答不上来的问题。指名道姓地问三样东西：BOM 表归谁维护、工艺文件存在哪、库存台账多久更新一次。三个问题有一个答不上来，说明数据没人管，开工后光是找数据、对口径就要耗掉近一半的工期——这是死法二的前兆。数据没人管不是不做项目的理由，但意味着第一期预算里要留出钱和时间先理数据，这件事没人在乎，项目几乎必死。

第 3 问：上线之后，每天谁来用、出了问题谁来管？

让业务部门当场点名到人，写进立项书——不是一个部门名，是一个具体的人，连他每天什么时候用、用来干什么一起写。答案是「大家一起用」「到时候再说」，就是死法三的前兆。没人认领的系统，上线那天就是它这辈子最忙的一天。

多数来找我们「救项目」的厂，死在第 2 问和第 3 问的组合上：数据边做边理，人到最后也没定。所以这两问不要合并成一句「你们业务要配合」带过。场景本身靠不靠谱、为什么标准产品进了非标车间常常跑不动，可以对照非标制造的 AI 两难再核一遍。

立项阶段最该避开的六个坑

把供应商的演示当成自己厂的效果。 演示数据是挑过的，挑的都是系统最擅长的样本。合同里要写死：验收指标用你们自己的数据测，抽多少样本、准确率到多少算过，逐条写清。这一条不愿意写进合同的供应商，本身就是信号。

用「系统上线」当项目的终点。 上线只是中点，不是句号。合同里把验收后 3 个月的使用情况写进去：多少人登录、处理了多少单、业务部门打几分。只验收功能、不验收使用，等于亲手给死法三留后门。

让 IT 部门单独背这个项目。 AI 项目是业务项目，不是 IT 项目。IT 能保证系统活着，保证不了有人用。立项书上要业务部门负责人联签，项目例会业务必须到场。这一条做不到的厂，成功率掉一半不止——我们的判断，不是行业统计。

为了补贴立的项，验收完就死。 补贴能覆盖一部分开发成本，覆盖不了数据整理和日常运营。为补贴做的项目，验收材料通常齐全，使用记录几乎为零。把补贴当锦上添花可以，当立项理由，是拿厂里的信誉给政策陪跑。

第一期摊子铺得太大。 立项书里写着「覆盖 6 个场景、打通 3 个车间」，基本等于给三种死法各发一张邀请函。第一期只做 1 个场景，90 天内要看到结果：要么见效，要么止损。预算可控，人心也可控。

出问题先想着换供应商。 先查死因，再换人。如果是死法二，数据没理顺，换谁来都要重新理一遍；如果是死法三，没人用，新系统来了还是没人用。换供应商之前，把上面三个问题对新供应商再问一遍——多数情况下，这会帮你省下第二次学费。另外，部署方式属于签完合同就很难再改的决定，别在救项目的关口又添一个新变量，参考部署方式怎么选。

要一句话总结这六个坑：所有「到时候再说」的，最后都会变成「当初怎么就」。