AI项目死在上线前，FDE却火了：这个岗位在中国会不会沦为“高级驻场”？

2026-08-07 · 约 14 分钟

一边是95%的企业级生成式AI试点没有产生可衡量的损益影响；另一边，海外FDE职位一年从643条增至5330条。真正稀缺的，也许从来不是更强的模型，而是能把模型按进业务现场、再把现场经验带回产品的人。

一家企业的AI项目，是怎么死掉的？

通常没有事故，也没有人拍桌子。

它往往死得很安静：第一次演示时，模型能读合同、写周报、回答制度问题，会议室里人人点头；试点上线后，业务人员发现它记不住上次为什么被打回，财务数据拿不到，审批权限过不了，偶尔答错还不知道该由谁负责。三个月后，群里的项目链接再也没人点开。汇报材料上，它仍然叫“阶段性成果”；在业务现场，它已经是一具没人愿意认领的尸体。

这不是某一家公司的新闻，而是许多企业AI项目共同的死法：技术做出来了，工作没有因此改变。

也正是在这条裂缝里，Forward Deployed Engineer——前线部署工程师，简称FDE——突然成了AI行业的热门角色。

先别被“95%”吓到：失败的不是模型，是价值链断了

2025年，MIT Project NANDA发布了一份初步研究报告。它梳理了300多个公开AI项目，结合企业访谈与管理者调查，给出了一个被广泛传播的数字：95%的受访组织没有从生成式AI投入中获得可衡量的回报。

这个数字很有冲击力，也最容易被误读。

它并不是说“95%的AI模型不能用”，也不是说“95%的项目技术失败”。报告真正指出的是：大量企业级、任务型生成式AI试点没有走到能够持续影响生产率或损益表的阶段。报告自己也提醒，这些比例主要来自访谈，成功定义因组织而异，更适合作为方向性信号，而不是精确到个位数的全球普查。MIT NANDA《The GenAI Divide》

换句话说，很多项目不是败在模型不会回答，而是败在五件更琐碎的事情上：它不记反馈、拿不到上下文、接不进旧系统、嵌不进真实流程，也没有一个人对业务结果负责。

麦肯锡2025年全球调查呈现了相似的落差：88%的受访组织已经在至少一个职能中使用AI，但被定义为“AI高绩效者”的组织只占约6%。这些少数赢家更常做的，不是多买几个模型，而是重构工作流、建立管理层责任、设置人工校验，并持续追踪业务指标。麦肯锡《The State of AI 2025》

这说明了一件不太性感、却很重要的事：AI真正昂贵的部分，往往发生在模型调用之后。

企业AI价值断层与FDE闭环

图注：企业AI的难点正在从“模型能不能做”转向“系统能不能在真实世界持续产生结果”。图中阈值属于方法建议，不应被理解为全行业承诺。

FDE是谁？就是PPT关掉以后还留在现场的人

FDE最早由Palantir系统化发展。Palantir对这个岗位的描述很直接：工程师要进入客户的现实，理解最棘手的问题，参与架构、数据、应用开发和部署，并对真实结果负责。Palantir FDE岗位说明

如果一定要用一句人话解释：

售前负责让客户相信“这件事能做”；FDE负责留下来，直到这件事真的在生产环境里发生。

他可能上午还在和业务负责人追问：“你说效率低，到底是谁每天多花了几个小时？”下午就要打开数据库、接API、补权限、写生产代码；晚上还得和安全、法务、运维一起决定，模型答错时由谁接管、数据留在哪里、系统怎么回滚。

因此，FDE不是更会说话的程序员，也不是更会写代码的顾问。这个岗位同时踩在三条线上：

第三条最重要。没有产品回流，FDE就只剩下一支昂贵的驻场队伍。

OpenAI目前对FDE的官方要求也印证了这一点：不仅要从原型做到稳定生产，还要用采用率、工作流影响和评测反馈衡量成功，并把有效做法固化为其他团队可复用的工具或组件。

FDE现场工程、结果验收与产品回流

图注：判断一支团队是不是FDE，不要只看它是否驻场，要看它是否同时完成现场工程、结果验收与产品回流。

为什么中国可能比硅谷更需要FDE

模型进入中国企业后，通常先撞上三堵墙。

第一堵是数据墙。

数据并不只在数据库里。它还散落在Excel、企业微信、老旧ERP、部门共享盘，以及某位干了十二年的老师傅脑子里。技术团队以为自己缺一个接口，真正缺的可能是“这家公司到底相信哪一份数”。

第二堵是流程墙。

制度文件写的是流程A，系统里跑的是流程B，真正遇到急单时，大家会在群里找副总批一句“先发货再补单”。一个Agent如果只读制度，会很合规，却可能根本干不了活；如果只模仿现实，又可能把灰色习惯自动化。

第三堵是责任墙。

IT部门希望尽快上线，业务部门不愿为错误背锅，安全部门追求零风险，采购部门要求范围和价格一次写死。模型能力越强，谁有权让它执行、谁负责按停它，反而越难回答。

这三堵墙都不是再加一轮微调就能解决的。它们需要有人站在业务、工程和组织之间，把模糊的口头需求翻译成系统，把系统翻译成现场能接受的工作方式。

腾讯研究院的《FDE模式行业观察与实践》把中美差异概括得很准确：美国企业的软件流程、数据治理和岗位分工相对成熟，AI更像给一台机器加装大脑；中国许多企业仍由对话、表格、习惯和关键人物驱动，FDE经常不是“给机器加大脑”，而是一边装大脑，一边补神经、画骨架、理清谁能动哪一根手指。

这也是中国市场真正的机会：我们缺的不是会做Demo的人，而是能陪着客户把一段真实工作重新做一遍的人。

岗位一年增至8.29倍，但中国还谈不上遍地开花

热度确实在上升。

腾讯研究院报告附件对海外招聘市场的统计显示，Indeed平台与FDE相关的搜索结果从2025年4月的643条增至2026年4月的5330条，同比增长729%，约为原来的8.29倍。报告同时强调，这是平台搜索结果数，用于观察市场趋势；不是去重后的实际净增岗位数。

国内则是另一幅图景。截至2026年7月，直接以“FDE”或“Forward Deployed Engineer”命名的活跃职位约30条以上。数字不算大，但大量相近工作被放在“AI解决方案架构师”“大模型落地工程师”“AI交付专家”等旧名称下。腾讯研究院对一线从业者的访谈也反复提到，国内真正的挑战并非有没有人做这份工作，而是现场经验能不能被“蒸馏”为下一个客户可用的能力。腾讯研究院FDE行业圆桌

所以，八倍增长说明市场正在给“部署能力”重新定价，却不能推出中国会立刻出现成千上万个高薪FDE岗位。更可能发生的，是原有的架构师、交付工程师、产品经理和行业专家被重新组合，强者获得更高溢价，弱者继续做换了英文名的实施。

真FDE和高级驻场之间，只隔着一道测试题

这道题很简单：

做完第一个客户以后，第二个同类客户是否更快、更便宜、更少依赖原班人马？

如果答案是否定的，那么无论工牌上写的是FDE、AI Architect还是首席落地官，本质上都还是项目制。

可以用四个指标拆穿“伪FDE”：

  1. 客户特定代码占比是否下降：每来一个客户就新增一套分支，说明债务在累积。
  2. 复用资产是否真的被使用：沉淀了多少文档不重要，下一支团队调用了多少连接器、模板和评测集才重要。
  3. 业务采用是否持续：上线不等于落地。30天、60天以后还有多少人每周使用，才接近真实答案。
  4. 下一次交付成本是否下降：同类项目的上线周期、人天和故障率应该逐步下降，否则规模越大，亏得越快。

Palantir提供了一个值得观察、但不能简单归因的样本：它在保留重度现场工程能力的同时，2025财年毛利率达到82%。这至少说明“深入客户现场”与软件经济性并非天然冲突；但前提是现场工作不断回流平台，而不是永久堆人。Palantir 2025年报

Palantir把这套机制形容为软件组织里的“人类反向传播”：前线团队靠近问题，核心工程团队吸收反馈，再把它变成产品能力。Palantir架构中心

这才是FDE真正的商业秘密：不是把最聪明的人永远留在客户现场，而是让组织以后不必为同一个问题再交一次学费。

在中国做FDE，一套比较老实的打法

与其先成立一个声势浩大的FDE部门，不如先跑通一个四到六周的小闭环。

第一步：只选一个有人负责的痛点

不要从“建设企业级AI平台”开始。先找一个业务负责人愿意签字、愿意给真实数据、愿意每周参加复盘的问题。

“提高运营效率”不是痛点；“排产冲突导致每周平均停机18小时”才是。

第二步：写代码之前，先把“什么叫成功”钉死

只保留三到五个指标，并采集上线前基线。它们可以是任务耗时、错误率、转化率、外包成本、准时交付率或人工确认率。

没有基线，项目成功时大家会抢功；失败时，大家会争论“是不是模型已经比以前好了”。

第三步：跟着真实用户过一天

问卷会告诉你制度怎么写，影子工作才能告诉你事情怎么做。观察用户打开哪些表、等谁回复、在哪一步复制粘贴、遇到什么情况会绕过系统。

很多需求不是在访谈里“问”出来的，而是在等待、返工和抱怨里被看见的。

第四步：用真实数据做最小可行部署

MVD（Minimum Viable Deployment，最小可行部署）不是更小的Demo，而是更窄的生产闭环：范围小、时间固定、数据真实、业务真的用，并且知道失败时如何退出。

第一版不必自动完成所有步骤。高风险环节先保留人工确认，远比为了“全自动”把项目拖死更有价值。

第五步：项目必须毕业，也必须允许停

在启动时就写明毕业条件：什么时候转为客户自助、什么时候进入标准产品、什么时候由伙伴接手；同时写明停止条件：数据拿不到、业务负责人缺席、连续两轮没有可验证改进，就暂停，而不是靠加人续命。

最后做一次残酷的复盘：哪些能力属于这个客户，哪些可以进入公共连接器、行业模板、评测集和交付手册？没有产品回流的项目，不算完整交付。

从项目选择到验收交付

图注：先验证痛点、经济性和可行性，再进入最小可行部署。图中数字为建议基准，应按行业风险和客户基线调整。

谁适合做FDE？不是“六边形战士”，是有三份履历的人

招聘启事常把FDE写成一个什么都会的人：懂模型、会全栈、能咨询、会销售、能出差，还要有行业人脉。这种写法最后往往只能招到一个擅长面试的人。

真正值得看的，是候选人有没有三份履历。

第一份是工程履历：他是否真的把系统送进过生产，遇到过权限、延迟、脏数据、回滚和夜间故障。

第二份是业务履历：他能不能把“效率提升”追问成一个有基线、有公式、有责任人的指标。

第三份是组织履历：当业务、IT、安全和采购各说各话时，他有没有推动过一个艰难决定，而不只是把问题转成工单。

纯编码能力不会消失，但AI会让“写出第一版”的成本越来越低。真正变贵的，是判断什么值得做、什么不该自动化、什么必须由人负责，以及怎样把一次交付沉淀成组织资产。

结论：FDE在中国有前途，但未必永远叫FDE

短期看，FDE类能力会继续升温。原因不是硅谷又发明了一个缩写，而是越来越多中国企业已经过了“要不要试AI”的阶段，开始追问：“它能不能进生产？出了错谁负责？到底替我省了多少钱？”

中期看，岗位会明显分层。强FDE走向行业解决方案、产品负责人或客户成功核心岗位；只会部署、培训和响应工单的“弱FDE”，会被平台工具和AI Agent不断压缩。

长期看，真正有利润的不会是派出最多工程师的公司，而是能做到三件事的组织：原厂跑通0到1，伙伴复制1到N，客户最终能够自助。FDE应该是一副帮助产品站起来的脚手架，而不是一座永远拆不掉的工棚。

所以，FDE在中国当然有市场。但它的前途，不在于明年能印出多少张新工牌，而在于一个更朴素的数字：

同一个坑，第二次还要不要再派一群人跳进去。

企业AI走向规模化的关键

图注：规模化的终点不是永久驻场，而是数据治理、评测体系、低门槛使用和可复制资产共同形成价值闭环。

延伸观看