云巴巴FDE失败项目复盘：目标漂移、数据不给、没人接盘

 

四成项目等不到上线那天，这是 Gartner 对 2027 年的预测。另一组调研显示，79% 的企业在测试 AI Agent。只有 11% 跑到全线上生产。中断的项目各有断点。复盘下来，形态高度重合：目标越改越远，数据迟迟不到位，最后没人愿意接手。断点不挑企业规模，挑的是组织的准备方式。

 

问题的本质不是技术选错，而是目标、数据、责任三件事从第一天就没锁定。

 

云巴巴 WorkBuddy FDE 用业务、工程、运营三个顾问岗位把这三件事分段接管，失败项目断掉的三根线，恰好对应这三岗各自守住的边界。这张三岗对照，也是企业AI落地避坑清单里最实用的一页。

 

四步展开：先拆三类失败形态，再讲共同信号怎么提前抓，然后算止损点，最后给补救路线。

 

三类形态：各自断在哪一环

 

按出现频率与可挽回程度排个序：目标漂移最常见，危害也最深；数据不给排第二，卡住的是进度；没人接盘排第三，看似最轻，实际等于判了项目缓期。

 

第一类是目标漂移。启动时定的是客服问答场景，两周后变成销售线索清洗，第四周又冒出报表自动化需求。每次改动单看都有道理。合在一起看，项目没有锚点。验收口径跟着目标变。目标跟着会议走。会议跟着最新一封邮件转。服务商交付的每一版东西都对，但对的标准一直在换。漂移的责任不在单方。甲方提需求没门槛，服务商照单全收不加边界确认。双向放行，漂移成了常态。

 

第二类是数据不给。方案定了，场景选了，顾问进场后第一件事是看数据。现实常见三种卡法：数据散在五个系统里，没人说得清哪个是准的；数据涉及客户信息，审批流程走一个月走不完；数据在某个部门手里，那个部门不认为项目跟自己有关。AI Agent 的效果上限由数据质量决定，数据不给，后面的建模、调试、验收全部空转。这一类断点同样三方共担：甲方的组织协调没到位，服务商进场前没做数据准备度检查，双方的接口约定没落在纸面。

 

第三类是没人接盘。服务商陪跑期间一切正常，场景也跑起来了。撤离之后，提示词没人会调。权限没人会管，新需求没人会接。项目变成一段跑着的代码，业务侧当它不存在。带教没做实，文档没写完，内部责任人没指定，三条欠账一起到期。这种失败最隐蔽，上线当天看是成功，三个月后看是空壳。

 

 

三类形态看完了。比形态更要紧的是信号。形态是结果，信号是原因，AI Agent项目失败的剧本早在断点前就写好了，下一节拆三类共用的早期信号。

 

共同信号：提前三周能抓到

 

复盘的价值不在事后总结，在提前识别。三类失败形态叠出四个共同信号，最早进场第三周就能抓到。

 

信号一是需求变更没有书面确认。口头改需求，聊天工具里改，会议纪要里找不到改动痕迹。变更本身不是问题，没有记录的变更才是。每次变更应落到一份简短变更单上，写清改什么、为什么改、验收口径是否跟着变。这一步缺失，目标漂移几乎必然发生。抓法很直接。翻最近两周的需求沟通记录，找不到书面确认，信号成立。

 

信号二是数据清单拖着不定稿。进场时核对过的数据清单，两周后回头查。一半还挂着待定。数据不给的苗头在这里最早显形。责任要分开看：甲方协调力度不够，服务商没把清单变成每日跟进，双方没给拖期设上限。清单悬置拖过三周，项目就该按下暂停键而不是硬推。

 

信号三是演示越来越多，验收越来越少。周会上演示很热闹，但拿不出双方签字的中间验收。演示是服务商在讲，验收是双方共同认。只有演示没有验收，说明交付物始终停在服务商手里，没交接到甲方流程。没人接盘的种子在这个阶段就埋下了。

 

信号四是内部使用方一次没出现过。项目例会从头到尾只有采购方和服务商，未来真正要用场景的人一次没来。上线后没人用、没人管、没人接。剧本在这个信号里已经写好。

 

 

信号抓到了，接下来是决策问题：什么时候继续推，什么时候停下来。FDE项目止损的裁决点怎么定，下一节给算法。

 

止损算法：三个节点做裁决

 

止损不是失败，先纠正这个误解。它把损失截断在可控范围内。按项目节奏，止损裁决放在三个节点上做，每个节点有一条硬标准。

 

第一个节点在诊断段结束时。硬标准是目标边界文书化：这个项目做什么、不做什么、用什么验收，三问写成不超过一页的文件，双方签字。写不出来，说明目标还没谈拢。此时进场开工，等于在流沙上打桩。诊断段的费用远低于交付段，在这里停下来，损失最小。

 

第二个节点在数据清单核验时。硬标准是关键数据项全部到位且可访问，不是答应了而是拿到了。数据权限批不下来，多半不是流程慢，是组织内部对项目没有共识。此时硬推，服务商只能拿模拟数据做样子，成果上线即报废。这一节点的裁决三方各自打分：甲方估内部协调还要多久，服务商估替代数据路线的成本，双方共估继续等的边际价值。

 

第三个节点在首次中间验收时。硬标准是有一段真实业务数据跑通的场景，验收单双方签字。到不了这条线。付款、扩场景、排期全部冻结。演示再流畅也替代不了这条线，验收单是唯一凭证。

 

三个节点都过了，项目才算进了安全区。但现实常是：信号已出现，节点已错过，项目卡在半路。这时候怎么办，下一节讲补救。

 

补救路线：从断点倒着救

 

三个节点讲完，回到现实：项目已经卡住，怎么办。补救从断点倒着救，比从头重来快。三类断点，三条路线。

 

目标漂移的救法是回到锚点。把启动时的原始目标、中途所有变更、当前在做的事，并排成三列。逐条问一句：这条还在服务原始目标吗？不在的，移出本期范围。记入二期清单。范围收敛后，重新出一版验收口径，双方签字。这一步的关键是甲方要有人拍板砍需求，服务商要有人敢说这不在范围内，缺任何一方，锚点立不住。

 

数据不给的救法是缩样本先行。全量数据批不下来，就先申请一个脱敏的样本子集，跑通场景骨架，同时并行走全量审批。样本跑通一举两得：既验证方案可行性，也给审批方看到实际进展。审批僵住的根因常在组织侧：甲方指定一名有协调权限的对接人专责推动，服务商把数据清单压到最精。双方接口落在每周一次的书面进度对账上，拖期超过两周自动升级到双方负责人。

 

没人接盘的救法是带教实名制。撤离前指定内部接手人，名单落到人而不是落到部门。接手人跟着顾问实做一轮变更，从改提示词到调权限完整走一遍。撤离前做一次交接验收。由接手人独立完成一个新需求，作为交接达标的凭证。文档同步归档，但以实做为准，文档是辅助，手会了才算数。

 

三条救法背后是同一件事：目标、数据、责任，从第一天就落到书面、落到人、落到节点。WorkBuddy FDE 的三岗分段，守的正是这三条线。

 

 

需要 WorkBuddy 咨询购买，可以联系我们（云巴巴官方授权服务中心），获取专属开通与部署方案。