# 第 3 章 AI 时代的 FDE：变与不变

## 本章目标

- **O1** 能够按同一组维度比较“模型能力变化”“交付责任不变”和“评估反馈闭环”（产物：AI 时代职责变化表）
  - 证据: AI 时代职责变化表用相同维度填写“模型能力变化”“交付责任不变”和“评估反馈闭环”三列
- **O2** 能够构造AI 时代职责变化表，让每列使用相同问题和证据口径（产物：AI 时代职责变化表）
  - 证据: AI 时代职责变化表每列至少包含一条可复核证据和一项未决问题
- **O3** 能够区分 AI 改变的交付杠杆与仍需人工承担的结果责任（产物：AI 时代职责变化表）
  - 证据: 产物分别记录一项能力变化、一项责任连续性和验证方法

## 学习路径

- **初学者**: 本章迁移任务是：能够区分 AI 改变的交付杠杆与仍需人工承担的结果责任。先按图中的“并列比较”关系完成AI 时代职责变化表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够区分 AI 改变的交付杠杆与仍需人工承担的结果责任。提交AI 时代职责变化表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: AI 时代职责变化表
- **图解类型**: change-continuity
- **关系语义**: 三列是并行比较关系，共用评价维度；列之间没有先后顺序，也不代表成熟度高低。
- **核心概念**: 模型能力变化 · 交付责任不变 · 评估反馈闭环

![第 3 章AI 时代职责变化表教学图](/learning/diagrams/zh/chapter-03.svg)

横向读取AI 时代职责变化表的共同维度，比较差异后再作选择，不按列序推断因果。

图把“模型能力变化”“交付责任不变”“评估反馈闭环”放在三个并列列中，共用横向评价线。三列没有流程先后或高低关系；学习者应逐行比较相同维度，再记录选择依据与保留条件。

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

## 课程讲解

第 2 章结尾留下了一个问题：当编码 agent 让代码的生产成本急剧下降，FDE 与相邻角色的边界会怎样移动？哪些部分会被放大，哪些会被侵蚀？

本章正面回答它。先给结论：代码在变便宜，但定义这个角色的三件事没有变便宜——数据集成、客户理解、结果问责。变的是杠杆，不变的是支点。

### 3.1 一个"脏秘密"：最热的岗位，没有统一定义

Sierra Agent Engineering 负责人 Meurer（2016-2021 年任 Palantir FDE）在一场公开演讲里讲过行业对这个角色的坦率判断，大意是：关于 FDE 有一个"脏秘密"——这个岗位其实"并不存在"（it doesn't exist），但与此同时，它又是"AI 领域最热的岗位"（the hottest job in AI）。

注意：这是 Meurer 的单一权威观点，不是行业共识，但这个看似矛盾的表述值得琢磨：所谓"不存在"，指的是没有一个稳定、统一、可照抄的岗位定义——不同公司挂出 FDE 头衔的岗位，实际工作可能相差很远；所谓"最热"，指的是市场对这类人的需求在真实而快速地增长。

为什么一个"不存在"的岗位会"最热"？编码 agent 的普及给出了半个答案：当"会写代码"本身不再稀缺，各公司忽然发现自己真正缺的，是能把模型能力接进客户真实业务、并对结果负责的工程师。于是各式各样的岗位描述被写了出来，有的叫 FDE，有的叫别的名字——这正是 3.4 节要讨论的"角色收敛"。

另外半个答案，藏在"什么没有变便宜"里。

### 3.2 没变便宜的三件事：数据、理解、问责

编码 agent 让"把想法变成能跑的代码"这个动作的成本坍缩了。连带贬值的是：语法与框架细节的熟练度、代码产出的速度、以及一个演示级原型所能证明的东西——当任何人都能在几小时内生成一个像样的 PoC，"能做个 demo"就不再是职业护城河。第 2 章划出的边界随之移动：演示与生产之间的鸿沟没有变窄，反而因为"演示更容易了"而显得更宽。

而客户现场的三件事，一件都没有变便宜：

| 没变便宜的事 | 为什么 agent 帮不上 | 对应本书 |
|---|---|---|
| 数据集成 | 客户数据分散、异构、质量堪忧（见 1.2 节第②层），这是组织现实，不是编码问题；模型再强，无米下锅，而且 AI 系统对数据质量更敏感 | 第四部分（蓝图与架构） |
| 客户理解 | 真问题在哪、谁说了算、上线后谁在用、错了谁买单——这些上下文长在客户现场的组织里，不长在模型的权重里 | 第九部分（客户交付） |
| 结果问责 | 客户为结果付钱，总得有一个人对结果负责；agent 可以生成代码，不能替你背书 | 贯穿全书 |

第三件事值得单独强调。Meurer 在同一场演讲里给出了她眼中这个行业唯一的连续性（continuity point）：每一个 FDE 都对客户负责（accountable to the customer）。技术栈在换、工具在换、头衔也在换，唯独"现场有一个人对客户结果负责"这件事，从 Palantir 时代贯穿到 AI 时代没有变过。（同样是单一权威观点，本章按此惯例逐处标注。）

这解释了本教材的一条主线为什么成立：AI 是杠杆，你是支点。杠杆越长，越需要稳定的支点——代码生成能力越强，数据集成、客户理解、结果问责这三件事的相对价值就越高。FDE 的核心价值不在杠杆上，在支点上。

### 3.3 交付半径的扩张：从原型到端到端

"没变便宜的三件事"讲的是不变的部分。变的部分同样深刻：FDE 的交付半径被 coding agent 大幅拉长了。

传统模式下，FDE 的时间被"把方案一行行写出来"大量占据，一个人能覆盖的交付面是有限的。Meurer 对新一代 FDE 工作方式的描述是：不只是见客户、不只是做原型，而是用 coding agent 真正构建端到端的方案（actually build end-to-end solutions with coding agents）。

这句话与第 1 章的四要素严丝合缝：端到端拥有（职责五）过去是意愿问题，现在同时是可行性问题——一个 FDE 加上 coding agent，能覆盖过去一个小团队才能覆盖的 discovery→scoping→设计→构建→上线全流程。第 1 章说过，AI 辅助编程让一个 FDE 顶过去一个小团队；本节补上它的另一面：能力扩张的同时，问责范围也在扩张。你构建得越多，要验收、要评估、要运维的就越多。

而这里恰好埋着 AI 时代 FDE 最重要的一处新功课：AI 系统的输出是概率性的，传统软件测试那套确定性断言接不住它。构建变便宜了，验证没有变便宜——怎么让模型输出可度量、可回归，是第七部分"评估体系"（第 21-23 章）整整一个部分的主题；怎么把构建出来的系统在客户环境里推到生产、让客户真正用起来，是第九部分"客户交付"（第 27-29 章）的主题。本章先立框架，方法论在后面等你。

用一个教学场景检查这件事：agent 提前完成了工单助手的接口，工程师因此空出半天。如果他马上再接三个功能，发布时仍无人知道误派工单会落到谁手里，交付半径只是表面扩大。更有价值的安排，是带着失败样本找值班主管核对分类边界，让实际操作者试用，并约定误派后的接管人。回来后，把争议样本写进评估集，把接管路径写进交付记录。代码节省的时间于是变成了可核验的质量与清楚的责任，而非更多等待验收的功能。这里也有边界：工程师可以组织证据、提出建议，但不能因为工具替他写完代码，就替客户接受新的风险或业务承诺。

把本章到目前为止的判断收进一张表：

| | 变（被放大） | 不变（被凸显） |
|---|---|---|
| 代码 | 生成成本坍缩，交付半径扩张 | 在客户基础设施上跑生产流量的要求 |
| 原型 | 几小时可得，证明力下降 | demo 能跑 ≠ 系统能用的鸿沟 |
| 验证 | 需要新能力（评估体系） | 上线前必须有人签字负责 |
| 角色 | 头衔多样化、边界移动 | 数据集成、客户理解、结果问责 |

### 3.4 角色收敛：一个趋势，两种读法

现在回到 3.1 埋下的问题：为什么各公司的岗位描述五花八门？

Meurer 的判断是：所有相关角色都在向 FDE 这个方向收敛——产品工程、agent 工程、AI 工程、解决方案工程、客户工程（product engineering, agent engineering, AI engineering, solutions engineering, and customer engineering），"一切都在朝这个方向走"（everything is trending that way）。她本人在 2024 年 7 月提出 agent engineering 这个术语时，就把它定位为 FDE 工作的一个子集。再次强调：收敛论是她的单一权威观点，并非行业共识——第 2 章已经看到，业界至少在名义上仍在细分这些角色（OpenAI 内部就把 SA 与 FDE 明确分成两个岗位）。

对这句话可以有两种读法，两种都对你有用：

读法一（机会）：你练的能力是通用的。如果趋势成立，本书教的东西——端到端交付、数据集成、评估、客户协作——将横跨五类头衔的招聘需求。你的职业面不是变窄了，是变宽了。

读法二（清醒）：头衔在通胀，判断要回到判据。"趋势收敛"与"岗位通胀"是一枚硬币的两面：当 FDE 成了热词，就会有越来越多名片印上它，而其中的实际工作可能仍是售前、支持或咨询（见第 1 章三问：写不写客户生产代码？拥不拥有端到端过程？对不对客户结果负责？）。评估一个"机会"或一个"岗位"时，永远不要看头衔，要看三问的答案。

这也是本教材反复出现的动作：外部声音（哪怕是权威的）提供视角，判断永远回到第一性判据。Meurer 的演讲是本书引用的重要视角之一，但它没有豁免权。

一次交接还要验证接收者能否独立操作：让客户负责人根据记录复现异常、找到接管入口，并说明何时停止自动处理。如果只能由开发者口头解释，省下的编码时间尚未变成可持续交付能力。这一步的产出是可复核的接管记录，而不是更多功能。

### 【练习】给自己的岗位做一次"变与不变"审计

题目：用 3.2 节的框架审视你当前的工作——列出过去一年里因为编码 agent 变便宜的三件事，再列出没变便宜的三件事。然后回答：你的时间分配，正在向哪一列移动？

引导：重点检查一个危险信号——如果你省下来的时间全部用于"生成更多代码"，而没有投向数据集成、客户理解或结果验收中的任何一项，说明杠杆变长了、支点没跟上。这正是第 2 章说的角色漂移在 AI 时代的新形态。

参考方向（供讲师参考）：健康的迁移方向是"构建时间占比下降，评估与客户协作时间占比上升"；不健康的方向是"单位时间产出代码量上升，但验收与问责方式不变"。前者是交付半径扩张，后者是熵增螺旋的入口（第三部分与第六部分会分别展开）。

### 3.5 本书路线图：认清角色之后

第一部分到此完成了一个闭环：第 1 章定义角色（你是谁，为谁负责），第 2 章划清边界（你不是谁），本章看清趋势（什么在变、什么不变、怎么判断）。贯穿三章的主线只有一句话：从"写代码的人"，转变为"为客户结果做决策的人"。

认清角色之后，下一部分回到你的日常：怎么和 AI 搭档干活。第二部分（第 4-6 章）完成认知重塑——AI 编码是什么、不是什么；为什么说它是"超级实习生"而你是决策者；以及必须警惕的三个陷阱。之后的地图是：第三部分核心方法论（六步工作法）、第四部分蓝图与架构、第五部分技能体系、第六部分流程约束、第七部分评估体系、第八部分质量与风险治理、第九部分客户交付、第十与第十一部分团队协作与持续进化、第十二部分实战演练。

你会发现整本书的结构，就是本章那张"变与不变"表的展开：为"变"的部分提供杠杆（方法论、技能、流程），为"不变"的部分提供支点（评估、质量、客户交付、问责）。

---

> 本章业界事实的来源说明：FDE "脏秘密"论（"it doesn't exist"与"the hottest job in AI"）、"每一个 FDE 都对客户负责"的连续性判断、"用 coding agent 构建端到端方案"的工作方式描述、以及五类工程角色向 FDE 收敛的趋势判断，均出自 Meurer（Sierra Agent Engineering 负责人，2016-2021 年任 Palantir FDE）的公开演讲；她于 2024 年 7 月提出 agent engineering 术语并定位其为 FDE 子集，出自其同期公开论述。以上观点均为单一权威观点、非行业共识，正文已逐处标注。OpenAI 内部 SA 与 FDE 分为两个岗位的事实出自 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访（见第 1 章来源说明）。本章未引用额外行业统计；未标明来源的场景和时间分配均为教学假设。

---

> 第一部分完成。你已经知道自己是谁（第 1 章）、不是谁（第 2 章）、以及在 AI 时代什么会变、什么不变（第 3 章）。现在，让我们进入第二部分：认知重塑——回到你的日常，看清你与 AI 搭档的真实关系：AI 编码是什么、不是什么，为什么它是超级实习生，以及你必须警惕的三个陷阱。

---

## 独立练习

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

把工单交付拆为访谈、脚手架、规则确认、评估、上线批准五项，标明AI可辅助的动作和必须由人确认的决定。

<!-- chapter-artifact-requirement -->
### 本章必交产物：AI 时代职责变化表

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

- O1: AI 时代职责变化表用相同维度填写“模型能力变化”“交付责任不变”和“评估反馈闭环”三列
- O2: AI 时代职责变化表每列至少包含一条可复核证据和一项未决问题
- O3: 产物分别记录一项能力变化、一项责任连续性和验证方法

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

## 参考反馈

AI可整理获授权访谈、草拟代码和评估脚本；人仍需确认业务规则、授权范围、评估结论及上线决定。记录节省时间的实测窗口和返工成本，不从代码生成速度推断客户成效。同时注明比较的任务范围、样本数量和观察日期，使另一位评审者可以判断口径是否一致。

### 自评与下一步

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

</details>

## 来源与边界

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

- [Forward Deployed Engineer 旧金山职位说明](https://openai.com/careers/forward-deployed-engineer-(fde)-sf-san-francisco/) — OpenAI, 2026-09-28. 该岗位涵盖发现、技术定界、系统设计、构建、上线、采用和现场反馈；这是 OpenAI 的岗位说明，不是行业统一标准。
- [FDE 的起源、角色区分与 OpenAI 工作阶段访谈](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers) — The Pragmatic Engineer, 2026-09-17. 该访谈报道 FDE 起源脉络、OpenAI 的 SA/FDE 区分、客户项目三阶段及团队知识分享节奏；属于二手访谈材料，不代表行业通用标准。
- [Transformers 文本生成策略](https://huggingface.co/docs/transformers/generation_strategies) — Hugging Face, 2026-09-17. 贪心、采样和束搜索使用不同的下一 token 选择策略，解码选择会影响输出。
- [FDE 的脏秘密](https://www.ai.engineer/talks/Byv311hdoHE-dirty-secret-forward-deployed-engineering) — AI Engineer, 2026-09-17. Natalie Meurer 以个人观点说明 FDE 名称缺少统一职责边界，但其连续性在于对客户结果负责；演讲同时回顾她在 Palantir 与 Sierra 的相关经历。