FDE（Forward Deployed Engineer，前线部署工程师）不是一个新名字，而是一种新的责任边界：把工程师放到客户真实业务现场，让他对"系统有没有真的被用起来、有没有真的产生业务结果"负责到底。
很多岗位都在客户附近工作，但大多只对自己那一段负责——销售对签约负责、售前对方案负责、交付对验收负责、工程师对代码负责。FDE 的不同之处在于：他对最终结果负责，并且为了拿到这个结果，可以横穿这所有环节。
先想象一个画面
一家银行说想做"AI 助手提升客户经理效率"。
- 第一周，FDE 不在写代码，而是坐在客户经理旁边看他们怎么处理一天的工作，发现真正的瓶颈不是"问答"，而是分散在五个系统里的客户信息。
- 第二周，他接通了其中三个系统的只读接口，做了一个能按权限检索、带出处引用的草稿助手，先给 10 个人试用。
- 第三周，他在修一个会让客户经理看到越权数据的检索 bug，同时把试点采纳率做成一个客户高管能看懂的图。
- 第四周，他发现"按角色过滤客户数据"这件事，下一家银行也会遇到——于是把它抽象成一个可复用的模块，提给产品团队。
这四周里，他做了销售、售前、交付、工程师、产品经理各自会做的一部分——但他做这些不是为了交付物，而是为了那个结果真的发生。这就是 FDE。
一个更准确的定义
FDE 是结果的所有者（owner of the outcome）：一个能进入客户现场理解真实问题、能亲手把系统写到生产、并能把现场经验回流成产品能力的工程型角色。衡量他的不是交付了什么文档，而是业务流程有没有被真正改变。
这也是各家头部公司官方描述的共识：OpenAI 把 FDE 定义为对客户部署从发现、定界、设计、构建到生产 rollout 全程负责，成功指标是生产采用与可衡量的业务影响。OpenAI Careers↗ Google Cloud 强调 FDE 是 embedded builder，要和客户一起 code、debug、ship，而不是给建议。Google Careers↗
四个面的交叉点：现场 · 代码 · 校准 · 回流
理解 FDE，最好的方式不是拆解它的英文缩写，而是看它同时站在哪四个面上。我们把它叫做 4C——一个合格的 FDE，四个面缺一不可。
深入客户的真实环境：业务流程、数据在哪、谁有权限、谁买单、失败成本是什么。问题不是"客户要什么功能"，而是"客户真正的业务结果卡在哪"。这一面决定你做对的是不是正确的事。
亲手把方案写到生产：接数据、做检索与 Agent、处理权限与审计、部署上线。不是 demo、不是 PPT、不是配置，而是能在客户基础设施上真实运行的系统。这一面决定你到底能不能交付。
用真实业务指标和失败模式做 eval，把系统调到真有用：正确率、覆盖率、越权率、人工接管率、采用率……不是"上线了"就算赢，而是"被用起来、指标真的变好"才算。这一面决定你交付的是真有效，还是自我感觉良好。
把现场反复出现的摩擦，沉淀成可复用的连接器、模板、评估集与产品需求，让下一个客户更快落地。这一面决定你是在做会复利的产品，还是一次性的项目。
只占一个面的人很多：只懂现场的是顾问，只会写代码的是工程师，只盯指标的是分析师，只想着产品化的是 PM。真正稀缺、也真正定义 FDE 的，是把四个面收在同一个责任主体上——不是几个专家接力，而是端到端对结果负责；在 AI 时代，这个主体可以是一个人带一支 agent 舰队，也可以是一支小队带多个 agent。
FDE 不是什么
正因为它横跨太多环节，FDE 很容易被误解成"换了名字的售前 / 咨询 / 交付"。一句话先放在这里：
售前对方案负责，咨询对建议负责，交付对验收负责；FDE 对生产环境里真实发生的业务结果负责。
它们的边界、以及如何判断一个岗位是不是"真 FDE"，我们在 与相邻岗位的区别 里展开。
"大 FDE"：前线部署化正在外溢
值得注意的是，FDE 不只是一个岗位编制，更是一种正在外溢的工作方式。当 AI 能力变化太快、客户问题高度异质，"把懂结果的人放到现场、让他端到端拿结果"这件事，开始影响销售、售前、交付、产品乃至创始人的工作方式——我们把这种更宽的范式叫做 "大 FDE"（Forward Deployed 化）。
这也是为什么这一页和你有关，无论你现在是什么岗位：
想看不同岗位怎么切入、能走多远，去 从你的岗位看 FDE；想看一条具体的转型路线，去 各岗位转型路线。想先理解它为什么在 2025–2026 爆火，去 为什么现在。