FDE在硅谷是香饽饽，在中国可能是个坑？

混AI 圈，很难躲开FDE 这三个字母。Forward Deployed Engineer，前沿部署工程师。

数据确实唬人。领英今年初的报告说，这个岗位从 2023 到 2025 年涨了 42 倍，同期 AI 工程师只涨了 13 倍；Indeed 的口径是一年翻了七倍多。OpenAI 和 Anthropic 前阵子几乎同时成立企业服务公司，OpenAI 一出手就收购了一家英国 AI 咨询公司，把上百名资深 FDE 直接收编。国内也跟上了，腾讯在深圳挂出 40 到70K、15 薪的 FDE 岗，上海ZF还专门办了 FDE 人才培训班。

于是"转 FDE，年薪百万"的帖子满天飞。

我想泼盆冷水。在美国，FDE 是香饽饽；在中国，它很可能是一个换了新名字的老坑。 这篇文章不再科普 FDE 是什么，我想站在一个做了很多年产品、自己也要招人的老板角度，聊两件更扎心的事：国内的 FDE 凭什么大概率被做成"高级外包"；以及产品经理、研发、项目经理、运营、售前这五类人，转 FDE 分别会卡在哪。

01同一个名字，两种活法

FDE 这套打法，是 Palantir 当年为了伺候涉密ZF客户逼出来的。它有一个灵魂假设：工程师嵌进客户团队，帮客户把能力建起来，项目结束后客户能自己跑。Palantir 卖的是"能力转移"。

国内甲方要的是什么？是交付物。付钱，给我系统，验收，结项，出了问题再来找你。

这背后是一整套组织逻辑。海外的 FDE 通常是被业务一把手亲自拉进项目的，坐在会议桌中间，和客户一起定义问题，考核看业务指标变没变，钱按成果算，越做合同越大。国内的 FDE 往往是 IT 部门或采购按合同招进来的，坐在会议室角落等需求，考核看有没有按期结项，钱按人天算。

你把右边这一串特征连起来读一遍：按人天收费、按需求实现、按期验收。这不就是外包吗？只不过外包出去的，是一个更贵、更懂大模型的人。

所以我的第一个判断是：FDE 在国内会不会沦为外包，不取决于你技术多强，取决于你被放进了一个什么样的权力结构。 进了一家真想做 AI 转型、愿意给你话语权的公司，你是特种兵；进了一家只想"买个 AI 系统交差"的甲方，你就是个高级实施。

02先把尺子立起来：FDE 的六块拼图

要对比岗位，先得有把尺子。我把 FDE 的能力拆成六块。

动手编码，原型自己写，而且要写到能上生产，不是做个 demo 拍拍屁股走人。方案架构，客户的数据、老系统、权限体系，你得真能接起来。业务翻译，客户嘴里说"我想用 AI 提升效率"，你得把它翻译成一个能做、能验证的具体问题。推动协调，在别人的组织里把事推下去，你没有任何行政权力。客户沟通，坐得住会议桌，扛得住业务老大的质疑。结果闭环，对系统上线后真有人用负责，再把现场踩的坑反哺回产品。

有个说法是 FDE 的时间大约四成写代码、六成面向客户。这个比例本身就说明问题：决定成败的，是后面那六成。

六块里，我认为最难补、也最值钱的是两块：业务翻译和结果闭环。前者靠对行业的理解，后者靠心态和担当，这两样都没有速成班。

03五个岗位，一个一个拆

拿着这把尺子量下去，我发现一个规律：真正决定你能不能转过去的，往往不是你缺哪块能力，而是你原来岗位养出来的那个惯性。 能力缺口可以补，惯性不改，补了也白补。

售前和解决方案：离得最近，但最大的坑恰好在终点线上。

售前的底子在五类人里最接近 FDE。面客是满分，天天在客户现场；方案架构很强，知道怎么把产品塞进客户的 IT 环境；编码中等，大多能自己搭个 POC。

但售前有一块几乎是空的：结果闭环。售前的 KPI 是签单，POC 做漂亮了、合同签了，就交给实施团队，人转身去追下一个商机。FDE 恰恰相反，签单只是开始，你要对上线三个月后有没有人用负责。

所以售前的惯性是"签完单就撤"。还有一个更隐蔽的毛病：为了成交，售前习惯过度承诺。到了 FDE 的位置，你承诺的每一句话都得自己兑现，这时候就知道当初画的饼有多烫手了。

想转，最好的练法是主动跟一个项目，从 POC 一路跟到上线后三个月，亲眼看看自己的方案在真实业务里是怎么"坏掉"的。站在老板角度，售前转 FDE 是最快的，但前提是考核得改，你还按签单额给他算钱，他就永远是个售前。

产品经理：底子第一梯队，但要戒掉"等排期"的瘾。

B 端产品经理最值钱的就是业务翻译，这正好是 FDE 六块拼图里最难补的那块。懂流程、懂权限、懂客户组织里谁说了算，这些都是 PM 天天在干的事。

缺口也很明确：动手编码。但说句实在话，这块缺口在今天比任何时候都好补。TRAE、Qoder、Cursor、Claude Code 这些 AI 编程工具，已经能让一个不怎么写代码的产品经理把原型做到能跑。问题在于从"能跑"到"能上生产"，中间隔着数据权限、异常处理、日志、回滚这些工程素养，这不是工具能直接给你的，得靠在真实项目里一次次被现实教育。

产品经理真正要戒的，是两个惯性。一个是"写完 PRD 等排期"。FDE 身后没有研发团队给你排期，你想清楚了就得自己动手。另一个更隐蔽：PM 习惯做通用产品，一上来就想抽象、想复用、想平台化。FDE 的顺序正好反过来，先为一个客户把事做成，再从里面抽象。顺序一反，就会变成在客户现场画平台大饼，客户最烦这个。

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

运营：最被低估的一类人，但硬技能补课最多。

很多人第一反应是运营跟 FDE 不沾边，我不这么看。

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

问题出在硬技能上。方案架构和编码，是运营离 FDE 最远的两块。运营的惯性是"只盯数据不碰系统"，习惯在既有系统上做运营动作，从来不去碰数据从哪来、接口怎么调、权限怎么配。

我的建议是别想着一步变成全栈工程师，可以先从扣子、Dify 这类智能体编排平台切进去，把一个真实的业务流程用 Agent 搭起来跑通，再慢慢往代码和系统集成里扎。老板这边也要看清楚：一个懂业务、肯补技术的运营，往往比一个只会写代码、不会跟人说话的工程师，更接近"能交付结果"的 FDE。

研发工程师：代码最硬，却可能离得最远。

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

研发的编码是满分，架构也强，这两块是 FDE 的地基。但研发最缺的，恰好是最难补的那两块：客户沟通和业务翻译。

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

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

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

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

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

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

项目经理想转，第一件事是戒掉"范围变更就走流程"的本能，学会对业务结果而不是对计划负责。老板这边有个很好用的自检：如果你招 FDE，最后面进来的人全是项目经理画像，那说明你心里要的其实是交付，不是 FDE。

04一个反直觉的排序

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

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

原因就在 AI 本身。AI 编程工具正在以肉眼可见的速度，把"写代码"这块缺口变便宜。一个产品经理今天借助 TRAE 或 Qoder 能做出来的东西，三年前得配一个小研发团队。但面客的本事、对结果负责的担当，没有任何工具能替你补，只能靠你自己一次次下场练出来。

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

05站在老板这边，说几句不好听的

先对想转 FDE 的人说。

别被百万年薪晃了眼。那是美国顶级选手、在尊重工程师的土壤里拿到的数字。在国内，你第一要问的不是"我能力够不够"，而是"这个平台给不给 FDE 真正的话语权"。面试的时候留个心眼：面你的是业务负责人，还是 IT 部门？考核是按人天，还是按业务结果？进项目之后，你能不能见到客户真正拍板的那个人？这几个问题的答案，比 JD 上写的薪资更能决定你三年后是什么样子。能力可以补，但一个把你当高级外包用的坑，你再强也跳不出来。

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

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

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

FDE 这阵风会越刮越大。但风口上，有人飞起来，有人只是被吹得团团转。

区别从来不在风，在你站的地方。