时代一直在巨变FDE就是背后的推力~一边是 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.产品杠杆提升通过「产品发现」核心产品的功能越来越完善越来越贴合这个行业客户的需求。因此在后续的部署中需要的 FDE 人力会越来越少。2.合同价值增长通过解决第一个问题你赢得了客户的信任能接触到企业更核心、更有价值的业务场景从而推动合同金额的持续增长。因此一个健康的 FDE 业务其成本曲线应该是下降的而交付的价值和合同金额曲线应该是上升的。最终项目的利润率会从负转正并且持续增长。第二看核心产品是否在持续进化。FDE 模式的核心绝对不是让 FDE 们在外面成立一个个独立的「外包开发小作坊」。FDE 在前线做的所有工作都必须有一个反馈机制能将通用的需求和模式「反哺」给总部的产品团队。这里就涉及到一个非常关键但又常常被忽视的角色产品经理。在一个 FDE 驱动的公司里产品经理的角色和传统的 SaaS 公司非常不一样。他们需要具备极高的「抽象能力」。当一个 FDE 从客户现场带回一个需求时产品经理不能直接说「好的我们把这个功能加到产品里」。这样做出来的产品往往会为某个客户过度定制。他必须思考「这个需求的本质是什么它代表了哪一类通用问题我们应该如何设计一个更通用的功能既能解决这个客户的问题也能服务未来 10 个类似的客户」这种从具体问题中「猜测正确的通用问题」的能力是 FDE 模式能否最终走向规模化的关键。所以FDE 和咨询的根本区别在于FDE 的最终目标是打造一个越来越强大的平台化产品而咨询的目标是完成一个个独立的交付项目。AI Agent 时代FDE 模式为何全面复兴过去FDE 一直被视为 Palantir 的「独门绝技」是其特殊客户性质 (政府、军队) 的产物。也因此即便 Palantir 取得了成功这种做法在很长一段时间里都被认为是「个例」甚至被建议「不要模仿」。那么是什么让 AIAgent创业公司集体走上了这条「别无选择」的道路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)」的角色。