# 第 27 章 客户项目三阶段

## 本章目标

- **O1** 能够说明“定界”“验证”“交付接管”的输入输出顺序（产物：客户项目阶段出口表）
  - 证据: 客户项目阶段出口表按输入输出顺序连接“定界”“验证”和“交付接管”
- **O2** 能够构造客户项目阶段出口表，为每一步定义责任人和完成标准（产物：客户项目阶段出口表）
  - 证据: 客户项目阶段出口表为三个步骤分别写出负责人、输入、输出和完成标准
- **O3** 能够为定界、验证与接管三个客户阶段定义出口（产物：客户项目阶段出口表）
  - 证据: 产物为一个客户项目标出三阶段的负责人、证据和退出条件

## 学习路径

- **初学者**: 本章迁移任务是：能够为定界、验证与接管三个客户阶段定义出口。先按图中的“输入输出流程”关系完成客户项目阶段出口表的第一项证据，再逐项核对责任人与判断标准。
- **有经验者**: 先用当前项目完成这一任务：能够为定界、验证与接管三个客户阶段定义出口。提交客户项目阶段出口表后，再对照正文复核关系类型、缺失证据和授权边界。

## 教学图解

- **必交产物**: 客户项目阶段出口表
- **图解类型**: client-lifecycle
- **关系语义**: 三步按输入输出单向衔接，每一步必须产出下一步可检查的输入，并在出口条件处作决定。
- **核心概念**: 定界 · 验证 · 交付接管

![第 27 章客户项目阶段出口表教学图](/learning/diagrams/zh/chapter-27.svg)

顺着输入输出阅读客户项目阶段出口表，在每个出口检查证据，而不是只看最终结果。

图从左到右连接“定界”“验证”“交付接管”。每个箭头表示前一步输出成为后一步输入；学习者应在每一步写明负责人和完成标准，出口证据不足时返工或停止。

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

## 课程讲解

### 27.1 业界标杆三阶段：scoping → 验证 → 交付

先看一个典型场景。你的团队与一家制造企业签下合同，做"设备故障工单智能分类与派单"。启动会上客户 CIO 说得很干脆："三个月，上线，处理工时降三成。"挂了电话你面对的是：工单数据散落在三个系统里，没人说得清分类规则的例外情形，真正的用户在千里之外的工厂。这时候第一个问题不是"怎么写代码"，也不是"先让 AI 出个方案"——而是这个项目按什么节奏走。

本书到上一部分为止，给了你从会话级到项目级的全套武器。但客户项目有它自己的生命周期，这个生命周期决定了那些武器什么时候拿出来、什么时候必须收起来。业界标杆的答案是三段节奏。据 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访，其客户项目的典型流程分三个阶段：早期 scoping，去客户现场数日；验证期，构建 evals、加特性并在 evals 上爬坡；交付期，每周数天驻场。逐段拆开看。

第一阶段：scoping——现场数日，换三个判断。scoping（范围勘察）回答三个问题：这是不是一个真问题？数据拿得到吗？方案大致可行吗？注意这三问没有一问是"代码怎么写"。为什么必须现场而不是远程会议？因为真问题藏在一线的抱怨里而不是高管的 PPT 里，数据长在客户的系统里而不是接口文档里，而现场两天能逼出来的答案（"这个导出权限要走审批，三天起"），远程一个月都问不出来。scoping 的产出不是任何可运行的东西，而是一个诚实的判断：进入验证期，还是到此为止。敢于给出否定判断，是这一阶段最被低估的专业能力——一个注定失败的项目被礼貌地推进到验证期，烧掉的是双方三个月的信任。

第二阶段：验证期——在 evals 上爬坡。这一阶段的核心工作不是写功能，是构建 evals，加特性，并在 evals 上爬坡。爬坡这个词值得咀嚼：迭代不是在感觉上爬坡，是在评估集上爬坡——提示词改了，跑一遍；模型换了，跑一遍；方案调了，跑一遍。评估集就是坡道，没有坡道的迭代是自由落体（第 21 章已把这套评估体系完整立起来：最小可行 eval、五个质量维度、golden set 与回归）。验证期的"验证"两字有对象：验证的是方案在客户真实数据上的成色，而不是演示环境里的效果。这一阶段的出口判据同样清晰：评估集上的结果是否支撑生产承诺。

第三阶段：交付期——每周数天驻场。系统推入生产前后，节奏变成每周几天在客户现场。为什么不是远程？因为生产的最后一公里不在代码里，在客户的网络、权限、变更流程和活生生的人里：审批卡在哪个人手里、哪个车间的班组长不信任机器派的单、凌晨的告警该找谁——这些问题的答案都长在现场。驻场不是保姆式待命，是把反馈回路压缩到最短：采用率上不去，当天就能坐在用户旁边看到卡点；新的失败模式出现，当天回流成新的 eval 用例。交付期怎么与客户的干系人协作、何时必须现场何时可以异步，第 28 章专门展开。

三阶段是一张项目级的时刻表。但读到这里你应该冒出一个疑问：本书已经讲过六步工作法、"三步走"、Job 八阶段，现在又来一个三阶段——一个工程师到底该听哪个的？这个疑问完全正当，下一节一次性说清。

### 27.2 四套流程模型：不是四选一，是四层变焦

先把结论说死：四套流程模型不矛盾，因为它们根本不在同一个粒度上。六步工作法是会话级，"三步走"是高风险会话级，八阶段是项目级全自动，三阶段是客户项目级。它们的关系像地图的四层变焦：城市图上看不到街道，街道图上看不到城市——你不会同时"使用"两张图，你只是根据当前要回答的问题选择一层。

| 流程模型 | 粒度 | 出处 | 适用场景 | 谁在用 | 什么时候用 |
|----------|------|------|----------|--------|------------|
| 六步工作法（拆解 → 下发指令 → 编码 → 验收 → 分支判断 → 更新图纸） | 会话级：一个功能的一次 AI 编码任务 | 第 7 章 | 需求明确、风险可控的常规功能开发 | 所有使用 AI 编码的开发者 | 默认档——写任何单个功能时 |
| "三步走"（调研 → 谋局 → 落地） | 会话级·高风险：剥夺执行权，强制慢思考 | 第 19 章 | 中等复杂度以上、陌生领域、方案选错代价高的需求 | 面对高不确定需求的开发者 | 一件事预计超过半天、或决策影响面大时，从默认档升级上来 |
| 八阶段全自动构建（Job） | 项目级：从零到部署的整条链 | 第 17 章 | 蓝图成熟、测试电网完备、技术栈清晰的低风险从零项目 | 技能体系的调用者 | 新项目冷启动、且路径已被验证可自动化时 |
| 三阶段（scoping → 验证 → 交付） | 客户项目级：数周到数月的客户交付 | 本章 | 嵌入客户现场、对结果负责的交付项目 | FDE | 客户项目全生命周期 |

四者的真正关系是嵌套，不是并列。三阶段是外壳：在验证期里，如果项目满足第 17 章接入的第 19.3 节权限边界（蓝图成熟、技术路径已验证、风险低、测试电网完备），你可以用八阶段把项目从零搭起来；失败时只降级执行模式；已获批的非关键备用路径之外，验收标准、客户承诺和范围变化都由获授权的人决定，失败门禁不能降标改成 PASS。搭起来之后，每个具体功能用六步落地，其中高风险的那些升级为"三步走"。反过来说也成立：一次任务只在一个粒度上选流程——你不会在客户启动会上"执行六步工作法"，也不会在写一个函数时"进入交付期"。

所以选择的顺序是从粗到细的三问。先问项目在哪个阶段——scoping、验证还是交付（三阶段）；再问这个项目怎么起步——满足边界就上八阶段全自动，否则手工走蓝图路线（第 16 章）；最后问这个功能怎么写——常规用六步，高风险用"三步走"。每一层的答案约束下一层：验证期的目标决定要建哪些 eval，eval 守住的底线决定敢不敢放开全自动。

顺带把一项审计遗留正式关掉。本书此前在不同章节并列陈述过这四套流程，而未说明粒度关系，读者容易读成"四选一"，甚至读出冲突——最典型的表面冲突是第 19 章"在问题没想清楚之前严禁生成任何一行实质代码"与第 17 章"全自动从零到部署"：一个剥夺执行权，一个放权到底，像不像是打架？映射之后答案明确：禁令是会话级高风险场景的防御，全自动是项目级低风险场景的授权，两者的适用判据分别在各自章节的使用边界里写死，粒度不同，永不同场竞技。第 15 章的技能全景图末尾也已补上指向本章的互引。

### 27.3 scoping 实战：数日现场要换回什么

三阶段里最容易被做轻的是 scoping——它花的是全项目里最"贵"的时间（FDE 本人在客户现场），换回的却是看不见摸不着的东西。这一节给它一套可操作的打法：核心工具就是第 11 章的 Event Storming，这里把它扩展到客户语境。

现场访谈：把 Event Storming 开到客户会议室。第 11 章的问法原样成立：不问"系统需要什么功能"，问"业务中发生了什么事件"。设备工单的场景里，从"设备报警"到"工程师到场"之间发生了什么？一线操作者会给你一条过去式的事件流——"报了警、值班群吼了一嗓子、王工判断是误报、但还是去看了、填了工单"——这条事件流比任何需求文档都可信，因为它就是实际发生的流程。客户语境的三点扩展：

其一，访谈对象分层。一线操作者给你事件流，中层流程负责人给你规则与例外，高管给你价值叙事与预算边界。三层口径几乎必然对不上：高管说"我们要智能派单"，一线的真相是"派单有三条潜规则只存在老师傅脑子里"。对不上时，事件流以一线为准，优先级以高管为准——如何与三类人分别对话、各用什么语言和产物，第 28 章展开。

其二，用足"在场"的红利。事件流里每一个"然后呢"都可以当场起身去看真实的屏幕、工单、表格。远程访谈得到的是"应该的流程"，现场得到的是"实际的流程"，两者的差值就是你的需求金矿——那些没写进任何文档的潜规则、变通和 workaround，恰恰是 AI 方案成败的分水岭。

其三，把分歧记录带进客户现场。第 11 章的分歧记录（分歧、决策、原因、影响范围、日期）在客户项目里价值翻倍：客户组织内部的分歧比内部团队更常见，项目重启、对接人换人时重开的概率也更高，一条记录替未来的你省掉一整场重复论证。

数据盘点：AI 项目的成败有一半在数据里，而数据在客户手里。做自己的项目，数据是顺手的；做客户的项目，数据有主权、有格式、有看门人。scoping 期间必须落一张数据盘点表（以下是虚构教学示例，实际使用填入来源、审批依据及核验日期）：

| 系统/来源 | 有什么数据 | 格式与质量 | 获取路径 | 时效 | 合规约束 |
|-----------|-----------|-----------|----------|------|----------|
| 工单系统 | 18 个月历史工单约 4 万条 | 结构化字段 + 大段自由文本，文本质量参差 | 接口导出，需 IT 审批约 3 个工作日 | T+1 | 仅限项目环境，禁止回传外部模型 |
| 值班群记录 | 两年即时消息 | 非结构化，含图片 | 无导出通道，需找平台管理员人工拉取 | 不确定 | 含人员信息，脱敏后可用 |
| 设备台账 | 全量设备档案 | 结构化，维护良好 | DBA 直连只读库 | 实时 | 无特殊限制 |
| 知识库（Wiki） | 故障处理手册 | 半结构化，三年未更新 | 可自助导出 | 静态 | 无特殊限制 |

这张表有两个作用。一是判断验证期有没有米下锅：没有可获取的历史数据，第 21 章的评估集就是无米之炊——这种情况要在 scoping 阶段就摊开，而不是验证期才发现。二是提前暴露那个经典陷阱："数据在会上永远存在，在导出时永远缺权限"。表里的"获取路径"和"时效"两列，就是在现场把这件事逼出水面的工具。

快速 PoC：边界比速度更重要。scoping 常常包含一个快速 PoC——用一两天做一个最小演示，验证"这类数据 + 这类模型"的关键假设。PoC 的目的是对齐认知，不是提前交付。三条边界必须守住：一，不承诺——演示里跑通的任何东西，当场口头声明"验证期会在评估集上重新验证"；二，不进生产——PoC 不接客户真实业务流、不留存生产数据；三，不脱离 eval——PoC 过程中每一个让客户点头的案例，当场记下来，它们就是验证期评估集的第一批种子用例（对应第 21 章 6 + 2 + 2 配比里的"真实输入"）。边界坍塌的症状很好识别：客户开始在 PoC 上提验收意见。一旦发生，不要陷入逐条回应，立刻拉回三阶段叙事——"这正是我们验证期要做的事"。

scoping 的出口判据。数日结束时，你应该带着四样东西离开现场：一份事件流与 REQUIREMENTS.md 雏形（第 11 章的格式）、一张填实的数据盘点表、一批 eval 种子用例、一个明确的进入或终止判断。写不出后两样，说明 scoping 还没做完；用"再约下周的会"来回避判断，是把最贵的现场时间稀释成了最便宜的远程等待。

### 【练习】为一个虚构客户设计一次三天的 scoping

题目：场景——某连锁口腔诊所集团想做"病历辅助摘要与复诊提醒"，你有三天现场时间。产出四样东西：①访谈对象清单（按一线/中层/高管分层），每人各写 3 个事件式问题；②数据盘点表（至少 4 行，"获取路径""时效""合规约束"三列必须填实）；③快速 PoC 的范围声明，把三条边界的表述写成你在现场会说出口的原话；④对照出口判据做一次自检：四样产出里你最可能缺哪个，为什么。

引导：重点体验两个落差。①"事件式问题"的落差：写到第二个访谈对象时你会发现，高管答不了事件问题、一线答不了价值问题——这不是缺陷，这正是分层访谈的意义所在。②"合规约束"的落差：病历是医疗数据，你会第一次认真面对"数据明明在场、但一个字段都不能带走"的情形，数据盘点表的最后一列会从套话变成整个方案的约束条件。

参考方向（供讲师参考）：评阅主要看三点。事件流的采集是否坚持以一线为准，而不是把高管的话翻译成事件；数据盘点是否包含获取路径与时效——只写"有数据"不算盘点，写清"谁能批、几天批下来"才算；PoC 三条边界是否落成了可执行的话术——"不承诺"有没有一句现场真的会说的话来承载。常见的反例是把 scoping 做成了需求清单誊写：三天产出一份功能列表，四个出口判据一个都没碰。

---

> 本章业界事实的来源说明：OpenAI 客户项目"三阶段流程——早期 scoping 现场数日、验证期构建 evals 并在其上爬坡、交付期每周数天驻场"出自 The Pragmatic Engineer 2025 年 8 月对 OpenAI FDE 负责人的采访记录。Event Storming 方法与分歧记录格式复用自本书第 11 章；四套流程模型的统一映射、scoping 三问、数据盘点表与 PoC 三条边界，属于本书的方法论展开，不归属特定公司的内部实践。本章未另引行业统计；未标明来源的案例、数据量、目标比例、审批时长和练习节奏均为教学假设，不是客户实测或行业基准。

---

## 独立练习

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

为定界、验证、交付各写输入、产物、退出条件和暂停条件。客户想把演示直接接入生产时，给出下一步。

<!-- chapter-artifact-requirement -->
### 本章必交产物：客户项目阶段出口表

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

- O1: 客户项目阶段出口表按输入输出顺序连接“定界”“验证”和“交付接管”
- O2: 客户项目阶段出口表为三个步骤分别写出负责人、输入、输出和完成标准
- O3: 产物为一个客户项目标出三阶段的负责人、证据和退出条件

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

## 参考反馈

定界确认问题、权限和业务主责；验证用获授权样本与独立评估；交付要求接管、恢复和采用观察。演示成功不能跳过权限及红线验收。先列缺失证据与负责人，约定受控验证范围，不承诺未经确认的上线日期。

### 自评与下一步

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

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