"上线"不是一次动作，而是一组开关
AI 功能出问题时，最贵的成本是反应时间 ✗：定位要多久、能不能马上关掉 ✔。
所以上线前必须把"开关"设计好 ✔ —— 它决定了你能否在 5 分钟内止损 ✔。
一、该有哪些开关（六类）
| 开关 | 作用 | 粒度 |
|---|---|---|
| 总开关 | 一键关闭该功能 | 功能级 |
| 模型/版本切换 | 切回旧模型或旧提示词 | 功能级 |
| 降级开关 | 强制走小模型/缓存/规则兜底 | 功能级 |
| 流量比例 | 灰度放量（1% → 100%） | 功能级 |
| 租户/用户白名单 | 只对内部或指定租户开 | 租户级 |
| 单请求上限 | 输入长度/输出长度/超时 | 请求级 |
前三个是止损用的 ✔，后三个是控制影响面的 ✔；缺一个都会在事故里付出代价 ✔。
二、开关的设计要求
- 生效快 ✔（秒级，不要重新发布 ✗ —— 发布要几分钟，事故里等不起 ✗）；
- 可审计 ✔（谁在什么时候改了开关，记下来 ✔）；
- 有默认值 ✔（配置缺失时取安全值：例如默认关闭新版本 ✔）；
- 有演练 ✔（每季度真的关一次，确认能关掉 ✔ —— 没演练过的开关等于没有 ✗）。
三、谁有权关
- 值班人可关 ✔（不需要审批 ✔ —— 止损优先 ✔）；
- 开启需要审批 ✔（尤其是全量 ✔）；
- 关闭动作要自动通知相关人 ✔（避免"关了没人知道" ✗）。
四、常见反模式
- 开关只在代码里 ✗（改开关要发版 → 止损要 20 分钟 ✗）；
- 一个总开关管所有环境 ✗（测试环境一关，线上也关 ✗）；
- 开关没有日志 ✗（不知道谁改的、什么时候 ✔）；
- 开关太多且含义重叠 ✗（事故时不知道该关哪个 ✔）；
- 从没演练过 ✗（真出事时发现开关失效 ✔）。
五、上线前检查（可直接抄）
□ 总开关已就位且秒级生效 □ 演练过关闭流程
□ 可切回旧版本（模型+提示词） □ 降级链已配置
□ 灰度比例可调 □ 租户白名单可用
□ 单请求上限已设 □ 开关变更进审计日志
一条判据
值班人不看代码、不问人 ✔，能否在 5 分钟内把功能关掉或降级 ✔？
不能，就别全量上线 ✗。