M0第 2 课 · FDE 与相邻岗位
M0-L2.3FDE 与软件工程师、AI 工程师
一句话： 软件工程师或 AI 工程师为许多用户构建并改进本公司的产品；FDE 从一个客户的问题出发，在产品之上做出这个客户需要的东西，并对它在那里是否起作用负责。
软件工程师（SWE）和 AI 工程师做的是产品本身。他们的起点是路线图；他们的用户大多是永远见不到的人；他们的环境是公司自己的技术栈。AI 工程师专注于和模型打交道的部分：prompt、检索、tool calling、评测、微调。
FDE 用到的很多是同样的技能，这也是为什么本手册的模块一到模块四看起来像一套软件和 AI 工程课程。变化的是语境：起点是一个客户的问题，用户是一个组织里的具体的人，环境是别人的系统、数据、安全规定和遗留代码。
FDE 为什么需要
Section titled “FDE 为什么需要”“为什么选 FDE 而不是软件工程？“是最常见的面试题之一，很多候选人答得不好（“我喜欢和人打交道”）。一个清楚的对比能让你从责任和环境的角度回答。
| 软件 / AI 工程师 | FDE | |
|---|---|---|
| 起点 | 产品路线图 | 一个客户的问题 |
| 用户 | 很多，大多是匿名的 | 一个组织里叫得出名字的人 |
| 环境 | 公司自己的技术栈，团队能控制 | 客户的系统、权限和遗留系统，团队里没人能控制 |
| 成功 | 功能质量和整个用户群的采用 | 这个客户的结果 |
| 代码放在哪里 | 产品主仓库 | 对产品的贡献，加上客户特有的集成 |
| 典型的反馈回路 | 规模化的指标和用户研究 | 直接对话，每天都有 |
技能相同，权重不同
Section titled “技能相同，权重不同”两个角色都需要读写生产代码、设计系统、评估 AI 行为。FDE 还需要在自己无法改变的约束下工作（客户的身份认证系统、只能读不能写的数据库、排队六周的安全审查），并且要负责 discovery 和采用，而产品工程师很少负责这些。
工程师从 SWE 转到 FDE，是为了更直接地接触客户影响、获得更快的反馈；从 FDE 转到 SWE 或产品岗位，是为了更深入地拥有一个系统。两种转变都很常见，都不算降级。
- “FDE 的代码是一次性的。” FDE 的代码在客户的生产环境运行，标准一样；客户定制不等于质量低。
- “SWE 能力强就能做好 FDE。” 必要但不充分。大多数 FDE 的失败是 discovery 或采用的失败，而不是写代码的失败。
- “FDE 比 SWE 低一档。” 这是另一种取舍：在单个系统上深度少一些，广度更大，对结果的直接责任更多。
为什么选 FDE 而不是产品工程岗位？
讲你想对什么负责：为真实客户交付一个能用的结果，包括代码之外的部分。说说你想工作的环境（别人的系统、真实的约束），再举一个你已经做过类似工作的例子。
在客户环境里写代码比在自己公司难在哪里？
环境不受你控制：拿权限要时间，数据比预期更乱，安全规定限制你能部署什么，你可能要和一个没人完全搞懂的系统集成。你还必须把代码留在一个别人能运行的状态。
- 文章：Dev versus Delta: Demystifying Engineering Roles at Palantir（Palantir 博客，Dev 部分）— Palantir 定义的产品工程
- 文章：What are Forward Deployed Engineers?（The Pragmatic Engineer）— FDE 的日常工作与产品工程有何不同