第一章 FDE 的本质与范式转移

第一章 FDE 的本质与范式转移

过去二十年，企业软件交付出现过两种主流模式。一种是以 IT 咨询公司为代表的现场交付，一种是以 SaaS 公司为代表的产品标准化。我在两种模式里都工作过，对各自的优势和缺口有切身的体会。FDE 是我看到的第三条路——它把前两者的优点合在了一起。

1.1 两套交付范式，各自留下了什么缺口

现场交付模式

我刚毕业那会在汉得信息工作过，恰好交付部门和产品部门都待过。在 2019 年左右，汉得的交付方式还是非常典型的 IT 咨询模式。

做法是这样的：产品中心开发标准化产品，交付中心带着产品到客户现场，和客户多轮沟通后，基于标准产品做二次开发。组织上，产品中心负责收集各项目的需求，形成标准化产品；交付中心在客户现场实施和二次开发。

在现场，团队分为业务顾问和技术顾问。业务顾问把客户需求梳理出来，技术顾问根据需求实现功能，业务顾问验收后和客户确认。客户认可，功能就并入当前项目的系统主线。

这套模式有一个容易被忽略的闭环。每周，各项目的需求池——当时上百个项目——会被汇总分析。如果超过 50% 的项目出现了同一种需求，这个需求就被拉到产品中心做标准化开发，完成后反哺给所有项目组，不用再重复造轮子。

我对这套模式的判断是：前线优先做得好，但标准化有结构性瓶颈。

顾问和工程师就在客户现场，离问题近，响应快。这是现场交付真正的优势。但闭环的问题比看起来更严重。

首先是 50% 的门槛太高——只有"大家都要"的需求才会被标准化。那些在少数项目里冒出来的创新、在特殊场景里发现的机会，永远过不了 50%，永远不会变成通用能力。

其次，哪怕需求过了 50% 被提交到产品中心，标准化产品的迭代周期也很慢——大概半年才会更新一次，有些情况下甚至一年。这意味着一个需求从被识别到变成标准化功能，中间隔了至少几个月。

最后，这个标准化功能只有给到之后的新客户才用得上。已经在线上跑着的旧项目，现场工程师还是得自己开发——或者等产品中心先做一个 Demo 出来，再由现场工程师并入当前项目的分支。本质上，已交付的项目并没有真正享受到标准化的红利。

SaaS 标准化模式

我后来去了三四家互联网 SaaS 公司。它们的做法和汉得完全不同，而且到目前为止，这个流程基本没有变化。

一个产品线，所有客户用同一套软件。某个客户提出需求后，运营团队收集反馈，产品经理评估，然后做一个决策：要么所有人用这个新模块，要么所有人都不用，要么直接拒绝。产品决策的逻辑是"一荣俱荣一损俱损"——没有中间态，没有"先给这一个客户做"。

整个流程是需求调研→产品→研发→测试→上线，但这个循环不围绕单个客户转，围绕整个产品转。

我对这套模式的判断是：标准化做得好，但离前线远了。

产品统一迭代，一个改进所有客户受益。但运营团队虽然在前端接触客户，不写代码、不解决技术问题——只负责"理解所有人的问题，取出可以被并入产品的部分"。产品经理坐在办公室里做决策，看不到系统跑起来之后客户那边真正发生的事情。

同一个缺口

两种模式放在一起看，有一个有意思的地方。

现场交付解决了"离客户近"，但标准化慢，项目间割裂。SaaS 解决了"标准化"，但离客户远了，个体需求被"所有人用或不用"的逻辑过滤掉。

两条路各留下了一个缺口，而且恰好是对方解决过的那个。

有没有一种模式，能把现场交付的前线优势和 SaaS 的标准化优势合并起来？

这就是 FDE 要回答的问题。

1.2 FDE：两条路的合题

FDE 不是对前面两种模式的否定，是合题。它从现场交付模式里取了前线优先的基因，从 SaaS 模式里取了平台化标准化的基因，用一种新的组织方式把它们接到一起。

FDE 有四个核心原则。

前线优先

四个里面最重要的一个。如果只留一个，就留这个。

前线优先的意思是：组织的所有设计——人才标准、考核方式、资源分配——都围着前线转。不是产品中心定义好东西让前线去卖，是前线发现问题、解决问题，然后把发现的东西带回来。

在汉得的现场交付模式里，前线已经有了，业务顾问和技术顾问就在客户那里。但前线被拆成了两拨人：一拨理解问题，一拨解决问题。FDE 的做法是把两拨人合成一个人，或者合成一个极小的单元。一个人（或两三人的 pod）嵌入前线，从理解问题到写出方案到上线到运营，全程负责。不用翻译，不用交接，不用等需求文档。

工程师前移

如果前线优先是原则，工程师前移就是操作层面的第一步。

传统模式下，工程师坐在产品中心或研发中心，等需求文档传过来。FDE 把工程师直接推到前线。不是顾问去前线、工程师留在后方，是工程师自己就在前线。这意味着工程师需要具备传统交付模式下不具备的能力：不只写代码，还要理解业务、和客户直接对话、独立判断什么值得做什么不值得做。

产品-前线闭环

这是从 SaaS 模式里取来的基因。

现场交付模式有闭环，但太慢、门槛太高。SaaS 模式的标准化快，但不来自前线。FDE 的闭环是：前线在解决一个客户的具体问题时，就在想"这个模式能不能抽象出来给下一个人用"。不需要等 50% 的项目有同样需求，不需要等一周汇总。

根据过往的经验，前线大约 70% 的工作成果可以沉淀为可复用的平台能力或模板。这个数字不是拍脑袋的——如果沉淀率太低，FDE 就退化成了"更贵的驻场开发"；如果要求 100%，前线就没有空间处理真正的特殊情况了。70% 是一个合理的区间。

迭代共创

前三个原则在时间维度上的展开。

FDE 不是"先想清楚再动手"，是边做边学。工程师嵌入前线后，和客户一起发现问题、定义问题、构建方案、上线验证、再调整。每个周期都在缩短"理解问题"和"解决问题"之间的距离。

四个原则的关系：前线优先是锚点，工程师前移是实现它的手段，产品-前线闭环保证前线经验不浪费，迭代共创是具体的工作方式。

1.3 从 Palantir 到 OpenAI：一个模式的扩散

被迫发明

FDE 最早的公开来源是 Palantir。

2000 年代中期，Palantir 做美国情报机构的生意。CIA、NSA 这些机构的数据高度机密、格式混乱、没有标准。传统软件销售模式——开发一个产品，卖给客户，客户自己配置——在这种场景下完全行不通。没人能把需求文档写清楚，因为需求本身就是混乱的。工程师不到现场，不知道数据长什么样、系统怎么运转、用户怎么工作。

Palantir 把工程师直接派到现场，和情报分析师坐在一起，边看边做。这个做法后来被命名为 Forward Deployed Engineer。

Palantir 随后把模式正式化：Delta 面向单一客户，在前线做技术驱动的价值创造；Dev 面向所有客户，负责平台能力建设。Delta 在前线发现的问题和模式，回流给 Dev 变成平台能力；Dev 的新能力，交给 Delta 在前线使用。

Palantir 不是先有了 FDE 理论再去实践的。他们碰到的是极端场景——需求没法文档化、数据没法标准化、环境没法远程访问——被逼出了这套做法。这个极端场景把两种旧范式的结构性缺陷放大到了无法忽视的程度：既需要前线优先（需求在现场），又需要平台化（每个客户的底层问题其实是相似的）。

从一家公司的做法到行业共识

Palantir 之后，FDE 没有停在一家公司。到 2025-2026 年，OpenAI、Anthropic、Vercel、Scale AI、Databricks 都在公开招聘和组织公告中使用了 FDE 这一角色标签。

OpenAI 成立了专门的部署公司，募资 40 亿美元，直接把前向部署工程师嵌入战略级客户，现场编写代码，定制化实施 AI 系统与决策工作流。Anthropic 与顶级投资机构成立部署合资企业，募资 15 亿美元，将 AI 研发力量深植于大型金融、保险及零售企业。

风投机构 a16z 的数据显示，FDE 岗位需求在 2025 年增长了超过 800%。不是一家公司在招一个特殊岗位，是一个行业在用脚投票：AI 时代，旧范式交付不了复杂系统，FDE 可以。

---