AI 模型能力快速迭代的当下，“如何落地 AI” 成为关键难题，硅谷 FDE 模式（驻场工程师模式）因此再度兴起。超 100 家 AI Agent 公司及 OpenAI 均在招募 FDE，这类工程师驻扎客户现场，填补 “产品能力” 与 “客户需求” 的鸿沟。
在模型能力快速迭代之下，如何落地AI成了所有人关心的一个话题。
原因很简单，尽管AI能力很强，但如何将这些「魔法」真正融入到自己复杂又具体的业务流程中，成了一道难以逾越的鸿沟。
这不，为了解决这个问题，硅谷开始重新兴起了一个新的模式：FDE。
简单说，FDE就是一个驻扎在客户现场的工程师，负责填补“产品能做什么”和“客户需要什么”之间的巨大鸿沟。
这模式现在有多火？YC的招聘网站上，已经超过100家上百家AI Agent公司在招FDE，连OpenAI自己也组建了FDE团队，专门服务大客户。
甚至连 Bob McGrew（Palantir前高管、OpenAI 前首席研究员）都忍不住调侃：他去参加 AI 创业者大会，大家对 ChatGPT 或 GPT-4 没啥兴趣，全场只想问他一件事——Palantir 的 FDE 模式到底怎么玩？
今天乌鸦君就来聊聊，这个十几年前又重又累的模式，为什么在AI时代突然就火了？
FDE模式，最早源于Palantir。
甚至毫不夸张的说， FDE模式撑起了如今4000亿美金的Palantir。
故事还要从Palantir创业伊始说起。在2003年，Palantir刚刚成立，想给CIA（美国中央情报局）、NSA（美国国家安全局） 做一款分析软件。
这时候却犯了难。因为由于情报工作的特殊性，你根本没法直接问间谍“你们平时怎么工作”，因为没人会告诉你。
更麻烦的是，这些任务差异极大：反恐、反核扩散、反洗钱……听上去都是“信息分析”，但用到的数据源、操作流程、优先级完全不一样。
当时，Palantir的创始人Stephen Cohen带着演示版去CIA展示，对方直接泼冷水：“这和我们做的事一点关系都没有。”
换成别人可能就灰心了，但Cohen接了一句关键的反问：“那你们希望它能做什么？”这一问，成了 Palantir 命运的转折点。
团队很快意识到，那种靠销售收集需求，再由工程师开发的传统模式根本跑不通。必须有人直接扎到客户现场，和他们一起摸索，一边改一边用。这就是FDE模式的雏形。
这种模式在战场上很快就见效了。在伊拉克和阿富汗战场，美军最怕的就是路边炸弹，传统做法只能靠巡逻或者事后排查，危险又低效。
与士兵混在一起的Palantir的工程师发现，这些士兵根本不需要什么花哨的情报图表，而是只想要一个能在地图上标注“这条路可疑”的小工具。于是，工程师当场拼了个简易地图，士兵点一下就能标出风险路段，其他人立刻能看到更新，绕开危险区域。
这个看似简陋的“土办法”，立刻改变了士兵的日常，降低了伤亡，还顺带沉淀成了 Palantir 平台的标准功能，并被用在走私追踪、资金流向等各种场景里。
后来，Palantir 的核心人物Shyam Sankar 干脆把这套“不得已的苦活”升级为正式打法：把这些驻场工程师命名为Forward Deployed Engineers，它们不是服务的执行者，更像是“产品探路者”。
在过去相当长时间里，这种“反直觉”的打法并没有在硅谷流行。原因很简单，这么做需要大量人力，短期内利润率极低，远远不如SaaS那样简单粗暴。
但Palantir 没得选。
他们发现每个客户需求都有细微但致命的差异，为A客户开发的功能，B 客户完全用不上。要么走向外包，要么产品臃肿成怪物，最后谁都不满意。
Shyam Sankar（公司CTO）的解决方案是：既然躲不开定制化，那就把定制化本身变成武器。他们做的不是死板的产品，而是高度灵活的平台。
FDE 在现场铺设“碎石路”，总部团队挑出最有价值的部分，修成“高速公路”，沉淀到平台里。久而久之，平台越来越强大，新客户的现场“土路”就越来越少，FDE可以把精力放在更深层次的问题上。
这构成了Palantir与其他科技最大的不同。
按照硅谷常规剧本，公司一旦找到 PMF，就会立刻拉开和客户的距离，把产品标准化，然后拼命招销售、搞规模化，把一套东西卖给所有客户。这样才快，才像台“印钞机”。
但Palantir却走了反方向：即使已经找到了PMF，他们依然选择继续做那些又重又累的事。FDE 工程师依旧扎在客户现场，一边帮客户解决独特问题，一边把最有价值的部分带回去沉淀成平台。
这其实是一种全新的商业哲学：规模化地做那些不规模化的事。这种“明明很笨重，却能不断积累优势”的方式，才慢慢变成了Palantir最大的护城河。
为什么现在FDE模式又火了起来？原因很简单：传统的 SaaS 卖软件逻辑，在 AI 时代彻底跑不通了。
AI 是个全新物种，没有现成的标杆。支付领域有 PayPal，CRM 有 Salesforce，你可以对照做得更好。但 AI 代理还没有统一定义，每个客户就像第一次接电网，连插头都不一样。一家银行要风控建模，一家物流公司要路线调度，听上去都在用 AI，落地方式却完全是两回事。
更麻烦的是，客户需求差异特别大，根本没法靠一个“标准产品”打天下。
举个实际的例子：一家做 AI 法律助手的公司，去大所谈业务时，律师们最关心的是合同条款能不能被准确标记；但同样的产品给中小律所用，他们更在意的是“能不能帮我写初稿”。同样一个“AI律师”，场景完全不同。
这意味着，产品探索成本极高。你只能把人派到客户现场，和他们一起用、一起改，才能摸清楚问题。YC 投的 Castle 就是这样起步的：工程师直接蹲在银行客服中心，盯着抵押贷款流程，一点点把 AI 语音助手调到能真正上手用。
为什么值得这么“重”？因为 AI 合同金额往往很大。一旦解决了客户的核心痛点，带来的价值是成倍的。
Palantir 当年在国防部，做的只是一个能让士兵在地图上标记可疑道路的小工具，却直接减少了踩地雷的风险，这就是无价的价值。现在很多 AI 初创公司和大银行、大物流公司签的单子，动辄上千万美元，这足以支撑前期的高投入。
就这样，FDE成了AI公司落地的标准打法：先靠人力硬凿，把需求摸出来，再把“土办法”抽象成平台，最后靠平台化来赚钱。
很多人听到这里，第一反应往往是：这不就是咨询吗？都是派人去客户现场，帮客户解决最急的问题嘛。但 Bob McGrew 提醒，真正健康的FDE和咨询，隔着一个天一个地。
区别的第一个维度，是钱。
咨询公司很直白：做一个项目收一份钱，做十个项目就要十倍人力，成本和收入几乎是线性关系，利润率很难有质变。
而FDE软件公司的逻辑完全不同：一开始派人驻场，投入大、效率低，往往是亏钱的。但随着一线经验不断沉淀到产品里，形势会出现拐点——核心产品功能越来越完善，部署越来越轻，FDE 投入越来越少。
同时，解决了第一个痛点后，你赢得了客户的信任，合同金额会一路走高。最终，曲线就变成了：成本线往下走，价值线往上走，利润率从负转正。这才是一家健康的FDE公司该有的样子。
区别的第二个维度，是 产品。
FDE 不是在外面养一堆“外包开发小作坊”，真正的价值在于“前线的发现”能否被总部产品团队吸收和沉淀。如果 FDE 只是在替客户写小工具，最后一定会陷入定制泥潭。
这里，产品经理的角色尤为关键。他不能简单地把客户的需求原封不动塞进产品里，否则产品会越做越臃肿。他必须具备极强的抽象能力，能从一个客户的具体需求里，提炼出背后的通用问题，并设计成适合未来十个客户都能用的功能。
Palantir 最早的本体论（ontology）就是这么来的：不直接做“反恐数据库”或“资金数据库”，而是抽象成“对象+关系”的通用模型，于是能跨场景灵活复用。
那么，FDE团队究竟是怎么干活的呢？
要想真正落地FDE模式，一个最好的案例就是Palantir。
Bob McGrew 透露，Palantir内部的FDE团队有两个关键角色：Echo（嵌入式分析师）和Delta（部署工程师）。
Echo 团队的人，多半来自客户所在的行业。他们要深潜到客户内部，听懂用户的“黑话”，摸清楚真正的痛点，还要顺带维护客户关系。
而Delta 团队则是“部署工程师”，负责快速写代码，把Echo的想法变成一个能跑起来的原型解决方案。
听起来分工挺清晰，但难点在于，这两类人都不是随便能找的。
Echo需要找那些具备叛逆精神的人，他们来自细分领域，是真正懂行的人，但又深刻理解现有模式不行、渴望变革。
Delta 团队则是真正的极客。他们需要在在最短时间里交出能跑的原型。粗糙没关系，能用最重要。因为他们要在客户高管面前，拿得出一个“看得见的结果”。
一个定义问题，一个解决问题。两者搭在一起，简直就是一个迷你创业团队：陌生的环境、有限的资源、必须快速交付结果。这也是为什么 Palantir 后来被称为“硅谷的创业黄埔军校”，从这里走出了大量创始人。
当然，要想让 FDE 模式跑通，还有三条“生死规则”：
第一，必须搞定客户CEO。Palantir 只做客户CEO最关心的前5个问题的项目，否则宁可不做。因为没有高层背书，内部流程绝对推不动。
第二，初期要敢赔本赚吆喝。大客户经历过太多失败项目，他们既不信自己，也不信你。你必须用“没效果就退款”这种方式换取信任。
第三，警惕沦为外包。客户往往会让你做些“容易交代”的小活，但真正的关键痛点不会主动交给你。FDE 的使命，就是找到并解决那个能改变客户命运的大问题。只有搞定了第一个核心问题，你才有机会渗透进更核心的系统。
这就是 FDE 的精髓：规模化地去做那些本来不该规模化的事。听上去笨重，但在一个没有标准答案的新市场里，这恰恰是最可靠的路径。
文/林白
本文由人人都是产品经理作者【乌鸦智能说】，微信公众号：【乌鸦智能说】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。