FDE 模式席卷硅谷：AI 能力狂飙却部署迟缓，一线驻场成为大模型落地的唯一解法？

我们正处在一个矛盾的时代。

一边是 AI 能力的狂飙突进。GPT、Gemini、Claude、Grok、DeepSeek、Qwen、GLM、Kimi……模型迭代的速度快到让人应接不暇。技术发布会上展示的那些能力，让人感觉 AGI 仿佛触手可及。

另一边却是企业应用部署的步履蹒跚。许多企业体浅尝辄止地体验过后，却不知道如何将这些「魔法」真正融入到自己复杂又具体的业务流程中。大家都认为 AI 的潜力很大，但从潜力到生产力的「最后一公里」，成了一道难以逾越的鸿沟。

模型的能力和落地之间，出现了巨大的断层。

为了解决这个问题，硅谷开始重新兴起 FDE 模式， 全称是 Forward Deployed Engineer，可以翻译成「前线部署工程师」或者「驻场工程师」。

最近，YC 请到了 OpenAI 原首席研究官 Bob McGrew，他曾经在 PayPal、Palantir 担任过核心技术人员。

有趣是，兴奋的 AI 创业者们并没有问他如何打造下一个 GPT，而是向他请教「Palantir 的 FDE 模式到底是怎么玩的？」

Bob 感慨道：

在过去一年里，我为许多创业公司提供咨询，他们几乎把所有精力都用来学习 FDE 策略是如何运作的。

这个诞生于 20 年前，曾经被视为「非主流」、「劳动密集型」、「无法规模化」的模式，为什么在 AGI 前夜，突然成了 AI 公司，特别是 AI Agent 公司们争相学习的「屠龙之术」？

今天，我们就来拆解一下 FDE 模式，看看究竟是 AI 落地的灵丹妙药，还是一个美丽的陷阱。

FDE：填补产品与需求鸿沟的「特种兵」

让我们先给 FDE 下一个简单的定义。

Bob 给出的定义是：

FDE 通常是一个技术人员，一个工程师。他驻场在客户公司办公，核心任务是负责填补产品现有功能与客户实际需求之间的鸿沟。

这听起来可能有点抽象，我们把它放到一个具体的场景里。

假设你开发了一款强大的 AI 数据分析软件。你带着这款产品去见一个制造业客户。他们最大的痛点是产线上的残次品率太高，想用你的软件来解决。

问题是，你的软件是一个通用平台，并没有针对「制造业残次品分析」这个场景做过任何优化。客户的数据格式、工作流程、分析维度都和软件预设的不一样。

这时候怎么办？

传统的 SaaS 公司可能会说「抱歉，我们的产品目前不支持这个功能，我们会记录下来，排入未来的开发计划」。然后，这份订单大概率就黄了。

而采用 FDE 模式的公司会怎么做？

他们会派一个 FDE 团队进驻到客户的工厂里，和客户的业务人员坐在一起，用现有的产品作为基础，写代码、做定制、整合数据，在客户现场拼凑出一个能解决问题的方案。

Bob 把这个过程形容为铺出一条能勉强通行的「碎石路」。

这条路虽然简陋，但它解决了客户的燃眉之急，交付了一个实实在在的「结果」。

与传统的「销售主导的产品发现」相比，FDE 模式有着本质的不同。

销售人员是从外部与客户沟通，带回的是二手信息和需求列表。

而 FDE 则是作为内部人员，与客户并肩作战，亲手解决问题。他们能发现客户自己都未能清晰表达的、更深层次的痛点和机会。

用 Bob 的话说，这是一种由内而外的、更贴近实战的产品需求发现机制。

FDE 的诞生：Palantir 的「无奈之举」

FDE 模式虽然起源于 Palantir，但并不是深思熟虑的刻意设计，而是在特定历史条件下的无奈之举。

时间回到 2000 年代中期，Palantir 刚刚成立，他们的目标非常明确，为美国的情报机构，特别是那些神秘的间谍们，打造一款数据分析软件。

但是问题来了：没人知道间谍究竟是怎么工作的。

公司里自然没人当过间谍。Bob 回忆说：

就算你找到一个间谍，问他具体做什么，他通常也不会告诉你。

面对这样一个完全陌生的用户群体和高度保密的工作内容，Palantir 只能采用 Demo 驱动的开发方式。

他们先是基于自己的想象，做了一个 Demo。然后，联合创始人 Stephen Cohen 就拿着这个 Demo，跑去给情报界的潜在客户看。

客户的反应也很直接「这东西太烂了，跟我们实际的工作完全没关系」。

Stephen 就会追问「那您觉得，要怎么改才能对您有用呢？」

客户提出各种修改意见，这里加个功能，那里改个流程。

Stephen 把所有意见都记下来。回去之后，连夜修改 Demo。第二天，再拿一个新的版本给客户看。

如此反复。

这也正是 Paul Graham 后来布道的核心理念：「Go talk to customers, make things people want.」

Bob 也开玩笑说，自己花了好几年才掌握的秘诀，后来被 Paul Graham 一条推文就给总结了。

但 FDE 模式真正的关键转折点，发生在找到「产品市场契合点」（Product-Market Fit）之后。

按照传统硅谷剧本，一旦你找到了 PMF，接下来要做的就是「拥抱与客户的距离」，全力以赴地搞「规模化」。

你要做的就是把产品标准化，让所有客户都用同样的功能，然后疯狂地招销售，把市场份额做大。如果你能做到这一点，恭喜你，你拥有了一台印钞机。

Bob 也强调，如果你手里的业务能这么做，那就千万别学 FDE。

但 Palantir 发现，这条路走不通。

他们遇到的每一个客户，需求都存在细微但关键的差异。为 A 客户开发的功能，B 客户可能完全用不上。反之亦然。

如果为每个客户都开发一个独立的产品，那公司就变成了一个项目外包公司。如果试图把所有功能都集成到一个产品里，那这个产品会变得臃肿不堪，最终谁都用不好。

正是在这个两难的困境中，Palantir 的早期核心员工、现任 CTO 的 Shyam Sankar，真正发明了 FDE 策略。

Shyam 意识到，既然无法避免为每个客户做定制化，那不如把这种「定制化」本身，变成一种有价值的核心能力。

他们不应该构建一个固化的「产品」，而应该打造一个高度灵活的「平台」。这个平台提供核心能力，但具体应用则由 FDE 在客户现场进行定制化配置和开发。

他提出，FDE 在客户现场做的那些定制化开发，不应该被看作是「服务成本」，而应该被看作是「产品发现」的过程。

这种做法违背了硅谷对「纯软件」、「零边际成本」的信仰。但正是这个「无奈之举」，最终构成了 Palantir 坚不可摧的护城河。

前面我们提到，FDE 在客户现场铺设了一条「碎石路」。而总部产品和工程团队的任务，就是观察这些 FDE 铺设的无数条碎石路，思考一个问题。

「下一批 5 个或 10 个客户，他们可能会需要什么样的路？」

然后，总部的团队要把那条最普遍、最有价值的「碎石路」，修建成一条通用的、高质量的「铺装高速公路」，也就是把这个功能沉淀到核心产品里去。

这样一来，就形成了一个完美的闭环。

• • FDE 在前线，利用产品的平台化能力，快速响应客户的个性化需求，解决具体问题，完成「产品发现」。
• • 总部产品团队在后方，将前线验证过的、最有价值的功能「产品化」，提升平台的核心能力。

随着时间推移，核心平台越来越强大，FDE 在新客户现场需要铺设的「碎石路」就越来越少，因为很多路已经被修成了「高速公路」。他们可以把更多精力放在为客户解决更深入、更有价值的新问题上。

这本质上是一种全新的商业哲学：在规模化的状态下，持续做那些无法规模化的事情 (doing things that don’t scale at scale)。

FDE 实战手册：Echo 与 Delta 团队

那么，在 Palantir 内部，FDE 团队具体是如何运作的呢？

Bob 介绍了一个核心的组织架构，这个架构由两种关键角色组成，他们被称为 Echo 团队和 Delta 团队。

Echo 团队：嵌入式分析师

Echo 团队通常不是技术背景最强的人，但他们拥有深厚的「领域知识」。

比如，如果要服务军方客户，Echo 团队的成员可能就是一位退役的陆军军官。如果要服务医疗客户，他可能就是一位资深的医疗行业从业者。

他们懂客户的「黑话」，理解客户的工作流程和组织文化。他们的任务是深入客户内部，和一线的用户打成一片，去发掘客户真正面临的、最有价值的那个问题。同时，他们也扮演着客户经理的角色，负责维护客户关系。

但仅仅懂领域还不够。Bob 强调，一个优秀的 Echo 成员，必须是一个「叛逆者」或者「异端」。

什么意思？

他必须深刻理解现有工作方式的种种弊端，并坚信「一定有更好的方法」。如果他觉得现在的一切都很好，那他永远也无法帮助公司找到那个能带来 3 倍甚至 10 倍效率提升的突破口。

没有这种颠覆性的改变，客户为什么要费那么大劲，去采购和部署一套全新的、昂贵的软件系统呢？

Delta 团队：前置部署工程师

Delta 团队是软件工程高手，尤其擅长「快速编写代码」和「吃苦」。

他们需要把 Echo 团队发掘出来的想法和需求，迅速变成一个可以实际运行的原型系统。

对 Delta 成员来说，追求完美的软件抽象、编写可以维护十几年的优雅代码，并不是第一要务。他们的核心目标是在一个极短的时间内，交付一个能用的东西，一个能解决问题的软件。

这个原型可能很粗糙，代码可能需要推倒重来好几次，但这不重要。重要的是，它能在极短的时间内，在客户高管面前的汇报演示中，展示出实实在在的进展和价值。

协作与画像

Echo 和 Delta 这两种角色，对人的要求截然不同，他们就像一个创业公司的迷你创始团队。

• • Echo 负责找方向，定义问题 (What & Why)。
• • Delta 负责做产品，解决问题 (How)。

这种分工协作，使得团队既有对客户业务的深度理解，又有强大的技术执行力。

有趣的是，这种 FDE 的经历，本身就是最好的「创始人训练营」。你需要在资源有限的情况下，在一个陌生的环境里，去发现问题，定义产品，搞定客户，交付结果。这几乎涵盖了创业的所有核心技能。

这也解释了为什么 Palantir 被称为硅谷的「创业黄埔军校」，后来走出了大量的创业公司创始人。

FDE 究竟是不是「咨询」？

听到这里，很多人会有一个自然的疑问。

这听上去不就是咨询公司换了个马甲吗？把咨询顾问换成了工程师，听起来更酷炫而已。

Bob 表示，这是一个非常真实的现实风险。如果执行不当，FDE 模式确实很容易退化成一个「咨询业务」，甚至最终沦为一家项目制的人力外包公司。

那么，一个健康的 FDE 模式，和咨询业务的核心区别在哪里？

Bob 提出了几个关键的衡量标准。

第一，看成本和利润的变化趋势。

关注一个指标：单位价值交付成本的变化曲线。

• • 咨询公司：其成本与收入呈线性关系。做一个项目收一份钱，做十个项目需要十倍的人力，利润率是相对固定的。
• • FDE 软件公司：在项目初期，由于投入了大量 FDE 人力进行产品发现和定制开发，很可能是亏损的。但随着时间推移，这条曲线必须发生变化。

这种变化在于：

1. 1. 产品杠杆提升：通过「产品发现」，核心产品的功能越来越完善，越来越贴合这个行业客户的需求。因此，在后续的部署中，需要的 FDE 人力会越来越少。
2. 2. 合同价值增长：通过解决第一个问题，你赢得了客户的信任，能接触到企业更核心、更有价值的业务场景，从而推动合同金额的持续增长。

因此，一个健康的 FDE 业务，其成本曲线应该是下降的，而交付的价值和合同金额曲线应该是上升的。最终，项目的利润率会从负转正，并且持续增长。

第二，看核心产品是否在持续进化。

FDE 模式的核心，绝对不是让 FDE 们在外面成立一个个独立的「外包开发小作坊」。

FDE 在前线做的所有工作，都必须有一个反馈机制，能将通用的需求和模式「反哺」给总部的产品团队。

这里就涉及到一个非常关键，但又常常被忽视的角色，产品经理。

在一个 FDE 驱动的公司里，产品经理的角色和传统的 SaaS 公司非常不一样。他们需要具备极高的「抽象能力」。

当一个 FDE 从客户现场带回一个需求时，产品经理不能直接说「好的，我们把这个功能加到产品里」。这样做出来的产品，往往会为某个客户过度定制。

他必须思考「这个需求的本质是什么？它代表了哪一类通用问题？我们应该如何设计一个更通用的功能，既能解决这个客户的问题，也能服务未来 10 个类似的客户？」

这种从具体问题中「猜测正确的通用问题」的能力，是 FDE 模式能否最终走向规模化的关键。

所以，FDE 和咨询的根本区别在于，FDE 的最终目标是打造一个越来越强大的平台化产品，而咨询的目标是完成一个个独立的交付项目。

AI Agent 时代，FDE 模式为何全面复兴？

过去，FDE 一直被视为 Palantir 的「独门绝技」，是其特殊客户性质 (政府、军队) 的产物。

也因此，即便 Palantir 取得了成功，这种做法在很长一段时间里都被认为是「个例」，甚至被建议「不要模仿」。

那么，是什么让 AI Agent 创业公司，集体走上了这条「别无选择」的道路？

Bob 认为，当前 AI Agent 所处的市场阶段，与 Palantir 当年面临的困境高度相似，都源于一个核心事实：

它们都在创造一个全新的市场品类，这个品类里不存在成熟的现有产品。

这背后有方面含义。

第一是市场的异质性。

Palantir 当年服务的市场，看似都是「政府」，但内部差异巨大。国家情报、国家执法、军队，甚至军队内部的反恐和反核扩散，其工作流都完全不同。

每一个细分领域，都可以看作一个独立的市场。 你需要先在一个细分市场里通过 FDE 模式找到 PMF，然后把经验和产品能力复制到下一个细分市场。这个过程需要不断地重复「做不能规模化的事」。

今天 AI Agent 面临的情况非常类似。所谓的「AI Agent」并不是一个单一的市场，它会渗透到各行各业的无数个具体场景中。每个场景的工作流、数据、决策逻辑都千差万别。这是一个高度异质性的市场，不存在一个「万金油」式的产品可以通吃。

第二，AI Agent 是一个「全新的产品品类」。

如果你想做一款新的 CRM 软件，去替代 Salesforce。虽然很难，但至少市场的需求是明确的，大家知道 CRM 是干什么的，应该有什么功能。

但 AI Agent 不是。

目前没有人能准确定义，一个成熟的 AI Agent 产品到底应该是什么形态。用户自己也不知道他们到底需要什么样的 Agent。

市场上没有现成的参照物。

这和 Palantir 当年面临的局面一模一样。在 Palantir 出现之前，情报分析师们协作的方式，居然是在一个类似 PowerPoint 的工具里画关系图，然后把文件传来传去。Palantir 创造了一个全新的品类。

当你在创造一个新品类时，产品发现的价值就变得至关重要。 你无法通过市场调研来了解用户需求，你唯一能做的，就是像 FDE 那样，扎到用户的真实工作流里，和他们一起去探索、去创造。

这就是为什么 FDE 模式突然火了。

因为今天的 AI 创业者们，就像当年的 Palantir 一样，面对的是一片充满未知和机会的无人区。

他们需要做的，不是优化一条已有的路，而是去探索和开辟一条全新的路。

FDE 模式下的商业逻辑：卖「结果」，而不是卖「软件」

当产品形态和交付模式都发生改变时，商业模式也必须随之调整。

传统的 SaaS 软件，通常是按「订阅账户」或者按「实际用量」收费。这种模式简单、可重复、易于规模化。

但在 FDE 模式下，这种定价方式失效了。

因为你卖的不再是一个标准化的软件工具，而是一个帮助客户解决特定问题的「结果」。

那么，该如何为「结果」定价？

这是一个困扰着无数 AI 创业者的问题。Bob 提到，FDE 模式会天然地将公司推向「更大、更灵活的合同」。

你不用去纠结一个账号卖多少钱，而是应该和客户一起评估，你帮他解决的这个问题，到底值多少钱。

这种「价值定价」和「风险共担」的模式，在早期对创业公司其实是有利的。

初创公司可以承担早期风险，对客户说「你不用先付钱，等我们做出了效果，你再根据效果付费」。

这种自信，往往是敲开大客户大门的最好方式。

在 FDE 模式下，CEO 需要关注两个最核心的内部指标：

• • 交付给客户的结果价值：我们为客户解决的问题是否越来越重要？创造的价值是否越来越大？
• • 产品杠杆：我们的核心产品是否让 FDE 交付这些结果变得越来越容易？FDE 是否需要更少的时间和代码就能完成部署？

一个成功的 FDE 公司，必须同时在这两个维度上取得进展。前者决定了公司的收入天花板，后者决定了公司的利润率和扩张速度。

小结

在 Bob 看来，未来五年世界的样子可能是，AI 能力一路狂奔，但现实世界的变化却可能比我们想象的要慢得多。

这种「能力」与「应用」之间的巨大鸿沟，正是创业者最大的机会所在。

而填补这条鸿沟，需要的不仅仅是更强大的模型，需要一种更贴近客户的落地方法论。

过去人们想象 AGI 诞生，可能是过了一个周末，它就突然觉醒并接管了世界。但现在看来，这个过程被严重简化了。

AI 革命不会自动发生，它需要无数充满「人类智慧和探索精神」的团队，深入到各行各业的毛细血管中，历经无数痛苦和试错，将 AI 的潜力真正转化为生产力。

OpenAI、Google 这样的基础模型公司，就像是 FDE 模式中的「总部产品团队」，他们负责打造越来越强大的通用平台。

而广大的 AI Agent 创业公司，则扮演了「前置部署工程师 (FDE)」的角色。

他们的使命，就是带着这些强大的模型，走到一线，去填补那道鸿沟。