企业 AI 落地这两年最常见的抱怨是”试点效果很好，规模化就死”。但把几十个项目的复盘摊开看，会发现一件更本质的事：大多数项目不是死在技术实现上，是死在选型阶段——那个场景从一开始就不适合用当时的模型能力去做。模型在那件事上只有 70 分的水平，而业务需要 95 分，中间的 25 分不是靠调 prompt 能补上的。
这次我们把 18 个月内做的 42 个 AI 项目翻出来重新算账，诚实到了有点难看的地步：19 个成功、15 个失败、8 个处于”说起来还在跑但业务已经不用了”的僵尸状态。这篇文章不复盘技术，只复盘一件事——当时是什么信号告诉我们这个项目会失败，而我们为什么没看见。
一、先定义什么叫”成功”，不然账没法算
很多团队的复盘失真，是因为把”上线了”当”成功了”。我们的口径更严，四条同时满足才算成功：
- 业务指标真的动了（不是效率指标的漂亮数字，是营收/成本/风险三类里至少一类被财务或业务负责人书面确认）。
- 仍在被使用——我们按 90 天活跃口径回头看，僵尸项目直接判失败。
- 有人对它的结果负责。没有 owner 的项目，出问题没有人管，等于没有兜底。
- 边际成本可控，不存在”规模越大亏损越多”的结构性问题。
用这个口径，42 个项目的分布是：成功 19（45.2%）、僵尸 8（19.0%）、失败 15（35.7%）。而这 8 个僵尸项目，是最值得研究的样本——它们功能完好、指标体面，只是业务部门某一天起就不打开了。
二、42 个项目的真实得分：哪一类场景最值得先做
| 场景类型 | 项目数 | 成功 | 僵尸 | 失败 | 成功率 |
|---|---|---|---|---|---|
| 内部知识检索（RAG） | 11 | 7 | 2 | 2 | 63.6% |
| 客服 / 工单处理 | 9 | 5 | 1 | 3 | 55.6% |
| 内容生成（营销 / 文案） | 8 | 3 | 2 | 3 | 37.5% |
| 代码辅助 / 研发提效 | 7 | 3 | 1 | 3 | 42.9% |
| 决策支持 / 数据分析 | 4 | 1 | 1 | 2 | 25.0% |
| 流程自动化（Agent） | 3 | 0 | 1 | 2 | 0% |
| 合计 | 42 | 19 | 8 | 15 | 45.2% |
三个值得记住的规律：
第一，成功率最高的不是最热的方向，而是最”有据可查”的方向。内部知识检索 63.6% 的成功率，是因为它有明确的对照物——用户以前要花多少时间找到答案，现在花多少。指标越接近真实业务行为、越少主观评价，项目越容易活。
第二，Agent 项目 0 成功，但它不是技术不行，是”责任链”没设计。三个流程自动化项目全部倒在同一个地方：出事以后没有人能定义”这一步该不该让 AI 做主”。法律、财务、运营都能从自己的角度提出否决理由，但没有人能说出”允许它错到哪一步”。
第三，内容生成类 37.5% 的成功率低于想象，但不是效果问题，是口径问题。三个失败项目里有两个的质量指标其实达标了，但业务方心里的及格线是”能不能直接对外发”，而我们交付的是”要改三成”。这不是模型的问题，是开始时没有把”合格”定义清楚。
三、八类失败原因：占最多的那个，和技术完全无关
| 失败原因 | 命中项目数 | 占比 | 起步阶段能否预判 |
|---|---|---|---|
| 成功标准没有对齐（口径之争） | 9 | 60.0% | 能，访谈就能发现 |
| 数据质量不达标（没有可用的输入） | 7 | 46.7% | 能，做一次数据摸底 |
| 模型能力低于该场景的正确率阈值 | 6 | 40.0% | 能，用小样本试跑 |
| 组织阻力 / 没有 owner | 6 | 40.0% | 能，看谁签字谁出钱 |
| 上线后无人使用（僵尸化） | 5 | 33.3% | 部分能 |
| 集成成本被低估（系统对接） | 4 | 26.7% | 能，让工程给出评估 |
| 成本模型不成立 | 3 | 20.0% | 能，按峰值估算 |
| 合规 / 数据风险 | 2 | 13.3% | 能，一次法务评审 |
15 个失败项目平均命中 2.2 个原因，而 9 个项目的首要原因是”标准没对齐”。这类失败的典型过程是：技术团队按”准确率上 90%”来打磨，业务团队按”能不能直接用”来验收，双方都没有说谎，只是尺子不同。到 Demo 那天才第一次对齐，成本已经付了。
第二个高信号是”模型能力低于阈值”。六个项目在选型时就能用一个 100 条的试跑集判断出来，但当时所有人的兴奋点在”能不能跑通 Demo”。Demo 跑通的能力门槛，比生产门槛低一个数量级。
四、我们后来强制的四道闸门：成本在闸门口付，不在上线后付
| 闸门 | 时点 | 交付物 | 挡掉了什么 |
|---|---|---|---|
| 1. 口径闸 | 立项前 | 一页《验收口径书》，业务负责人签字 | 标准之争、口径返工 |
| 2. 数据闸 | 口径确认后 | 一次真实数据摸底报告 | 没有可用输入的幻觉 |
| 3. 能力闸 | 100 条小样本试跑 | 分场景正确率与阈值对比表 | 能力不足的场景 |
| 4. 集成闸 | 立项前 | 工程给出的接入工时与接口清单 | 被低估的集成成本 |
四道闸门最大的价值是顺序。必须是口径 → 数据 → 能力 → 集成，因为口径不清，后面的数据摸底和能力试跑全都测的是错的东西。42 个项目里，有 5 个失败项目是把顺序做反了——先做了两周技术验证，然后才回头问业务”你们到底要什么样的结果”，拿到答案之后发现那个场景不成立。
另一个必须配套的东西是”阈值”。没有阈值的能力闸是无效的。我们把阈值分级写进口径书：对外交付类 95%、内部效率类 85%、辅助建议类 75%。低于对应阈值的场景，不许立项。这一条单独看是保守，实际是省钱的——它砍掉了后面至少两个项目的返工。
总结
42 个项目的复盘可以压成三句话：45.2% 的成功率是常态，不必为此焦虑；但失败原因里排第一的不是技术，是”成功标准没有对齐”，这一项在立项前一天就能查出来;四道闸门按口径、数据、能力、集成的顺序排，能让成本在门口付完，而不是在上线之后反复付。
更重要的认知是：企业 AI 落地真正的瓶颈，是把”这个场景能不能成”的判断从 Demo 阶段往前挪。Demo 证明的是”能做”，立项要证明的是”该做”和”做成什么样算成”。后者不需要模型参与，只需要团队诚实地写下验收口径和正确率阈值。把这件事做扎实，比多接一个 API 的回报高得多。
互动提问：你们公司现在做 AI 立项，有没有一份业务负责人签字确认的验收口径书？还是先跑 Demo 再说？
互动提问：那 8 个”僵尸项目”里，你们见过的是技术问题还是口径问题——业务是真的不用了，还是从来就没真用过？
— IMAI 编辑部 | 2026-11-02