第八章 建议到执行
8.1 交付曲线与预期管理
承前：第七章我们搭好了评估集，把"好不好"从嘴仗变成了数据。但数据只能告诉你现状，客户的期待还在天上。这一章要处理的是交付里最微妙的一段——从"能用"到"好用"之间那条漫长的曲线，以及怎么把客户的预期从"电影里的 AI"拉回到"这季度能交付的东西"。这一节先讲曲线本身：它为什么不是开关，以及 FDE 该怎么管理它。
8.1.1 从能用到好用，是一条曲线，不是一个开关
做传统软件交付的时候，我们的心智模型是"开关式"的：需求评审、开发、测试、上线，咔哒一声，灯亮了，验收，结项。功能要么有要么没有，边界清楚。
Agent 项目不是这样。第一章讲过，大模型是概率系统，同一输入不保证同一输出。这意味着"能用"和"好用"之间不是一步之差，而是一段连续的爬坡：
交付质量曲线（示意）
质量
│ ┌──── 目标水位
│ ┌───────┘
│ ┌──────┘ ← 每一轮靠评估集+bad case 修
│ ┌──────┘
│ ┌──────┘
│ ┌─────┘ ← demo 惊艳，但水位很低
└───┴────────────────────────────────→ 时间
demo 试点 修正期 生产
传统软件：demo → 开发 → [开关] → 达标
Agent 项目：demo → 一段爬不完的坡 → 永远在修注意那条曲线的形状：demo 阶段质量起点看起来很高（因为 demo 是挑过的场景），然后进入试点会掉一截（真实数据、真实长尾），再一轮一轮往上爬。客户如果拿 demo 的惊艳感当起点，拿"电影里的 AI"当终点，中间这段坡在 TA 眼里就是"你们越做越差了"。
这就是 FDE 在 W8 阶段的核心任务：把曲线画给客户看，并且和客户一起在曲线上钉两个钉子——现在在哪，承诺到哪。
8.1.2 用评估集跟客户对齐"什么叫好"
第七章建的评估集，这一节终于要发挥它最大的价值——不是给你自己调模型用，而是成为甲乙双方的共同语言。
想想没有评估集时的典型对话：
客户："我觉得这次的效果不好。" FDE："哪里不好？" 客户："就是……感觉不如上次准。"
"我觉得不好"是一场没有裁判的比赛。有评估集之后，对话变成：
FDE："上周 200 条评估样本，发券建议的准确率是 87%，这周是 91%。您说的'不好'，是指这 4 个点里哪个场景？我们把那批 bad case 调出来看。"
争议从"感觉"落到"样本"，会议从互相试探变成一起看 bad case。这不只是效率问题，是信任问题——客户相信你透明，才敢让你继续往前走。
用评估集对齐预期，有三个具体动作：
- 定期跑分：每周固定跑一遍评估集，把趋势图画出来发给客户。涨跌都发，尤其是跌的时候——主动报跌是建立信任最快的方式。
- bad case 共审：每月挑 20 条双方一起过。客户会告诉你"这条其实可以接受""这条是致命的"——这就是在帮你校准验收标准的权重。
- 预期水位线：在趋势图上画一条双方认可的"可交付水位线"。曲线在水位线之上，就是"好用"；什么时候曲线跨过线，什么时候谈放量。
8.1.3 双方责任：把"共同对齐"写进机制
预期管理不是 FDE 单方面"会说话"，它有明确的责任边界。这一条很多新手 FDE 会漏：预期是双方共同确认的，责任也是双方的。
| 事项 | FDE（乙方）负责 | 客户（甲方）负责 |
|---|---|---|
| 质量标准 | 工程化质量标准：准确率口径、评估方法、bad case 分级 | 业务口径确认：什么叫"该发券"、什么叫"不该发" |
| 验收标准 | 提出可量化的验收指标（基于评估集） | 确认并签字：确认这个标准是 TA 愿意验收的 |
| 业务事实 | 用业务事实做验证，发现矛盾主动上报 | 对业务事实负责：规则解释、数据口径的唯一权威 |
| 权限与配合 | 提出需要的权限、接口、人员清单 | 对权限审批和配合度负责：卡在客户侧的环节要有承诺时间 |
这张表的关键在最后一行。W8 阶段项目最容易卡死的地方往往不是技术，是"客户侧的配合"：运营经理说好每天抽 10 条看，两周后不看了；IT 说好开接口，三周没动。责任矩阵的意义就是在卡住的时候，明确这是谁的责任田。
在青禾优选的沙盘里，这一节对应的具体剧情是：数字化总监（W7 空降那位）认可了方案，但把验收标准从"建议准确率 85%"提到了"准确率 90%，并且助手要能直接执行发券和打标签"。你怎么办？先别慌，也别硬扛。用评估集回一句："目前 200 条样本上是 87%，剩下 13% 的 bad case 我们过了一遍，8% 是标签数据历史问题，5% 是模型判断问题。90% 可达，但需要清洗两个门店的历史标签数据——这份数据在贵方运营系统里，需要运营团队配合。"——把承诺、差距、以及差距里属于对方的部分，一次说清。
8.1.4 沟通节奏：让预期管理变成日常，而不是危机公关
预期管理做在平时，就不用在验收会上"救火"。给一个 FDE 可用的最小沟通节奏：
- 周报（每周）：评估集跑分趋势 + 本周修了什么 + 下周计划。半页纸，别写长。
- 双周对齐会：过 bad case 共审清单，确认责任矩阵上有没有卡住的环节。
- 里程碑复盘（每月）：对照交付曲线，明确"现在在曲线哪个位置，离水位线多远"。涨了讲为什么涨，跌了讲为什么跌、多久能修回来。
一个反直觉的经验：**坏消息要趁小的时候说。**评估集跌了 3 个点，本周报里就写，附原因和修复计划——客户看到的是"这个团队对系统有掌控感"。等跌到验收线以下才说，客户看到的就是"这个团队在掩盖"。
预期管理的本质，是把"信任"从个人印象变成可审计的过程记录。你能拿出 12 周的周报、趋势图和 bad case 共审记录，验收会就从"辩论赛"变成"看图说话"。
8.1.5 阶段门：把曲线切成可以"停、看、走"的段
曲线管理光有水位线还不够，还需要"阶段门"（stage gate）——在曲线上预设几个决策点，到了点就停下来，双方一起决定是继续、加速还是回退。没有阶段门的项目，最常见的死法是"一路狂奔到验收，才发现客户对'好'的定义和你们从第一天起就不一样"。
阶段门和里程碑复盘的区别在于：复盘是"看数据、总结经验"，阶段门是"行使决策权"——它有明确的进入条件和通过标准，不通过就不过。给一个 Agent 项目在 W8 阶段可用的最小阶段门设计：
G0 试点启动门 G1 建议期门 G2 执行权门 G3 放量门
├────────────────┼────────────────┼────────────────┼──────→
│ 条件：评估集冻结 │ 条件：准确率≥水位线 │ 条件：采纳率+兑现率 │ 条件：灰度无回滚
│ 数据回填完成 │ bad case 分级完成 │ 达标、动作审计闭环 │ 财务口径确认
│ 双方签字确认口径 │ │ │
│ 通过→进入试点 │ 通过→进入建议期 │ 通过→开放执行工具 │ 通过→全量+进SLA
│ 不过→暂停扩数据 │ 不过→再修一轮 │ 不过→延长建议期 │ 不过→停在灰度每个门有三要素：进入条件（哪些硬指标必须达标）、决策人（谁是签字的那只手——G1 是数字化总监，G2 必须有 IT 负责人会签，因为涉及动作权限）、不过的后果（提前写清楚，避免到时候临时扯皮）。
沙盘里它是这样用的：数字化总监把验收标准提到"准确率 90% + 直接执行"之后，你把 G1 和 G2 拆开谈——"90% 是 G1 的门槛，我们承诺四周内爬到；'直接执行'是 G2 的授权，G1 通过之前不谈执行，先看建议期的采纳率。一次只开一道门，每道门都有数据背书。"这样把一个"加价的需求"翻译成了"两个有顺序的阶段"，客户的提标被接住了，你的交付风险没有被放大。
一个实践细节：阶段门的通过/不通过要在周报里公示。G1 差 2 个点没过，周报里写"未通过，缺 2 个点，bad case 主要是历史标签问题，修复预计 10 天，G1 延期一周"——客户对"有秩序的延期"的容忍度，远高于"含糊的再看看"。
8.1.6 常见的预期错位与拆解话术
W8 阶段客户的预期错位有几类高频形态，FDE 最好提前准备拆解话术，而不是会上现想。
**错位一："demo 那么好，怎么试点反而差了？"**本质是把"挑过场景的高水位"当成了基线。拆解话术："demo 是我们挑的 20 个最配合的场景，试点是真实流量的 2000 个场景。这就像驾校考试路线和早高峰的区别。评估集会把差距拆开给您看，哪些是模型问题、哪些是数据问题——上周的 bad case 共审里，13 条里有 9 条是历史标签数据的问题，正在和运营团队清洗。"
**错位二："友商说他们能到 95%。"**本质是口径不透明下的数字军备竞赛。拆解话术："95% 的口径是什么？分母是谁、谁打的标、什么时间窗？我们愿意和友商用同一套评估集跑一次对比——口径不明的 95% 和口径透明的 87%，后者才有资格进 SLA。"多数时候，对方给不出口径，话题自然回到你的评估集上。
**错位三："这个月能不能就上全量？"**本质是进度焦虑压过风险意识。拆解话术回到放权路径（8.3）："可以快，但快有代价。跳过建议期直接执行，等于跳过采纳率这道关卡——出错的动作会直接打到会员身上。建议期是三周，这三周买的是'全量之后不用回滚'。您要是愿意承担回滚成本，我们技术上能做，但我必须在会议纪要里写明风险。"最后一句不是威胁，是把决策权和决策责任一起交还客户——这正是双方责任矩阵的日常应用。
预期管理的最后一条心法：**承诺要留缓冲，但解释要给足透明。**说"下周二上线"之前先看自己的依赖清单（客户侧接口、测试环境、审批），每个依赖留 50% 缓冲；同时把"为什么需要这么久"的依赖链摊开给客户看。客户对慢的容忍度，远高于对"说到做不到"的容忍度——尤其在你前面已经有了一堆同行的烂尾案例背书的行业里。
8.1.7 要点总结
- 从能用到好用是曲线不是开关：demo 高开、试点回落、逐轮爬坡，要把这条曲线画给客户看。
- 评估集是甲乙双方的共同语言：定期跑分、bad case 共审、水位线，让"我觉得不好"变成"样本 X 判断错了"。
- 责任是双方的：FDE 管工程化质量标准与验收标准提案，客户管业务口径、验收签字、业务事实与配合。
- 沟通节奏制度化：周报 + 双周会 + 月度复盘；坏消息趁小说，主动透明是建立信任最快的方式。
参考资料
- Klarna AI assistant handles two-thirds of customer service chats in its first month — Klarna 官方新闻稿，本节及 8.5 案例的核心事实来源（首月 230 万次对话等）。
- OpenAI: Klarna's AI assistant does the work of 700 full-time agents — OpenAI 官方客户案例，说明"惊艳数据"如何被官方渠道放大，预期管理的外部参照。
- Building Effective Agents — Anthropic — Anthropic 官方工程博客，强调从简单可组合模式起步、逐步增强，与交付曲线的渐进思路一致。