AI能力与落地困境：FDE模式的兴起

如今，我们正处在一个矛盾的时代。一方面是AI能力的狂飙突进，GPT、Gemini、Claude、Grok、DeepSeek、Qwen、GLM、Kimi等模型迭代速度之快令人应接不暇，技术发布会上展示的能力让人感觉AGI（Artificial General Intelligence: 通用人工智能，指拥有与人类同等或超越人类智能水平的AI）仿佛触手可及。另一方面，却是企业应用部署的步履蹒跚，许多企业浅尝辄止地体验过后，却不知道如何将这些“魔法”真正融入到自己复杂又具体的业务流程中。大家都认为AI的潜力巨大，但从潜力到生产力的最后一公里，成为了一道难以逾越的鸿沟。简而言之，模型的能力和落地之间出现了巨大的断层。

为了解决这个问题，硅谷开始重新兴起FDE（Forward Deployed Engineer: 前线部署工程师，驻场客户公司，负责弥合产品功能与客户需求之间鸿沟的技术人员）模式，更接地气一点，就是驻场工程师。最近，YC请到了OpenAI原首席研究官鲍勃·麦格鲁（Bob McGrew），他曾在PayPal（PayPal: 一家全球领先的在线支付服务商）、Palantir（Palantir: 一家专注于大数据分析和情报软件的公司）担任过核心技术人员。有趣的是，一同参与讨论的AI创业者们并没有问他如何打造下一个GPT，而是一直向他请教Palantir的FDE模式到底是怎么玩的。Bob不禁感慨，在过去一年里，他为许多创业公司提供咨询服务，他们几乎把所有精力都用来学习FDE策略是如何运作的。这个诞生于20年前，曾被视为非主流、劳动密集型、无法规模化的模式，为什么在AGI前夜突然又成为了AI公司，特别是AI Agent（人工智能代理: 能够感知环境、做出决策并采取行动以实现特定目标的人工智能系统）公司们争相学习的“屠龙之术”呢？今天，我们就来拆解一下FDE模式，看看它究竟是AI落地的灵丹妙药，还是又一个美丽的陷阱。

FDE的定义与传统模式的对比

我们先来给FDE下一个简单的定义。按照Bob给出的定义，FDE通常指的是一个技术人员，一个工程师，他驻场在客户的公司办公，核心任务是负责填补产品现有功能与客户实际需求之间的鸿沟。

这听起来可能有点抽象，我们把它放到一个具体的场景里。假设你开发了一款强大的AI数据分析软件，你带着这款产品去见一个制造业的客户，他们最大的痛点是产线上的次品率太高，想用你的软件来解决。问题是，你的软件是一个通用平台，并没有针对制造业残次品分析这个场景做过任何优化，客户的数据格式、工作流程、分析维度都和软件预设的功能不一样。那这时候该怎么办呢？传统的SaaS（Software as a Service: 软件即服务，一种通过互联网提供和使用软件的模式）公司可能会说：“抱歉，我们的产品目前不支持这个功能，我们会记录下来，在未来的开发计划里排期。”然后，这份订单大概率就黄了。而采用FDE模式的公司会怎么做呢？他们会派一个FDE团队进驻到客户的工厂里，和客户的业务人员坐在一起，用现有的产品作为基础，写代码、做定制、整合数据，在客户现场拼凑出一个能解决问题的方案。Bob把这个过程形容为铺出一条能够勉强通行的“碎石路”。这条路虽然简陋，但是它解决了客户的燃眉之急，交付了一个实实在在的结果。

与传统的、由销售主导的模式相比，FDE模式有着明显的区别。首先，销售人员是从外部与客户沟通，带回的是二手信息和需求列表；而FDE则作为内部人员，与客户一同工作，亲手解决问题。他们能发现客户自己可能都没能清晰表达的、更深层次的痛点和机会。用Bob的话说，这是一种由内而外的、更贴近实战的产品需求发现机制。

Palantir的FDE起源：历史的无奈之举

有意思的是，FDE模式虽然起源于Palantir，但并不是一个深思熟虑的刻意设计，而是在特定历史条件下的一种无奈之举。时间回到2000年代中期，Palantir刚刚成立，他们的目标非常明确：为美国的情报机构，特别是那些神秘的间谍们，打造一款数据分析软件。但是问题来了，公司里自然没人当过间谍，所以也没人知道间谍究竟是怎么工作的。Bob回忆起来说，就算你找到一个间谍，问他具体是做什么，他通常也不会告诉你。

面对这样一个完全陌生的用户群体和高度保密的工作内容，Palantir只能采用Demo驱动的开发方式。他们先是基于自己的想象，做了一个Demo。然后，联合创始人史蒂芬·科恩（Stephen Cohen）就拿着这个Demo跑去给情报界的潜在客户看。客户的反应也很直接，说这东西做得实在是太烂了，跟我们实际的工作完全没关系。史蒂芬就会追问：“那您觉得，要怎么改才能对您有用呢？”于是客户就提出各种修改意见，这里加个功能，那里改个流程。史蒂芬把所有的意见都记下来，回去之后连夜修改Demo，第二天再拿一个新的版本给客户看，如此反复。这也正是保罗·格雷厄姆（Paul Graham）后来布道的核心理念：“去与顾客交谈，制造他们想要的东西（Go talk to customers, make things people want）。”Bob也开玩笑地说，自己花了好几年才掌握的秘诀，后来被Paul Graham一条推文就给总结了。

PMF后的关键转折：定制化成为核心能力

不过，FDE模式真正的关键转折点还是发生在找到PMF（Product-Market Fit: 产品市场契合点，指产品在目标市场中找到足够多的客户并满足其需求的状态）之后。按照传统的硅谷剧本，一旦你找到了PMF，接下来要做的就是要拥抱与客户的距离，全力以赴地去搞规模化。你要做的就是把产品标准化，让所有客户都用同样的功能，然后疯狂地招销售，把市场份额做大。如果你能做到这一点，那么恭喜你，你就拥有了一台印钞机。Bob也强调，如果你手里的业务能这么做，那就千万别学FDE。

但是Palantir发现，这条路走不通。因为他们遇到的每一个客户，需求都存在细微但是关键的差异。这就导致为A客户开发的功能，B客户可能完全用不上，反之亦然。如果为每个客户都开发一个独立的产品，那公司就变成了一个项目外包公司；如果试图把所有功能都集成到一个产品里，那这个产品又会变得臃肿不堪，最终谁都用不好。正是在这个两难的困境中，Palantir的早期核心员工、现任CTO的希亚姆·桑卡尔（Shyam Sankar）真正发明出了FDE策略。希亚姆意识到，既然无法避免为每个客户做定制化，那不如把这种定制化本身变成一种有价值的核心能力。也就是说，他们不应该构建一个固化的产品，而是应该打造一个高度灵活的平台，这个平台能够提供核心的能力，但是具体应用则由FDE在客户现场进行定制化的配置和开发。于是他提出，FDE在客户现场做的那些定制化开发，不应该被看作是服务成本，而应该被看作是产品发现的过程。这种做法在当时违背了硅谷对于纯软件、零边际成本的信仰，但也正是这个无奈之举，最终构成了Palantir坚不可摧的护城河。

FDE的闭环机制：从“碎石路”到“柏油高速公路”

前面我们提到，FDE在客户现场铺设了一条所谓的“碎石路”。而总部产品和工程团队的任务，就是观察这些FDE铺设的无数条“碎石路”，然后思考一个问题：下一批5个或者10个客户，他们可能会需要什么样的路？然后，总部的团队要把那条最普遍、最有价值的“碎石路”修建成一条通用的、高质量的“柏油高速公路”，也就是把这个功能沉淀到核心产品里去。

这样一来，就形成了一个完美的闭环：FDE在前线，利用产品的平台化能力，快速响应客户的个性化需求，解决具体问题，完成产品发现的过程。而总部产品团队在后方，将前线验证过的、最有价值的功能产品化，提升平台的核心能力。这样一来，随着时间的推移，核心平台就会越来越强大，而FDE在新的客户现场需要铺设的“碎石路”就会越来越少。这样他们可以把更多精力放在为客户解决更深入、更有价值的新的问题上。这本质上其实是一种商业哲学，也就是在规模化的状态下，持续去做那些无法规模化的事情。

Palantir内部的FDE团队架构：Echo与Delta

那么在Palantir内部，FDE团队具体是如何运作的呢？Bob介绍了一个核心的组织架构，这个架构由两种关键角色组成，他们被称为Echo 团队（Echo Team: Palantir内部负责发掘客户深层需求并维护客户关系的团队）和Delta 团队（Delta Team: Palantir内部负责将客户需求快速转化为可运行原型系统的技术实现团队）。

Echo团队通常不是技术背景最强的人，但是他们拥有深厚的领域知识。比如，如果要服务军方客户，Echo团队的成员可能就是一位退役的陆军军官；如果要服务医疗客户，他可能就是一位资深的医疗行业从业者。他们听得懂客户的“黑话”，理解客户的工作流程和组织文化。他们的任务是深入客户内部，和一线的用户打成一片，去发掘客户真正面临的、最有价值的那个问题。同时，他们也扮演着客户经理的角色，负责维护客户关系。但是Bob强调，仅仅懂领域知识还不够，一个优秀的Echo成员必须是一个叛逆者或者异教徒。这是什么意思呢？他必须深刻理解现有工作方式的种种弊端，并且坚信一定有更好的方法去解决。如果他觉得现在的一切都很好，那他永远也无法帮助公司找到那个能带来3倍甚至10倍效率提升的突破口。毕竟，如果没有这种颠覆性的改变，客户又为什么要费那么大劲去采购和部署一套全新的、昂贵的软件系统呢？

相比之下，Delta团队里的尽是软件工程高手，尤其擅长快速编码和吃苦耐劳。他们需要把Echo团队发掘出来的想法和需求，迅速变成一个可以实际运行的原型系统。对于Delta成员来说，追求完美的软件抽象、编写可以维护十几年的优雅代码，并不是他们的第一要务。他们的核心目标是在一个极短的时间内交付一个能用的东西，一个能解决问题的软件。这个原型可能很粗糙，代码可能需要推倒重来好几次，但是这些都不重要。重要的是，它能在极短的时间内，在客户高管面前的汇报演示中，展示出实实在在的进展和价值。

显然，Echo和Delta这两种角色对人的要求截然不同。他们就像一个创业公司里的迷你创始团队：Echo团队负责找方向，定义问题和需求；而Delta团队负责做产品，解决问题。这种分工协作，使得团队既有对客户业务的深度理解，又有强大的技术执行力。有趣的是，这种FDE的经历本身就是最好的创始人训练营。你需要在资源有限的情况下，在一个陌生的环境里，去发现问题，定义产品，搞定客户，交付结果。这几乎涵盖了创业的所有核心技能。这也解释了为什么Palantir被称为硅谷的创业“黄埔军校”，后来从中也走出了大量的创业公司创始人。

FDE与咨询业务的本质区别

听到这里，很多人会有一个自然的疑问：“这听上去不就是咨询公司换了个马甲吗？只不过把咨询顾问换成了所谓的工程师，听上去更加酷炫一点而已。”而Bob则表示，这是一个非常真实的现实风险。如果执行不当，FDE模式确实很容易退化成一个传统的咨询业务，甚至最终沦为一家项目制的人力外包公司。

那么，一个健康的FDE模式和咨询业务的核心区别又在哪里呢？Bob提出了几个关键的衡量标准：

第一，要看成本和利润的变化趋势，同时关注一个关键的指标，那就是单位价值的交付成本的变化曲线。对于咨询公司来说，它的成本与收入呈线性关系，做一个项目收一份钱，做十个项目需要十倍的人力，利润率是相对固定的。而对于FDE软件公司来说，在项目初期，由于投入了大量FDE人力进行产品的发现和定制开发，很可能是亏损的。但是随着时间推移，这条曲线必须发生变化。首先是产品杠杆的提升，通过产品发现的过程，让核心产品的功能越来越完善，越来越贴合这个行业客户的需求。因此，在后续的部署中，需要的FDE人力会越来越少。其次是合同价值的增长，通过解决第一个问题，你赢得了客户的信任，能够接触到企业更核心、更有价值的业务场景，从而推动合同金额的持续增长。因此，一个健康的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（Customer Relationship Management: 客户关系管理，一种管理公司与客户之间互动的系统）软件去替代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的角色，他们的使命就是带着这些强大的模型，走到一线，去填补那道鸿沟。不过从目前的情况来看，无论是否采用FDE，AI的落地可能都会是一个艰苦、曲折的过程。对于AI创业公司来说，务必要做好打一场持久战的准备了。

希望今天的内容对AI创业的朋友来说能有一点帮助。那大家又是如何来看待FDE模式的呢？它真的能够解决AI落地的问题？还是咨询顾问加实施人员的“新瓶装旧酒”呢？欢迎在评论区留言。感谢收看本期视频，我们下期再见。