第 6 章 · 六阶段交付法
本章你会学到：一次 AI 部署从发现到移交的完整节奏，每个阶段该做什么、不该做什么、交付什么、用什么标准决定「继续」还是「停」。
一句话：六阶段不是瀑布，而是一串带门禁的循环——每个门禁都要允许你说「不」。
一个现场片段
以下是合成场景，用于说明典型情境，不对应任何真实客户。
周一早上九点，项目启动会。客户 IT 总监、客服总监、采购负责人都在。你在白板上画了一条十二周的线：第 1-2 周发现，第 3 周定义，第 4-6 周原型，第 7-9 周试点，第 10-11 周生产，第 12 周移交，之后规模化。
有人问：「能不能第三周就上线？」你说：「第三周我们可以给你一个用真实数据跑出来的演示，但不是上线。」会议气氛有点僵，客服总监补了一句：「先让他做。」
后来的十二周大致如这条线，但每个门禁都比预想更紧：第 2 周你才发现真正的痛点是「分类错导致工单来回转」，不是「话术不好」；第 5 周的演示用真实工单跑，准确率只有 68%，被打回重做了一轮；第 8 周试点指标比目标低一半，追下去是标签口径没对齐；第 11 周灰度到 50% 时，你按预案回滚了一次。
到第 12 周交接时，客服总监说的不是「效果很好」，而是：「至少现在我知道它什么时候不可靠、出了问题找谁。」这句话，比任何夸奖都更像上线。
六阶段总表
| 阶段 | 典型周期 | 目标 | 关键动作 | 交付物 | 退出标准 | 反模式 |
|---|---|---|---|---|---|---|
| 发现 Discover | 2 周 | 找到值得做的问题和能买单的人 | 现场访谈、影子跟岗、流程走查、数据初勘 | 发现纪要、流程地图、数据地图、候选场景清单 | 五问能答、owner 在场、有数据样本 | 只和管理层开会 |
| 定义 Define | 1-2 周 | 把问题变成一页纸的可验证方案 | 项目章程、指标与基线、范围与不做清单、评测集草案 | 项目章程、试点计划、评测计划、数据接入清单 | 指标可测、数据可拿、范围冻结 | 指标不可测就开工 |
| 原型 Prototype | 2-4 周 | 用真实数据验证可行性 | 真实样本、基线、模型/规则方案、30 条评测、真实用户试用 | 原型、评测报告、演示脚本、技术风险清单 | 相对基线有可测提升、用户愿意继续用 | 假数据演示 |
| 试点 Pilot | 4-8 周 | 在限定范围跑出可复现的指标 | 限定范围、用户培训、人工复核、周度指标、反馈回流 | 试点周报、评测报告 v2、上线就绪检查 | 指标达标或偏差可解释、安全审查通过 | 偷偷扩大范围 |
| 生产 Production | 2-4 周 | 从「能用」到「稳定、可回滚、有人负责」 | 部署、监控告警、灰度、回滚演练、Runbook（运行手册） | 上线检查表、Runbook、监控面板 | 灰度稳定、值守到位、变更可回滚 | 无监控上线 |
| 移交与规模化 Handover & Scale | 持续 | 让客户能自己跑，把现场变成产品 | 培训、SOP、支持渠道、季度复盘、产品反哺 | 交接清单、培训材料、产品反哺需求单 | 客户独立度达标、有续约或扩展计划 | 交完人就走 |
W1-2 W3 W4-6 W7-9 W10-11 W12 之后
发现 ──▶ 定义 ──▶ 原型 ──▶ 试点 ──▶ 生产 ──▶ 移交 ──▶ 规模化
▲ ▲ ▲ ▲ ▲ │
└─ Gate 1 ──┴── Gate 2 ──┴── Gate 3 ───┴── Gate 4 ────┴─ Gate 5 ◀──┘发现 Discover（约 2 周）
目标：找到值得做的问题，以及愿意为结果买单的人。不要做：讲技术方案、做 demo、承诺效果、写长篇需求文档。
关键动作
- [ ] 访谈 3-5 位一线用户，至少做半天的影子跟岗
- [ ] 走一遍真实案例的完整流程，画出实际流程而不是 SOP
- [ ] 找到经济买家，确认预算、验收人和决策路径
- [ ] 初勘数据：有哪些表、谁能给、质量如何
- [ ] 列出 3-5 个候选场景，用项目选择评分卡排序
交付物：发现纪要、流程地图、数据地图、候选场景清单 → 附录 B · 模板工具箱。
退出标准（Gate 1）：五问都能答；有明确 owner；拿到可评估的数据样本；能说出「如果做成了，哪个指标会变」。
合成小例子：候选场景有三个——工单分类、客服话术建议、知识库问答。评分卡打完，只有工单分类在价值、数据、owner 三项都过线，项目范围由此收敛。
定义 Define（1-2 周）
目标：把问题写成一页纸的可验证方案。不要做：急着定技术栈、写完整 PRD、答应无法测量的指标。
关键动作
- [ ] 写项目章程：问题、目标、范围、不做清单、里程碑、验收方式
- [ ] 锁定指标：基线值、目标值、测量口径、数据来源
- [ ] 划定试点范围和用户名单
- [ ] 写 30 条评测集草案（真实样本 + 难例 + 边界）
- [ ] 记录风险与依赖，确认数据接入与合规口径
交付物：项目章程、试点计划、评测计划草案、数据接入清单 → 附录 B · 模板工具箱。
退出标准（Gate 2）：经济买家签字确认指标与范围；数据可实际拿到；评测集有基线可跑；「不做清单」写清楚。
合成小例子：章程最初写「智能客服助手」，评审时被改成「工单分类与分派建议，覆盖 3 个高频类别，准确率目标 85%，人工可一键修正」。范围一小，所有人都知道验收看什么。
原型 Prototype（2-4 周）
目标：用真实数据做出能给真实用户看的版本，验证可行性，不追求完美。不要做：假数据演示、直连生产系统、提前做规模优化。
关键动作
- [ ] 从真实历史数据里构建样本集（含难例）
- [ ] 先做最简单基线：规则、关键词、现成模型的零样本
- [ ] 加模型方案，固定评测集，记录每次改动
- [ ] 请 3-5 位真实用户试用，收集定性反馈
- [ ] 初测成本与延迟，识别技术风险
交付物：可运行原型、评测报告 v1、演示脚本、技术风险清单。
退出标准（Gate 3）：相对基线有可测提升；真实用户愿意继续用；成本可接受；没有阻断性合规问题。
合成小例子：规则基线准确率 62%，模型方案 78%，但用户反馈「不知道为什么这么分」。加上「分类理由」后，人工修正率明显下降，这个设计被带进了试点。
试点 Pilot（4-8 周）
目标：在限定范围真实使用，跑出可复现的指标。不要做：偷偷扩大范围、把试点当上线、只测顺利路径。
关键动作
- [ ] 锁定试点组、时间窗、指标看板
- [ ] 培训用户，明确「AI 建议 + 人工确认」的分工
- [ ] 保留人工复核与修正入口，记录每一次修正
- [ ] 每周复盘指标，把偏差追到具体原因
- [ ] 扩充评测集到 100 条左右，准备上线就绪检查
交付物：试点周报、评测报告 v2、上线就绪检查表、初步 ROI 测算 → 附录 B · 模板工具箱。
退出标准（Gate 4）：指标达到目标或偏差有解释；用户使用率与留存达标；成本可预测；安全审查通过；经济买家同意进入生产。
合成小例子：第 2 周误分率反弹，追查发现新标签和旧标签没有映射表；补上映射并重跑评测后回到目标区间。这个坑如果拖到上线后才暴露，代价会大得多。
生产 Production（2-4 周）
目标：从「能用」到「稳定、可回滚、有人负责」。不要做：没监控就上线、没有回滚方案、把模型当确定性系统。
关键动作
- [ ] 完成部署架构、密钥与权限、审计日志
- [ ] 配监控告警：错误率、时延、成本、无答案率、升级率
- [ ] 灰度发布：10% → 50% → 100%，每一档观察指标
- [ ] 回滚演练一次，写 Runbook 与 on-call（值班）安排
- [ ] 约定事故分级与通知机制
交付物：上线检查表、Runbook、监控面板、变更记录。
退出标准（Gate 5）：灰度期间指标稳定；值守与升级路径明确；回滚可用；用户侧沟通完成。
合成小例子：灰度到 50% 时，某类工单的模型调用超时上升，你按 Runbook 回滚到上一版本，半小时后恢复，再定位到是新提示词导致输出变长。
移交与规模化 Handover & Scale（持续）
目标：让客户能自己跑，把现场经验变成可复用的能力。不要做：交完人就走、把客户特例做成核心、只写文档不做培训。
关键动作
- [ ] 培训客户团队：日常操作、异常处理、指标查看
- [ ] 交付 SOP（标准作业程序）、Runbook、评测集与数据字典
- [ ] 建立支持渠道与升级路径，约定响应时间
- [ ] 每季度做一次业务复盘：指标、成本、下一步
- [ ] 把通用问题写成产品需求，进入产品轨评审
交付物：交接清单、培训材料、产品反哺需求单、规模化路线图 → 附录 B · 模板工具箱。
退出标准：约定的独立度指标达成（例如客户团队能自行处理大部分日常问题）；有续约或扩展计划；产品需求进入评审。
合成小例子：交接三个月后，客户自己扩了两个类别，遇到新标签口径问题时先查数据字典再来问——这就是从「项目」变成「能力」的信号。
现场最常见的反哺有三类：标签体系（客户的定义会沉淀成行业模板）、评测集（难例进入回归库）、配置项（权限、字段映射、审批流）。把这三类写进需求单，比写「希望产品更智能」有用得多。
演示就是概念验证
很多团队把「演示」当成销售道具：假数据、顺利路径、精心设计的台词。这在 FDE 的现场是反向操作——演示是你能拿到的最便宜的概念验证，前提是三条「真实」：
- 真实数据：用客户的历史样本，包括脏数据、长尾和空值。
- 真实用户：让实际使用它的人来点、来骂、来挑错。
- 真实指标：现场跑评测集，报准确率、召回率、时延和成本，不报「感觉不错」。
据 First Round Review 2025 对 Looker 的回顾（单一来源），他们把「演示」直接当成概念验证来卖，并用「2.5 万美元 × 2,000 个客户」的模型测算过约 1 亿美元 ARR 的可能空间——这说明一个好演示能承载商业判断，但它不是业绩本身。
Palantir 早期有一个被反复讲述的细节：客户看完演示说「这东西太糟了」，Stephen Cohen 没有辩解，而是问「那你们希望它哪里不一样」（据 YC Lightcone 播客与公开报道，多源）。演示的目的不是赢得掌声，而是把用户的真实标准逼出来。
一个可用的演示结构：3 分钟讲清问题与基线 → 2 分钟走真实案例 → 1 分钟报指标与成本 → 留 5 分钟只为挨骂。演示里必须包含一个失败案例：无答案、低置信度、人工接管——这比一百次成功更能建立信任。
演示的底线
镜头前有三样东西不能假：数据来源、指标口径、失败案例。任何一样造假，后面都要用三倍时间还债。
演示前逐条检查：
- [ ] 用的是客户的数据，不是自己准备的样例
- [ ] 指标由同一个评测集跑出，可当场复现
- [ ] 失败路径准备了三个：无答案、低置信度、需要人工接管
- [ ] 演示不会写脏生产数据，出了问题能立刻回退
双轨：交付轨与产品轨
FDE 的工作有两套成功标准：交付轨对客户负责，产品轨对复用负责。只做前者会沦为定制外包，只做后者会在现场失信。
| 轨道 | 目标 | 成功标准 | 典型产出 | 节奏 |
|---|---|---|---|---|
| 交付轨 | 让这个客户的问题被解决 | 指标、上线、续约 | 方案、部署、Runbook | 按项目周期 |
| 产品轨 | 让下一个客户少走一遍 | 复用次数、平台能力 | 配置项、通用功能、文档 | 按季度评审 |
现场需求变成产品需求，要过一道「通用化」的筛子。每次提交需求时，用一张固定的需求单：
| 字段 | 填什么 |
|---|---|
| 现场现象 | 发生了什么，用户的原话是什么 |
| 证据 | 数据、频次、受影响的用户数量 |
| 出现范围 | 几个客户、几个部门出现过 |
| 通用化判断 | 是配置问题、平台能力，还是这个客户独有 |
| 建议动作 | 做配置 / 进平台 / 写文档 / 不做 |
| 负责人与评审时间 | 谁跟、什么时候评审 |
一个简单的纪律：同一现象至少在两个客户现场出现过，才进入平台排期；只出现一次的，先用配置或文档解决。这条线能防止「把某一个客户的怪癖做成产品核心」。
项目治理：让每周都有可决策的信息
治理不是开会，是让风险、范围、决策都有记录、有 owner、有复查时间。最小可用的治理包：
- 周会（30 分钟）：指标变化 5 分钟 → 本周进展 5 分钟 → 风险与阻塞 10 分钟 → 需要决策的事 5 分钟 → 下周计划 5 分钟。
- 风险登记：每条风险写概率、影响、缓解动作、owner、复查日期。没有 owner 的风险不是风险，是愿望。示例：数据口径不一致（高/中，定义阶段补数据字典，你，每周一）、用户不用（中/高，试点前培训 + 人工复核入口，业务主管，每周五）、模型升级导致回归（中/中，固定评测集 + 灰度，你，每次发版）。
- 范围变更：所有变更进变更单，评估工期与指标影响，由项目 owner 或经济买家批准；口头同意不算。
- 升级路径：FDE → 项目 owner → 经济买家 → 高层 sponsor，每一级约定响应时限。
- 决策记录：每个 Gate 的结论、证据、参与人，一页纸存档。
12 周计划
| 周次 | 阶段 | 关键输出 | 决策点 |
|---|---|---|---|
| 第 1-2 周 | 发现 | 访谈纪要、流程与数据地图、候选清单 | Gate 1：做不做 |
| 第 3 周 | 定义 | 项目章程、指标与基线、评测集草案 | Gate 2：范围冻结 |
| 第 4-6 周 | 原型 | 真实数据原型、评测报告、演示 | Gate 3：进不进试点 |
| 第 7-9 周 | 试点 | 限定范围运行、周度指标、上线就绪检查 | Gate 4：上不上生产 |
| 第 10-11 周 | 生产 | 灰度、监控、Runbook、值守 | Gate 5：交不交接 |
| 第 12 周 | 移交与规模化 | 培训、SOP、产品反哺、季度复盘 | 续约或扩展评审 |
| 第 13 周起 | 规模化 | 扩展到新场景与新产品需求评审 | 下一阶段规划 |
上面是 12 周的压缩版，试点只留 3 周；周期更充裕的项目，按总表的典型范围展开。周期可以压缩，顺序最好不要跳。跳过发现会做错题，跳过定义会没有验收，跳过试点会把风险一次性带进生产。
如果只有 6 周，可以压成：发现 1 周 + 定义 0.5 周 + 原型 1.5 周 + 试点 2 周 + 生产 1 周，移交同步开始。压缩的代价是评测集更薄、灰度窗口更短，要提前和经济买家说清楚。
Go/No-Go 评审
每个 Gate 用同一张表评审，结论只有三种：Go、有条件 Go（写清条件和复查日期）、No-Go（写清原因和下一步）。
| 决策点 | Go 条件 | No-Go 条件 | 签字人 |
|---|---|---|---|
| Gate 1 发现→定义 | 五问有答案、owner 明确、有数据样本 | 只有用户热情、没有预算人 | 项目 owner |
| Gate 2 定义→原型 | 指标可测、范围冻结、评测集就绪 | 指标无法测量、数据拿不到 | 经济买家 |
| Gate 3 原型→试点 | 相对基线有提升、用户愿意用 | 提升不可归因、成本不可接受 | 项目 owner + 用户代表 |
| Gate 4 试点→生产 | 指标达标或偏差可解释、安全通过 | 只测顺利路径、无 rollback | 经济买家 + 安全 |
| Gate 5 生产→移交 | 值守到位、独立度达标、文档齐全 | 客户无法独立运维 | 经济买家 |
评审时只认证据，不认情绪。做不到 No-Go 的团队，最后的 Go 都会变成事故。
常见反模式
| 反模式 | 表现 | 后果 | 对策 |
|---|---|---|---|
| 范围蔓延 | 「顺便再加个功能」每周都出现 | 工期失控，指标被稀释 | 变更单 + 不做清单 + 范围冻结 |
| 跳过基线 | 直接定「准确率 90%」 | 无法证明提升，验收扯皮 | 定义阶段必须交基线 |
| 只和 IT 聊 | 全程没有一线用户参与 | 方案正确但没人用 | 影子跟岗 + 用户代表进评审 |
| 把试点当上线 | 试点一开就全量放开 | 事故影响面失控 | 限定范围、灰度、回滚预案 |
| 没有 owner | 双方都觉得对方负责 | 决策卡住，试点无法转生产 | Gate 1 起必须有明确经济买家 |
本章小结
- 六阶段是带门禁的循环：发现、定义、原型、试点、生产、移交与规模化，每个 Gate 都必须允许说 No-Go。
- 每个阶段的交付物不是文档摆设，而是下一个 Gate 的证据；周期可以压缩，顺序不要跳。
- 演示就是概念验证：真实数据、真实用户、真实指标，并且要主动展示失败案例。
- 双轨并行：交付轨对客户负责，产品轨对复用负责；现场需求进产品要有频次与通用化门槛。
- 治理的最小包是周会、风险登记、范围变更、升级路径和决策记录。
练习
- **写一份 12 周计划。**选一个你熟悉的场景（可以是 Lab A），按本章总表填出六个阶段、关键输出和 Gate；标出你最没把握的一个门禁。判断标准：每个 Gate 都有可核对的证据清单。
- **做一次 Go/No-Go 评审。**找一个同伴扮演经济买家，用 Gate 2 的条件评审你的计划，练习说出「有条件 Go」和「No-Go」。判断标准：结论后能写出 3 条具体的复查条件。
- **设计一张产品反哺需求单。**从你的场景里挑一个「可能不只这个客户会遇到」的问题，填写六字段需求单，并说明为什么它够格（或不够格）进入产品轨。判断标准：通用化判断有依据，动作明确。
- **写一份两周试点周报模板。**包含指标、偏差原因、用户反馈、风险和下周决策点。判断标准：不看正文也能从模板里看出项目是否健康。
下一章：第 7 章 · 你的第一个部署：用三个 Lab 把六阶段完整跑一遍。
相关：Lab A · 客服工单分流 · 附录 B · 模板工具箱 · 案例库 · Palantir：FDE 的原点 · 附录 A · 术语表