为什么 60% 的企业 AI 试点停在 Demo？9 个失败模式

结论先给：失败几乎都在模型之外。 超过 60% 的企业 AI 尝试停在试点阶段，卡点不是“模型能不能做”，而是系统怎么对接、权限怎么梳理、数据质量够不够、流程要不要改、组织里谁配合。下面九个模式都能在投入之前被识别。

卡点为什么总在模型之外

模型能力按季度进步，把它接进企业的工作没有变快。一项覆盖 1500 名 FDE 的调查显示，这类角色的时间分配是客户沟通 47%、写代码 31%、内部协调 22% —— 花在“让模型更好”上的时间，远少于花在接口、权限、口径和人身上的时间。

九个失败模式

1. 演示数据和真实数据不是一回事

• 现象：Demo 跑得顺，接进真实系统就出错。
• 根本原因：演示用的是清洗过的样本；真实数据里同一字段多种格式、缺失成片，还叠着废弃多年的规则。
• 早期信号：不愿用生产库只读账号跑一遍；说不清字段有几种写法。
• 怎么避免：把“在真实数据上跑通”写进第一阶段验收；数据准备成本单独列。

2. 只看技术指标，不看业务指标

• 现象：汇报准确率、响应速度、调用量，业务侧说不出省了谁的时间。
• 根本原因：准确率、响应速度只是中间指标，降本、增效、增收才是终极目标。
• 早期信号：目标只写“准确率不低于多少”，没人写“哪一步从几分钟变成几分钟”。
• 怎么避免：立项先测人工基线 —— 谁做、多久一次、错一次代价多大。

3. 一线员工的抵触（中国场景里最被低估的一条）

• 现象：系统上线了，流程里没人用；账号发了，大家还在微信群和表格里干活。
• 根本原因：员工把外部团队理解为“老板请来优化我岗位的人”；系统可能废掉某个岗位或某种管理方式。
• 早期信号：对接人只报好消息；关键岗位反复说“我们情况特殊”；评审没人反对，上线后集中出问题。
• 怎么避免：先讲清岗位会变成什么样，再讲能力；从本来就嫌这活烦的班组做起。
• 中层要单独谈：若系统改变了他的排期权或团队规模，他完全能让项目表面推进、实际停住。要单独对齐他自己的考核怎么变。

4. 用 KPI 强压使用

• 现象：高层要求“全员必须用、本月提效 30%”，结果员工连账号密码都记不住，为应付考核造假截图，或生成一堆没人看的低质内容。
• 根本原因：把使用率当成了目标。它是最容易伪造的指标；培训为零时，员工交出来的只有形式。
• 早期信号：考核表里出现“生成率”“对话次数”；会议和加班变多。
• 怎么避免：不考核使用率，考核某个环节的产出质量与耗时；账号和算力由公司出钱。

5. 数据口径不统一，算出来的数字没人敢用

• 现象：问“上个月销售额是多少”，模型语句正确、数字是错的，因为各部门定义不同。
• 根本原因：不是模型问题，是元数据治理问题；同一指标多个版本，模型只是更快地产生分歧。
• 早期信号：两个部门的月报对不上；有人追问数是从哪个系统导的。
• 怎么避免：口径对齐做成第一阶段交付物，指标定义清单由业务方签字；口径没定的先不算。

6. 组织里没有人对结果负责

• 现象：复盘会上人人都在证明“不是我的错”：业务说难用，IT 说需求不清，供应商说调研不配合。
• 根本原因：项目被当成交付物，而不是业务变更；没有内部负责人，就没人有权叫停。
• 早期信号：问“成了谁负责、砸了谁负责”，回答是“大家一起”。
• 怎么避免：开工前指定内部负责人并写进项目章程，明确有权调动配合、签字验收、叫停。

7. 验收标准缺失，项目无限修改

• 现象：技术做完了，一句“再改一下”“效果还没达到预期”，验收就往后退。
• 根本原因：验收标准没前置，还被写成主观表述（“客户满意”），到验收必然变成争议。
• 早期信号：合同里找不到可测量的验收条款；开发中需求还在增加。
• 怎么避免：开工前写清指标定义、数据采集、对比基线、不达标怎么办。

8. 成本被转嫁给员工个人

• 现象：公司把 AI 用量写进绩效，报销单上的 AI 一栏却空着；员工自掏腰包买算力。
• 根本原因：预算只批了工具采购，没批运行成本；或默认“员工自己会用就自己解决”。
• 早期信号：出现“我用工资买 Token，效率给公司提升了”这类说法。
• 怎么避免：推理成本、账号、算力写进预算由公司承担；禁止用个人账号处理公司数据。

9. 把上线当成终点

• 现象：上线庆功，三个月后模型升级、数据分布变了、业务规则改了，没有人管。
• 根本原因：部署只占总成本的 20%，另外 80% 是后续持续运行；大多合同只给第一部分定价。
• 早期信号：合同里没有运行期责任条款；没有监控面板；问响应时间对方要回去确认。
• 怎么避免：上线前定好运行期责任人、响应时间、评测频率与升级策略。

一张对照表

失败模式	早期信号	应对
演示与真实数据脱节	不敢用生产只读账号	真实数据进首阶段验收
只看技术指标	目标里只有准确率	先测人工基线
一线抵触	说“我们情况特殊”	先讲岗位怎么变
中层隐性阻挠	汇报“全员已使用”	单独对齐他的考核
KPI 强压使用	考核生成率、对话次数	考核环节产出
口径不统一	两份月报对不上	口径清单前置签字
无人负责	回答“大家一起”	指定内部负责人
验收标准缺失	写成“客户满意”	指标、基线、兜底前置
成本转嫁个人	员工自费买算力	运行成本进预算
上线即终点	没有监控与运行条款	责任与预算随上线定

什么样的项目从一开始就不该立项

• 目标只能写成形容词。 “提升效率”“拥抱 AI” —— 无法验收，也无法判断该不该继续投钱。
• 没有基线，也不打算测。 结束后就无法证明它有用。
• 没有人有权叫停，也没人愿意负责。 一把手只出现在启动会上，业务部门只负责“配合”。
• 数据不许出内网，也不提供内网环境。 安全要求与实施条件矛盾 —— 这种情况我们建议先不做。
• 预期是“先做出来，再想怎么用”。 没有场景和使用者的项目，做出来一定没人用。
• 预算只够买人力。 买不到诊断和试点，买到的就是人力。

给内部推动者的五条建议

1. 先讲岗位怎么变，再讲能力有多强。 不主动说清，员工会往最坏的方向猜。
2. 从愿意试的人开始，不要从“全员”开始。 先帮本来就嫌这活烦的岗位把最耗时的一步做掉。
3. 让工具先对员工自己有用。 只有当 AI 对员工真正有用，抵触才会降低；只用来产出更多汇报材料，它就是新负担。
4. 保护第一个说真话的人。 早期最有价值的信息是“这里跑不通”。
5. 把中层的利益摆到桌面上谈。 直接问他的考核、排期权、团队规模会怎么变；含糊过去，他会用含糊的方式让项目停下。

常见问题

试点做完了，怎么判断该不该继续投？ 看三件事：有没有人每天在用；业务指标有没有动；运行期的钱有没有人批。缺两条就该停下重新界定范围。

员工抵触是不是培训不够？ 多数时候不是。培训解决“不会用”，抵触解决的是“不想用”，后者来自岗位、权力和考核的变化。

换个更强的模型是不是就好了？ 通常不会。卡点大多在接口、权限、口径、责任和人；模型升级还会重置基线，把调好的效果再打乱。

---

九个模式里，没有一条的根因是模型不够强。这也是我们坚持先做诊断的原因：把失败模式、验收口径、数据边界在开工前谈清楚，再决定要不要投入。已经停了一段时间的试点，可以先看我们的 FDE 外包服务怎么组织，或者了解我们怎么交付；概念上还不清楚，从《FDE 是什么》和《FDE 和外包到底有什么区别》看起。卡在具体问题上，直接联系我们讲一遍。