比成功案例更有价值的是死亡案例。我们复盘过不少中途停摆的项目，发现AI落地的失败方式高度重复，基本收敛在六类死因上，而且每一类都有明确的早期征兆。本文把这六类死因、征兆和补救动作摊开写，最后给一份尸检清单，帮你在项目还有救的时候就发现问题，而不是等预算烧完才开总结会。

死因一：场景没有主人

最常见的一种。项目立项时由IT或战略部提出，业务部门只是"配合"，于是需求没人拍板、数据没人给、结果没人验收。征兆很明显：需求评审会业务只派实习生参加，试用反馈永远是"还不错"这种没有信息量的话。补救办法是暂停开发，重新找一位愿意把自己的KPI押上去的业务负责人，找不到就换场景。某企业连换两个场景才找到真正着急的仓储主管，项目随后六周内跑通。

死因二：数据脏得超出预期

方案阶段假设数据可用，开发阶段才发现物料编码三套并行、客户名称五种写法、历史工单一半没有结论字段。这类项目通常在第三到六周开始延期，然后陷入无限期的数据补齐。征兆是数据同学开始频繁说"这个字段的含义我们再确认一下"。正确处理是立刻把项目切成两段，先用两到四周做主数据和字段治理并单独验收，再回到模型开发，而不是让两件事互相拖累。

死因三：指标定得虚，成败说不清

项目目标写成"提升智能化水平""增强客户体验"，上线后自然谁也说不清成没成，于是无人续投，项目自然死亡。征兆是立项文件里找不到一个带数字和口径的指标。补救动作是补做基线测量：花一周把现状的工时、错误率、周期时长量出来，把目标改写成可核算的形式。没有基线的项目，等于从一开始就放弃了自证价值的机会。

死因四：只做主流程，不做兜底闭环

演示环节一切顺利，真实用户一上来就问出模型答不了的问题，而系统既不转人工也不记录，用户吃两次亏就再也不来了。征兆是需求文档里没有"答错怎么办"这一节。必须补的是四段闭环：识别不确定、转人工、收集错误样本、定期回灌知识库。某客服项目上线首周准确率只有六成八却活下来了，正是因为兜底顺畅、样本回流及时，六周后升到八成七。

死因五：成本失控，账算不回来

按调用量付费的场景没有设配额，一次批量任务把月度预算烧掉大半；或者为了追求几个百分点的准确率，把上下文塞满导致单次成本翻了几倍。征兆是没人能回答"每处理一单花多少钱"。做法是从第一天就把单位成本作为跟踪指标，设置预算告警和配额，并在方案里明确"多少准确率是够用的"。够用比最优重要，AI落地的账必须算到单笔。

死因六：一次交付，无人运营

上线即散场，没有人负责监控准确率、更新知识、处理反馈。三个月后制度改了、产品换代了，模型还在用旧信息回答，用户流失后项目悄然下线。征兆是项目计划里只有开发和上线，没有运营岗和运营预算。补救是明确运营责任人、固定月度检视机制、把知识更新写进某个岗位的日常职责，并给运营留出不低于建设投入两成的年度预算。

一份可直接用的尸检清单

项目每月自检六问：场景有没有一位押了KPI的业务主人；数据治理是否已单独验收；目标是否有带口径的基线和数字；答错的兜底闭环是否跑通；单位成本是否可测且在预算内；运营责任人与预算是否落实。六问里有两问答不上来，就该停下来修，而不是继续往前赶进度。这张清单花二十分钟就能过一遍，却能省下大半年的返工。

小结

AI落地失败很少是因为模型不行，多半是没有主人、数据脏、指标虚、缺兜底、成本失控、无人运营这六件事之一。它们都有早期征兆，也都有明确的补救动作。把尸检清单变成月度例行动作，项目就有机会在还能救的阶段被救回来。