一句话版本
FDE 是驻在客户现场、把公司的技术能力接进客户真实业务系统、并对上线结果负责的工程师。
三个关键词缺一不可：在现场、动手写、对结果负责。少任何一个，就变成别的岗位了。
这个岗位名从哪来
FDE 全称 Forward Deployed Engineer。「Forward deployed」原本是军事术语，指部署在最前线的部队。约二十年前，Palantir 把这个说法搬进商业世界，用来描述一类特殊工程师：不坐在总部写通用产品，而是被派到客户单位里，用公司的平台帮客户把具体问题解决掉。
后来 OpenAI、Anthropic 等公司在做企业落地时也采用了这个岗位设置，FDE 逐渐从一个公司的内部叫法，变成一个通用的岗位名。
2026 年它在国内变热，直接原因是模型能力已经足够，但企业真正把 AI 用起来的那一段——数据怎么接、流程怎么改、出了错谁负责——没人干。FDE 补的就是这一段。
每天在做什么
不同公司叫法一样，职责侧重不同，但大体跑不出这四件事：
第一，进现场摸清真实流程。 客户说「我们想用 AI 做客服」，实际情况可能是工单散在三个系统里、知识库两年没更新、一线人员根本不用。这些在需求文档里看不到，只能到现场看。
第二，动手把它做出来。 FDE 是要写代码的。写的是把模型、平台能力、客户系统粘起来的那层胶水，不是训练基础模型，但也不是配置几个参数就完事。
第三，对上线之后的结果负责。 这一点是 FDE 和其他岗位最大的分界。系统上线后准确率掉下来、客户业务指标没改善，FDE 要回去改。
第四，把现场问题带回产品。 同一个坑在五个客户那里都出现，就该由 FDE 反馈给产品团队，变成通用能力。不做这件事的 FDE，只是在做定制外包。
和四个相邻岗位的真实区别
这是最容易混淆的地方。下面这张表按「在哪工作 / 干不干代码 / 对什么负责」三个维度切开：
| 岗位 | 主要在哪 | 写不写代码 | 对什么负责 |
|---|---|---|---|
| FDE | 客户现场 + 公司 | 写，且要改 | 上线后的业务结果 |
| 售前 / 解决方案架构师 | 客户会议室 | 一般不写，出方案 | 方案能不能签下来 |
| 交付 / 实施工程师 | 客户现场 | 少量，按既定方案部署 | 按合同交付完成 |
| 算法 / 后端工程师 | 公司 | 写 | 功能是否按需求实现 |
| 技术支持 / 客户成功 | 远程 + 偶尔现场 | 基本不写 | 问题是否被响应 |
最容易搞混的是售前和交付。
售前也懂技术、也进客户现场、也画方案，但售前的终点是签约。签完之后系统跑得好不好，不是售前的考核项。FDE 的起点恰恰在签约之后。
交付工程师也驻场、也部署，但交付的边界是「按合同把这个东西装上去」。装完验收通过，任务结束。FDE 要的是「装上去之后客户那个指标真的动了」，指标没动就得继续改。
所以一句话：售前对签约负责，交付对验收负责，FDE 对效果负责。
为什么这个岗位会有副作用
FDE 模式不是没有代价，公开讨论里被提到最多的有四点：
- 成本按人头算，一个 FDE 同时只能服务有限客户，规模效应差
- 知识沉淀在人身上，人走了经验也走了
- 出差和驻场强度高，对生活节奏影响大
- 容易退化成定制外包，如果第四件事（反馈回产品）不做，FDE 就只是贵一点的实施
这四点决定了 FDE 不是一个「轻松转行」的岗位，而是一个要求很高、消耗也很大的岗位。
和证书的关系
理清岗位之后再看证书，判断标准就清楚了：一张 FDE 证书值不值，取决于它考的东西和上面这四件事有多接近。
如果考的是纯概念记忆，那它证明的是你读过资料；如果考的是场景判断和方案设计，那它至少能证明你想过真实问题。
站内另一篇《FDE 认证到底有几种》把目前市面上的四套体系逐条拆开过，那篇讲「有哪些」，这篇讲「这个岗是什么」。
常见误解
「FDE 就是 AI 工程师的新叫法」——不是。AI 工程师是能力标签，FDE 是工作方式标签。一个 FDE 可能主要在做数据对接和流程改造，模型部分只是调用现成接口。
「FDE 是初级岗」——相反。要同时面对客户、改代码、担结果，通常需要有几年的工程经验打底，新人很难直接胜任。
「考个证就能转 FDE」——证书能证明你了解这个岗位的工作方式，但 FDE 的核心门槛是现场判断力，那个只能在做项目里长出来。
*本文关于岗位职责与模式的描述，参考了公开可查的行业讨论与百科词条；涉及具体公司内部职级、薪酬的部分，因无法核验，本文不作引用。*