灰度发布 = 新版本不一次性推给所有用户，而是先推给一小部分用户测试表现，没问题后再逐步扩大，最终覆盖全量用户。
简说：不 All in，先用 1% 用户测试，扩大再全量。
核心认知：AI 产品不是"上线即成品"，是"上线即起点"。上线只是产品研发的"考前预习"，运营迭代才是真正的"考试"。
在三阶段验证链路中的位置
灰度发布是 POC验证 → MVP验证 → 灰度发布 三阶段验证链的最后一环：
| 阶段 | 验证什么 | 失败怎么办 |
|---|---|---|
| POC | 技术可行性（这事儿能不能做出来） | 换技术方案或砍场景 |
| MVP | 用户意愿与商业价值（用户买不买账） | 回炉重做或转向 |
| 灰度 | 真实流量下的稳定性与效果（线上扛不扛得住） | 暂停扩量、回滚旧版 |
三段之间是漏斗关系，前一段不通过不应进入下一段。灰度的特殊性在于：它是 AI 产品**唯一暴露"评测集没覆盖到的真实场景"**的环节。
步骤总览
| 步骤 | 名称 | 核心问题 | 主要产出 |
|---|---|---|---|
| 1 | 版本准备 | 能不能安全上线？回滚预案有没有？ | 版本包、监控配置、回滚方案 |
| 2 | 小流量灰度（1%） | 真实用户会不会翻车？ | 实时监控数据、初步效果对比 |
| 3 | 逐步扩展（5% → 20% → 50%） | 每个量级稳吗？ | 各阶段对比数据、Badcase 清单 |
| 4 | 监控对比 | 新版 vs 旧版到底好不好？ | 双版本指标对比报告 |
| 5 | 全量发布（100%） | 全量后还稳吗？ | 旧版下线、持续监控 |
为什么 AI 产品对灰度的依赖比传统产品高 10 倍
| 维度 | 传统软件迭代 | AI 产品迭代 |
|---|---|---|
| 改动性质 | 改代码，行为可预期 | 改 Prompt，输出完全不同 |
| 测试覆盖 | 测试用例，bug 可发现 | 评测集再全，也有真实场景遗漏 |
| 回滚成本 | 回滚=改代码 | 回滚=评测集+Prompt+数据+储量回复 |
| 影响范围 | 功能，影响可控 | 用户对话行为，信任感、品牌影响 |
第一步：版本准备
版本打包、配置管理、监控配置、回滚方案。回滚预案必须在发布前演练过——临时写的回滚脚本本身就是风险。
第二步：小流量灰度（1%）
真实用户验证、实时监控、快速验证。这一步的目的是抓真实场景下被评测集漏掉的问题——比如某类口音、某种排版、某个时间段的流量特征。
第三步：逐步扩展
5% → 20% → 50% → 100%，每阶段监控、Badcase 分析、成功后扩大。
第四步：监控对比
核心对比：旧版本 vs 新版本；Badcase 分析；用户/成本/质量双监控。
第五步：全量发布
100% 全量、旧版本下线、继续监控、持续迭代。
黄金比例节奏（推荐）
| 阶段 | 流量 | 时间 | 关注指标 |
|---|---|---|---|
| 1 | 1% | 2-4 小时 | 效果≥+5% / 体验≥+15% / 成本≤-5% |
| 2 | 5% | 4-8 小时 | 效果≥+3% / 体验≥+10% / 成本≤-5% |
| 3 | 20% | 1-2 天 | 效果≥+1% / 体验≥+6%到+8% |
| 4 | 50% | 2-3 天 | 效果≥0% / 体验≥+3% / 成本≤0% |
| 5 | 100% | 3-7 天 | 全量无明显波动 |
没有灰度的 5 个真实灾难场景
- Prompt 优化上线，评测集准确率 89%→72%，3 小时后发现，损失大量用户投诉
- 模型升级：Claude Sonnet→Opus，效果好但 API 成本达到原来 5 倍，月度成本 ¥50 万
- 新 Agent 功能，导致用户 ×200，公司一夜亏 ¥10 万
- RAG 知识库更新，新文档对了，旧的 AI 开始胡说八道，大量错误答复
- 模拟微调国产模型，GPT 国际化产品英文能力下降，导致海外用户大批流失
运营迭代：AI 产品的"持续进化引擎"
运营迭代 = AI 产品上线后，通过持续监控、用户反馈、数据分析、版本更新，让产品效果不断变好、能力不断扩展、用户体验不断优化的全生命周期过程。
不重视运营迭代的 5 大灾难：准确率悄悄退化 / 用户反馈黑洞 / Badcase 积压 / 竞品超车 / 没有数据飞轮
传统产品的护城河在功能，AI 产品的护城河在持续迭代速度和数据飞轮。
PM 此阶段职责
- 定灰度节奏：根据改动风险（Prompt 微调 vs 换模型 vs 新功能）决定起步流量与扩展速度
- 定门禁指标：每个阶段的"放行/回滚"指标提前写死，不要现场拍脑袋
- 演练回滚：发布前必须验证回滚链路真的能用
- 盯 Badcase：1% 阶段的真实 Badcase 优先于评测集，因为它代表"评测集漏掉的真实场景"
- 决策放行/回滚：每阶段结束后基于数据决策，不被"已经投入了"绑架
协作对象：算法工程师、AI 工程师、运维、客服（用户反馈一线）
相关页面
→ 效果评测体系 → AI工程集成 → AI工程六大核心问题 → Badcase分析方法论 → MVP验证 → POC验证 → AIPM课程 Day2 → 2026-05-07 互联网产研到AI产研的变化和区别