AI 功能的灰度开关设计：谁、什么时候、怎么关

上线是一组开关：总开关、版本切换、降级、流量比例、白名单、单请求上限。本文给出六类开关与作用、四条设计要求、权限划分、五个反模式与可直接抄的上线前检查清单。

"上线"不是一次动作，而是一组开关

AI 功能出问题时，最贵的成本是**反应时间** ✗：定位要多久、能不能马上关掉 ✔。

所以上线前必须把"开关"设计好 ✔ —— 它决定了你能否在 5 分钟内止损 ✔。

| 开关 | 作用 | 粒度 |

|---|---|---|

| 总开关 | 一键关闭该功能 | 功能级 |

| 模型/版本切换 | 切回旧模型或旧提示词 | 功能级 |

| 降级开关 | 强制走小模型/缓存/规则兜底 | 功能级 |

| 流量比例 | 灰度放量（1% → 100%）| 功能级 |

| 租户/用户白名单 | 只对内部或指定租户开 | 租户级 |

| 单请求上限 | 输入长度/输出长度/超时 | 请求级 |

**前三个是止损用的** ✔，后三个是控制影响面的 ✔；缺一个都会在事故里付出代价 ✔。

1. **生效快** ✔（秒级，不要重新发布 ✗ —— 发布要几分钟，事故里等不起 ✗）；

2. **可审计** ✔（谁在什么时候改了开关，记下来 ✔）；

3. **有默认值** ✔（配置缺失时取安全值：例如默认关闭新版本 ✔）；

4. **有演练** ✔（每季度真的关一次，确认能关掉 ✔ —— 没演练过的开关等于没有 ✗）。

**值班人可关** ✔（不需要审批 ✔ —— 止损优先 ✔）；

**开启需要审批** ✔（尤其是全量 ✔）；

关闭动作要**自动通知**相关人 ✔（避免"关了没人知道" ✗）。

**开关只在代码里** ✗（改开关要发版 → 止损要 20 分钟 ✗）；

**一个总开关管所有环境** ✗（测试环境一关，线上也关 ✗）；

**开关没有日志** ✗（不知道谁改的、什么时候 ✔）；

**开关太多且含义重叠** ✗（事故时不知道该关哪个 ✔）；

**从没演练过** ✗（真出事时发现开关失效 ✔）。

```

□ 总开关已就位且秒级生效 □ 演练过关闭流程

□ 可切回旧版本（模型+提示词） □ 降级链已配置

□ 灰度比例可调 □ 租户白名单可用

□ 单请求上限已设 □ 开关变更进审计日志

```

> 值班人**不看代码、不问人** ✔，能否在 5 分钟内把功能关掉或降级 ✔？

> 不能，就别全量上线 ✗。