FDE 到底是什么，为什么 AI 公司开始把工程师送进现场

FDE ，简单说，就是跟着客户的真实问题走进现场，把 AI 原型做成能稳定运行的生产系统，再把现场学到的东西带回产品的工程师。

模型能力越强，这个角色反而越重要。因为客户买到的是通用能力，真正决定项目成败的却是本地上下文：业务规则藏在哪里，数据能不能用，旧系统怎么接，权限和合规如何处理，上线后怎样保证成本、延迟和可靠性。模型升级不会自动补齐这些缺口。

一句人话定义： FDE 是一条责任链

Forward Deployed Engineer 通常译为“前沿部署工程师”。“ Forward ”容易让人只注意到“前线”或“现场”，但地点不是定义这个角色的关键，责任范围才是。

OpenAI 的 FDE 官方岗位把团队放在“客户交付与核心平台开发的交叉点”。岗位负责需求发现、技术范围界定、系统设计、构建和生产发布；成功指标包括生产采用、可衡量的工作流影响，以及能够改变产品和模型路线的评测反馈。岗位还明确要求编写和评审前后端生产级代码，把有效做法沉淀成工具、手册或可复用组件。

Scale AI 的官方岗位描述提供了另一组证据： FDE 每天与技术客户协作，把客户问题转成工程方案，设计、构建和部署从前端、后端到基础设施的全栈功能，同时直接影响产品路线。

Scale AI 的 FDE 负责人岗位把生产责任写得更明确：交付系统需要达到可靠性、安全、可观测性和评测标准，现场经验还要转成可复用的平台能力，让下一次部署不再从零开始。

Palantir 对 Forward Deployed Engineering 的描述更接近一种产品研发方法：工程团队尽可能靠近问题，与核心工程团队协作，持续综合现场反馈并发布新功能。它把这个过程类比为“人类版本的反向传播”。

三个来源的业务不同，但共同结构很稳定：

• 接近客户现场，获得文档之外的上下文；
• 仍然直接写代码，并对生产运行负责；
• 把一次交付中的共性问题沉淀回产品。

因此，本文采用的工作定义是：FDE 是把客户现场、生产级工程交付和产品回流连成闭环的组织角色。 这是对多家公司官方职责的归纳，不代表所有企业都使用完全相同的岗位名称。

为什么模型越强，现场上下文越容易成为瓶颈

一个大模型可以写代码、调用工具、理解文档，但它不知道某家企业内部的“订单完成”到底以哪个系统字段为准，也不知道一次看似简单的退款动作要穿过哪些审批、风控和审计链路。

企业 AI 项目真正进入生产时，至少会遇到五类问题：

瓶颈	现场要回答的问题
上下文	真实规则在文档、人的经验还是系统状态里
数据	数据是否完整、可访问、可追溯，语义是否一致
集成	模型怎样接入 ERP 、 CRM 、工单、权限和消息系统
可靠性	错误怎样发现、降级、回滚和人工接管
反馈回流	哪些问题应现场修，哪些应该进入通用产品

这也是为什么 AI 落地不能只靠“模型专家远程给方案”。很多约束只有进入实际工作流才会暴露：用户可能绕开系统，历史字段可能有多套口径，接口可能没有文档，模型输出即使正确也未必符合审批顺序。

这里需要区分事实与判断。 OpenAI 、 Scale AI 和 Palantir 的官方材料能够证明这些公司要求 FDE 承担客户协作、全栈构建、生产部署和反馈回流；“模型越强，现场上下文越成为相对瓶颈”则是基于这些共同职责做出的工程判断，不是三家公司发布的统一结论。

从业务问题到产品回流： FDE 的五步工作闭环

第一步：发现问题。 进入业务现场，找到真正影响结果的流程、角色和约束。客户说“想做一个智能客服”， FDE 需要继续追问：要降低的是首次响应时间，还是人工转接率？哪些问题允许自动回答？谁对错误答案负责？

第二步：定义方案。 把模糊需求变成技术范围、验收指标和风险边界。这里要决定用模型、规则还是传统代码，哪些数据可以进入上下文，哪些动作必须保留人工确认。

第三步：构建与集成。 写生产代码，把模型接进数据源、业务系统、权限体系和用户界面。 FDE 不是把需求转交给另一支研发团队后离场，而是直接参与关键工程实现。

第四步：生产运行。 让原型跨过上线门槛：评测、观测、成本、延迟、安全、故障降级和回滚都要有人负责。 OpenAI 的岗位描述从“第一个原型”一直写到“稳定生产”，这正是 FDE 与演示型项目的分界线。

第五步：反馈回流。 把现场反复出现的问题抽象成工具、组件、评测集、产品功能或研发路线输入。否则每个客户都从头定制，工程团队只会不断增加一次性负担。

这五步不是瀑布流程。生产反馈会把团队重新带回问题定义，产品改进又会进入下一轮部署。完整的 FDE 是一个循环，而不是一次交付。

和驻场、售前、解决方案工程师，最小边界在哪里

FDE 与这些岗位有明显重叠：都需要理解客户、设计方案、跨团队沟通，有些也会驻场或写代码。不能只看标题做分类。

角色或模式	常见核心任务	与完整 FDE 的最小差异
驻场开发	在客户现场完成指定开发任务	“驻场”只说明工作位置，不保证端到端责任和产品回流
售前工程	验证方案可行性，支持客户决策	重点通常在签约前，不必长期承担生产运行
解决方案工程	设计架构、集成产品、推进落地	可能非常接近 FDE ，差异取决于是否直接写生产代码并影响核心产品
FDE	从问题发现做到稳定生产，再把反馈送回产品	同时承担客户结果、工程交付和产品学习

这张表是责任模型，不是行业统一职级标准。不同公司的“解决方案工程师”可能承担完整闭环，某些名为 FDE 的岗位也可能只做实施。

本篇只保留两个最小判据：

• 只驻场但不直接承担关键生产代码，不是完整 FDE 。
• 只完成一次性交付但没有产品回流，也不是完整 FDE 。

至于长期驻场是否会退化成外包、客户需求与产品路线冲突时谁做决定，这些需要结合组织结构和商业模式判断，系列后文再展开。

上海和北京写进政策，证明国内开始采纳这种模式

国内政策不是 FDE 的定义来源，但它能证明这种组织模式已从企业岗位进入产业执行语言。

上海《支持先进制造业转型升级三年行动方案（ 2026 — 2028 年）》在“深化数智转型”中明确提出培育 FDE 队伍，用于支持企业应用大模型、打造行业模型和工业智能体。这里强调的是制造业数智化场景。

北京 2026 年发布的智能体产业措施写得更接近本文的闭环：支持模型服务商和行业企业通过 FDE 等模式加速智能体落地，通过“驻场共创、持续迭代”反哺智能体能力提升。

两地政策可以支持一个谨慎结论： FDE 已被国内正式政策采用，作为连接模型能力与行业场景的一种落地机制。它们不能证明 FDE 已形成统一职业标准，也不能推出岗位数量、薪资或个人补贴必然增长。上海的培养、赛事和职称机制，以及各地成熟度差异，将在系列下一篇单独展开。

开发者为什么要关注：真 FDE 最小判断卡

FDE 对开发者的价值，不是多学一个岗位缩写，而是提供了一套新的工程完整性标准。过去做 AI Demo ，重点可能是模型能否回答；进入 FDE 语境，问题会继续向后延伸：能否进入业务流程，能否稳定运行，能否衡量结果，能否让一次项目改善下一次交付。

判断一个岗位、项目或作品集是否具备完整 FDE 特征，可以先问四个问题：

• 是否直接接触真实用户、业务流程和约束；
• 是否亲自编写或评审关键生产代码；
• 是否对部署、可靠性和上线后的运行负责，并用生产采用或业务结果衡量成功；
• 是否把现场经验沉淀回通用产品、工具或方法。

下面这份 YAML 可以直接用于筛选 JD 、复盘项目或规划作品集。它把“稳定运行”进一步拆成生产责任与结果指标；每项都要求写证据，避免只给自己打勾：

fde_minimum_test:
  customer_context:
    pass: false
    evidence: "访谈、流程图、现场约束或需求诊断记录"
  production_code:
    pass: false
    evidence: "本人负责的接口、前后端、数据或基础设施变更"
  production_ownership:
    pass: false
    evidence: "评测、监控、降级、回滚和人工接管方案"
  measurable_outcome:
    pass: false
    evidence: "采用率、任务完成率、成本、延迟或业务指标"
  product_feedback_loop:
    pass: false
    evidence: "回流到组件、评测集、工具、手册或产品路线的记录"
  decision:
    complete_fde_loop_requires:
      - customer_context
      - production_code
      - production_ownership
      - measurable_outcome
      - product_feedback_loop

这份清单同样适合团队招聘。真正应该问的不是“候选人是否做过驻场”，而是他能否说明一个现场问题怎样进入生产、怎样被衡量，又怎样改变后续产品。

事实边界

本文依据的是 2026 年 8 月 5 日仍可公开访问的公司官方岗位、官方工程文档和政府政策。需要保留四个边界：

• FDE 尚无跨公司的统一职责标准，本文定义是对多份官方材料共同部分的归纳；
• 公司岗位页面会更新，具体职责、地点和要求以申请时页面为准；
• 本文没有采用招聘聚合站的岗位数量或薪资统计，也没有采用社区收入、融资和培训效果说法；
• 政策采纳只能证明模式获得正式关注，不能证明个人培训、职称、补贴或就业结果。

如果把 FDE 压缩成一句话，它不是“到客户那里写代码”，而是把现场问题变成生产系统，再把生产经验变成产品能力。

这也是开发者真正值得关注的变化： AI 工程的交付终点，正从“模型能跑”向“系统能用、结果可量、经验可复用”移动。

公开来源

以下页面均在 2026 年 8 月 5 日重新打开核验。

1. OpenAI ： Forward Deployed Engineer (FDE) - SF
       核验客户交付与核心平台开发的交叉定位、端到端生产部署、生产级代码和产品反馈职责。

2. Scale AI ： Forward Deployed Engineer, GenAI
       核验每日客户协作、全栈构建与部署、云和数据基础设施要求，以及对产品路线的影响。

3. Scale AI ： Director, Forward Deployed Engineering
       核验生产可靠性、安全、可观测性和评测责任，以及现场经验向可复用平台能力的沉淀。

4. Palantir ： Architecture Center Overview
       核验 Forward Deployed Engineering 作为产品开发方法，以及现场反馈与核心工程协同。

5. 上海市人民政府：《上海市支持先进制造业转型升级三年行动方案（ 2026 — 2028 年）》
       核验上海正式提出培育 FDE 队伍及其制造业数智转型语境。

6. 北京市人民政府：《北京市关于加快智能体引领发展的若干措施》
       核验通过 FDE 、驻场共创和持续迭代加速应用落地并反哺智能体能力的政策表述。

JOTO 企业落地观察

• 对企业部署意味着：FDE 模式要求企业将AI落地视为端到端工程闭环，而非单次交付。当客户现场问题无法被通用模型覆盖时，企业必须建立能同时承担生产运维与产品反馈的复合型角色，否则将陷入重复定制、不可复用的交付陷阱。
• 对智能体工程而言，FDE 的五步闭环（尤其‘反馈回流’）直指当前行业痛点——大量智能体项目止步于POC，缺乏将现场约束沉淀为可复用组件的机制。企业若希望智能体具备规模化复制能力，就必须在工程流程中强制嵌入知识回流环节。
• 对RAG知识工程来说，FDE所强调的‘现场上下文获取’揭示了一个关键现实：企业知识不仅存在于文档库，更分散在系统字段逻辑、人工审批链路和隐性业务规则中。单纯依赖文档切片的RAG难以应对这类非结构化上下文，需结合FDE式的实地建模。
• 对AI安全治理而言，FDE承担的‘生产运行责任’意味着安全边界必须从模型层下沉至业务流层。例如退款审批链路中的风控校验、权限穿透检查等，无法由通用安全策略覆盖，需FDE在集成阶段就嵌入治理逻辑并持续验证。