FDE产品化：FDE和外包最本质的分水岭丨每次交付，都应该让下一次的成本更低

做完部署阶段的三件事——集成墙打通、裁定接口设计好、用户真正用起来——系统已经在生产环境里稳定运行了。

这时候很多团队会做一件事：把项目标记为完成，FDE撤出，去接下一个客户。

先看两支团队。

A团队做了两年AI落地交付，接了十几个客户，每个项目都顺利完成，客户评价不错。一个项目一个项目做下来，经验是有了，但交付周期和项目成本变化并不大，平均大概80%。

B团队同样做了两年，最新项目的交付速度比第一个快了1-2倍，交付成本也越来越低，平均不到原来的50%。

两支团队的技术能力差不多，成本差距越来越大，原因就在很多团队会漏掉整个FDE落地工程最重要的那一步-FDE产品化。

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

经验存在脑子里，会消失

交付完成，FDE撤出去接下一个客户，那么这次交付里积累的经验都去了哪里？

比如，用什么方式打通了那个十年前的遗留系统，评测标准怎么设计才让业务方真正认可，用户信任建立的节奏大概需要多长时间，哪类组织会在权限审批上卡住、该怎么提前疏通。

这些经验和判断，如果没有产品化阶段，那最终只是存在FDE自己的脑子里。

最常见的组织错误是把FDE的工作并入销售市场团队（GTM），FDE实际上变成了改了名字的解决方案工程师。

产品化根本就不在GTM的职责范围之内。所以，两年之后团队尽管积累了大量项目经验，但经验全在个人那里，无法形成有效的产品迭代。公司越做越重，扩张变得越来越难。做到最后，做成了一家外包服务公司。

知识存在人脑里有三个问题：不能复制，无法检索，会随着人员流动消失。一个做过多个项目的FDE离职，他积累的所有判断经验就跟着走了。

FDE产品化要解决的，是把这些经验从个人头脑转移到系统和产品里。

什么值得产品化，什么不值得

不是所有经验都值得提炼，产品化要有选择。判断标准只有一个：这个东西，后面的客户会不会需要？

有三类东西通常值得产品化：

连接器和集成模式

打通了某类遗留系统的集成方案，很可能在其他客户那里也会遇到同类系统。同一个行业里，用的ERP系统往往就那几套，权限管理体系也有共同的模式。把这次打通的方式整理成可复用的连接器，下一次同类集成的工作量可以从两周压缩到两天。

评测框架

为某个行业场景建立的评测标准，有跨客户的复用价值。医疗行业的文书准确性判断、金融行业的合规核查标准、制造业的设备参数异常识别——这类框架不是这一个客户特有的，是这个行业共同需要的。下一个同行业客户，不用从零建评测标准，可以在已有框架上做针对这个客户的适配。

部署模式和工作流

某类场景的标准部署路径，包括遇到什么类型的障碍用什么方法处理——把这些整理成可复用的工作流，新的FDE接类似项目时，已经知道这条路大概是什么样的，不需要每次重新发明轮子。

有三类东西通常不值得单独产品化：高度依赖这个客户特定组织结构的业务逻辑、只在这个项目里用过一次的临时方案、还没有在第二个客户身上验证过有没有普适性的方法。

产品化不是把这次交付的所有东西都整理一遍，是有选择地提炼出下次可以直接用的部分。

90天门槛：判断产品化有没有真正发生

判断FDE模式是否真正运转，最重要的指标是：第90天，至少有一个可追溯到这次交付的功能合并进了核心产品。如果FDE只建了一个定制集成，没有任何东西泛化进平台，你在运营的是一家外包服务公司。

一次完整的交付通常在60到90天之间，90天给了足够的时间积累真实反馈，又不会因为等太久让经验"变冷"——时间一长，当时为什么做这个判断、当时遇到的那个具体场景，细节会慢慢模糊。

OpenAI把这件事叫"持久产品化"，ServiceNow叫"可复用的AI原生模式"，Anthropic叫"可重复的部署模式"。措辞不同，任务是一样的。

具体怎么让这件事真正发生，而不是停在原则层面？需要一个固定的机制：FDE团队和核心产品团队之间定期开产品化评审，专门决定这次交付里什么东西可以泛化——一个新的连接器、一个新的评测框架、一个可复用的部署工作流——然后核心工程团队把它整合进平台，让下一个客户直接受益，而不需要这一切从头来。

这个机制不是可选的，是区分FDE模式和外包模式的实际标志。外包也会产出东西，但产出留在这个项目里，下一个项目换个人接，重新开始。FDE的产出要回流到平台，让整个系统比上一次更有能力。

产品化如何让下一次成本更低

当产品化的循环运转起来，下一个客户的边际成本就会下降。具体体现在三个维度：

发现阶段更快

上次建立的行业知识——这个行业的组织决策方式、常见的数据问题、用户信任建立的典型障碍——让FDE进场之后能更快定位真正的问题，不用从头开始摸索。

上次打通的连接器，让发现阶段对可行性的判断也更有依据。“这类集成我们做过，大概需要多长时间、会遇到什么障碍”——这个判断来自真实经验，不是估算。

工程化阶段更轻

可复用的连接器和部署模式，把重复性的集成工作从"每次重新写"变成"套用已有方案+针对这个客户的适配"。不是所有工作都能复用，但能复用的部分越来越多，需要从零开始的部分越来越少。

这个变化直接体现在工程投入上。第一个同类客户可能需要四周的集成工作，第三个类似客户可能只需要一周半——工程时间缩短，成本下降，FDE可以把省出来的精力用在真正需要定制判断的地方。

交付质量更高

前几次踩过的坑，后来的客户不用再踩。不只是速度变快，是交付出来的系统更可靠——已知的失败模式已经在产品里被处理掉了，已知的集成风险已经在工作流里有了对应的处理方案。

第一个客户拿到的，是FDE在现场一边学习一边交付的结果。第五个同类客户拿到的，是FDE已经踩过四次坑之后积累的最佳实践。两者的质量差距，对客户来说是看得见的。

需要FDE团队和核心产品团队共同参与

产品化不只是整理文档，不只是写复盘报告。它的本质是一个判断：这次交付里，什么是这个客户特有的，什么是后面的客户也会需要的。

这个判断做对了，沉淀下来的是真正有复用价值的资产。做错了，沉淀下来的是一堆只在特定上下文里有意义的文档，下一个FDE打开看了半天不知道怎么用。

判断能力是随着经验积累的。第一次做产品化，FDE可能不确定什么该提炼、怎么提炼。多次之后，哪类经验有普适性、哪类只是这个客户的特殊情况，判断会越来越准。

这也是为什么产品化需要FDE团队和核心产品团队共同参与，而不只是FDE自己整理——产品团队的视角是"这个东西对其他客户有没有价值"，这个视角是FDE在客户现场容易缺失的。两个视角合在一起，产品化的选择才会准确。

写在最后

FDE落地地图篇里说，FDE模式和定制开发的本质区别在于产品化闭环——每次交付都是下一次的起点，不是终点。

这话说起来容易，真正落地需要一个具体的机制：90天门槛、每周产品化评审、FDE团队和产品团队的协同判断。有了这个机制，边际成本才会随着交付次数有效下降；没有这个机制，FDE做的再好，也只是把同样的工作重复做了很多次。

下一篇进交接阶段——产品化完成之后，FDE怎么把系统和运营能力完整移交给客户内部团队，同时保证自己撤出之后系统继续运转，不依赖FDE的持续在场。

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

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