企业 AI 落地成功率不到一半，项目往往死在这三步

[!abstract]- 摘要 一家服务近百家企业的 FDE 公司判断，企业 AI 转型成功率不到 50%。这个数字并非行业统计，却很接近我看到的现场：老板高估生成能力，IT 接过业务项目，员工还要训练可能接替自己的 Agent。问题分别卡在预期、预算和利益。

上一篇写到，OpenAI、Anthropic、AWS、Microsoft 开始大规模派工程师进入企业现场。

模型公司把生意做得越来越重，原因很简单：调用模型很容易，让模型进入生产流程很难。

那篇文章最后留了一个问题。

FDE 已经进场，模型能力也足够强，企业 AI 项目为什么还会大量失败？

最近听《十字路口》的一期 FDE 访谈，Rolling AI 的两位合伙人提到一个判断：他们服务过近百家企业，整体 AI 转型项目的成功率不到 50%。

这个数字没有统一的行业口径，我也不会把它当成权威统计。可它和我看到的项目非常接近。

很多项目演示时相当惊艳。老板看完 Demo，当场要求全公司推广；三个月后再问，系统还在，使用量已经掉下去了。还有一些项目顺利通过验收，知识库、权限、日志、监控一应俱全，财务报表却没有变化。

模型强和项目成功，中间隔着一家公司。

公司的历史系统、预算归属、部门目标、员工利益，都会在模型进入生产环境以后，一层层冒出来。

最常见的坑，大致有三个。

老板刚吃到 AI 的甜头，项目已经被推上生产线

前段时间，一个做传统行业软件的朋友找我做 Agent 架构设计。

这家公司老板在行业里做了几十年，对业务很熟。开始深度使用 ChatGPT 和 Claude Opus 以后，他很快进入了一种兴奋状态。

需求可以让 AI 写。

产品方案可以让 AI 写。

页面原型一晚上就能出几十张。

数据库表结构也能顺手生成。

在他看来，软件开发已经被压缩成最后一个步骤：把 AI 给出的东西交给程序员，照着实现。

有一次，他拿着一套原型说：

几十个页面，一晚上都做完了。开发两周应该够了。

程序员接过原型，没人敢多说话，只能摇头。

页面看上去很完整：登录、工作台、流程、报表、统计图，一个不少。再往下追，问题开始成片出现。

现有系统用了另一套技术栈，新旧模块怎么共存，没有方案。

用户、组织、角色和数据权限已经运行多年，原型里重新画了一套。

页面上的数据从哪里来，后台接口没有定义。

多租户、审计、异常补偿、幂等、历史数据迁移、灰度发布和回滚，全都空着。

AI 生成的表结构更直接。字段名看着都对，事务边界、索引、历史版本、数据归档和遗留映射几乎没有考虑。

老板看到的是产品已经完成了八成。

程序员看到的是最表面的一层刚刚画出来。

后面老板又让 AI 出了几套技术方案。每套方案读起来都很完整，涉及的组件、架构图和实施步骤也都有。他的判断很自然：AI 都已经给出方案，技术上肯定能做。

我看完以后，只能告诉他，这些方案活在一个没有存量系统的世界里。

AI 很擅长补全空白。你没有提供的约束，它会用概率补上；你没有描述的历史包袱，它会默认不存在；你没有说清楚的数据来源，它也能先给你画出一张漂亮的页面。

输出越完整，缺失的上下文越容易被藏起来。

这也是刚开始用 AI 时最容易产生的错觉。

过去做不了的事，现在突然都能做了。不会写 PRD，可以生成一份；不会画原型，可以生成一套；不懂数据库，也能得到几十张表。人的信心增长得很快，对交付成本的判断却没有同步更新。

真正用 AI 写过大量生产代码以后，态度通常会慢慢变化。

你会开始关心上下文有没有丢，工具调用是否稳定，代码有没有重复生成，测试是否覆盖关键路径，长任务会不会跑偏，升级模型后结果是否变化。代码生成便宜了，评审、取舍、验收和长期维护变得更贵。

工程步骤一项都没有减少，还多了一层模型带来的不确定性。

怎么改：先让 AI 碰现实，再让项目碰生产

企业项目需要一条明确的验证路径。

第一阶段只验证最关键的业务假设。能否拿到数据，能否调用现有系统，关键决策能否达到可接受的准确率。页面做得漂不漂亮，可以往后放。

第二阶段进入影子模式。Agent 跟着真实流程运行，只给建议，不直接执行。团队用真实数据比较它和人工结果的差异。

第三阶段再开放有限权限，先处理低风险、可回滚的任务。每一步都要有指标、有人工检查点、有退出条件。

项目里还需要一个能对工程可行性负责的人。他要懂 AI，也要熟悉存量系统；既能快速做出原型，也敢在老板兴奋的时候踩刹车。

老板最好亲自用 AI。

也最好亲自吃几次 AI 的苦。

预算放在 IT，最后容易交付一套“合规的无用系统”

企业里常见的预算，大致可以看成三类钱。

第一类是 IT 预算。

这笔钱用来维持系统稳定，保证安全、权限、审计和合规，控制基础设施成本。IT 部门的工作有一个特点：做得好时没人注意，出一次事故全公司都知道。

第二类是业务预算。

销售、客服、供应链、运营、门店等部门花这笔钱，目标通常很直接：增加收入、提高毛利、缩短周期、减少损耗、扩大产能。

第三类是营销预算。

买流量、做品牌、获客和转化，投入多少、带来多少线索和收入，通常有一套相对成熟的 ROI 算法。

这三类预算没有严格的会计边界，却会决定项目最后长成什么样。

传统 SaaS 大量进入 IT 预算。采购时关注功能清单、并发量、权限、部署方式和服务等级；项目上线以后，业务部门能用到多少功能，往往排在后面。

FDE 项目走的是业务预算。

客户愿意付钱，通常因为销售转化能提高、客服处理量能上升、库存损耗能下降、一个流程能从三天缩短到半天。系统只是实现手段，业务指标才是合同里的主语。

很多企业 AI 项目从一开始就放错了位置。

老板把任务交给 CIO，IT 部门开始选模型、搭平台、做知识库、设计权限、处理数据安全。经过几个月建设，项目顺利验收：回答准确率达标，日志齐全，权限可控，生产环境稳定。

业务部门打开系统问了几次，发现它既不能直接填报价单，也不能推进 CRM 里的商机，无法发起审批，更不知道下一步该跟客户说什么。几周以后，使用量开始下降。

项目没有技术故障。

业务也没有得到结果。

一个销售 Agent 的价值，要看商机有没有向前推进；一个客服 Agent 的价值，要看问题有没有解决、客户是否继续留下来；一个门店 Agent 的价值，要看营业额、排班和损耗有没有改善。

IT 可以保证跑道安全，很难替业务决定飞机飞向哪里。

怎么改：业务做 Owner，IT 掌握生产底线

谁承担收入、成本和效率结果，谁来做项目 Owner。

业务负责人需要提供预算、场景、人员和成功标准，也要承担项目没效果的责任。IT 团队负责数据、系统集成、权限、安全、基础设施和生产稳定性，并保留风险否决权。

验收指标至少分三层。

• 业务指标：收入、转化率、处理量、周期、损耗或人均产出；
• 流程指标：Agent 接管了哪些环节，人工介入比例多少，失败集中在哪里；
• 工程指标：准确率、延迟、成本、稳定性、安全和回滚能力。

只看第三层，容易做出稳定但没人用的系统。

只看第一层，项目又可能在安全、数据和工程质量上留下大坑。

FDE 的工作，就是把这三层放在同一张桌子上。

员工为什么要教会一个可能接替自己的 Agent

第三个坑最难处理，因为它涉及人的利益。

很多老板启动 AI 项目时，脑子里的第一句话是“降本增效”。员工听到的重点通常在“降本”。

可 AI 要进入业务，第一步往往是把人的经验拿出来。

销售冠军要讲清楚客户在什么状态下会成交。

资深客服要整理各种异常情况和情绪处理方式。

店长要解释为什么同样下雨，有的门店该减人，有的门店反而要加货。

运营人员要把每天靠经验完成的动作，拆成数据、规则、判断和例外。

公司还可能要求录屏、记录会议、补文档、标注数据，让 Agent 长期跟在旁边学习。

站在员工角度看，这件事很容易变成：把多年积累打包交给公司，再训练一个可能接替自己岗位的数字员工。

如果项目材料里还写着减少多少人、提升多少人效，抵触几乎是必然的。

抵触未必表现成公开反对。

员工可以只提供标准答案，不讲真正有价值的例外；文档永远差几个关键字段；业务流程看起来已经梳理完成，到了生产现场又发现一半靠口头协调；Agent 出错后，没人愿意花时间反馈和校正。

中层管理者也有自己的顾虑。

很多管理岗位承担信息汇总、上传下达、协调和检查。Agent 一旦能自动收集信息、生成报告、分发任务，其中一部分岗位价值会受到直接影响。要求他们全力推动项目，相当于让人主动削弱自己的权力边界。

这是组织面对新生产力时的正常免疫反应。

那期播客里提到一个做法：原来销售团队的绩效全部看结果，后来把一部分比例调整为过程和知识贡献。员工提供有效经验、帮助 Agent 改进，也能获得积分和收入。

这个逻辑很重要。

过去，一个金牌销售自己多卖两三倍，已经很有价值。现在，他的经验有机会复制给全国几百、几千名销售，对公司的贡献反而放大了。激励机制还按个人销量计算，员工自然没有动力把核心经验交出来。

怎么改：先给价值，再取知识

Agent 进入团队以后，应该先帮员工处理最烦、最重复的工作。

查资料、整理记录、填写表格、生成初稿、跟进提醒，这些事情先接走。员工感受到实际收益以后，才更愿意教它处理复杂场景。

接下来要把知识贡献写进考核和回报。

哪些经验被采纳，帮助多少人，Agent 的结果改善了多少，带来了多少业务收益，都可以成为奖励依据。承担导师、评测和校正职责的员工，需要新的岗位定义和收入安排。

企业还要说清楚三件事：

• 哪些工作会交给 Agent；
• 人在什么节点做判断并承担责任；
• 效率收益如何分配，岗位如何迁移。

一句空泛的“AI 不会取代你”解决不了问题。

员工看的是实际安排。

三个坑，最后会连成一条线

这类项目的失败路径经常很相似。

老板看完 Demo，对 AI 形成过高预期，直接定下一个庞大的目标。

项目交给 IT，验收标准逐渐变成平台、权限、安全和功能清单。

业务人员需要贡献知识，却看不到自身收益，开始消极配合。

半年以后，平台上线了，培训做了，宣传稿也发了。业务部门仍然沿用原来的流程，Agent 偶尔被当成搜索框使用。

可以把这三个问题放在一张表里：

项目表面现象	深层问题	调整方向
Demo 很惊艳，生产迟迟不敢放量	预期超过工程现实	分阶段验证，明确人工检查与回滚
平台顺利验收，业务使用量很低	预算和 Owner 放错位置	业务主导结果，IT 守住生产底线
员工不配合，知识始终沉淀不出来	收益和风险分配失衡	先提供价值，再奖励知识贡献

三个坑分别落在预期、预算和利益上。

技术团队只修模型和 Prompt，修不到这些地方。

FDE 能补位，也救不了一个不愿改变的客户

一支靠谱的 FDE 团队，可以帮企业控制预期、定义业务指标、打通系统、设计人机流程，也能把一线反馈带回平台。

可 FDE 没有魔法。

企业内部缺少业务 Owner，数据和系统权限拿不到，员工利益没人处理，外部团队最后也会退化成昂贵的驻场开发。

项目启动前，我会先问下面几个问题：

1. 三个月内，哪个业务指标需要发生变化？
2. 谁为这个指标负责，预算掌握在谁手里？
3. 项目团队能否接触真实数据、系统和一线用户？
4. Agent 可以执行到哪一步，哪些决定必须由人批准？
5. 哪些岗位会得到帮助，哪些岗位会发生变化？
6. 员工贡献知识以后，可以得到什么？
7. 项目失败时如何回滚，什么条件下应该停止？

前四个问题都答不清楚，先别急着部署 Agent。

把问题定义清楚，通常比多接一个模型更有价值。

躲开这三个坑，项目只能算活了起来。

企业继续沿用旧流程，只在局部加速，AI 带来的收益很快会碰到上限。业务系统怎么围绕 Agent 重新设计，人和 Agent 怎么分工，组织结构和考核方式怎么调整，后面还有更大的工程。

第三篇继续写这件事：

FDE + AI
    ↓
重塑生产力
    ↓
重新定义业务系统
    ↓
重构企业组织

---

资料说明

[^1]: 文中“企业 AI 转型成功率不到 50%”来自《十字路口》对 Rolling AI 两位合伙人的 FDE 访谈，是嘉宾基于近百家企业服务经验给出的判断，未作为统一行业统计引用。