坑一：首档撞上关键客户
按比例随机切流量时，大客户往往因为调用量大而更容易被抽中。为什么首档要设白名单：问题直接落在收入贡献最高的客户身上，补救成本远高于内部试错；首档用白名单加组织维度排除关键客户。
坑二：观察时间不足
上午放量、下午看板正常就继续推，是常见做法，但很多问题只在特定时段或特定请求组合下出现。为什么至少要覆盖一个高峰：低谷期的数据量小，异常被稀释，指标看起来平稳，实际隐患并未被发现。
坑三：共用数据无法归因
新旧版本读同一份知识库、同一套提示词配置，出问题时无法判断是哪一版造成的。怎么做：版本可标记、可追溯，至少在日志里记录命中的版本；没有版本标记的灰度，本质上只是一次全量发布。
坑四：多变量同时改
灰度期间顺手调整了检索参数、换了模型、又改了话术，结果变好变坏都说不清。怎么做：每轮只改一个变量，其余冻结；确实要同时改的拆成两轮，用中间版本作对照，代价远低于事后重做。
坑五：没有明确的叫停人
值班工程师觉得该停，业务方觉得还能看，两边僵持时问题在扩大。为什么必须写名字：发布方案要写明谁有权叫停、在什么阈值下必须停，以及停止后由谁对外说明，一个名字最能缩短决策时间。
适用与不适用
适合谁
- 正在准备第一次灰度发布、缺少经验的团队
- 做过灰度但效果结论说不清楚的项目组
- 多团队协作、发布指令容易打架的组织
不适合谁
- 无监控数据、无法逐档判断的系统
- 影响面极小、可随时回退的单点功能调整
典型场景
某电商平台在大促前做搜索改版灰度。首档名单里原本包含两家头部商家，运营提出异议后改为内部账号加两个中小商家；第一档观察到第二天发现长尾词召回下降，停在该档并回退检索配置，第二轮只改排序权重后再放量，大促期间未出现搜索相关投诉。
可执行步骤
- 首档改用白名单加组织维度，显式排除关键客户与调用量较高的账号
- 为每一档设定最短的观察时长，并且必须覆盖一个完整的工作日高峰
- 在每个请求日志里记录命中的版本标识，确保出问题以后能够快速归因
- 每轮灰度只允许改动一个变量，其余配置全部冻结，并同时记录基线值
- 指定唯一的叫停人与停止阈值，并提前约定好对外统一使用的说明口径
常见坑
- 首档按调用量加权随机抽取，头部客户被优先抽中，问题直接暴露在最重要的合作方身上。
- 灰度期间顺手升级了模型版本，指标变化完全无法归因，最终只能整轮回退，从头再来一遍。
- 每档只观察了半天，数据量不足以支撑判断，全量后问题集中出现，回退又要协调多个团队。
- 叫停权分散在三个人手里，谁都可以说再等等，等决定下来时影响面已经扩到全部的用户。
自检与验收清单
- 首档名单是否已排除关键客户与调用量高的账号
- 每档最短观察时长是否覆盖一个完整的工作日高峰
- 请求日志是否记录版本标识，以支持事后归因
- 本轮是否只改动一个变量，其余配置是否已冻结
- 叫停人、停止阈值与对外口径是否已书面明确
常见问题
灰度被叫停算不算事故？
不算，属于预案生效。真正需要复盘的是为什么第一档没有拦住问题，比如观察时长不足或判据太宽。把叫停记录进台账并在复盘会上说明，比回避更能建立团队对流程的信任。
小改动也要分档吗？
可以只分两档，但不宜跳过。小改动的风险常被低估，尤其是提示词微调，影响面看起来局部，实际会改变全部输出的语气与口径；两档加一天观察，成本很低，却能拦住大部分低级问题。
灰度期间能修 bug 吗？
可以修缺陷，但要留记录并在修完后重跑本档观察。更稳妥的做法是把修复做成一个小版本，单独灰度一小批，避免在同一个观察窗口里既有原改动又有修复，导致指标无法解释。