为什么我要给想做FDE业务的老板泼一盆冷水

AI圈FDE模式成巨头新宠，国内老板却盲目跟风？一文揭秘其真相与落地误区。

核心内容：
全球AI巨头FDE布局：Palantir成功，OpenAI/Anthropic等大规模建团队招人
国内老板盲目跟风：简单复制“驻场全栈工程师”的错误认知
FDE真实运作细节：多角色小队现场观察，国内模仿者忽略关键要素

最近AI圈最热的三个字母，除了OPC，还有一个是FDE。

发明这个模式的Palantir，财报和股价双双起飞，不用再赘述。更有意思的是另外两家的动作：

OpenAI专门组建了FDE团队，挂在"Model Deployment for Business"下面，从纽约、旧金山到都柏林、新加坡、东京，一口气在十几个城市同步招人。今年5月它还成立了一家独立的"部署公司"（The Deployment Company），收购英国AI咨询公司Tomoro，一把收下约150名部署工程师。

Anthropic在Applied AI团队下大建FDE队伍，岗位说明写的是"嵌入我们最具战略性的客户内部"，年薪20万到30万美元。它还跟黑石、高盛搞了一个15亿美元的合资实体，干一件事：把工程师塞进被投企业里。

再往外看，Google Cloud、Salesforce、Snowflake、Stripe……名单还在变长。《金融时报》报道说，2025年前九个月，FDE岗位的月发布量涨了8倍。

当全世界最聪明的几家AI公司都在all in同一个模式时，国内老板的雷达自然就响了。我这段时间至少听了五六位老板说同一句话："我们也要搞FDE，招几个厉害的全栈工程师，直接驻到客户现场去，像Palantir、像OpenAI那样交付。"

每次听到这话，我都想泼一盆冷水。请你先睁大眼睛看看，All in这个模式的都是些什么公司：Palantir、OpenAI、Anthropic，全世界最不缺钱、最不缺顶级人才、最不缺平台沉淀的三家公司。一个连它们都要举全力去做的重模式，你打算用两个驻场的全栈工程师就启动？

不是这个模式不对。FDE是我见过的最扎实的AI落地方法论。问题在于，你今天在国内复制它，大概率复制出来的不是Palantir，而是一个改了名字的、更贵的外包团队。

一、先把FDE是什么搞清楚，很多老板根本没搞懂

大部分AI公司见客户的第一件事是演示。Palantir不是。它派人到你的办公室、工厂、指挥中心，坐下来，先看你怎么干活。

有几个细节，每一个都被国内模仿者忽略了。

去现场的不是一个人，是一个小队。Deployment Strategist负责定义问题、管理客户关系、衡量价值；FDSE负责数据、建模和技术实现；碰上复杂的基础设施，还有专门的FDIE管网络、部署、安全和生产运维。再加上客户那边的业务专家和IT，一个典型的现场项目是五六个人甚至更多。

他们到现场第一件事不是接需求，是观察。不开需求讨论会，跟着业务人员上班。看他们用什么系统，哪些数据靠手工从Excel复制到SaaS，哪些判断规则只存在于老员工脑子里，出了异常要打几个电话、找几个人签字。他们只回答一个问题：谁在什么时候，基于哪些信息，做什么决策，这个决策为什么慢、为什么错、为什么不可追踪。

他们找的不是"最适合AI的场景"，是"最关键的运营问题"。这两者之间的区别，比很多人想象的大得多。

他们不等数据治理。传统IT项目先花三个月做数据治理、建数仓、统一主数据。FDE不等。围绕那一个具体问题，找到最少需要哪几张表、哪几个API，先把最短的数据链路打通。有案例显示，第一周就把SAP、Salesforce、UPS和几个ERP的数据接进了平台。

几天之内交付一个能用的东西。不是PPT，不是原型截图，是真实数据、真实操作、真实用户能完成一次真实任务的应用。Palantir官方叫"1到5天，从零到用例"。调度员打开应用，看到今天可能延误的航班，点一个按钮重新分配飞机，结果直接写回航空公司自己的排班系统。这种东西在传统项目里通常要六个月。

AI是最后才上的。整个流程走到这里，还没提大模型一个字。只有当业务流程已经被对象、函数、动作和界面稳定承载之后，FDE才会往上叠LLM。叠了也不放手，先跑"影子模式"：系统给建议但不执行，人自己判断采不采纳，所有决策被记录、被评测，跑上几周，确认可靠了才一步步提高自动化程度。公开案例里，从最小可运行版本到覆盖大部分复杂业务查询，用了六周。

交付标准不是"系统上线"，是"系统真的改变了人的工作方式"。用户每天在用吗？决策变快了吗？业务指标改善了吗？FDE会一直做培训、改界面、改规则，直到答案是肯定的。

还有一个飞轮。FDE在现场发现的共性问题，会反馈给核心产品团队，把一次性定制变成平台的标准能力。下一个FDE去下一家客户，这个能力已经是产品的一部分。Foundry里很多工具就是这么长出来的。客户越多，现场经验越密集，平台越强，下一次交付越快。

这几条加起来，才是FDE。

二、FDE和外包的区别，不是程度问题，是物种问题

我知道有老板会说：这不就是高级外包吗？派人驻场，定制开发，我们做软件外包的干了二十年了。

不是。FDE和外包的区别是物种级别的。

外包按需求文档交付，FDE按业务结果交付。外包的终点是验收单签字，FDE的终点是客户的工作方式被改变、业务指标被改善。一个交付的是代码，一个交付的是决策能力。

外包从需求出发，FDE从问题出发。外包是客户说什么做什么，FDE是先扎进现场观察，然后告诉客户"你以为的问题不是真正的问题"。这需要工程师有跟客户一把手对话的资格。

外包沉淀的是人天，FDE沉淀的是平台。外包项目结束，经验跟着人走；FDE项目结束，能力留在平台里，下一个项目直接复用。FDE模式能越跑越快、外包永远线性增长，根源在这里。

外包卖的是人力，FDE卖的是杠杆。Palantir被华尔街质疑了十几年"你到底是软件公司还是咨询公司"，但它的客户留存和扩展收入说明了一切：工程师嵌进客户的运营决策链之后，替换成本高到离谱。

判断一家公司是真FDE还是假FDE，标准很简单：项目结束三年后，你的现场经验是变成了平台能力，还是变成了前员工的简历亮点？

三、国内的钱，养不起这个模式

FDE是一个极重的模式。一个小队五六个人，在客户现场泡几周甚至几个月，交付一个只覆盖"一个流程、一个角色、一条规则"的应用，然后继续泡着，直到系统真正被用起来。

你算一笔账：一个能跟客户高管对话的Deployment Strategist，加两个能做数据建模和应用开发的高级工程师，再加上运维和交付支持，这个小队一个月的人力成本是多少？保守算，大几十万。

Palantir为什么撑得住？它的客单价是百万美元级起步，客户是国防部、空客、BP这个量级的组织，合同一签好几年，扩展收入源源不断。FDE的重投入，是被极高的客单价和极长的客户生命周期摊薄的。

国内甲方为软件付费的意愿，做过ToB的都懂。一个定制项目，预算批下来先砍一半，招标再砍一刀，最后还要求"上线即验收、验收即付款、付完款人撤走"。你跟客户说"我要在你这儿驻一个小队六个月，第一年只能交付三个场景，但我们按业务结果收费"，采购部门会觉得你疯了。结果就成了，国内甲方想用雇一个外包的钱，招聘一个CTO。

四、国内的人，也撑不起这个模式

FDE对人要求有多苛刻？

他要能扎进客户现场看懂业务，看懂的程度是"比客户自己更清楚他们的流程哪里是断的"；他要能做数据建模、写应用、接系统；他要能跟操作工聊，也能跟CIO聊；他要有判断力，敢对客户说"你要的这个不对"；他还要有产品sense，知道这次踩的坑哪个能沉淀成平台能力。

这是一个集咨询顾问、产品经理、全栈工程师、交付经理于一身的复合物种。Palantir为这种人开出的薪酬是对标顶级科技公司的，而且给的是"你在定义一个行业怎么运转"的成就感。

国内的问题是双重的。

这种人本来就极其稀缺。懂业务的不写代码，写代码的没到过客户现场，能写代码又懂业务的大多去做了自己的产品，还愿意驻场的所剩无几。

就算有，你也给不起钱。这个能力画像的人，在国内市场上的对标薪酬是大厂高P。而国内ToB项目的客单价和毛利，根本养不起用这种人去驻场。你最后能派去的，大概率是工作五年以内、技术不错但没见过真实业务场面的工程师。他不是FDE，他是驻场开发。

于是你就看到了国内"FDE部门"的典型结局：要么是招聘的人压根无法交付，要么就是招十几个不错的工程师，撒到各个客户现场，干的是定制开发加实施运维的活，按人天或者项目制收费，经验全部沉淀在个人脑子里，两年后骨干离职，经验清零。这不是FDE，这是用Palantir的包装纸，包了一个传统外包。

五、FDE不是一个人，是一种组织能力

最后这点，是对"招两个牛人先试试"这种想法说的。

回看前面那七条：小队作战、问题定义、快速接数、Ontology建模、几天交付、影子模式、平台飞轮。这里面没有任何一条是一个天才能独立完成的。
问题定义需要懂业务和懂技术的人互相校准；
快速接数需要平台本身有现成的连接器和安全体系；
几天交付需要底层已经有成熟的对象建模和应用生成能力，不然"五天从零到用例"就是"五天从零到demo"；
影子模式和评测需要一整套可观测性工具；
飞轮更需要公司层面有机制，把现场经验反哺给产品团队。而国内大部分公司，现场团队和产品团队是互相抱怨的两个部门。

Palantir的FDE之所以快，不是因为它的工程师是超人，是因为他们背后站着一个沉淀了二十年的平台。你看到的"五天交付"，是二十年平台能力的利息。

没有这个底座，你的"FDE"每次进现场都是从零开始手搓，规模越大亏得越多，最后要么放弃，要么降格成外包。而后者，是绝大多数玩家的真实归宿。

六、那到底还能不能做？

能，但要先回答三个问题，想不清楚就别挂牌子。

你的客户愿意为结果付费吗？如果答案是否，先做能标准化收费的产品，别碰FDE。或者极度挑剔地选客户，只服务那些客单价撑得起一个小队、且有长期扩展空间的头部组织，宁可少，不可滥。

你有没有平台可以沉淀？FDE模式的全部经济学都建立在飞轮上。如果你的现场经验无法回流成产品能力，那FDE对你就是纯成本中心。先做平台，哪怕很粗糙，再往里放人。

你养得起、留得住那种人吗？算清楚一个小队的真实成本，再算清楚要多少客单价才能打平。算不平，就别用"FDE"这个词自我感动。老老实实说自己在做"深度交付"，不丢人，骗人骗己才丢人。

冷水泼完了。

FDE本身没有错，它甚至是AI时代ToB交付最正确的方向之一。我和我的技术合伙人也接了几个FDE的活，所以我并否认这个模式。错的是把一个需要二十年平台沉淀、顶级人才密度、和百万美元客单价共同支撑的模式，当成一个"招几个人驻场"就能启动的部门。

Palantir的护城河从来不是"派工程师去客户现场"这个动作，而是这个动作背后那一整套别人抄不走的系统。

学它的形，三个月就能学会。学它的神，先问问自己的钱包、人才库和平台，答不答应。

[登录查看剩余 70% 内容](javascript:void (0);)