爆火的FDE，跟驻场工程师有啥区别？

“FDE火了，但同一个名字下面，混着两种完全不同的东西。

2026年，一个英文缩写在中国企业AI圈突然火了。

脉脉数据显示，2026年上半年FDE相关职位发布量同比飙升21倍，在发布FDE岗位的公司中，37.3%是AI原生企业。猎聘大数据研究院发布的《2026 FDE人才供需趋势洞察报告》显示，近一年FDE相关职位平均年薪达到40.8万元，薪资中位数36.6万元，6月招聘需求环比增长237.21%。字节跳动的“豆包AI大模型FDE”开出月薪3.5万至7万元、全年15薪的待遇，蚂蚁数科的B端FDE月薪4万到6万元。工信部发文提出“鼓励服务商搭建前线部署工程师（FDE）团队，扎根用户现场，保障场景落地”。

火到这种程度，争议也跟着来了。

“FDE在中国，就是驻场牛马的新名词。”有人在社交平台上调侃，说实施工程师换个头衔，人天单价就想从1500涨到15000。阿里云智能集团副总裁霍嘉在云栖大会上表示过：“不想谈FDE了，现在说什么都有可能被挑刺儿。”

那么，FDE到底是什么？它跟中国市场上早已存在的售前解决方案顾问、驻场工程师、实施顾问，究竟有没有本质区别？还是只是把原来那群人换了个英文名重新包装？

要回答这个问题，得从FDE的起源讲起。

FDE的全称是Forward Deployed Engineer，译作“前线部署工程师”。“Forward Deployed”本来是军事用语，指把部队顶到最前线，而不是缩在后方指挥部。

Palantir公司成立于2003年，最初的客户是美国情报机构。这类客户有一个特殊的问题：需求本身就是机密的，业务逻辑极其复杂，传统的“产品经理收集需求→工程师开发→客户验收”这条路完全走不通。Palantir的应对方式是：把工程师直接派到客户现场，嵌入客户的团队里，从内部去理解问题、发现需求、构建方案、端到端交付。

Palantir Foundry工作区截图

这套模式让Palantir内部诞生了一个独特的角色分工。公司管FDE叫“Delta”，正式职位名称是Forward Deployed Software Engineer（FDSE），与负责核心平台开发的“Dev”形成互补。对这两个角色的区别，有一个被反复引用的概括：Dev是“一种能力，服务多个客户”；Delta是“一个客户，调用多种能力”。约2016年以前，Palantir的FDE人数比普通软件工程师还多。按照软件公司的标准，这种比例是非常罕见的，它表明了嵌入式模式从一开始就是其业务的核心。

Palantir把这套方法形容为软件研发中的“人类反向传播”：工程师靠近客户正在处理的问题，再将现场发现带回核心研发团队。正是20年的FDE驻场，将国防、金融等行业逻辑沉淀为可复用模块，使Palantir在2023年实现盈利，完成从项目制向产品化的跃迁。

近两年，随着Palantir估值上升，FDE从硅谷传到国内，迅速成为AI落地领域最热的岗位概念。全球招聘平台Indeed数据显示，美国FDE在招岗位数从2025年4月的643个增至2026年4月的5330个，同比增长729%，远超AI工程师整体约45%的增速。OpenAI、Anthropic、Stripe、Google Cloud都在招聘这一类工程师。

FDE和驻场工程师的区别，Palantir自己总结过三个动词：Builds、Embeds、Owns。这三个维度构成了判断真假FDE的核心标尺。

Builds——能自己动手写生产代码。咨询顾问的交付物是文档：需求规格说明书、流程图、PPT。FDE的交付物是可运行的系统。他不是把需求写下来交给别人实现，而是自己直接把它变成本体定义、数据管道和可执行的行动。中间没有文档传递，没有二次理解，没有“我以为你说的是这个意思”。

Embeds——驻扎在现场。咨询顾问通常阶段性介入，做完调研走人，写完方案走人。FDE每周四到五天嵌入客户日常工作，坐在调度员旁边看他怎么做决策，在车间看产线怎么跑。只有在现场，才能捕捉那些说不出来但极其重要的内隐知识。驻场交付工程师只负责落地执行，客户提什么需求就做什么定制，遇到问题临时改代码和调环境，只求当下交付过关。FDE则要在客户现场写代码，亲手把系统交付上线。

Owns——对生产结果负责，而不是对交付物负责。这是最核心的差异。驻场工程师通常对“约定的范围内上线和运维”负责，FDE还要对系统在实际业务中产生的结果负责，并且要把现场发现带回产品团队。

三个动词，拿掉任何一个，这个岗位就降级成了别的东西。拿掉Builds，它变成售前顾问；拿掉Embeds，它变成远程技术支持；拿掉Owns，它变成外包。

但最能区分真假FDE的，是它跟实施顾问的差异。SAP的实施顾问配置SAP模块，Salesforce的实施顾问配置Salesforce流程——范畴框架是预定义的，实施顾问在框架内做参数调整。FDE做的不是配置已有框架，而是从头构建范畴框架本身。Palantir的本体没有预定义的实体类型，没有现成的“供应链模板”等你填参数。FDE要走进业务场景，判断“这个世界里什么东西是重要的”，然后实现出来。

如果说FDE是Palantir的“手”，那么本体论就是Palantir的“大脑”。

Palantir Ontology是位于Palantir架构核心的运营系统与组织运营层，它把企业数字资产连接成现实业务对象和关系，并把判断逻辑、受控Action与安全规则放进同一个可运行的决策世界。这个系统包含两个不可拆开的部分：Ontology既描述“世界现在是什么样”，也定义“谁能在什么条件下把它变成什么样”。

从技术结构看，Ontology的核心元素包括Object（对象）、Property（属性）、Link（链接）、Function（函数）、Action（动作）和Security（安全）。它不存业务数据本身，但定义了业务世界里有哪些实体、这些实体长什么样、彼此怎么连、能对它们做什么。

这两件事是一体的。本体论的构建，必须由FDE在现场完成。原因很简单：企业里真实存在的东西，人看得见，软件看不见。同一家客户，在CRM叫“某某有限公司”，在ERP叫“某某股份”，在仓库系统叫“某某集团”。系统们各叫各的，一到汇总就露馅。

腾讯云开发者社区文章《Palantir Study 05｜Ontology是什么：既描述世界，也改变世界》中提到，Palantir公开讨论过一个典型场景：某客户建了全量数据模型，把Supplier、Material、Plant和Customer Order都连成了一张图，看起来该有的都有了。但计划员打开一个缺料事件时，仍然无法直接回答：这批缺料影响哪张客户订单，谁能批准调拨，批准后怎样进入执行。数据能够被找到，不等于决定能够被执行。问题出在业务认知到系统实现之间的翻译损耗。FDE存在的全部理由就是填这条缝。

而这件事必须由FDE在现场完成。业务决策者的知识是内隐的。你问一个资深调度员“你做调度时需要看什么”，他大概率说不清楚。但你坐在他旁边看他干一天活，会发现他眼睛扫的那几个指标、脑子里默算的那几个关系，恰好就是本体应该建模的核心范畴。这些判断藏在日常操作的肌肉记忆里，不是开几次需求调研会能挖出来的。

OpenAI FDE负责人Colin Jarvis对这个角色的工作有一个很直白的概括：FDE的工作是“eat pain and excrete product”——消化痛苦，产出产品。团队的北极星指标是：“You must leave with product”——必须带着产品离开。

FDE传入中国后，迅速出现了分化。同一个名字下面，混着两种完全不同的东西。一半是产品化前线工程，一半是旧驻场模式换皮。

先看美国那边跑通的案例。Palantir的General Mills供应链项目，这家食品企业在北美连接着4000家供应商和200多座工厂，每年处理约120万份订单。FDE团队接入200张主数据和运营数据表，建立供应链决策系统ELF。它每天检查约3000份订单，提供约400条调整建议，其中超过70%被工作人员接受。General Mills称，这套系统每天节省约4万美元，年省约1400万美元。系统必须同时理解订单、运力、产能、成本和业务约束，还要知道什么建议可以执行，什么决定必须交给人。顾问可以提出优化方向，传统实施工程师可以把数据库接起来，FDE则要把模糊问题变成生产系统，再用采用率和业务指标判断系统是否有效。

国内一些FDE却在做另一件事。

据相关媒体报道，FDE依然在客户现场反复修改细节、配合验收。驻场、差旅费用全都要自己承担；客户一句“这里再改一下”“那里效果还没达到预期”，验收就得继续往后推。每天都在投入成本。

有从业者描述了自己的真实工作画面：面试时聊的是Agent架构和Prompt工程，但到了客户现场，一家制造业工厂，真实的工作是钻进车间，在轰鸣的机器声里记录每台设备的“外号”，并亲手把二维码贴到设备上做定位。

这些案例的共同问题是：FDE被当成了“高级售前”或“AI项目经理”用，没有给予足够的工程权限和业务决策参与权。FDE沦为PPT制作机器，失去了“在前线写代码”的核心价值。

更深层的问题是商业模式。美国的企业软件和订阅制更成熟，FDE的成本可以摊进经常性收入里。但国内很多项目按人天、按驻场时长来结算，这样的模式下FDE很容易被做成高级实施甚至外包。驻场是一种工作安排，外包是一种资源组织关系，FDE是一种面向业务结果的交付模式——三者本质不同，但在国内的项目制环境下，很容易被混为一谈。

不过，国内头部公司已经在尝试走出差异化路径。

明略科技2026年中期业绩公告显示，公司上半年约30%的交付人员转型为FDE，在172个报告交付场景中建立AI提效评估标准，整体效率提升56.1%，沉淀359个可复用Skill，新人培养周期缩短一半。公司同时披露，将推动普联软件团队转型成为面向央国企的FDE。

明略科技CEO吴明辉指出，大数据时代的FDE做的是数据治理，帮客户构建数据中台；AI时代的FDE要做的事情更多，协助客户的业务人员构建自己的Agent，把Agent和中台连起来，不仅share context，还要share skills、share memory。

软通动力以“FDE前线交付＋AI平台支撑”构建“咨询定义场景—FDE落地实施—场景资产沉淀—规模化复用”闭环能力，在金融、制造、航空、钢铁、农牧、交通物流、零售等十余个行业打造标杆项目。公司已构建超500人的软通FDE行业解决方案团队。

致远互联设立AI-FDE共创服务模式，通过“AI技术+行业业务+价值交付”三位一体团队深入客户现场，与客户联合完成需求共创、方案设计、场景验证与持续运营。

这些尝试的共同特征是：不再把FDE当成“驻场人力”，而是试图把现场经验沉淀为可复用的产品能力。

从目前的市场数据看，答案是“部分是，部分不是”。

猎聘大数据研究院的报告显示，近一年FDE相关职位平均年薪达到40.8万元，薪资中位数36.6万元，50万元以上职位占比28.25%，远高于IT互联网技术类职位的16.11%。但薪资中位数约36.6万元，50万元以上岗位占比不到三成。换句话说，“年薪百万”是头部岗位、头部公司、头部城市的特例，并非行业平均水准。在上海某AI公司工作的90后从业者表示，职级较低的FDE月薪在2万元至3万元，高职级的以年包为主，多在40万元以上。

从城市分布看，FDE岗位高度集中。近一年新发职位中，上海占23.33%，北京占22.50%，深圳占14.31%，杭州排在第四位，占8.19%，这四座城市合计占了68.33%。

从转型来源看，目前国内从事FDE的主力，确实是原来做软件工程和解决方案的那群人。

但真正稀缺的不是“会写代码的人”，也不是“懂业务的人”，而是同时具备两种能力的人。一位从2023年就开始做企业AI落地的AI产品团队负责人告诉行业观察者：自己整个团队，真正称得上优秀FDE的，其实也就2、3个人。不是刚入局的人在抱怨人才难招，而是一个已经做了几年企业AI落地、团队规模不小、产品跑到细分赛道头部的人，在承认这个岗位真的很难。

驻场工程师要转型FDE，需要补齐的不只是编程能力。Palantir的FDE不是单兵作战，而是采用Echo-Delta双人协作模式——Delta是写代码的工程师，Echo是来自客户所在行业的领域专家，能用“现场的语言”把一线需求抠出来。这意味着转型FDE的人，要么自己同时具备两种能力，要么学会在团队协作中承担其中一种角色的职责。

要判断FDE是持续成长为关键力量，还是最终“一地鸡毛”，有一个核心标尺：看它是否把经验沉淀为可复用的产品能力。

Palantir的做法是制度化的。他们建立了“碎石路到高速公路”的机制——FDE在单个客户现场铺出“碎石路”（定制方案），产品团队再把它泛化成服务更多客户的“高速公路”（标准功能），且原FDE全程参与泛化讨论。这套机制确保了FDE的现场经验不会停留在某个客户的定制项目里，而是变成整个平台的能力增量。

如果一家公司的FDE只在客户处写一次性代码，下一次交付仍从头开始，这份工作依旧是定制开发，只是换了一个更昂贵的名字。

目前中国市场上，两种模式并存。明略科技在尝试改造原有交付队伍，把经验写成Skill和Agent，让下一次交付少依赖人。但更多的公司还在把FDE当“赠品”用——丢给客户看一眼，告诉他们“我们有这个能力”，好让公司顺利签单。

行业标准也尚未定型。博彦科技在互动平台上的表态代表了一种审慎的判断：FDE是国内外AI行业应用产业重点关注的落地模式之一，但仍处于行业探索和实践阶段。

回到开头的争议：FDE到底是新瓶装旧酒，还是真正的职业重构？

FDE不是新瓶装旧酒，但它很容易被做成新瓶装旧酒。

区别不在于岗位名称，而在于三件事：能不能在客户现场写生产级代码，能不能从项目中提炼出可复用的本体能力，能不能对业务结果而不只是交付物负责。做到这三件事的，是真正的FDE。做不到的，就是把驻场工程师换了个英文名。

Palantir的FDE用了近二十年时间，把美国国防部和中情局最复杂的数据场景，变成了一套可复用的产品体系。中国企业的AI落地才刚刚开始。FDE能不能在中国跑通，不取决于这个岗位名称能流行多久，而取决于中国企业AI的交付模式，能不能从“卖人天”真正转向“沉淀产品能力”。

如果做不到，FDE最终会像很多曾经火热的概念一样，留下一地鸡毛。如果做到了，它可能成为中国企业AI从“项目制”走向“产品化”的关键转折点。

这个问题的答案，不在FDE本身，而在用FDE的人手里。

文：海岛数据猿
责编：凝视深空数据猿