百万美元年薪，超越同级别 AI 科学家，FDE 究竟是什么？
百万美元年薪，超越同级别 AI 科学家，FDE 究竟是什么？
2026 年，一个叫 FDE 的岗位，Principal 级别总包突破了 100 万美元。
同一个级别，比 AI 科学家高出 10% 到 25%。
美国 Indeed 平台上，FDE 岗位从 2025 年 4 月的 643 个增加到 2026 年 4 月的 5,330 个，一年涨了 729%。猎头公司 Adecco 的大盘数据也差不多：需求增速每年约 800%，—同时，人才供给增速只有 50%。
OpenAI 和 Anthropic 在 2026 年 5 月同一天分别宣布成立企业 AI 服务公司——OpenAI 投了 40 亿美元成立 The Deployment Company（部署公司；这是在致敬马斯克的‘挖洞公司‘吗），同时收购了一家有约 150 名 FDE 的英国公司 Tomoro；Anthropic 和 Blackstone、Goldman Sachs 合资组建 AI 服务公司。
Google Cloud 把 FDE 面试流程压缩到了 2 天 2 轮来抢人。—按我之前的了解，Google 的面试流程通常是按周计算。
Perspective AI 调查了 1,200 名 FDE，78% 的受访者说团队规模将在 2027 年增长 2 倍或以上。
以下是各家公司的 FDE 总包数据（2026 年，单位美元）：
| 级别 | OpenAI / Anthropic | Scale AI、Cohere 等 | Palantir | Deloitte、JPMorgan 等 |
|---|---|---|---|---|
| 中级 | 38.5万 – 66.5万 | 25万 – 45万 | ~21.5万 中位 | 19万 – 26.5万 |
| Staff | 61万 – 75万 | 40万 – 60万 | 30万 – 45万 | 26.5万 – 42万 |
| Principal | 100万 – 128万 | 60万 – 90万 | 50万 – 70万 | 35万 – 50万 |
股权占总薪酬的 60% 到 70%。Anthropic L4 FDE 每年约 44.5 万美元股权加上 27.5 万美元 base。
为什么一个岗位突然值这么多钱？它到底做什么？
国内的岗位也正在起步。Boss 直聘上 FDE 薪资参差不齐，既有 200 块钱一天的，也有 150k 一个月的。
北京
上海
FDE 到底是做什么的
FDE 的全称是 Forward Deployed Engineer，前线部署工程师。
这个名字借自美军术语”Forward Deployed Forces”——把力量投送到离问题最近的地方。Palantir 在 2000 年代早期把这个概念引入了软件行业：派工程师离开总部，长期驻场到客户现场，和客户一起工作。
Palantir 第二号工程师、后来出任 OpenAI 首席研究官的 Bob McGrew 给过一个定义：
“A forward deployed engineer is someone, typically technical and an engineer, who sits at the customer site and fills the gap between what the product does and what the customer needs.” 一个技术背景的人，坐在客户现场，填补”产品能做什么”和”客户需要什么”之间的空缺。
Palantir CTO Shyam Sankar 总结为：
“Software that works, not software that ought to work.” 交付真正起作用（而不是”理论上应该行”）的软件。
Perspective AI 对 1,500 名 FDE 的调查显示，时间分配中位值是：
- 47% 客户面对——访谈、现场部署、设计评审
- 31% 写代码和交付
- 22% 内部协调和研究整合
写代码只占不到三分之一。如果 FDE 整天在写代码，通常意味着某个环节出了问题。
技能要求可以概括为三件事：
Full-stack 工程。 Python/TypeScript、React、API 设计、数据库、Docker/K8s。—和 SDE 重叠。
AI/Agent 实操。 LLM API、RAG、Agent 框架（LangGraph、OpenAI Agents SDK 等）。用 AI 辅助开发工具（Claude Code、Cursor）是基本要求（表现就是，它们都在 JD 里。）。
客户沟通和业务理解。 业务理解、架构评审、高管汇报、在需求还模糊的时候就已经在行动了。
这三件事单独都不新鲜，但捏在一个人身上就马上稀缺了。（能者多劳。技术越厉害人越忙啊。）
我也想转型 FDE 去赚大钱
你可能已经感觉到了，FDE 做的事情，自己至少有一部分不陌生，甚至还挺熟。
传统软件工程里，从业务需求到代码实现，翻译工作分散在几个角色之间：PM 写 PRD、BA 梳理流程、SA 做技术方案、SDE 写代码。每个角色接收的输入都比较确定，给出的输出也比较明确。这条链能工作，前提是每一段的边界清晰。
但 LLM 让自动化边界突然扩大，软件开发迭代速度加快，企业对于从需求到落地之间的时间要求也变高了。之前虽然每个角色都能完成自己那一段，但没人能端到端地交付一个系统。——每个角色都在等上一段给更明确的输入。
然后 FDE 就火了。至少从工作职责上，他把 PM 的需求理解、BA 的流程梳理、SA 的技术判断、SDE 的实现能力，都捏合到一个人身上。哪怕每个环节一个人，也省了 3 个人的钱。
所以，不同背景的人转向 FDE，就得把剩下的几环补上。
如果你是产品经理
你已经会需求理解和业务流程梳理了。
还需要补的是：
- LLM 的能力边界——哪些需求适合用 agent，哪些用规则、SQL、普通 workflow 就够了。也就是，要知道什么时候应该用/不用 AI。
- 概率性系统的验收标准——传统功能的验收条件通常是明确的（“点击按钮后 200ms 内显示结果”），agent 的输出不固定，验收就要更关注，万一错误的代价是什么，能不能撤回。
- 原型验证的节奏感——FDE 做项目不是”需求→开发→测试→上线”，是 48 小时冲刺型：进场前两天跑通一个能看的东西→给业务员看→收集反馈→第二版。第一个版本不求稳，求快。
如果你是 AI 科学家 / ML 工程师
你已经会模型选型、训练、评估了。
还需要补的是：
- 客户现场工作——离开笔记本屏幕，坐在业务员旁边看他们实际操作。注意三个东西：决策点（在哪一步会停下来想）、变通点（在哪一步不按文档走）、断点（在哪一步要把结果交给另一个人）。
- 风险设计——哪些动作只读、哪些可写、哪些需要 approval、哪些不能自动化。可逆性是划线的第一原则，不能撤销的坚决不给 AI。
- 用业务语言沟通，习惯用‘冷却塔的温度控制范围‘来描述问题，改掉动不动就蹦准确率、召回率、AUC 这些词的毛病。。
如果你是 SDE / 后端工程师
你已经会写代码、设计系统、也能保证稳定性。
还需要补的是：
- 在模糊需求里行动——FDE 接的不是 SOW（工作说明书），是 mission！客户说”帮我们提高审批效率”，但进场两周发现：审批效率根本不是问题，是客户经理不知道怎么理解 AI 的输出，导致根本不用。
- 原型的“加固“——原型跑通了、业务员说‘挺好‘，这只代表前 48 个小时达标了。可观测性、错误处理、边缘 case、权限、审计——把原型变成产品，是接下来几天、几周甚至几个月的任务。在制造业这种场合，生产稳定性大于一切，失去信任的系统是没人用的系统。
- 把一次定制抽象成可复用功能——FDE 不只是做项目。客户现场的共性需求要反哺到通用产品（这可以解释为什么 Palantir 出来的工程师前前后后创建了 300 多家公司）。
你注意到一直在说要让客户用起来。FDE 不能用传统 SDE 的 KPI——代码行数、功能交付量没有意义。FDE 的考核标准一般会说什么业务侧使用率、信任读、“从 AI 输出到业务动作的转化率“这几个指标。但我感觉这三个东西完全可以归到一个东西，客户的 AI token 用量。使用率上去了，token 用量涨；信任上去了，token 用量涨；AI 输出真的变成了业务动作，token 用量还是涨。反过来，任何一个环节出问题，token 用量最终会掉下来。
就像看一个地区的经济不用翻 GDP 报告，看用电量就行了。token 用量就是 FDE 的价值标尺。
如果你是 MLOps
技术上我感觉这是最接近 FDE 的。你会模型部署、监控、数据漂移检测，肯定也已经熟悉了用户的业务和数据。
还需要补的是一些软技能：
- 与客户高层/一线人员沟通的能力，把他们的模糊/隐藏需求转成可交付/可验收的产品
- Agent 的可观测性——传统系统看 logs、metrics、traces。Agent 还要看 prompt 输入、retrieved context、model output、tool call 参数和结果、reasoning trace、evaluator 结果。能回答客户：“为什么这次 agent 做错了？下次怎么避免？模型升级后会不会坏？”
- Human-in-the-loop 设计——人的介入点要放在不可逆动作之前、agent 置信度低时、高金额/高合规/高客户影响场景。
如果你是 Solution Architect
你已经会设计方案、做架构评审了，通常跟高层讨论也没问题。
还需要补的是现场干活能力：
- 实际写代码交付——SA 的工作在售前和架构设计阶段基本完成。FDE 的工作从售后开始：实际写代码、实际在客户环境里跑通、实际为生产问题负责。如果说 SA 的产出是个 PPT：“这个方案可以这样这样设计”，FDE 产出是个验收报告：“这个方案已经在你的环境里跑通了，这是踩过的坑和最终的效果”。
- 现场发现需求——不在现场，做不了准确的 agent 技术判断。客户的数据源质量、系统权限、例外规则，只有坐在那里才看得到。
我已经入职了！想要成为大佬
各公司正在建立 FDE 的职级体系。综合多个 JD 和招聘页面：
| 级别 | 经验 | 重点 |
|---|---|---|
| FDE Analyst / Junior | 0–2 年 | Hire-to-train，学习全栈 + 云 + AI |
| FDE / Senior Analyst | 2–5 年 | 独立端到端部署，设计 agent 方案 |
| Senior FDE | 5–8 年 | 战略客户，影响产品路线图 |
| Staff / Principal → 管理层 | 8+ 年 | 多客户技术领导，pre-sales |
职级是公司定的。能力层的成长路径比职级更有用。我把 FDE 的成长分成四层：
第一层：能部署。 把 AI 系统在客户环境里跑通——环境适配、接口调试、权限配置。这一层是基础，但停在这一层，你就是”会装工具的人”。
第二层：能诊断。 部署之后业务侧不用，你能判断为什么——是界面问题、输出格式问题、还是信任问题。能找到根因，不是反复培训业务员”你再试试”。
从第一层到第二层，关键是多问一个”为什么”。不只是把系统跑起来，是跑起来之后盯着业务员的实际使用，看到底卡在哪一步。
第三层：能设计。 不只是诊断已有问题，是从一开始就设计人机协作流程。知道哪些节点适合 AI、哪些必须留给人，在项目启动前就跟业务方画出协作流程图，给每个节点标注 AI 的角色。
从第二层到第三层，关键的“跃迁点“，是建立自己的判断框架——从凭经验，到有系统。判断框架至少包括三个维度：可逆性（做错了能不能撤销）、代价分布（错了谁会‘被考核‘）、信任度（业务员对 AI 的信任程度）。
第四层：能沉淀。 每次部署不只产出跑起来的系统，还产出可复用的资产——部署 checklist、踩坑记录、适配 playbook、业务侧沟通模板。下一个 FDE 拿到你的手册，如果能至少少走一半弯路，那你就是合格的 L4 级了。你能把客户现场的发现反哺到产品路线图，让一次定制变成可复用功能。
从第三层到第四层，关键跃迁是抽象能力——从”解决一个问题”到”让下一个问题更好解决”。
如果一直卡在第三层，很可能是—干活太多了！一个项目接一个项目，做完就赶下一个。每次都从零开始，每次都重新踩同样的坑。
一流 FDE 在项目里会刻意留 10% 到 15% 的时间做记录——踩了一个坑当场记三句话，发现一个不规范的 API 当场记下来，搞定了一个难沟通的业务员当场记下他说了什么让你终于理解了他的顾虑。不是项目做完了再写，那时候什么都想不起来了。
短期看，你在帮团队提速。长期看，你在把自己从一个能部署的人，变成了一个“有办法“的人。当你的 playbook 被团队反复使用、踩坑记录帮新人少走了三个月弯路，你就变成”定义了团队怎么做 FDE“ 的那个人。
我现在担心犯啥错误被开除
FDE 不做什么指北：
不要在所有地方用 Agent。 能用规则用规则，能用 SQL 用 SQL，能用普通 workflow engine 就不要让 agent 自由发挥。Agent 的灵活性有代价——不可预测、难调试、出问题难定位。核心判断力不是”怎么把 AI 用上去”，是”什么时候不该用 AI”。
不要把原型当产品交付。 48 小时冲出一个能看的原型，业务员说”不错”，这不是终点。原型的硬化——可观测性、错误处理、边缘 case、权限、审计——是完全不同的工作模式。最常踩的坑：把原型当产品交付了，三个月后出了问题才发现到处是裂缝。
不要只做客户定制。 Reddit 上有人直接把 FDE 叫成”professional services with better branding”。这个批评不是没道理——如果你的工作退化为无休止的客户定制化实施，FDE 就是高级外包。FDE 的价值取决于抽象能力：能不能从一次定制里看出可复用的产品功能，能不能把现场发现系统化地反哺到产品路线图。
不要靠精度数字建立信任。 没有一个案例是靠”准确率 95%“让业务侧接受的。业务侧怕的不是 AI 出错，是 AI 出错之后他们兜不住。建立信任的方法是双轨测试、影子模式、种子用户共建——让对方亲眼看到、亲身参与。信任可以不靠数字，靠设计。
不要过度自动化。 AI 接管太多之后，人的判断能力会退化。要刻意保留人的实践机会——不是防备 AI，是为了 AI 出错时人能接住。
你是谁，怎么还了解 FDE？
2022 到 2024 年，我作为一个 AI 实验室的负责人，不时要到客户现场待上两三周到两三个月不等，前前后后加起来应该有多半年吧。做的事和 FDE 不能说很相似，只能说是一模一样——
同样是到现场挖掘需求。客户不清楚 AI 能做什么，只知道要用起来。至少先把日报、周报、月报这些要收集数据、分析、生成 word/excel 先解决了。但难点当然还是在装置上。操作间、观察流程、提出问题、把可能性翻译成可交付任务。
同样要补领域知识。乙烯装置怎么运行、芳烃装置的关键参数、操作员的日常动作——要买化工教材、找工程师要装置手册来学哦。每个行业都有自己的领域知识，FDE 不管进入什么行业都必须要补，否则跟客户对不上话。
同样是数据源混乱。PI 系统的记录精度不够，西门子的系统只有 Excel，现场记录用的是 WPS ，这些坑都要自己去踩。先梳理出哪些数据可靠、哪些缺失、哪些口径不一致，这些就够忙活一个月。
同样是交付可用系统。有传统工程（接数据、做界面、写逻辑），也有 AI 部分（建模、故障检测、根因分析），也有‘报表一键导出‘这样的技术简单但体感明显的“取巧“模块。
同样是 human-in-the-loop。操作员看到系统建议后自己做判断；shadow 模式（ AI 只给建议不实际操作）运行一个月，是推进技巧也是基操。human-in-the-loop 的重要性没有变化，现在 agent 的能力更强，但背锅的永远是人啊。
同样是验收标准模糊。技术深度没人关心，界面美观也没要求，结果可靠就行。但能不能达到、怎么衡量，很大程度上取决于设计。让 AI 做它不擅长的事，比如在数据超出历史分布之外还要强行预测甚至操作，翻车是早晚的事；但引入告警机制就能让结果既负责又稳定。
同样是没人帮你写 PRD、做技术方案评审、梳理业务流程。一个人（或者两三个人的小团队）同时/分头做流程梳理、领域理解、数据工程、模型选型、软件开发，还有——跟一屋子客户的技术骨干开会。
但比起两年前，现在的 AI 确实强太多了。之前想要引入 AI 来解决问题的，主要还是生产部门的核心装置。这些地方格式化数据多，也有预算，又有明确的降本增效诉求，AI/ML 恰好可以帮助提前定位问题（预测性维护）、总结规律（回归分析）。
两年之后，大模型也能阅读非结构化文本、理解意图、生成回复、调用多种工具。想要引入 AI 的，也就扩大到了客服、销售、运营、人力这些职能部门。
以前的 ML Ops，AI 赋能工程师，现在的 FDE，或许还有新的名字出来，但把 AI 接到业务里要干的事和原则变化都不大。都得理解业务，都得 HITL，都得交付能真正干活的东西。
@金哲 Dev