在人工智能领域，FDE这三个字母几乎无法回避。Forward Deployed Engineer，即前沿部署工程师。

相关数据确实令人印象深刻。根据领英年初发布的报告，这一职位从2023年到2025年间需求增长了42倍，而同期AI工程师的增幅仅为13倍；Indeed的统计则显示，其招聘量在一年内翻了七倍多。OpenAI与Anthropic近期几乎同步成立了面向企业的服务公司，OpenAI更是直接收购了一家英国AI咨询公司，将上百名资深FDE纳入麾下。国内市场也迅速跟进，腾讯在深圳发布了月薪40K至70K、实行15薪制的FDE岗位，上海ZF还专门组织了FDE人才培训班。

因此，网络上充斥着“转行FDE，年薪百万”的宣传。

我想在此提出一些冷静的看法。在美国，FDE是抢手的人才；但在中国，它很可能只是一个换上新名称的旧有陷阱。 本文不再赘述FDE的定义，而是从一个多年从事产品工作、且自身也负责招聘的老板视角，探讨两个更现实的问题：为什么国内的FDE大概率会沦为“高级外包”；以及产品经理、研发、项目经理、运营、售前这五类人，在转型FDE时各自会遇到什么障碍。

同一个职位，截然不同的境遇

FDE这一工作模式，源于Palantir为服务涉密ZF客户而被迫形成的体系。其核心假设是：工程师嵌入客户团队，协助客户构建自身能力，项目结束后客户能够独立运作。Palantir出售的是“能力转移”。

而国内甲方通常追求的是“交付物”。他们支付费用，获得系统，完成验收，项目结束，出现问题再寻求支持。

这背后是截然不同的组织逻辑。海外的FDE通常由业务最高负责人直接引入项目，处于会议桌的核心位置，与客户共同定义问题，考核标准是业务指标是否改善，报酬基于成果计算，项目规模会随之扩大。国内的FDE则往往由IT部门或采购部门根据合同聘用，坐在会议室的角落等待需求分配，考核标准是项目是否按期完成，报酬按人天计算。

如果将后者的特征串联起来：按人天收费、按需求实现、按期验收。这本质上就是外包，只不过外包的对象是一个更昂贵、更精通大模型的人。

因此，我的第一个判断是：FDE在国内是否会沦为外包，并不取决于技术能力有多强，而取决于你被置于何种权力结构之中。 进入一家真正致力于AI转型并愿意赋予你话语权的公司，你如同特种兵；进入一家只想“买个AI系统交差”的甲方，你只是一个高级实施人员。

先建立衡量标准：FDE的六项核心能力

要对比不同岗位，首先需要一个标准。我将FDE的能力拆解为六项。

动手编码：能够自行编写原型，并且要能部署到生产环境，而非仅仅制作一个演示后就撒手不管。方案架构：必须能真正对接客户的数据、遗留系统和权限体系。业务翻译：能将客户口中“我想用AI提升效率”的说法，转化为一个可执行、可验证的具体问题。推动协调：在客户的组织内部推动工作，但没有任何行政权力。客户沟通：能坐在会议桌前，承受业务负责人的质疑。结果闭环：对系统上线后有人实际使用负责，并将现场遇到的问题反馈回产品。

有一种说法是，FDE大约40%的时间用于编写代码，60%的时间面向客户。这个比例本身就说明问题：决定成败的关键在于那60%的部分。

在这六项中，我认为最难弥补、也最有价值的是两项：业务翻译和结果闭环。前者依赖于对行业的理解，后者依赖于心态和责任心，这两者都没有速成的方法。

五个岗位，逐一分析

用这个标准来衡量，我发现一个规律：真正决定你是否能转型成功的，往往不是你缺少哪项能力，而是你原有岗位培养出的惯性。 能力缺口可以弥补，但惯性若不改变，弥补了也无用。

售前和解决方案：距离最近，但最大的陷阱恰在终点。

售前人员的底子在五类人中与FDE最为接近。面向客户的能力满分，他们常驻客户现场；方案架构能力强，知道如何将产品嵌入客户的IT环境；编码能力中等，大多能自行搭建概念验证（POC）。

但售前人员有一项几乎空白的能力：结果闭环。售前的考核指标是签订合同，POC做得漂亮、合同签署后，就移交给实施团队，自己则去追逐下一个商机。FDE恰恰相反，签单只是起点，你需要对上线三个月后是否有人使用负责。

因此，售前的惯性是“签完单就走”。还有一个更隐蔽的问题：为了促成交易，售前习惯于过度承诺。到了FDE的位置，你承诺的每一句话都必须自己兑现，那时才会知道当初画的饼有多棘手。

要想转型，最好的练习方式是主动跟进一个项目，从POC一直跟到上线后三个月，亲眼看看自己的方案在真实业务中是如何“失效”的。站在老板的角度，售前转型FDE是最快的，但前提是考核方式必须改变，如果仍按签单额计算报酬，他们就永远是售前。

产品经理：基础属于第一梯队，但需戒除“等待排期”的习惯。

B端产品经理最宝贵的资产就是业务翻译能力，这恰好是FDE六项能力中最难弥补的部分。他们懂流程、懂权限、懂客户组织中谁说了算，这些都是产品经理日常在做的事情。

缺口也很明确：动手编码。但说实话，这个缺口在今天比以往任何时候都容易弥补。TRAE、Qoder、Cursor、Claude Code等AI编程工具，已经能让一个不常写代码的产品经理将原型做到可运行的程度。问题在于从“可运行”到“可上生产”，中间隔着数据权限、异常处理、日志、回滚等工程素养，这不是工具能直接给予的，需要通过在真实项目中一次次被现实“教育”来获得。

产品经理真正需要戒除的是两个惯性。一个是“写完PRD等排期”。FDE背后没有研发团队为你排期，你想清楚了就得自己动手。另一个更隐蔽：产品经理习惯做通用产品，一上来就想抽象、想复用、想平台化。FDE的顺序正好相反，先为一个客户把事情做成，再从其中进行抽象。顺序一旦颠倒，就会变成在客户现场画平台大饼，这是客户最反感的。

站在老板的角度，我对产品经理转型FDE最为看好。原因很简单：FDE的终极价值是将现场经验反哺产品，而产品经理天然就掌握着这条通道。Palantir那套Ontology本体模型，最早就是从现场项目中提炼出来的。一个能写代码的产品经理去做FDE，三年后回来做产品负责人，那是降维打击。

运营：最被低估的一类人，但硬技能需要大量补课。

很多人第一反应是运营与FDE不相关，我并不这么认为。

运营有一项能力是其他岗位都不及的：结果闭环。运营天生对数字负责，知道“系统上线”和“有人使用”之间隔着多远。推动协调能力也强，在业务一线将某个动作推行下去，是运营的看家本领。业务理解同样不差。

问题出在硬技能上。方案架构和编码，是运营离FDE最远的两项。运营的惯性是“只盯数据不碰系统”，习惯在现有系统上做运营动作，从不接触数据来源、接口调用、权限配置等。

我的建议是不要想着一步到位成为全栈工程师，可以先从扣子、Dify这类智能体编排平台入手，将一个真实的业务流程用Agent搭建并运行起来，再逐步深入到代码和系统集成中。老板这边也需要看清楚：一个懂业务、肯补技术的运营，往往比一个只会写代码、不擅长与人沟通的工程师，更接近“能交付结果”的FDE。

研发工程师：代码能力最强，却可能距离最远。

这个结论可能会让不少工程师感到不服。

研发人员的编码能力满分，架构能力也强，这两项是FDE的基础。但研发人员最缺乏的，恰好是最难弥补的两项：客户沟通和业务翻译。

研发的惯性是“关上门才能写出代码”。需求不清晰？那请你先写清楚再来找我。但FDE的工作，正是在需求不清晰的地方展开。客户自己也说不清想要什么，你需要陪他一起把问题找出来。再加上许多工程师有技术洁癖，看到客户十几年前的遗留系统、堆积在Excel里的业务数据，第一反应是崩溃，第二反应是“推倒重来”，而客户最不可能接受的就是推倒重来。

能够转型成功的研发，是那些喜欢看到自己代码被真实用户使用的人，比起技术的优雅，他们更享受“这东西真的解决了问题”的成就感。站在老板的角度，这类人最为稀缺，因为愿意走出去的研发本来就少。找到一个，就是宝贝。

项目经理：推动力满分，但也是最危险的转型路径。

项目经理的推动协调能力满分，客户沟通能力也强，他们天天在甲方和乙方之间周旋。

缺口是编码和方案架构，硬技能几乎需要从零开始。但这并非我将项目经理排在最后的主要原因。

真正的原因是：国内很多公司招聘的所谓“FDE”，本质上就是驻场项目经理。 这恰恰是FDE沦为外包的那条路。项目经理的惯性是“按计划交付，不问结果”。甘特图是他们的安全感，范围变更要走流程，按期验收就是胜利。但FDE经常需要做的，恰恰是推翻原计划，因为你在现场发现客户最初提出的需求根本不是真正的问题。

项目经理想要转型，第一件事是戒除“范围变更就走流程”的本能，学会对业务结果负责，而不是对计划负责。老板这边有一个很好用的自检方法：如果你招聘FDE，最终入职的全是项目经理类型的人，那说明你内心真正需要的是交付，而不是FDE。

一个反直觉的排序

将五类人放在一起，我的排序是：售前和产品经理在第一梯队，运营和研发在第二梯队，项目经理在第三梯队。

最反直觉的是研发。代码写得最好的人，反而没有进入第一梯队。

原因就在于AI本身。AI编程工具正在以可见的速度，将“写代码”这项缺口变得廉价。一个产品经理今天借助TRAE或Qoder能做出的东西，三年前需要配备一个小型研发团队。但面向客户的能力、对结果负责的责任心，没有任何工具能替代，只能靠你一次次亲自下场练习来获得。

所以我的结论是一句话：缺口容易弥补，惯性难以改变。

站在老板的角度，说几句不中听的话

首先，对想转型FDE的人说。

不要被百万年薪所迷惑。那是美国顶级选手、在尊重工程师的环境中获得的数字。在国内，你首先要问的不是“我能力够不够”，而是“这个平台是否会给FDE真正的话语权”。面试时要留个心眼：面试你的是业务负责人，还是IT部门？考核是按人天，还是按业务结果？进入项目后，你能否见到客户中真正拍板的人？这几个问题的答案，比招聘信息上写的薪资更能决定你三年后的样子。能力可以弥补，但一个将你当作高级外包使用的陷阱，你再强也无法跳出来。

其次，对想招聘FDE的老板说，也包括我自己。

想清楚你要的是FDE，还是一个更便宜的乙方。如果你内心是“我出需求、你来实现、出事你背”，那你需要的是实施工程师，不要用FDE的头衔和薪资去招聘，招来了也留不住。真正的FDE需要三样东西：定义问题的空间、按结果而非人天的考核，以及他从现场带回的反馈能真正进入你的产品路线图。

还有一笔账需要算清楚：国内客户的付费习惯是按人天。如果你不敢与客户谈按结果收费，FDE模式在财务上就无法成立，算到最后它只是一门毛利很薄的人力外包生意。FDE的问题，归根结底不是招聘的问题，而是商业模式的问题。

FDE这股风潮会越刮越大。但在风口上，有人能飞起来，有人只是被吹得晕头转向。

区别从来不在风，在于你站的位置。

本文来自微信公众号“人人都是产品经理”（ID：woshipm），作者：老曹，36氪经授权发布。