一个FDE项目算不算成功？复盘时别只看上线了没有

最近在想一个问题：

一个FDE项目做完以后，到底凭什么说它成功了？

是系统上线了？是模型跑通了？是验收通过了？还是业务部门说了一句“效果还不错”？

这些当然都重要，但如果站在甲方FDE团队的角度，我越来越觉得，真正值得复盘的，不是这个项目做完没有，而是我们当初为什么做，最后拿到了什么，中间为什么有差距，这一仗打完以后，公司到底留下了什么。

如果这些问题说不清楚，一个项目即使按时上线，也很难说它真正成功。

一、先别看做了什么，先看当初为什么做

很多AI项目一立项，目标就开始变味。

最开始业务部门可能说：合同审核太慢了。客服每天重复回答的问题太多了。运营人员每天要花大量时间整理数据。销售每天写跟进记录太浪费时间。

这些其实都是业务问题。但项目一旦进入技术团队，目标往往慢慢变成了：建设一个智能体。搭一个知识库。接入大模型。实现RAG。完成工作流编排。上线AI助手。

最后项目汇报看起来技术含量很高，但没人再问最初那个问题：

原来的业务问题，到底解决了多少？

所以我觉得FDE项目复盘的第一件事，不是翻功能清单，而是把最初的目标重新拿出来。而且这个目标最好是业务语言。

比如：不是建设合同审核Agent，而是合同初审时间从2小时压缩到20分钟。

不是上线客服知识库，而让60%以上的重复咨询不再需要人工处理。

不是建设经营分析助手，而是让区域负责人每天上午9点前就能看到异常，而不是月底才发现问题。

这是两个完全不同的项目逻辑。前者是在交付技术，后者是在改变业务。FDE真正应该盯的是后者。

图片

二、项目结束以后，必须把数字摆出来

很多项目复盘最容易出现的一句话是整体效果达到预期。

这句话基本等于什么都没说。什么叫达到预期？原来多少？目标多少？现在多少？差了多少？这些数字必须摆出来。

比如一个项目，原来的目标是把人工处理比例从100%降到30%。项目结束以后发现，实际只能做到45%。那结果其实很清楚：目标：30%。实际：45%。差距：15个百分点。

再比如：原来一份材料平均处理40分钟。目标做到10分钟。实际上做到18分钟。那就不要写效率显著提升直接写：

从40分钟降到18分钟，提升55%，但距离10分钟目标还有8分钟。

只有数字摆出来，复盘才真正开始。否则所谓的成功，很容易变成一种感觉。而FDE项目最怕的，就是大家都觉得做得不错，但没人知道到底哪里不错。

三、真正有价值的复盘，是把那15%的差距找出来

项目没达到目标并不可怕。真正可怕的是最后归因成一句：

用户使用意愿不足。

这句话我现在越来越警惕。因为用户不用，很多时候只是结果，不是原因。为什么不用？这才是FDE该追的问题。

我通常会从几层去看。

第一种可能，是场景一开始就选错了。看起来很痛，实际上频次很低。看起来人工耗时很多，但这件事本身没有标准答案。或者业务部门嘴上说很需要，真正工作里根本不会高频使用。这种问题，后面模型做得再好，也很难成功。

第二种可能，是施工出了问题。业务需要是对的，AI能力也够，但产品不好用。入口太深。流程太长。数据没接全。权限没打通。用户每次还要复制粘贴半天。这种项目失败，不是AI不行，而是产品和工程没做好。

第三种可能，才是真正的AI能力不够。比如业务要求99%的准确率，但当前模型只能稳定做到85%。或者它可以给建议，却还不能稳定完成最终判断。这种时候最怕硬上。本来只能做助手，非要包装成数字员工。最后一定是人再检查一遍。AI干一次，人再干一次。所谓提效，最后变成了增加一道流程。

第四种，是组织没有跟着系统一起变。这个问题我觉得在甲方项目里尤其常见。系统已经能完成一部分工作了。但岗位职责没调整。审批流程没变化。考核方式没变化。原来谁负责，现在还要求谁负责。于是业务人员最理性的选择就是：

我可以用AI，但我不敢相信AI。

因为最后责任还是他的。

所以一个FDE项目没达到目标，不能笼统地说效果不好。要问清楚：

到底是哪一段出了问题？

是场景问题？产品问题？工程问题？模型能力问题？还是组织问题？把问题定位清楚，失败才有价值。

图片

四、项目结束以后，最该问的是：公司留下了什么

以前做信息化项目，我们很容易把交付物理解成系统。系统上线了。文档交了。代码交了。项目就结束了。

但我现在越来越觉得，FDE项目最大的价值，很多时候并不只在那个系统本身。而在于这场仗打完以后，公司有没有留下资产。

比如做合同审核。最后真正有价值的，可能不只是一个合同审核Agent。而是你第一次把：哪些条款高风险，哪些情况必须人工判断，哪些合同可以标准化，哪些风险历史上经常发生全部梳理清楚了。这些其实是公司的行业知识资产。

再比如做酒店人效项目。你可能第一次真正把：入住率和排班是什么关系，不同酒店什么岗位弹性最大，什么时候应该增加小时工，什么指标可以提前暴露经营问题这些逻辑沉淀了下来。这就是业务模型。

还有一些项目，会沉淀成平台能力。比如统一身份。知识库。流程引擎。数据接口。模型网关。Agent能力。下一个项目不需要重新从零搭。

还有一种更容易被忽略的资产：

人。

一个FDE项目做下来，有没有把一个产品经理带成更懂业务的人？有没有让一个研发开始知道怎么去现场？有没有培养出一个真正能够同时和业务、技术、管理层对话的人？

如果一个项目打完，公司只是多了一个系统，却没有多出任何新的能力，那这个项目其实很难规模化。

真正好的FDE项目，应该有一个很明显的特征：

下一次再打类似场景，不需要重新交一遍学费。

图片

五、复盘最后不是经验总结，而是决定下一仗打哪里

我见过很多项目复盘，最后一页叫经验与改进建议。写完以后就结束了。但FDE不应该停在这里。

一场项目真正结束的时候，最应该回答的是：

我们下一仗打哪里？

因为前一个项目留下的资产，应该直接成为下一个项目的起点。

比如合同审核做好了。那下一步是不是可以往合同起草、履约监控、付款审核延伸？客服问答跑通了。是不是可以继续做工单判断、异常处理、客户流失预警？酒店排班做完了。是不是可以继续做人效预测、小时工调度、经营异常提醒？

这时候项目才开始形成复利。第一个项目可能需要三个月。第二个项目因为数据、知识、接口、团队都有了，可能只需要一个月。第三个项目甚至只是在已有能力上重新组合。

我觉得这才是FDE模式真正有意思的地方。它不是一个项目接着一个项目做。而是：

打一仗，留一批资产。再用这批资产，去打下一仗。

慢慢地，组织就不再是每次从零开始。

六、所以，一个FDE项目到底怎么算成功？

现在如果让我复盘一个FDE项目，我大概只会问五个问题：

第一，当初的目标是什么？是业务语言，还是技术语言？

第二，最后到底拿到了什么结果？目标是多少，实际是多少，差多少？

第三，差距到底出在哪里？是场景、产品、工程、模型，还是组织？

第四，这一仗打完以后，公司留下了什么？知识、平台、方法、流程，还是人？

第五，基于这些资产，下一仗打哪里？

如果这五个问题都能回答清楚，即使这个项目最后只拿到70分，我也觉得它可能是一个有价值的FDE项目。

因为至少我们知道：哪里做对了，哪里做错了，能力边界在哪里，下一次该怎么打。

反过来，一个项目如果功能全部上线了、验收全部通过了、汇报PPT也很好看，但业务没变化、用户不用、团队没成长、能力没留下。那它最多只能叫：

项目交付完成。

还不能叫：

FDE成功。

真正好的FDE项目，不只是把这一仗打赢。而是打完这一仗以后，

下一仗，我们已经比别人更有胜算了。