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

guozi

混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 这阵风会越刮越大。但风口上，有人飞起来，有人只是被吹得团团转。

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

本文由作者@老曹，授权发布于平台，未经许可禁止转载。

--------------------------------------------------
本文转载自：https://www.woshipm.com/pmd/6476320.html