在人工智能领域，“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）。
但售前几乎有一项能力是空白的：结果闭环。售前的KPI是签单，只要POC做得出色、合同签了，就移交给实施团队，自己转身去追逐下一个商机。FDE恰恰相反，签单只是开始，你要对上线三个月后是否有人使用负责。
因此，售前的惯性是“签完单就走”。还有一个更隐蔽的问题：为了促成交易，售前习惯做出过度承诺。到了FDE的位置，你承诺的每一句话都得自己兑现，这时才会发现当初画的饼有多烫手。
想转型，最好的练习方法是主动跟一个项目，从POC一直跟到上线后三个月，亲眼看看自己的方案在真实业务中是如何“崩溃”的。站在老板的角度，售前转FDE是最快的，但前提是必须改变考核方式，如果还按签单额给他算钱，他永远只是个售前。
产品经理：底子属于第一梯队，但要戒掉“等排期”的习惯。
B端产品经理最值钱的就是业务翻译能力，而这正好是FDE六项能力中最难弥补的那项。懂流程、懂权限、懂客户组织里谁说了算，这些都是产品经理每天都在做的事情。
缺口也很明显：动手编码。但说实话，这块缺口在今天比任何时候都好弥补。TRAE、Qoder、Cursor、Claude Code等AI编程工具，已经能让一个不常写代码的产品经理把原型做到可运行的程度。问题在于从“能运行”到“能上生产”，中间隔着数据权限、异常处理、日志、回滚等工程素养，这并非工具能直接给予的，需要靠在真实项目中一次次被现实教育。
产品经理真正需要戒掉的，是两个惯性。一个是“写完PRD等排期”。FDE身后没有研发团队给你排期，你想清楚了就得自己动手。另一个更隐蔽：产品经理习惯做通用产品，一上来就想抽象、想复用、想平台化。FDE的顺序正好相反，先为一个客户把事做成，再从里面抽象。顺序一颠倒，就会变成在客户现场画平台大饼，而客户最反感这个。
站在老板的角度，我对产品经理转FDE最为看好。原因很简单：FDE的终极价值是将现场经验反哺产品，而产品经理天然就掌握着这条通道。Palantir那套Ontology本体模型，最早就是从现场项目中提炼出来的。一个能写代码的产品经理去做FDE，三年后回来做产品负责人，那是降维打击。例如，在九游（jiuyou）官网-九游游戏平台-9 SPORTS这类需要深度理解用户和业务场景的平台上，这种经验反哺的价值尤为明显。
运营：最被低估的一类人，但硬技能需要补课最多。
很多人第一反应是运营跟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氪经授权发布。
