FDE（Forward Deployed Engineer，中文常译「前线 / 前沿 / 前置部署工程师」）是把工程师派到客户真实业务现场，对着真实数据与系统写生产代码、打通场景，并对「能不能跑起来」负责的一类角色与交付模式。它源自 Palantir，近年随大模型落地再次走红；在中国，它既出现在招聘 JD 里，也出现在厂商的「试点路径 / 阶段交付 / 驻场 AI」服务包装里——形态并不只有一种。
什么是 FDE：为一个客户打通很多能力
经典定义可以记成四句话：
1. 位置在前线：尽量贴近客户现场（内网、涉密、业务会议室），而不是只在乙方办公室等需求文档。 2. 对象是一个客户：普通研发常是「为很多客户做一个功能」；FDE 更接近「为一个客户打通很多能力」。 3. 动手写生产代码：不只做 PPT 方案——原型、接入、治理、联调、灰度，都要能下场。 4. 对结果负责：验收看场景是否进入真实使用，而不是「人坐满了几个月」。
Palantir 官方曾把 FDE 类比为小型创业公司里的 CTO：在精干前线团队里，对高风险落地端到端负责。内部它常与后方产品研发形成「前线发现 → 产品回流」的闭环：现场趟出来的共性，应沉淀回平台，而不是永远停在一次性项目里。
生成式 AI 让这件事再次变刚需：模型很容易做出 Demo，难的是接进企业脏数据、审批流、权限与既有 ERP/协同系统。OpenAI、Anthropic、Databricks 等也组建类似团队，逻辑同一——缺的不是模型，是把模型接进真实业务的工程。
中国企业在「提供 FDE」时，常见五种表现形式
公开招聘、厂商方案页与交付转型报道里，中国语境下的 FDE 大致落在下面几类（同一家公司也可能同时占两类）：
| 表现形式 | 谁在卖 / 谁在招 | 你在合同或 JD 里会看到什么 | 典型信号 |
|---|---|---|---|
| 交付队伍改名转型型 | 传统软件与 IT 服务商 | 「交付人员转型 FDE」「把经验写成 Skill / Agent / 行业模板」 | 明略等披露交付人员转 FDE；金蝶、致远、软通等把 FDE 写进交付体系——强调经验回流产品 |
| 阶段结果交付型 | 垂直行业 AI 落地服务商 | 「按阶段目标 / 交付物 / 验收」「不是驻场外包」 | 明确写：按结果付钱、带着产品底座、做完会走；刻意切割「按人头驻场」 |
| 驻场 AI 工程师型 | 中小 AI 工程服务商 | 「派资深工程师驻进你的团队」「人月 / 弹性扩缩」 | 强调并肩开发与知识转移；计费更接近人月，需单独问清验收口径 |
| 甲方自建 FDE 型 | 大型央国企 / 集团数字化团队 | 「培养自己的 FDE」「业务 + 技术复合队伍」 | 如航运等复杂网络企业：外部懂模型，内部懂不能混的数据口径与不能绕的审批 |
再往细拆 JD，国内岗位其实是一条光谱，而不是一个工种：
- 偏业务 / 方案：把模糊痛点翻译成可量化目标、方案蓝图、行业知识库与模板（用友「行业专家」、部分美团「FDE 产品」等表述接近这一端）。
- 偏工程 / 私有化：云架构、部署、稳定性、内网联调（金融云、私有化部署类更明显）。
- 中间态：既能见客户，又能自己搭 Demo / Agent 原型——这是当前招聘里出现最多的「复合」画像。
对采购方来说，重要的不是对方有没有把三个英文字母印在 PPT 上，而是：人为什么进场、按什么验收、经验会不会回流成你们可留下的能力。
最容易混淆的一点：FDE ≠ 换了名字的驻场外包
国内讨论里反复出现同一句提醒：很多「号称 FDE」的服务，本质仍是开放式驻场人力。可以用一张表快速分辨：
| 维度 | 更接近真 FDE | 更接近驻场外包换皮 |
|---|---|---|
| 进场理由 | 数据摸底、接口、上线陪跑等阶段需要 | 默认长期常驻、随叫随到 |
| 带着什么来 | 产品 / 平台底座 + 行业模板 | 从零现写，走了没人敢动 |
| 结束后留下什么 | 可运行系统 + 团队可接手的方法 / 资产 | 依赖特定驻场人员 |
| 与产品的关系 | 前线经验应回流平台，降低下一单成本 | 项目经验只留在顾问脑子里 |
这不意味着「人绝不能出现在现场」——数据摸底、涉密内网、联调上线，本来就常常需要人在场。差别在于：人为阶段目标来，目标达成后进入下一阶段或移交；不是把「常驻」本身当成商业模式。
另一个常见误解：FDE 等于「全栈超人独自把客户系统重写一遍」。一线访谈更常描述的是：客户说的是现象（流程乱、表格飞来飞去），FDE 要先翻译成可被系统接管的逻辑，再对接 ERP、协同软件、权限与人工兜底——业务理解、工程融合、组织推动往往比「再调一次模型参数」更先发生。
什么时候值得上 FDE，怎么验收
结合公开实践与国内落地文章，较稳妥的判断是：
更适合上 FDE 的信号
- 场景已经验证过价值（内部 PoC、试点问法、大赛课题等），现在要进生产；
- 数据锁在多系统里，导不出、对不齐、没人说得清口径；
- 必须打通收费、工单、财务、ERP、协同等真接口；
- 要的是有权限、有日志、天天有人用的系统，而不是演示环境里的 Demo。
可以先不上 FDE 的信号
- 还只是「想了解一下 AI」；
- 场景未验证，数据一张表就能导出；
- 其实想要的是长期人力外派，而不是阶段结果。
采购 / 立项时可问的五句话
1. 本阶段的目标、交付物、验收标准是否写在纸上？ 2. 验收看的是场景是否跑起来，还是工时表？ 3. 是否带着可复用的产品底座 / 模板，而不是纯定制一次性代码？ 4. 前线发现的共性，如何回流成下一轮更便宜的能力？ 5. 人走之后，甲方团队能否独立运维与迭代？
这也解释了为什么不少厂商把 FDE 与「先小试点、边界可计量、再扩面」绑在一起：FDE 是重投入，时机错了会变成最贵的弯路；时机对了，它是越过「Demo 到生产」鸿沟最快的路之一。
延伸阅读
玲珑玄镜（北京亿来顿信息科技有限公司 / Eleton）在对外交流里，把 FDE 表述为「边界清晰可计量的试点路径」：先小范围验证本体与问法，再扩领域与系统接入——与上文「阶段目标 + 可留下能力」同向。读懂 FDE，是为了少买「换皮驻场」，多买「能跑起来的生产闭环」。