# 第 28 章 干系人与驻场协作

## 本章目标

- **O1** 能够为“业务负责人”“工程团队”“安全与治理”分配责任人与接口（产物：干系人责任网络）
  - 证据: 干系人责任网络为“业务负责人”“工程团队”和“安全与治理”分别指定责任人
- **O2** 能够构造干系人责任网络，标明信息、授权和证据如何跨接口传递（产物：干系人责任网络）
  - 证据: 干系人责任网络标出至少两个接口及其输入、输出和授权边界
- **O3** 能够在业务、工程与治理干系人之间建立责任和升级路径（产物：干系人责任网络）
  - 证据: 产物为一个争议记录三方立场、决定权、证据和升级路线

## 学习路径

- **初学者**: 本章迁移任务是：能够在业务、工程与治理干系人之间建立责任和升级路径。先按图中的“接口网络”关系完成干系人责任网络的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够在业务、工程与治理干系人之间建立责任和升级路径。提交干系人责任网络后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 干系人责任网络
- **图解类型**: stakeholder-network
- **关系语义**: 两侧角色通过中央接口协作，底部条带约束负责人、接口和证据，连接不表示授权自动转移。
- **核心概念**: 业务负责人 · 工程团队 · 安全与治理

![第 28 章干系人责任网络教学图](/learning/diagrams/zh/chapter-28.svg)

用干系人责任网络追踪跨角色接口，明确责任、授权和证据何时转移。

图将“业务负责人”与“安全与治理”置于两侧，“工程团队”位于中央接口。箭头表示信息或工作交接，底部条带要求逐项标注负责人、接口和证据；连接存在不等于授权已经转移。

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

## 课程讲解

### 28.1 co-location 的价值与边界：什么时候身体必须在场

第 27 章把三阶段的时刻表立了起来：scoping 现场数日、验证期远程爬坡、交付期每周数天驻场。但那张表只回答了"什么时候去现场"，没有回答一个更根本的问题：为什么是身体去，而不是摄像头去？

co-location（现场同地协作）的价值，不是"显得重视客户"，而是它物理性地改变了几件事。第一，信息带宽。坐在用户旁边看他的屏幕，一分钟能看到的东西——光标犹豫的位置、绕开的菜单、贴在显示器上的便签——是任何远程会议都传不过来的。第二，接触密度。在客户办公区，你能被"顺便"拉进走廊上的三分钟对话，而那三分钟往往正是项目最关键的暗线信息。第三，信任的建立速度。人对坐在身边、一起看过真实问题的人，信任建立的速度远快于屏幕上的头像——而交付期所有难事（要权限、要配合、要改动别人的流程）都押在信任上。

但 co-location 有真实成本：你的时间、差旅、以及团队后方的协作断连。所以它需要边界。三类场景必须现场：

其一，需求模糊期。scoping 之所以必须现场，第 27 章已经论证过——真问题藏在一线的抱怨里，"应该的流程"与"实际的流程"的差值只有坐在现场才能测到。其二，干系人密集期。交付期上线前后，涉及面最大、每个人手里都卡着一票：审批人、网络管理员、班组长、值班经理。这时候一天里要发生的协调，远程排会要排两周。其三，数据敏感期。当数据合规约束是"可以看、不能带走"，你的全部工作环境就是客户的内网——物理在场不是偏好，是约束条件本身。

反过来，验证期的大部分时间可以也应该远程。构建 evals、迭代方案、在评估集上爬坡，是深度工作，恰恰需要第 30 章讲的异步保护和整块专注时间。可先把每周或每两周一次的现场 checkpoint 作为本书的方法假设，再按数据访问、风险与客户反馈调整；这不是行业频率标准。

这里必须正面处理本书内部的一处张力。第 30 章"异步优先，默认公开"写得很重：同步是昂贵的，异步才是常态。而本章却在讲驻场、讲同步高互动。两者矛盾吗？不矛盾，因为它们管辖的是两个不同的协作面。第 30 章的语境是你与自己团队的内部协作——保护队友的专注时间，让信息在公开频道沉淀。本章的语境是你与客户组织的交付协作——信任尚未建立、暗线信息密度极高、对方的协作文化你无法单方面规定。内部协作你说了算，所以异步是默认；客户现场你只是客人，同步高互动是主菜。两个场景不可互相推论：不会因为团队内部异步，就对客户说"请写文档给我留言"；也不会因为在客户那边天天开会，就把这套节奏带回自己团队。这条边界，第 30 章末尾的"客户现场例外"一节有对称的表述，两处互引。

一句话总结本节：现场是手段，不是姿态。判断标准永远是——这件事的信息、信任和权限，是否只有在场才能获得。

### 28.2 干系人分层对接：一种角色，三种语言

客户现场没有"客户"这个单一实体，只有一群立场、语言、在意之事完全不同的人。FDE 最常见的翻车，不是技术翻车，是用错语言——拿架构图去见业务方，拿 ROI 去见一线班组长。第 27 章的 scoping 访谈已经按一线/中层/高层分了层，本节把这个分层沉淀为贯穿全项目的对接策略。

三类核心干系人——客户技术团队、业务方、高管——各有一套沟通语言和适配产物：

| 干系人 | 他们在意什么 | 沟通语言 | 适配产物 | 常见错误 |
|--------|--------------|----------|----------|----------|
| 技术团队（客户 IT/数据/安全） | 系统边界、数据流向、安全责任、上线后谁维护 | 架构与数据：接口、部署拓扑、权限模型、失败模式 | 架构图（含数据流向）、部署方案、ADR 记录、运维交接清单 | 把他们当"配合方"而不是共同Owner；方案绕开他们的约束 |
| 业务方（流程负责人/部门经理） | 流程怎么变、指标怎么算、自己的人要学什么 | 流程与指标：现状流程 vs 未来流程、每个环节的耗时与质量变化 | 流程对比图、指标定义表、用户操作指引、培训计划 | 谈模型能力而不是业务结果；指标口径没对齐就开工 |
| 高管（CIO/业务 VP/发起人） | 投入产出、风险敞口、组织政治、对外叙事 | ROI 与风险：省了多少工时、多大了风险、什么时候见数 | 一页纸进展摘要（红黄绿状态 + 里程碑 + 需要的决策）、风险清单 | 汇报细节不汇报判断；只报喜不报风险的量级 |

这张表的用法有三条纪律。

纪律一：同一件事，三种译法。假设同版本、同口径评估集的准确率从 82% 提到 91%，对技术团队说明 bad case 归因、分类别结果与回归防护；对业务方说明"该评估集错误占比由 18% 降到 9%，是否代表生产仍需试点验证"；对高管建议"评估结果支持申请下一阶段受控试点，待安全、延迟、成本、覆盖范围、运维和客户批准条件满足后再决定扩大上线"。这组教学数字只描述测试集，不保证生产错误减半，也不承诺全面上线日期。翻译的不是数字精度，是对方做决策需要的那一层信息。注意方向性：高层要判断，中层要管理，一线要执行——产物永远为对方的动作服务。

纪律二：每层认一个对接人，别织蜘蛛网。三个层级各确立一个主要接口人（技术侧通常是客户的架构师或 IT 负责人，业务侧是流程负责人，高管侧是项目发起人）。跨层沟通尽量经由接口人传导，而不是你单线直连所有人——一方面尊重客户的组织秩序，另一方面避免你成为唯一的信息枢纽之后，项目知识在你离开的当天归零。接口人机制本身就是交付可持续性的一部分。

纪律三：高管层用固定节奏的一页纸，而不是随叫随到。高管要的是"可控感"：一页纸进展摘要，固定节奏（如双周），固定结构（状态、里程碑、风险、需要的决策）。最后一栏最关键——需要的决策是高管对接的价值所在：预算追加、部门协调、合规例外，这些事只有发起人能拍板。一页纸里永远不要缺这一栏；缺了它，高管对接就退化成了礼节性汇报。

三个层级之间口径必然有摩擦：业务方想要的指标，技术团队说数据拿不出来；技术团队要的加固时间，高管不愿批。FDE 在其中的位置不是传声筒，而是翻译官兼仲裁提案人——把矛盾还原成双方都能看见的事实（数据可得性、工作量、风险），然后给一个带理由的提议。这正好引出本章最后一节的主题。

### 28.3 模糊环境下的自主决策：授权边界、决策记录与"提议而非询问"客户版

驻场最难受的时刻，不是技术难题，是没人告诉你该怎么办，而你又必须动。客户的对接人去休假了，一个数据导出的例外要不要按变通方案走？流程负责人没空确认，界面上一个字段的设计两版都说好？发起人在董事会，但今天不答复，验证期就白等一周。

传统工程师的答案是"等"，传统外包项目的答案是"问，然后等"。FDE 不能等——驻场的全部价值就是把决策延迟压到最短。但自主不等于莽撞，它需要一个事先划定的边界。

授权边界矩阵。项目启动时（最迟 scoping 结束时），与客户发起人当面对齐下面这张表——哪些事你可以当场定，哪些事后报备，哪些必须事前请示：

| 类别 | 当场定 | 事后报备（当日内，书面） | 必须事前请示 |
|------|--------|--------------------------|--------------|
| 技术实现 | 评估集构成、提示词与模型参数、代码结构、内部工具选型 | 依赖库与外部工具引入、非关键接口调整 | 客户系统内的架构变更、数据写入路径变更 |
| 范围 | 演示与验证的样本选择、评估指标口径细化 | 验证范围内的功能取舍 | 承诺新的业务范围、里程碑变更 |
| 数据 | 项目环境内的读取与分析 | 临时数据副本的使用与销毁 | 任何数据离开客户环境、接触新的数据域 |
| 沟通 | 与接口人的日常协调 | 跨部门新增对接人 | 对客户之外的任何披露 |

这张表的谈判本身就是价值：客户发起人会发现，原来"AI 项目"里藏着这么多需要授权的灰色地带；你也会发现，客户的真实风险偏好和口头说的不一样。矩阵一旦确立，模糊感的来源就从"不知道客户怎么想"变成了"知道自己在哪条车道上"——前者消耗心力，后者只需要执行。

决策记录：ADR 的客户版。第 12 章 4 节讲过 ADR 的适用判据——难以逆转、缺乏上下文会令人惊讶、真实权衡的结果——三条在客户项目里全部加倍成立，因为客户项目的"未来读者"还包括客户的接手团队和一年后换掉的对接人。复用第 12 章的 ADR 结构，客户版扩展三处：一，用客户的语言写背景（"为什么不用 A 方案"一段要能被客户的架构师看懂，而不是只写给自己团队）；二，标注授权来源（这个决策是当场定的、报备的还是请示的，依据矩阵哪一格）；三，落到双方共享的文档空间，而不是只存在你的笔记里——这也是第 30 章"结论必须回流"在客户场景的对应物。决策记录写得好的检验标准很朴素：项目移交或对接人更换时，新接手的人能不能靠这批记录重建全部关键决策的来龙去脉。

"提议而非询问"的客户版。第 12 章立的架构设计原则——不做信息不对称下的提问者，做带理由与替代方案的提议者——在客户现场要从技术决策升级为默认沟通姿态。区别在升级的两点。其一，第 12 章的"提议"面向用户，信息不对称主要是技术性的；客户场景的信息不对称是双向的——你不懂客户的组织潜规则，客户不懂技术的可能性边界。所以客户版的提议必须把假设摆上台面："我的提议基于三个假设——审批能走加急、历史数据格式三年未变、班组长配合试点；任何一个不成立，方案要调整。"假设被否定不是提议的失败，恰恰是提议的产出：它把双方各自的不知情变成了可见的清单。其二，客户场景的"询问"还有一个组织性代价：频繁把选择题抛给客户，会在客户心里累积一个判断——"这个人拿不准"——而信任一旦贴上这个标签，后面每个请示都会变得更贵。提议不是替客户做决定，是让客户能便宜地做决定——这句话在第 12 章成立，在客户现场以真金白银的方式成立。

最后把三件工具的关系串起来：授权边界矩阵划定你能在哪条车道上开，决策记录留下你开过的每一道岔口，"提议而非询问"是你变道时的标准动作。三者合起来回答的是同一个问题——在没有完整信息的现场，如何既快又可追责地行动。这正是 FDE 与传统交付角色的分水岭：后者把模糊上交，前者把模糊翻译成可决策的结构。现场积累的这些模式如何回流成团队资产，第 29 章展开。

### 【练习】把一次"模糊"翻译成三件工具

题目：场景接续第 27 章练习——口腔诊所项目进入交付期第三周，你驻场时发现：病历摘要的模板，诊所主任（业务方）上周口头说"A 版"，但科室医生普遍用 B 版的习惯写病历；客户的 IT 主管（技术团队）私下告诉你"其实 A 版在我们系统里渲染有兼容问题，但主任不知道"。主任本周在外地开会，只能邮件回复，每封邮件间隔一天。请产出：①这件事在授权边界矩阵里的定位分析（属于哪一格，为什么）；②一条 ADR 客户版记录（含背景、假设、授权来源标注）；③发给主任的一封"提议而非询问"邮件正文——中文版不超过 200 字，英文版不超过 200 words；两版均须包含三个摆上台面的假设和一个默认动作（"如无异议，我将于 X 日按 B 版推进"式）。

引导：重点体会两个转化。①"模糊"的解剖：这个场景的难受在于三方信息各缺一角——主任不知道兼容问题，IT 不愿越级说，你知道全部但没有决定权。三件工具的作用是把"我该怎么办"转化成"假设是什么、边界在哪、提议是什么"。②默认动作的分量："如无异议我将推进"把回复成本从"做出选择"降到"不反对"，这是异步等待高管决策时唯一不烧掉一周的办法——也注意它的前提：这件事必须真的落在"事后报备"那一格里，否则默认动作就是越权。

参考方向（供讲师参考）：评阅看三点。定位分析是否意识到这是复合事件——模板选择本身可能只是"事后报备"，但"不告知主任兼容问题"的路径选择涉及客户的组织关系，需要更谨慎的处理而不是简单套格子；ADR 是否把 IT 主管的私下信息以不点名、不损害其立场的方式写进背景；邮件是否真正做到了提议而非询问——最常见的反例是把三个假设写成三个问题（"您觉得 A 版还是 B 版？"），等于把整个决策原样退回给了主任。

---

> 本章业界事实的来源说明：本章为通用方法论章节。"三阶段中 scoping 现场数日、交付期每周数天驻场"的节奏出处见第 27 章末尾的来源说明（The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访）；"co-location"作为前沿交付模式的表述亦源自该采访。干系人分层对照表、授权边界矩阵、ADR 客户版扩展与"提议而非询问"客户版，属于本书的方法论展开：ADR 概念复用自本书第 12 章，内部协作的异步优先原则复用自本书第 30 章，均为本书自有内容，不归属特定公司的内部实践。本章未另引行业统计；未标明来源的案例、比例、金额、邮件等待时间和 checkpoint 频率均为教学假设，不是客户实测或行业基准。

---

## 独立练习

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

为业务负责人、技术负责人、使用者和运维写关切、决定权与沟通产物，提出一次驻场与异步结合的安排。

<!-- chapter-artifact-requirement -->
### 本章必交产物：干系人责任网络

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

- O1: 干系人责任网络为“业务负责人”“工程团队”和“安全与治理”分别指定责任人
- O2: 干系人责任网络标出至少两个接口及其输入、输出和授权边界
- O3: 产物为一个争议记录三方立场、决定权、证据和升级路线

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

## 参考反馈

业务负责人确认规则与价值，技术负责人审架构与权限，使用者验证流程，运维接管。驻场用于难以远程理解的工作流；决定和异议留在获授权共享空间。FDE负责协调不等于能替所有人批准数据使用或生产变更。

### 自评与下一步

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

</details>

## 来源与边界

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

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