# 第 2 章 与相邻角色的边界

## 本章目标

- **O1** 能够按同一组维度比较“FDE”“解决方案架构师”和“实施顾问”（产物：相邻角色责任矩阵）
  - 证据: 相邻角色责任矩阵用相同维度填写“FDE”“解决方案架构师”和“实施顾问”三列
- **O2** 能够构造相邻角色责任矩阵，让每列使用相同问题和证据口径（产物：相邻角色责任矩阵）
  - 证据: 相邻角色责任矩阵每列至少包含一条可复核证据和一项未决问题
- **O3** 能够用同一客户事件划分 FDE、解决方案架构师与实施顾问的责任（产物：相邻角色责任矩阵）
  - 证据: 产物用一个客户事件标出三个角色的责任、交接和空白

## 学习路径

- **初学者**: 本章迁移任务是：能够用同一客户事件划分 FDE、解决方案架构师与实施顾问的责任。先按图中的“并列比较”关系完成相邻角色责任矩阵的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够用同一客户事件划分 FDE、解决方案架构师与实施顾问的责任。提交相邻角色责任矩阵后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 相邻角色责任矩阵
- **图解类型**: role-comparison
- **关系语义**: 三列是并行比较关系，共用评价维度；列之间没有先后顺序，也不代表成熟度高低。
- **核心概念**: FDE · 解决方案架构师 · 实施顾问

![第 2 章相邻角色责任矩阵教学图](/learning/diagrams/zh/chapter-02.svg)

横向读取相邻角色责任矩阵的共同维度，比较差异后再作选择，不按列序推断因果。

图把“FDE”“解决方案架构师”“实施顾问”放在三个并列列中，共用横向评价线。三列没有流程先后或高低关系；学习者应逐行比较相同维度，再记录选择依据与保留条件。

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

## 课程讲解

### 2.1 边界为什么重要

第 1 章用四要素定义了 FDE：嵌入客户现场、在客户基础设施上写生产代码、端到端拥有全过程、对客户结果负责。但定义只是起点——真实职场里，你周围至少坐着三类"近亲"角色：咨询顾问、承担售前顾问工作的 Solutions Architect（SA）与 Solutions Engineer、内部 AI/agent 产品工程师。职称随公司变化；不能靠大小写把 solutions engineer 划成另一个必然只做内部产品的岗位。本章比较的是工作模式，2.3 节的 SA/FDE 事实限于所引 OpenAI 采访，2.4 节单独讨论内部产品工程。它们与 FDE 的日常动作高度相似：都见客户、都谈技术、都做方案、都可能碰代码。

相似正是危险所在。角色边界模糊时，最常见的结果不是"多干了别的角色的活"，而是用别的角色的工作方式做 FDE 的工作：用咨询的方式回应客户需求（先出一份厚方案），用售前的标准判断成败（演示通过即收工），用内部工程师的习惯写代码（只管能跑、不管客户谁能用起来）。每一种偏移单看都无伤大雅，累积起来就是把"对客户结果负责"悄悄换成"对交付动作负责"。

本章逐组划界。判据仍然是第 1 章那三个问题——写不写客户生产代码？拥不拥有端到端过程？对不对客户结果负责？——再加上 AI 时代特有的一问：现场经验有没有反哺自家产品？三组对照、一张总表、一次场景自检，本章之后，你对"我在做什么、不在做什么"应该不再有含糊。

### 2.2 FDE vs 咨询顾问：不做拼凑，快速组合

这是最容易被外界混淆的一组。Palantir 官方博客在 FDSE 问答里被直接问过 "Is an FDSE similar to a consultant?"，回答毫不客气："No, not really." 两者的分野可以浓缩成两句话：

- 咨询模式：以多年期的大型项目组合方式运作，把客户的场景拼凑（patchwork）成一系列长期工作，交付物很大程度是分析、方案与建议。
- FDE 模式：小队直达现场，依赖自家平台的现成能力（off-the-shelf capabilities）快速组合出可运行的系统，在几周而非几年的尺度上让客户看到结果。

两种模式没有高下，但它们是不同的工作。大型组织的多年期变革、跨部门利益调和、纯管理类诊断——这些是咨询的主场，FDE 不该以"迷你咨询团队"的姿态把它们签下来慢慢做。FDE 的价值恰恰在于用平台能力把"需要一支顾问军团的事"压缩成"几个工程师加一个平台的事"；当压缩不成立时，诚实地告诉客户这不是我们的战场，比签一份双方都会后悔的合同更专业。

对 FDE 个人来说，这条边界还有一个日常刻度：你的日历上是在排"访谈—写报告—评审"，还是在排"接数据—搭系统—上线"？前者滑向咨询，后者才是 Forward Deployed。当客户的问题适合用平台现成能力快速组合解决时，FDE 的回答永远是"我们直接做出来"，而不是"我们先研究三个月"。

### 2.3 FDE vs 售前/SA：顾问性演示 vs 生产代码

第二组近亲是 SA。以 OpenAI 为例（据 The Pragmatic Engineer 2025 年 8 月对其 FDE 负责人的采访），公司内部把 SA 与 FDE 明确分成两个角色，工作方式的差异一目了然：

| | SA（售前/解决方案工程师） | FDE |
|---|---|---|
| 角色性质 | 顾问性（advisory） | 交付性（delivery） |
| 数据 | 用匿名化数据构建 MVP/PoC | 接入客户真实数据 |
| 代码落点 | 几乎不在客户基础设施上写生产代码 | 直接在客户基础设施与工具链上写生产代码 |
| 模糊度 | 可挑选演示路径，模糊性可控 | 必须消化客户的全部现实，模糊性显著更高 |

注意"几乎不"这个词——SA 不是不写代码，而是代码落在演示环境与 PoC 里：用一份匿名化数据跑通一条最优路径，向客户证明"产品能力是真的"。这个工作有真实价值：没有 SA 的 PoC，很多合同根本不会存在。两者是接力关系，不是竞争关系：SA 用 PoC 赢得机会，FDE 把机会变成跑在客户生产环境里的系统。

接力的交接棒正是模糊性跃升的那一刻。演示环境里，数据是匿名化的、干净的、规模可控的；生产环境里，遗留系统、权限体系、数据质量、变更窗口、值班响应全都真实存在。SA 可以说"这个场景产品支持"，FDE 必须回答"在你们的环境里，它今天就能跑起来，出了问题有人修"。从前者到后者，隔着第 1 章说的那条鸿沟——demo 能跑和系统能用之间的鸿沟。

对个人的警示是：如果你名片上印着 FDE，但你的季度产出全部是演示、PoC 与技术方案文档，你实际在做 SA 的工作。反过来，这条边界也告诉你什么时候该把 SA 拉进来：客户还在选型比较、需要匿名数据上的快速验证时，那是 SA 的主场，FDE 越俎代庖反而昂贵。

### 2.4 FDE vs 内部 AI/Agent 产品工程师：反哺产品的双向通道

第三组近亲最微妙，因为日常动作可能高度重合：写 prompt、搭 agent、做评估、接数据、调集成——内部 AI/agent 产品工程师与 FDE 干的活，从代码上看几乎无法区分。分界不在"做什么"，而在为谁做、价值沉淀到哪：

- 内部 AI/agent 产品工程模式：主要服务自家公司。系统建在自家基础设施上，价值沉淀进自家产品与代码库，客户（如果有）隔着 API 使用成果。
- FDE：主要服务客户现场。系统建在客户基础设施上，价值直接体现在客户的业务结果上——但同时保持一条反哺通道：把现场验证过的工作模式沉淀（codify）成可复用的工具、playbook 与模板，回流到自家产品和模型团队。OpenAI 对 FDE 的职责描述里明确包含把可复用模式 codify 化这一条（见第 1 章来源说明所引招聘描述）。

这条双向通道是 FDE 区别于"高级驻场外包"的本质。只服务客户、不沉淀反哺，你会退化成一个昂贵的现场外包团队，公司层面不可持续；只沉淀资产、不进现场，你就不再是 FDE，而是产品工程师。健康的 FDE 实践始终同时朝两个方向输出：向客户输出生产系统与业务结果，向公司输出经现场验证的模式与积木。本书第九部分（第 27-29 章）将把这条"知识外循环"展开成具体机制。

### 2.5 一张对照表

把三组对照收进一张表。五个维度：工作对象、代码落点、时间跨度、成功标准、与自家产品的关系。下表是教学用的模式对照，不是所有公司的岗位职责法则；实际分工要核对团队职责、项目授权与验收对象。

| 维度 | 咨询式工作 | 售前顾问式工作（2.3 节 SA） | 内部 AI/Agent 产品工程 | FDE 交付式工作 |
|------|----------|---------|------------------------------|-----|
| 工作对象 | 客户的问题与建议 | 销售机会与产品演示 | 自家产品与代码库 | 客户的业务结果 |
| 代码落点 | 基本无生产代码，交付物是报告与方案 | 演示环境，匿名数据 PoC | 自家基础设施 | 客户基础设施上的生产代码 |
| 时间跨度 | 多年期，多层梯队 | 销售周期（周到月） | 产品迭代节奏 | 项目制（数周到数月），小队直达现场 |
| 成功标准 | 建议被采纳，报告通过验收 | 成交，演示效果 | 产品指标（采用、性能、留存） | 客户生产采用（production adoption）与业务结果 |
| 与产品关系 | 无关或第三方 | 推销自家产品 | 构建自家产品 | 用自家产品加定制填补缝隙，并把现场模式反哺产品 |

用法提示：这张表不是用来给其他角色贴标签、评高下的，而是用来给自己定位的。任何一个工作日，你都能在表里找到自己当天的"重心坐标"；连续数周坐标不在 FDE 列，就是角色漂移的信号。

### 2.6 这个岗位的一天：场景自检

最后做一次自检。以下是"FDE 的一天"里四个真实感很强的场景，每个场景后有一问。先自己作答，再看参考判断。

场景一（上午 10 点，客户高管会议室）。客户 CIO 说："这个方向很好，给我们做一份三年路线图，第一期先上顾问团队做诊断，人月按三个梯队配。"你是现场唯一的工程师。
问：这是 FDE 的工作方式吗？该怎么回应？
参考判断：这是典型的咨询式拼凑开局。FDE 的回应不是拒绝需求，而是改写需求：指出哪些目标可以用平台现成能力在数周内组合出可运行系统先行验证，用真实结果替代三年纸面路线图。如果客户要的确实是纯组织变革咨询，诚实划界——那是咨询顾问的主场。

场景二（下午 2 点，客户数据团队）。客户的数据科学家问："能不能拿一份脱敏样本数据，先做个 PoC 给业务侧看看效果？"
问：这个活该谁干？你会怎么安排？
参考判断：匿名数据上的 PoC 是 SA 的主场。正确的动作是把 SA 同事拉进来协作，而不是自己花两周做一个演示级原型——你的时间应该花在客户真实数据与真实基础设施上。若公司没有专职 SA，你可以代做，但要清楚这属于"客串"，并按 SA 的成功标准（说服业务侧）而非 FDE 的标准（生产采用）来验收它。

场景三（下午 4 点，回酒店路上）。你意识到客户的"工单自动分类加人工兜底"流程，在你服务的上一个客户那里也出现过，模式几乎一样。
问：这个发现属于谁？下一步做什么？
参考判断：这正是 FDE 反哺通道的入口。把该模式沉淀成可复用的工具或 playbook，通过公司的现场知识机制回流给产品与其他 FDE（机制详见第九部分）。如果你只是默默又实现了一遍，你就漏掉了 FDE 职责里"服务客户"之外的另一半。

场景四（晚上 8 点，周报）。你在演示环境里的端到端流程全部跑通，演示视频也录好了。客户业务负责人回复："很好，什么时候上到我们的生产环境？"
问：此刻你的项目处于什么状态？
参考判断：处于 SA 状态的终点、FDE 状态的起点。演示通过只证明"能力为真"，FDE 的交付物是跑在客户基础设施上、有真实流量、有采用度数据的系统。把"什么时候上生产"当成下一周期的第一优先级，而不是当成演示成功的注脚。

四个场景指向同一个结论：边界不是理论分类，而是每天的工作选择。划清了"不是什么"，下一个问题随之而来——当编码 agent 让代码的生产成本急剧下降，这些边界会怎样移动？FDE 的哪些部分会被放大，哪些会被侵蚀？这是第 3 章的主题。

---

> 本章业界事实的来源说明：Palantir 官方博客 FDSE 问答中 "Is an FDSE similar to a consultant? No, not really" 的表述、以及"咨询团队承接多年期拼凑项目、FDE 依赖平台现成能力快速组合"的区分，出自 Palantir 官方博客；OpenAI 内部 SA 与 FDE 的角色区分（SA 为顾问性角色、用匿名化数据构建 MVP/PoC、几乎不在客户基础设施上写生产代码；FDE 直接在客户基础设施与工具链上写生产代码并承担更高模糊性），出自 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人 Colin Jarvis 的采访；FDE "服务客户并反哺自家产品"、codify 可复用模式的职责，出自 OpenAI 公开招聘描述及上述采访。本章未另引行业统计，案例时间与比例均属教学假设。角色边界不能由职称直接推出：同名的 Solutions Engineer 可能承担不同客户阶段，内部产品工程师也可能参与现场调研。判断具体工作时，应询问生产系统归谁维护、谁批准变更、谁负责采用与业务结果，再核对这次任务的授权；不要只凭名片决定交接。

---

## 独立练习

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

客户同时提出售前演示、生产故障和产品路线图要求。做一张三行责任表，写主责、协作者、交付物与升级条件。

<!-- chapter-artifact-requirement -->
### 本章必交产物：相邻角色责任矩阵

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

- O1: 相邻角色责任矩阵用相同维度填写“FDE”“解决方案架构师”和“实施顾问”三列
- O2: 相邻角色责任矩阵每列至少包含一条可复核证据和一项未决问题
- O3: 产物用一个客户事件标出三个角色的责任、交接和空白

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

## 参考反馈

售前演示需销售与方案人员确认承诺；生产故障由值班与系统负责人主导，FDE提供上下文；产品路线图由产品负责人决策，FDE提交可复用需求与证据。角色名称不能代替实际授权。

### 自评与下一步

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

</details>

## 来源与边界

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

- [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 区分、客户项目三阶段及团队知识分享节奏；属于二手访谈材料，不代表行业通用标准。