FDE 最容易被误读成“换了名字的售前”或“包装得更花哨的咨询”。这两种说法都不准确。区分它们最可靠的方式不是看 title，而是看一件事：交付的最终产出物，到底是文档、建议，还是一个在客户生产环境里跑起来、能被衡量的系统。
一张表看清边界
| 维度 | FDE | 售前 / SE | Solution Architect | 后端 / 平台 SWE | 咨询顾问 |
|---|---|---|---|---|---|
| 主要产出 | 可运行的生产系统 | 演示与方案，支持成单 | 架构蓝图与选型建议 | 核心产品代码 | 分析报告与建议 |
| 是否写生产代码 | 是，端到端 | 基本不写 | 偶尔 PoC | 是，但不进客户现场 | 一般不写 |
| 是否进客户现场 | 是，深度嵌入 | 是，但偏销售周期 | 部分 | 否 | 是，但偏访谈调研 |
| 对什么负责 | 生产采用与业务结果 | 销售转化 | 方案可行性 | 系统质量与稳定 | 交付物与结论 |
| 与产品的关系 | 反哺 roadmap 与模型 | 反馈竞品信息 | 反馈架构需求 | 自身即产品 | 通常无闭环 |
售前工程师支持的是销售流程，目标是把单子推成；FDE 的目标是生产落地和可衡量的 workflow impact。OpenAI↗ Google 的表述尤其适合用来区分：FDE 不是 advisory role，而是嵌入客户环境一起 code、debug、ship，并解决 integration、data readiness、state management 等阻碍 AI 进入企业级成熟度的生产化障碍。Google Careers↗
两个最常见的误区
不准确。售前在销售阶段做 demo 和方案，签单后就交棒；FDE 的工作主要发生在签单之后——进现场、写代码、跑 eval、上生产、推采用。产出物从 PPT 变成了能跑的系统。
不准确。咨询顾问通常交付一次性分析或建议；FDE 的核心是工程实现与产品反馈。Palantir 官方博客明确把 Delta / FDSE 与 consultant 区分开：FDSE 做大量工程和技术工作，甚至会把现场代码贡献回核心产品。Dev vs Delta↗
真 FDE 的四要素
无论 JD 怎么写、岗位叫什么名字，真正的 FDE 一定同时具备这四点——这也是它区别于所有相邻岗位的本质。
客户现场 + 真实编码 + 生产落地 + 产品反馈闭环。 少了“客户现场”就是普通 SWE；少了“真实编码”就退化成售前或 SA；少了“生产落地”就只是做 demo；少了“产品反馈闭环”就沦为低毛利的定制服务。
如何判断一个岗位是否“真 FDE”
看 JD 时，可以用这张 checklist 逐条核对。命中越多，越接近真 FDE；如果大半落空，它多半只是借了个热门名字。
JD 里有没有“写并 review 前后端生产级代码”“full-stack build”这类硬要求？还是只字未提编码？OpenAI、Palantir、Scale 都把强 coding 列为底线。
是否提到 embedded、on-site、travel（OpenAI 部分岗位最高 50%）、与客户工程师 side-by-side？纯远程、纯总部的“方案岗”要警惕。
成功指标写的是“production adoption”“measurable workflow impact”，还是“支持销售”“完成方案”？前者才是 FDE。
有没有“codify reusable patterns”“share field feedback with Research and Product”“blueprints / product requests”？这是 FDE 与外包工程师的分水岭。
是否要求在 fast-moving、ambiguous environment 中交付，并在 scope、速度、质量之间做 tradeoff？真 FDE 不是“客户说什么做什么”。
OpenAI 和 Google 的 FDE 岗位是高质量参照：两者都强调从客户问题到生产系统、再到可复用模式与产品反馈的完整链路。OpenAI↗Google Careers↗
把这五条串起来，其实就回到了最浓缩的定义——现场、代码、上线、指标、产品化。想从头复习这个内核，请看 什么是 FDE。