FDE落地地图：AI交付的五个阶段丨从第一次见客户到系统移交，每个阶段做什么

上一篇说到，AI落地失败的根本原因不是模型问题，是交付问题。FDE这个角色，就是专门解决交付问题的。

但"解决交付问题"本身也是一句模糊的话。具体怎么解决？从哪里开始？到哪里算完？中间会遇到什么？

这篇把这些问题的答案画成一张地图。后续每一篇深挖地图上的一个位置，这篇是整个系列的坐标系。

这张地图不是凭空设计的。它来自业界对FDE实践的系统性整理——Palantir二十年的经验、OpenAI FDE团队的方法论、以及FDE从业者的总结。五个阶段，每个阶段有它存在的理由。

NotebookLM的音视频概览，解读的比较通俗易懂，对于时间比较紧张的读者朋友，可以听听，会有启发。

五个阶段，从一类失败反推出来

这个框架不是正向设计出来的，是从失败案例里反推的。每个阶段的存在，都对应一类真实发生过的、代价很高的失败：

跳过发现阶段直接开始建——做完，发现方向跑偏，解决了一个错误的问题，全部推倒重来。

跳过原型阶段直接部署——技术方案没有在真实数据上验证过，进生产环境后一进就崩，和测试环境完全两回事。

跳过部署陪跑直接宣布上线——系统技术上跑通了，但用户不信任、不敢用，采纳率挂零，系统成了摆设。

跳过产品化直接接下一个客户——经验全锁在人脑里，团队扩张之后新人什么都要重新摸索，越做越累，毛利越来越低。

跳过交接让FDE长期驻场——客户内部没有形成自己的运营能力，FDE一走系统就停转，而且一个FDE永远只能绑在一个客户上，规模化无从谈起。

五个阶段，堵住五类失败。

发现：把模糊的"想用AI"变成可以动手的问题

发现阶段做的事，听起来简单，实际上是整个交付里最容易被低估的一步。

客户说"我想用AI提升效率"——这不是一个可以动手的问题定义。FDE进场的第一件事，不是打开电脑开始写代码，而是和客户一起把这句话翻译清楚：效率是哪个环节的效率？现在这个环节是怎么运作的？卡点在哪里？如果AI介入，输入是什么、输出是什么、怎么判断做对了？

客户说不清楚这些，不是因为他们不专业。需求本身在现场才能被发现——很多时候客户自己也不知道真正的痛点在哪，直到有人在旁边问对了问题。

这个阶段最常见的失败：需求还在模糊状态就开始动手，用执行力掩盖方向不清晰的问题。动得越快，跑偏之后推倒重来的代价越高。

这个阶段结束的标志：双方都认可一个具体的问题定义，可以用一句话说清楚，可以被衡量。不是一份厚厚的需求文档，是一句双方都签字认可的话。

原型：在真实数据上验证，不是在干净环境里演示

发现阶段结束之后，很多人的直觉是"开始开发"。FDE的做法不一样——先做原型，在客户的真实数据上跑，看方向对不对，然后再进生产。

这里有一个关键细节：原型阶段用的数据，必须是客户真实的数据，不是精简过的测试数据，也不是模拟数据。OpenAI FDE团队有一个明确的原则——在写一行生产代码之前，先和客户一起建立评测标准：什么叫"对"，什么叫"可以接受"，什么叫"不行"。这个标准要用真实的业务案例来定义，不是工程师自己猜。

清晰的评测标准，对于后续Agent的实现尤为重要，没有标准，Agent很难实施，停下来都变得困难。

John Deere那个项目，FDE团队和农艺师一起审查了几百个真实农业样本，才建出评测标准。这不是在浪费时间，这是在确保后续所有的工程投入方向正确。

这个阶段最常见的失败：用干净数据或者精简数据做原型，模型表现很好，进真实环境之后发现完全两回事——数据格式不对、边缘案例大量出现、评测标准和真实业务脱节。

这个阶段结束的标志：在真实数据上，系统表现达到双方认可的评测标准。不是演示给客户看效果好，是在客户自己的数据上跑通了、数字达标了。

部署陪跑：技术跑通是入场券，用户敢用才是终点

原型验证之后，进入部署阶段。这个阶段做两件事，而且这两件事必须同时推进。

第一件是技术加固：把原型接进真实的生产环境。这里才是集成墙真正爆发的地方——权限体系、遗留系统接口、数据合规、IT审批流程。这些在原型阶段不存在的问题，在部署阶段会集中出现。加固的工作没有捷径，只能一个一个打通。

第二件是陪跑：技术接通之后，守在用户旁边，看他们怎么用，发现哪里卡、哪里不信任、哪里和他们的实际工作流不匹配，然后快速迭代。

摩根士丹利那个项目，技术管线六到八周就搭完了。但团队在这之后花了更长的时间陪财富顾问用，收集反馈、调整输出，直到顾问们真正信任系统，敢用它去服务高净值客户。最终采纳率98%，投研报告使用量提升了三倍。

技术跑通和用户真正用起来，是两件事。前者是入场券，后者才是这个阶段真正的终点。

这个阶段最常见的失败：技术上线就宣布项目完成，没有陪跑环节，用户采纳率低，系统变成摆设。

这个阶段结束的标志：有真实用户在真实工作流里依赖这个系统，而不只是偶尔试用一下。

产品化：这次的个性化，变成下次的通用能力

产品化阶段是FDE模式和定制开发的本质分水岭。

每次交付，都会产生一些这个客户特有的东西：一套为他们的业务设计的评测标准、一个接他们遗留系统的连接器、一种在他们的组织文化里建立信任的沟通方式。这些东西，在定制开发模式里留在项目文档里，下次换个客户重头来。在FDE模式里，这些东西要被提炼成通用能力，回流到核心产品，让下一个客户直接受益。

具体形式可以是：一个新的数据连接器、一套可复用的评测框架、一个标准化的部署工作流。不一定很大，但必须真实地回流到产品里，不能只停在文档里。

业界有一个很直接的衡量标准：90天内，如果没有任何东西从这次交付回流到核心产品，这个FDE团队在跑的是服务公司，不是FDE。

这个阶段最常见的失败：跳过这步直接接下一个客户。两年后团队扩张，发现新人什么都要重新摸索，而老人脑子里积累的经验根本没有办法转移。

这个阶段结束的标志：至少一个可复用的能力被沉淀并回流到产品。不用很多，但必须有。

交接：FDE撤出，系统继续运转

交接阶段是最容易被忽视的，但它是FDE能不能规模化的关键。

FDE不能永远守在一个客户那里。要服务更多客户，就必须把每个客户的系统移交给他们自己的团队来运营，FDE撤出去接下一个。

但交接不是最后一步才开始准备的事。好的FDE从第一周就开始识别客户内部的负责人，从第二周就让他们参与到日常工作里，到真正交接的时候，这个人已经理解系统的运作逻辑、能处理常见问题、知道什么情况需要升级。

交接准备的核心不是写文档——文档没人看。是把操作流程变成系统里的自动化工作流，让内部团队通过实际参与而不是阅读来学会怎么运维。

这个阶段最常见的失败：FDE长期驻场，客户产生依赖，内部没有形成自己的运营能力。FDE一撤，系统就停转。而且一个FDE被长期绑在一个客户上，整个FDE团队的规模化就无从谈起。

这个阶段结束的标志：FDE撤出之后，系统继续稳定运行，内部团队能独立处理日常运营。

闭环：产品化如何让下一次发现更快

五个阶段走完，不是终点，是下一圈的起点。

产品化阶段沉淀的东西，会直接改变下一次发现阶段的速度和质量。上次建立的评测框架，这次发现阶段就能更快判断一个方案是否可行；上次打通的连接器，这次不用从零开始；上次陪跑过程里摸索出来的用户信任建立方式，这次可以直接用。

每走一圈，下一圈的起点就高一格。边际成本随着每次交付递减，这才是FDE模式能规模化的底层逻辑。

定制开发没有这个闭环。每次交付是终点，经验留在人脑里，下次重头来。这就是为什么很多国内AI落地团队越做越累——他们做的是没有产品化环节的交付，五个阶段只走了前三个。

地图上的三个判断点

地图有路线，还有三个必须停下来做判断的位置。走错了，代价很高。

发现→原型之间：问题定义够清晰了吗？现在进原型合适吗？如果需求还模糊，进原型只是在用执行力掩盖方向不清晰。这里需要一个明确的确认，不是靠感觉。

原型→部署之间：这个原型真的可以进生产了吗？在真实数据上达标了，不代表生产环境能跑通。权限、合规、遗留系统接口——这些问题在测试环境不存在，进生产会集中爆发。

部署→产品化之间：什么时候经验足够沉淀了？太早沉淀的是假经验，太晚就直接跳过了。一般的参考线是：系统稳定运行、有足够的真实用户反馈积累之后。

这三个判断点，后续系列会单独拆开来讲。

写在最后

五个阶段，每个都有它存在的理由。跳过任何一个，都有对应的代价——不是抽象的风险，是真实发生过的失败。

这张地图的用法不是背下来，是在你下次进一个AI落地项目的时候，能知道自己在哪个阶段、这个阶段的核心任务是什么、结束的标志是什么、下一步做什么。

下一篇从发现阶段开始——怎么把模糊的业务痛点，翻译成一个可以动手的问题定义。

感谢你看到最后，如果你觉得有启发，随手点个赞、在看、转发吧，如果想第一时间收到推送，也可以给我加个星标⭐我们下期见。

我是「AioGeoLab」主理人塔迪Tardi，AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室，目前有两个主要研究方向：
「塔迪GEO判断工程」是基于GEO的价值SEO化，在AI从“说”到“做”的重要跃迁阶段，试图回答，如何让AI敢于行动、不因为责任问题而畏手畏脚，而做的一个前沿研究项目。
「塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践，深层共鸣的探索。不是用AI解读经典，也不是用经典指导AI。 这是一场跨越2500年的对话，在算法与古老智慧之间，照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025。