FDE 模式：硅谷新热潮，在国内水土不服吗？

最近，无论是在行业内，还是在我的读者群里，大家都在讨论同一件事：Palantir、OpenAI 以及众多硅谷创业公司正在大规模招聘 FDE（Forward Deployed Engineer，前沿部署工程师）。FDE 这个岗位名称对很多人来说还比较陌生，但在硅谷已经成为最热门的话题之一。据 YC 的统计，目前有超过 100 家 YC 创业公司在招聘 FDE 相关员工，而 3 年前这个数字还是 0。

而这个变化背后到底意味着什么？FDE 模式在国内是否可行？在这篇文章中，我会结合自己在 2B 软件领域十多年的经验，和大家聊聊我对这个话题的思考。

PART01

什么是 FDE 模式

01. FDE 到底是做什么的

简单来说，FDE 是一位技术人员，会驻扎在客户现场，填补产品功能与客户需求之间的差距。

这听起来似乎和传统的驻场开发没什么区别，但本质上有很大的不同。核心是被动与主动的区别。传统驻场往往是被动的“按需定制”，客户要什么就做什么。而 FDE 的目标是主动为客户交付有价值的结果（outcome），而不仅仅是软件或者服务。

让我用 Palantir 的例子来说明。Palantir 刚成立时，公司的重点是为情报部门搭建软件系统。面临的挑战是，他们几乎不认识任何情报工作人员，即便找到了这样一个人，对方也不可能详细告诉你具体的工作内容。

怎么办？Palantir 的做法是，先构建一个 demo，然后展示给潜在客户，收集反馈。创始人之一 Stefan Cohen 就做过这件事，他给潜在客户展示 demo，问：“你们觉得怎么样？”对方说：“这个产品太糟糕了，和我们做的事情完全没关系。”Cohen 继续问：“那你们希望它有什么不同？”然后把所有反馈都记下来，回去改进。

这个过程不断重复，直到产品真正能解决客户的问题。

02. FDE 团队的运作方式

在 Palantir，FDE 团队由两个核心角色组成：

Echo 团队：他们是嵌入式分析师（embedded analysts），会去客户现场，与用户交谈，深度融入客户业务，找出什么样的 demo 或用例对这个场景真正有价值。同时，他们也是客户经理，负责管理客户关系。

Delta 团队：他们是部署工程师，实际上就是软件工程师。这些人通常非常擅长快速编写代码，是把想法落地为实际运行产品的人。

所有这些都会在很短的时间内完成。FDE 团队带着一个项目的想法进场，设定好几个月后要向领导层做一次 demo，如果演示顺利，就会真正部署到客户的全组织范围。

03. FDE 不是咨询，而是产品探索

很多人会说：“这不就是咨询业务吗？”但 FDE 和咨询有本质的区别。

Palantir 的早期成员 Shyam Sankar 提出了一个关键的洞察：与其给每一家客户单独做一个版本，或者补一堆只适用于特定客户的功能，不如把产品做成高度可定制的平台。

FDE 的做法是：带着现有的产品进场，填补产品能力与实际需求之间的 gap，把路线先铺成一条“碎石路”（gravel road）。然后，总部的产品与工程团队再把这些现场做法抽象、泛化，修成能服务接下来 5 到 10 个客户的“高速公路”（paved superhighway）。

这就是为什么 FDE 不是咨询，而是产品探索的过程。FDE 是站在企业内部进行产品探索，而不是从外部与客户交谈。

从商业模式上看，Palantir 的一个关键趋势是：当他们去一个新客户那里做新项目部署时，一开始可能是在亏钱的，但随着时间推移，产品因为不断的产品探索而变得更适合这个客户的需求，交付成本逐渐下降，在这个客户的整体利润率从负转正。这个过程可能需要一年，也可能需要几年。

这就是 FDE 模式和咨询的本质区别：咨询是一次性的项目，而 FDE 是可以规模化的产品探索。

04.Palantir Ontology：从定制到平台化的关键

Palantir 能够让 FDE 模式运作起来的一个关键，就是他们发明了一系列的方法论以及方法论对应的平台。

以我上篇文章（从 Palantir 本体论到神策 SDAF 闭环：数据驱动决策闭环的两种实现路径）介绍过的 Ontology（本体论）为例：

最初，Palantir 在为美国政府和情报机构工作时，本能的做法是：给“人”建一张表，给“资金”再建一张表……但很快就发现，一旦要在不同机构和客户间部署，就会遇到无法通用的问题。

于是他们把抽象层级拉高，不再预设具体对象类型，而是让 FDE 按每个客户的语境去定义。底层只提供通用的对象、属性、链接等概念。Palantir Ontology 就是在这种思路下诞生的。

数据库模式本身极其通用，只保留：对象（objects）、属性（properties）、媒体（media）以及对象之间的链接（links）。至于每个客户场景下的具体语义，则由 Ontology 来编码。

这种做法不仅提高了交付效率，也让 Palantir 的产品从定制工具，演变成如今的 Gotham、Foundry、Apollo、AIP 这四大核心平台。从 Palantir 的最新年报可以看到：2024 财年的毛利率高达 80%，这意味着其软件业务已经实现了规模化效应。

PART02

在国内会水土不服吗

01.国内的普遍观点

行业内有一种普遍观点认为，FDE 不是什么新鲜事物，其实就是中国定开公司常见的驻场模式，只不过所谓 FDE 要更懂客户业务、更懂 AI、更懂产品。

更重要的是，很多人认为这种模式在国内不可持续。理由主要有以下几点：

第一，利润空间不足。国内 2B 项目的利润，没有高到可以吸引优秀的人才来做驻场，养不活优秀人才的高工资。

Palantir 的 FDE 新人总薪酬在 20-25 万美元，资深岗位可以达到 30-45 万美元。对应到国内，对应的 package 在 100 万人民币以上了。而国内 2B 项目的客单价和利润率，很难支撑这样的薪资水平。

第二，人才不愿意做驻场。优秀工程师的职业首选肯定是以字节为代表的互联网大厂。而即使选择了 2B 软件行业，肯定也是优先选择产品研发，最后才会考虑去做驻场开发。毕竟驻场工作更苦、更累、压力也更大，国内甲方客户对于乙方的驻场人员也的确算不上有多尊重。

第三，晋升机制有问题。在传统的 2B 公司，驻场干得好往往就会被升职，从一线“冲锋”变成后方办公室“指挥”。结果就是，最有经验的人反而离开了一线，这恰恰背离了 FDE 模式的初衷。

第四，产品抽象能力不足。Palantir 能够成功，很大程度上是因为他们发明了类似于 Ontology 这样的方法论和平台，能够把每次现场探索的经验沉淀为可复用的产品能力。但国内很多公司缺乏这种产品抽象能力，容易陷入“一次性定制开发”的陷阱。每个客户都要重新做一遍，无法从“碎石路”修成“高速公路”。

第五，组织文化和激励机制错配。FDE 需要很高的自主权，需要在客户现场快速做决策、快速迭代。但国内企业往往管控较严，审批流程长，很难给 FDE 足够的授权。更重要的是，缺乏将 FDE 打造为创业者培训营的文化。Palantir 的很多 FDE 后来都成为了成功的创业者，这本身就是一个巨大的吸引力。但国内公司往往没有这样的长期视角。

第六，市场竞争环境的问题。国内 2B 市场的竞争非常激烈，低价竞争很普遍。客户很容易被“看起来差不多但便宜很多”的方案吸引。即使你的 FDE 团队能力再强，也很难在招投标中说服客户接受高出数倍的报价。这就导致很难维持 Palantir 那样的高客单价和高利润率。

02.这些问题确实存在

作为一个在 2B 软件领域工作了十多年的从业者，我必须承认，这些问题确实存在，而且很严重。

在神策数据的早期，我们也面临过类似的挑战。客户希望我们派人驻场，帮助他们完成数据接入、分析建模等工作。但我们很快发现，如果每个客户都派人驻场，成本会非常高，而且很难规模化。

从我的观察来看，国内 2B 软件的利润率远低于 Palantir 的 80%。这样的利润空间，确实很难支撑一个大规模的 FDE 团队。

更重要的是，国内 2B 市场的定价机制和国外有很大差异。国内客户在项目上往往更看重“买断”而不是“订阅”，更看重“功能”而不是“效果”。这就导致很难像 Palantir 那样，按照交付的结果（outcome）来定价。

03.但也不能一概而论

虽然问题很多，但我认为也不能一概而论。这些判断更多来自传统 2B 软件的经验，但换个角度看，会发现 FDE 模式在国内也有其可行性：

第一，项目价值决定了利润空间。前面提到国内 2B 项目利润不足以支撑高薪 FDE，但这个判断需要分场景。在金融风控、能源调度、智能制造等领域，一个好的 AI 系统可能带来数亿元的价值。如果按照“效果付费”而非“功能买断”，客单价完全可以支撑百万级薪资的 FDE 团队。问题不是利润空间不存在，而是我们有没有能力去服务这样的高价值场景。

第二，人才吸引力的本质是成长空间。优秀工程师不愿做驻场，本质上不是因为“驻场”这个形式，而是因为传统驻场缺乏成长空间。但如果像 Palantir 那样，把 FDE 定位为“深入业务一线的产品探索者”和“未来创业者的培训营”，给予足够的自主权和决策权，这个岗位的吸引力就会完全不同。关键是要改变 FDE 的定位，从“执行者”变成“探索者”。

第三，晋升机制可以重新设计。传统驻场的晋升逻辑是“做得好就调回总部”，这确实有问题。但我们完全可以设计新的晋升路径：让资深 FDE 不是“脱离一线”，而是“带领团队攻克更难的客户”“探索更前沿的场景”。甚至可以让优秀的 FDE 成为内部创业者，孵化新的产品线。这需要的是组织创新，而不是照搬传统模式。

第四，产品抽象能力是可以培养的。国内公司确实在产品抽象能力上普遍不足，但这不是不可改变的。Palantir 的 Ontology 也不是一开始就有的，而是在大量项目实践中逐步抽象出来的。关键是要建立“从碎石路到高速公路”的产品开发机制，让每一次客户项目的经验都能沉淀为可复用的产品能力。这需要产品团队和 FDE 团队的紧密协作，而不是各自为战。

第五，组织文化是战略选择的结果。FDE 需要高度授权，但国内企业管控较严，这是事实。但如果我们把 FDE 模式作为核心战略，组织文化就必须随之调整。就像当年互联网公司引入敏捷开发，也经历了从“不习惯”到“新常态”的过程。关键是高层要有决心，把 FDE 作为核心竞争力来打造，而不是作为边缘业务来试水。

第六，市场竞争环境正在分化。低价竞争确实普遍，但市场正在分化。越来越多的头部客户开始意识到，AI 项目的成败不在于买了什么软件，而在于能否真正解决业务问题。这些客户愿意为优质服务付费，也更看重长期合作而非一次性交付。FDE 模式的目标客户，恰好是这部分正在觉醒的高价值客户，而不是还在打价格战的长尾市场。

第七，大环境可能正在变化。过去十年，国内 2B 市场的主题是“跑马圈地”，大家比的是谁签约客户多、谁收入增长快。但现在市场进入存量竞争阶段，客户续费率、客户 LTV（生命周期价值）变得更重要。这意味着，深度服务好一个客户，比签下十个不续费的客户更有价值。这种市场环境的变化，恰好为 FDE 模式创造了生存土壤。

PART03

AI 时代可能带来的改变

01.AI 项目的特殊性

AI 时代，尤其是 AI Agent 的兴起，可能会给 FDE 模式带来新的机会。原因有几点：

第一，AI 项目交付比传统软件项目交付更难。AI Agent 还无法像以前的 SaaS 那样基于标准化产品实现规模化扩张。每个企业的业务流程、数据结构、应用场景都不一样，需要大量的定制化工作。这恰好契合了 FDE 模式的特点。

第二，AI 放大了优秀个体的作用。在传统软件开发中，一个优秀程序员和一个普通程序员的生产力差距可能是 3-5 倍。但在 AI 时代，借助 AI 工具，一个优秀程序员的生产力可能是普通程序员的 10 倍甚至更多。这意味着，即使 FDE 的薪资很高，单位产出的成本可能反而更低。

第三，AI 能够提供更高的利润空间。如果 AI Agent 真的能够替代人工完成某些任务，那么它带来的价值就不是“提高效率”，而是“降低成本”。比如，一个客服 AI Agent 如果能够替代 10 个客服人员，那么它的价值就是每年节省的人力成本。这样的价值，足以支撑更高的定价。

02.核心问题：甲方能否转变思路

但是，AI 时代 FDE 模式能否在国内成功，核心问题不在于技术，而在于甲方能否转变思路。

具体来说，甲方需要回答两个问题：

第一，愿不愿意为“结果”付费，而不仅仅是为“功能”付费？如果还是按照传统的“买断”模式，要求乙方提供一个“交钥匙”的系统，那么 FDE 模式就很难运作。因为 FDE 模式的核心是产品探索，需要在实践中不断迭代，这个过程很难在签合同时就明确定义。

第二，愿不愿意为优秀的人才付费？Palantir 的 FDE 薪资水平远高于普通程序员，这反映在合同价格上，就是客单价会很高。如果甲方还是希望以最低的价格买到“差不多”的服务，那么就不可能吸引到优秀的乙方和优秀的 FDE。

从我的经验来看，的确有部分甲方正在逐渐转变思路。尤其是在一些对 AI 有迫切需求的行业，比如金融、制造、零售等，他们开始意识到，AI 项目的成功不是买一个软件就能解决的，需要深度的业务理解和持续的优化。但是，这个转变还需要时间。甲方需要经历足够多的失败项目，才会真正理解“便宜没好货”的道理。

03.一个可能的路径

如果要在国内推行 FDE 模式，我认为一个可能的路径是：

第一步，从高价值客户入手。不要试图服务所有客户，而是聚焦于那些真正有痛点、愿意为结果付费的客户。就像 Palantir 早期只服务 CIA 一样，先把一个客户服务好，打造出标杆案例。

第二步，建立产品杠杆。在服务客户的过程中，不断沉淀通用的产品能力。不要做“一次性”的定制开发，而要思考如何把这次的经验变成下次可以复用的模块。这需要有非常强的产品抽象能力。

第三步，培养 FDE 人才。把 FDE 打造成一个有吸引力的职业发展路径，而不仅仅是“驻场外包”。可以参考 Palantir 的做法，让 FDE 成为创业者的培训营，给他们足够的自主权和成长空间。

第四步，改变定价模式。从“按功能定价”转向“按效果定价”。这需要和客户一起探索新的合作模式，比如“无效果退款”、“按节省成本分成”等。

PART04

结 语

FDE 模式在国内是否可行，我认为不能一概而论。

从短期来看，FDE 模式在国内确实面临很多挑战，包括利润空间、人才吸引力、客户付费意愿等。但从长期来看，AI 时代可能会给 FDE 模式带来新的机会。

关键在于，能否找到愿意为结果付费的客户，能否建立起可规模化的产品杠杆，能否培养出优秀的 FDE 人才。

对于创业公司来说，我的建议是：不要盲目跟风，而要根据自己的实际情况来判断。如果你的产品需要大量的产品探索，如果你的客户愿意为结果付费，如果你能够吸引到优秀的人才，那么 FDE 模式是值得尝试的。

但如果只是把 FDE 当作“驻场外包”的另一个更好听的名字，那么还是不要浪费时间了。

上述所有观点只代表我个人看法，希望能够对大家有所帮助。有错漏之处不可避免，还请大家谅解。