作者：复盘我们经手和旁观的烂尾AI项目，死因排前三的，没有一个是纯技术问题。模型不行、数据太差这类理由，常常只是墓碑上好听的写法。真正的AI项目失败原因，多数在开工之前、甚至立项之前就埋好了，这篇把几种常见死法摆出来——对号入座，好过事后验尸。下面四种按出现频率排序，前两种尤其常见，几乎每三个烂尾项目里就有两个栽在这里。
死法一：目标定成“上AI”，而不是解决某件事
“我们也要搞AI”是能拍板的口号，不是能验收的目标。它的必然结局是：验收时没人说得清“成了”长什么样，收尾按“系统上线”交差——系统确实上线了，然后没人用，三个月后成为新人入职时听说的传说。顺手搭进去的还有团队信心：下一次谁再提AI，会议室里的眼神就变了。
识别这种项目很容易：立项书里全是技术名词，没有一个业务动词；验收标准写着“系统稳定运行”——稳定运行解决的是谁的问题呢。健康的立项长这样：把某个环节的人力时间砍一半；把某类咨询的自助解决率做到七成。目标里有业务动作和数字，才算数。再教一个识别技巧：让立项的人用一句话回答“这个系统上线后，谁的工作会变少、变少的部分去了哪”——答不上来的，大概率就是这一型。
死法二：数据家底没盘就开工
演示阶段用的是厂商的漂亮数据，正式开发才发现：文档全是扫描件，客服记录导不出来，两个系统的客户编号对不上。数据治理一拖三个月，预算烧掉三分之一，团队士气先于项目垮掉。
开工前花一两周盘数据家底，是全流程最便宜的保险。盘点清单不复杂：有哪些文档和记录、在各系统谁手里、能不能导出、干不干净；产出一张数据现状表，多少能直接用、多少要洗、多少干脆没有，白纸黑字摆到立项会上。盘完之后常会冒出一个好消息：不少场景根本不需要“治理三个月”，挑数据最齐的那一小块先做，剩下的边跑边补——盘点不是为了证明做不了，是为了知道从哪能做。这一步偷的懒，后面都会加倍还。
死法三：业务方没有一号位
IT部门牵头立项，业务部门全程旁观。系统做出来，业务的第一句反馈是“跟我们的实际流程对不上”——这话出现在测试阶段还来得及改，出现在上线之后，就是烂尾倒计时。根源常常不在态度在机制：业务的考核表里没有“配合数字化”这一项，凭什么指望人家把最懂流程的人长期借给你？立项时就把这笔投入算进业务方的产出，才是解法。
业务方是真是假投入，用三件套判断：验收人签字担责、每周固定例会不出席就顺延、试用阶段业务骨干真出工作量。三样齐了是动真格，一样没有就是挂名——挂名的项目，慎重开工。还有一种变相的旁观：业务方参与了，但派来的是刚入职的年轻人，主官从不出席。形式上有人的项目，本质还是没人的项目，判断时看职务分量，不看人数。
死法四：一把梭，不留退路
预算一次批完，范围一次锁死，中途没有任何验证点。等发现方向不对，钱已经花完了，沉没成本又逼着所有人继续演——这是最烧钱的一种死法。
分阶段打法不是为了省钱，是为了留纠错机会：一个季度一个台阶，每个台阶有可验收获益；每阶段结束留“继续、调整、停止”三个选项——注意，停止也是合法选项，敢写进制度，项目反而死不了。预算结构上也能留退路：把预算切成三段，每段解锁需要上一段的验收结论签字——钱怎么花这件事管住了，一把梭的冲动就管住了一大半。怎么挑第一个小场景，在AI先试的三个场景里写过。小步快跑听着朴素，但它是烂尾名单里出现频率最低的姿势。烂尾不可怕，可怕的是烂尾之后不知道为什么烂尾——把死法认全了，下次绕着走。
项目还没立项的，建议先把这篇转给拍板的人看一眼；已经在做、心里打鼓的，打18616880101找玉雀科技做个中期体检——比烂尾之后再补救，便宜得多。