【摘要】
Forward Deployed Engineer 这个词最早来自 Palantir：他们的工程师不是坐在总部等人提需求，而是被"前置部署"到客户现场，和客户一起把问题定义清楚，再自己动手做出能用的东西。
国内这几年这个词被大量借用，含义漂移得很厉害。有的公司把驻场运维改名 FDE，有的把售前技术支持叫 FDE，还有的把"会写 SQL 的实施"叫 FDE。
先给定义，再看边界：FDE 是被派到客户现场、对问题定义和交付结果同时负责的工程师。 三个要素：在现场、能自己动手、对结果负责。
【核心要点】
- FDE 的稀缺性不在技术，在"能在信息不全的现场做技术决策并承担后果"
- 实施对"上线"负责，FDE 对"上线后客户的业务指标"负责
- 售前卖可能性，FDE 兑现可能性，两者激励方向相反
- 驻场开发解决"写什么"，FAE 解决"设备/产品怎么用"，FDE 解决"这事到底该不该这么做"
- 三个问题就能识别真假 FDE：方案谁定、出问题谁顶、上线后谁还在
---
一、岗位从哪来：一个反常规的组织设计
传统软件公司的分工是：销售签单 → 产品经理写需求 → 研发实现 → 实施部署 → 售后运维。链条很长，每一环只对自己的动作负责，没人对"客户到底有没有解决问题"负责。
Palantir 的做法是把这条链压缩：派一个工程师到客户那里，让他同时做需求澄清、方案设计、原型验证和小范围交付。这个人既懂技术又听得懂业务，能在一周内做出可演示的东西，而不是三个月后交一份需求文档。
这个设计的核心假设是：客户自己说不清要什么，只有让他看到东西，需求才会浮现。 所以 FDE 的本质是"用快速交付来逼出真实需求"，而不是"按需求文档执行交付"。
二、五种角色，一张表看清
| 维度 | FDE | 普通实施 | 售前 | 驻场开发 | FAE |
|---|---|---|---|---|---|
| 何时出场 | 售前到上线后数月 | 合同签订后 | 签单前 | 项目期中 | 产品/设备使用中 |
| 是否定义问题 | 是，主要职责 | 否，按文档执行 | 部分（为了卖） | 否，按单实现 | 否 |
| 能否动手改 | 能，现场脚本/配置/原型 | 只配置 | 不改 | 改代码 | 不改软件 |
| 背什么结果 | 客户业务指标 | 上线时间与验收 | 签单额 | 需求完成度 | 故障恢复/使用效果 |
| 面对不确定性 | 日常 | 偶发 | 高但可回避 | 低 | 中 |
| 典型失败 | 承诺过度、范围失控 | 客户不满意但流程闭环 | 过度承诺 | 改出事故 | 判断错根因 |
这张表里最值得看的是"背什么结果"这一行。它决定了一个人日常在想什么：
- 想"这个需求什么时候能做完"的是实施
- 想"这个功能客户会不会真的用"的是 FDE
- 想"这个能不能写进合同"的是售前
三、和实施的真正分水岭：谁定义"做完了"
实施的"做完"由合同和验收单定义：功能清单跑通、文档交齐、客户签字。
FDE 的"做完"由客户的业务状态定义：不良率降了没有、人工录入少了几小时、异常响应从 4 小时变成 40 分钟没有。这些东西往往不写在合同里，但客户心里有一杆秤。
所以 FDE 必须做一件实施不需要做的事：在上线前就把"怎么算成功"和客户谈清楚，并且把它变成可观测的指标。谈不清楚的项目，最后一定变成"客户觉得没用，你觉得交付完了"的扯皮。
四、和售前的张力：不是立场问题，是时间尺度问题
售前看的是一个季度内的签单，FDE 看的是未来一年的交付。同一句话，两人的判断完全不同：
客户问："能不能和我们现有的系统打通？"
- 售前想：能，做过类似案例
- FDE 想：哪个版本、有没有接口、走什么协议、谁出人、多长时间
成熟的做法不是让 FDE 闭嘴，而是让 FDE 把答案变成带条件的承诺：
"可以打通，前提是对方系统提供 X 接口或数据库只读权限；如果只能文件交换，延迟会在 5 分钟级。这部分需要在合同附件里写明双方责任。"
这句话保护了三方：客户知道真实成本、销售保住单子、FDE 后期不被甩锅。
五、和驻场开发、FAE 的边界
驻场开发解决"写什么"，不解决"该不该写"。他在需求已经明确的前提下效率很高，但让他判断需求价值，通常判断不了——因为他看不到上线后的使用情况。
FAE（Field Application Engineer）解决"产品/设备怎么用、为什么不好用"，通常在硬件、芯片、设备行业。他懂产品和应用场景，但一般不做系统集成和业务方案设计。
FDE 站在中间偏上：往上要能跟客户的技术负责人谈架构和合规，往下要能跟一线操作工确认操作习惯，中间还要能自己写脚本验证假设。
六、三个问题识别真假 FDE
面试或合作时，问这三个问题，答案能立刻分出层次：
- "现场技术方案谁定？"
- "总部/产品经理定，你执行" → 实施或驻场开发
- "你定，但要过评审" → 真 FDE
- "上线后出 P0 故障，谁第一时间到现场？"
- "运维/客服" → 不是 FDE 岗
- "你，而且要出根因分析" → 真 FDE
- "上线三个月后，你还管这个客户吗？"
- "交接给售后了" → 实施
- "还管，要出价值复盘" → 真 FDE
七、为什么这个岗位在国内外都变贵了
三个结构性原因：
- 软件越来越难卖"标准功能"。客户要的是"解决我的问题"，不是"买你的模块"。谁能把标准产品改造成客户能用的形态，谁就有议价权。
- 交付失败的成本变高了。制造业停线、医药合规审计、政企数据泄露，任何一个事故的代价都远超软件本身的价格。客户愿意为"不出事"付溢价。
- 跨界人才供给极低。既懂行业业务、又懂系统集成、还能在一线做决策的人，培养周期 5 年以上，且很难批量复制。
下一篇讲钱：为什么 FDE 的薪资显著高于普通实施，这个差价到底在为什么付钱。