# 第 1 章 FDE 是什么，不是什么

## 本章目标

- **O1** 能够区分“客户结果责任”与“端到端交付”的范围、责任和交接点（产物：FDE 角色边界表）
  - 证据: FDE 角色边界表中标明“客户结果责任”和“端到端交付”各自的范围与负责人
- **O2** 能够构造FDE 角色边界表，明确纳入、排除与人工验收条件（产物：FDE 角色边界表）
  - 证据: FDE 角色边界表中列出至少一项排除项、一个交接点和一个验收条件
- **O3** 能够用生产代码、端到端责任和客户结果三问判断岗位是否属于 FDE（产物：FDE 角色边界表）
  - 证据: 产物记录对一个真实岗位描述的三问判定与引用依据

## 学习路径

- **初学者**: 本章迁移任务是：能够用生产代码、端到端责任和客户结果三问判断岗位是否属于 FDE。先按图中的“边界”关系完成FDE 角色边界表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够用生产代码、端到端责任和客户结果三问判断岗位是否属于 FDE。提交FDE 角色边界表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: FDE 角色边界表
- **图解类型**: role-boundary
- **关系语义**: 虚线框表示责任边界，框内三项通过交接点相连，越界或证据不足时必须停止。
- **核心概念**: 客户结果责任 · 端到端交付 · 生产采用

![第 1 章FDE 角色边界表教学图](/learning/diagrams/zh/chapter-01.svg)

用边界、交接点和验收条件检验FDE 角色边界表，而不是把三项误当成同一责任。

图用虚线外框标出FDE 角色边界表的责任范围，三个卡片分别表示“客户结果责任”“端到端交付”“生产采用”。箭头只表示已定义的交接，不表示三者可以互相替代；越过外框或缺少验收证据时应停止并升级。

> **公开课程改编版。**正文依据内部教材整理，保留概念、流程与示范。案例规模、用时、提升比例及目标阈值均用于教学，不是本站交付成果或通用标准。工具、平台与技能描述需在实际环境核验。提示词不能授予权限；重试次数不自动触发恢复；恢复须先保护工作并确认目标、共享状态和外部数据影响。

## 课程讲解

### 1.1 一个典型场景：星期一早上，你在客户那里

星期一早上九点，你不在自己公司的工位上。你在客户的数据中心会议室里，面前是客户运营团队负责人，白板上是他昨天画的三条业务流水线。他说：每月对账要占用三名分析师整整四天，他想用 AI 把这四天压到半天。他没有说"请给我们做个演示"，他说的是——"什么时候能用起来？"

这个场景里，你的身份是什么？

如果按照传统的岗位分工，这个问题会变得很含糊：你像售前，因为你在客户面前；你像开发，因为你要写代码；你像项目经理，因为你要回答"什么时候"。而业界对这类场景里的人，已经有了明确的角色定义——Forward Deployed Engineer（FDE，前沿部署工程师）。本教材的中文表述"AI 前沿交付工程师（AI Forward Deployed Engineer · AFDE）"，指的就是这个角色在 AI 时代的完整形态。

把它拆开到第一性原理，FDE 的定义有四个不可分割的要素：

1. 嵌入客户现场（Forward Deployed）。"Forward"不是职级，是方位——你被部署到离客户最近的前线，而不是坐镇后方。你的上下文不是公司内部的排期表，而是客户现场的真实约束：数据长什么样、流程卡在哪里、谁说了算。
2. 在客户基础设施上写生产代码。不是在自己公司的仓库里写个 demo，而是把代码部署到客户的私有云、内网环境甚至隔离网络里，跑在真实业务流量上，出错要真实买单。
3. 端到端拥有全过程。OpenAI 的 FDE 招聘描述把这个范围写得最直白：工程师需要 "own discovery, technical scoping, system design, build, and production rollout"——从发现问题、界定范围、系统设计、动手构建，一直到生产上线，全程归你所有。
4. 对客户结果（outcome）负责。注意，不是对工时负责，不是对功能清单负责，甚至不是对"代码能跑"负责，而是对客户的业务结果负责。回到开场场景：你的交付物不是"一个对账脚本"，而是"分析师每月只花半天"。

这四条加在一起，才是 FDE。缺任何一条，角色就会退化成别的什么东西——这正是 1.4 节要展开的内容。

在此之前，先回答一个自然的问题：这个角色是哪来的？为什么 2024 年之后突然遍地开花？

### 1.2 起源与演变：从 Palantir Delta 到 AI 公司标配

FDE 不是 AI 时代的新发明。这个角色起源于 2010 年代 Palantir 的 Delta 团队——一组被"向前部署"到客户现场、在客户环境里交付软件的工程师。据 Palantir 官方博客记述，早在 2016 年之前，这家公司里 FDE（当时的头衔是 Forward Deployed Software Engineer）的数量就一度超过传统开发工程师：公司的大多数工程师并不坐在总部写产品，而是坐在客户那里交付结果。

角色是怎么样长成今天这个形状的？不是一次设计出来的，而是四层职责逐层累积的结果——每一层都建立在上一层之上，而不是替代它：

| 累积层 | 回答的问题 | 典型工作 |
|--------|-----------|----------|
| ① 现场工程纪律 | 代码怎么在客户环境里活下来 | 部署、权限、网络、运维——DevOps 能力是入场券 |
| ② 数据集成 | 客户的数据怎么接进来 | 打通分散、异构、质量堪忧的客户数据源 |
| ③ 定制方案 | 产品覆盖不到的地方怎么办 | 在产品能力与客户需求之间的缝隙里构建定制系统 |
| ④ 客户赋能 | 你走了之后客户怎么继续跑 | 培训客户团队、沉淀可复用资产、移交运营 |

这四层的累积解释了 FDE 能力的"洋葱结构"：外面看是写代码的，往里一层是搞集成的，再往里是做方案的，最内核是让客户自己能跑起来的。本书后续部分的方法论——蓝图、验收、约束、评估——都会一层层挂在这四层上。

那为什么 2024 年之后，这个"古老"的角色突然成了行业热词？因为 AI 公司撞上了同一堵墙：模型能力与客户工作流之间隔着最后一公里。模型在评测集里已经很强大，但把它接进一家公司的真实业务——数据在哪、谁来用、错了怎么办、用起来之后衡量什么——这些问题的答案全在客户现场，不在实验室。于是 OpenAI、Anthropic、Ramp 等公司从 2024 年起相继把 FDE 设为规模化岗位（见 OpenAI、Anthropic 的公开招聘描述）。区别于 Palantir 时代的分析平台，这一代 FDE 部署的是 AI 系统，也因此对评估、风险与落地度量提出了更高的要求——这正是本书要把"业界 FDE 基线"与"AI 辅助工程方法论"合起来讲的原因。

### 1.3 五项核心职责

角色定义讲的是"你是谁"，职责讲的是"你每天在干什么"。综合业界对 FDE 职责的公开描述（以 Palantir 对 Forward Deployed Software Engineer 的定义最为完整），可以归纳为五项核心职责：

| # | 职责 | 含义 | 典型产物 |
|---|------|------|----------|
| 1 | 架构决策 | 在客户约束下决定系统形态 | 部署方案、集成架构、架构决策记录（ADR） |
| 2 | 用数据与 AI 加速客户运营 | 把模型能力接进客户日常业务 | 数据管线、AI 工作流、自动化流程 |
| 3 | 构建定制应用 | 填补产品与需求之间的缝隙 | 定制应用、集成中间件 |
| 4 | 干系人分层对接 | 让技术、业务、高管三种语言互通 | 分层沟通节奏、面向高管的 readout |
| 5 | 端到端拥有高风险项目 | 从发现到上线全程背责 | 上线的生产系统与采用度数据 |

逐项展开：

职责一：架构决策。FDE 经常要在没有"公司标准答案"的环境里做决策——客户的合规要求、遗留系统、网络拓扑各不相同，总部产品手册覆盖不了。你是现场唯一有技术全貌的人，部署架构怎么定、数据边界在哪、哪个组件买哪个组件建，这些决策的质量直接决定项目成败。本书第四部分"蓝图与架构"训练的正是这项职责。

职责二：用数据与 AI 加速客户运营。这是 AI 时代 FDE 的主战场。它不是"给客户训练个模型"，而是把模型能力嵌进客户的日常运营流：数据从哪来、经过什么加工、模型在哪个环节介入、人怎么复核。第七部分"评估体系"与第九部分"客户交付"合起来覆盖这项职责。

职责三：构建定制应用。当自家产品覆盖不到客户的场景时，FDE 用工程手段补齐——写定制应用、做系统集成。这是"Forward Deployed"与"Solution"的分野之一：解决方案工程师（SA）通常演示产品能力，FDE 则在客户基础设施上写生产代码补上缺口。AI 时代这项职责的杠杆被急剧放大：AI 辅助编程可以降低部分实现成本，但实际幅度必须由具体项目证据验证，这正是本书全部方法论的用武之地。

职责四：干系人分层对接。客户不是一个人，是一组利益与语言都不同的人：技术团队谈接口与安全，业务方谈效率与成本，高管谈战略与风险。FDE 是现场唯一的"协议转换器"——对上能把工程进展翻译成业务价值，对下能把业务诉求翻译成系统约束。对接错层（比如对高管讲技术细节、对工程师讲战略愿景）是现场交付失败的常见根因，第二十八章将专门展开。

职责五：端到端拥有高风险项目。注意"拥有"（own）这个词——不是参与，是拥有。客户现场的项目往往时间紧、模糊度高、失败可见度高，FDE 对它负全责：发现真问题、界定范围、设计方案、构建、上线、衡量采用。职责一到四是能力项，职责五是问责项——它是 FDE 与"现场帮忙的专家"之间的最终分界线。

### 1.4 FDE 不是什么

定义一个角色，划清"不是什么"往往比"是什么"更有效。三个最常被混淆的相邻角色：

| 相邻角色 | 它的定义 | 与 FDE 的分界 |
|----------|----------|---------------|
| 售前 / SA | 展示产品能力，支持销售成交 | SA 的战场是演示环境，不写客户生产代码；demo 能跑和系统能用之间隔着一条鸿沟 |
| 技术支持 | 响应工单，解决产品使用问题 | 支持对工单负责，FDE 对结果负责；支持回答"怎么用"，FDE 决定"该不该这么用" |
| 传统咨询 | 出分析、出报告、出建议 | 咨询的交付物是文档，FDE 的交付物是跑在客户基础设施上的生产系统；业界对二者的经典区分是：咨询团队可以多年期、多层梯队地推进，FDE 小队直达现场、以生产软件兑现结果 |

这三条边界背后是同一个判断标准，回到 1.1 节的四要素：写不写客户生产代码、拥不拥有端到端过程、对不对客户结果负责。三个问题里只要有一个答案是"否"，你就不是在做 FDE 的工作——无论名片上印的是什么头衔。

反过来说，这个判断标准也是自查工具。当你在一个客户项目里感到"哪里不对劲"——比如你发现自己在反复做演示、在等别人排期、在为"功能已交付"辩护而客户业务没变化——先别怀疑方法论，先对照角色：你可能正在用 FDE 的名义，做售前、支持或咨询的工作。

【自检清单】FDE 角色自查

逐条勾选，任何一条不成立，都值得停下来想一想：

- [ ] 我能说清当前项目的客户结果（outcome）是什么，以及怎么衡量它吗？
- [ ] 我写的代码部署在客户基础设施上、跑在真实业务流量上吗？
- [ ] 从发现问题到生产上线，中间每一环我都有决策权（或明确的升级路径）吗？
- [ ] 我在做架构决策，还是只在执行别人定好的方案？
- [ ] 客户的技术团队、业务方、高管，我都有对接节奏吗？
- [ ] 我交付的是生产系统，还是演示、报告或建议？
- [ ] 项目出了问题，客户第一个找的人是我吗？
- [ ] 我能区分"功能已上线"和"客户在用、业务在受益"这两个概念吗？

如果大部分条目你都答"是"，你已经站在 FDE 的位置上了。接下来的问题变成：这个角色和其他相邻角色到底怎么划界（第 2 章），以及在 AI 让代码变便宜的时代，它的核心价值将向何处迁移（第 3 章）。

### 【练习】用四要素检验一个真实角色

题目：任选一个你熟悉的岗位（可以是你的现职，也可以是合作过的角色——售前工程师、实施顾问、驻场开发、解决方案架构师……），用 1.1 节的四要素逐条检验：嵌入客户现场？在客户基础设施上写生产代码？端到端拥有全过程？对客户结果负责？给出每一项的"是/否/部分"判断与理由。

引导：可以重点观察两个"灰色地带"——① 写了代码但跑在演示环境里（有代码、无生产）；② 端到端参与了但结果由别人兜底（有过程、无问责）。这两个地带恰好是 FDE 与售前、支持角色最容易混淆的地方。

参考方向（供讲师参考）：四要素全"是"的是完整 FDE；"写生产代码 + 不拥有过程"常见于驻场外包开发；"嵌入现场 + 不写代码"常见于售前与实施顾问；"对结果负责 + 不在现场"则更接近远程交付的产品工程师。检验的价值不在分类本身，而在看清差距：从当前角色到 FDE，缺的是哪几要素，补上它们的代价与收益是什么。

---

> 本章业界事实的来源说明：Palantir 对 Forward Deployed Software Engineer 的角色定义、职责描述及"2016 年前 FDE 数量一度超过传统工程师"的记述，出自 Palantir 官方博客；OpenAI FDE 岗位 "own discovery, technical scoping, system design, build, and production rollout" 的表述出自其公开招聘描述；2024-2026 年 OpenAI、Anthropic、Ramp 等公司采纳 FDE 角色的行业脉络，参见 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访及相关公司招聘页。本章未引用上述来源之外的数字。

---

## 独立练习

使用虚构或已获授权的脱敏材料，先独立作答，再查看参考。将产物保存为 `chapter-01.md`，写上版本、决定、证据和缺项。

为虚构的清河设备工单项目写五条FDE责任，分别标明客户、FDE、产品和运维的决定权；拒绝一个超出授权的要求。

<!-- chapter-artifact-requirement -->
### 本章必交产物：FDE 角色边界表

以下证据必须出现在本次独立练习的提交物中；正文原有问题用于提供内容，不能替代这些验收项。

- O1: FDE 角色边界表中标明“客户结果责任”和“端到端交付”各自的范围与负责人
- O2: FDE 角色边界表中列出至少一项排除项、一个交接点和一个验收条件
- O3: 产物记录对一个真实岗位描述的三问判定与引用依据

<details>
<summary>查看参考反馈（先独立作答）</summary>

## 参考反馈

参考：FDE负责把分类问题转成可验证方案、组织实现和评估、准备接管。客户确认业务规则与数据权限，运维确认生产变更。客户要求上传原始工单到个人模型账户时，先暂停并确认授权，不能因为演示成功就直接上线。

### 自评与下一步

对照本章目标检查：决定是否明确，依据是否能复现，未知项是否如实记录。参考给出一种判断方式，不是唯一答案；若不同结论能提供同等证据，可请同伴复核。缺少证据的部分记未完成，再回到对应步骤补充。

</details>

## 来源与边界

登记来源只支持本章涉及的外部事实；FDE 角色边界表、示例数字和练习情境属于课程内部教学设计，必须在实际项目中重新验证。

- [Forward Deployed Engineer 旧金山职位说明](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. 该岗位涵盖发现、技术定界、系统设计、构建、上线、采用和现场反馈；这是 OpenAI 的岗位说明，不是行业统一标准。
- [Palantir：Dev 与 Delta 工程角色](https://blog.palantir.com/dev-versus-delta-demystifying-engineering-roles-at-palantir-ad44c2a6e87) — Palantir, 2026-09-17. Palantir 将 Dev 描述为面向多客户构建单一能力，将 Delta/FDSE 描述为面向单一客户启用多种能力，并区分其与一次性咨询。
- [FDE 的起源、角色区分与 OpenAI 工作阶段访谈](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. 该访谈报道 FDE 起源脉络、OpenAI 的 SA/FDE 区分、客户项目三阶段及团队知识分享节奏；属于二手访谈材料，不代表行业通用标准。