发布太快与太慢都伤
- 太快 ✗：评测跑不充分、回滚预案缺失、用户被频繁打扰 ✔；
- 太慢 ✗：问题长期不修、改进堆积、团队失去节奏 ✔。
发布节奏应该由"风险与批次大小"决定 ✔，而不是由心情或日历决定 ✔。
一、按改动类型定节奏
| 改动类型 | 建议节奏 | 理由 |
|---|---|---|
| 提示词/参数微调 | 随时（走四道关 ✔） | 影响可评测、可回滚 ✔ |
| 模型版本更换 | 低频 + 灰度 ✔ | 影响面大、行为变化多 ✔ |
| 检索/切分变更 | 固定窗口（如每周一次 ✔） | 需要重跑索引、观察质量 ✔ |
| 界面/文案 | 可随时（但仍要过门禁 ✔） | 风险低 ✔ |
| 权限/额度/默认值 | 谨慎 + 提前公告 ✔ | 影响用户预期 ✔ |
关键：小步快跑用于低风险 ✔，低频有序用于高风险 ✔。
二、四条纪律（无论节奏）
- 一次只改一类 ✔（见检查清单那篇 ✔ —— 便于归因 ✔）；
- 每个批次可独立回滚 ✔（见灰度开关 ✔）；
- 发布说明带评测结论 ✔（见发布说明那篇 ✔）；
- 不在高峰前发布 ✔（尤其模型替换 ✔）。
三、"合并批次"与"拆分发布"
- 合并：多个小改动一起上 ✔（减少用户打扰 ✔）—— 但必须是互相独立的 ✔，否则归因不了 ✗；
- 拆分：一个大改动拆成几次上 ✔（每次范围更小 ✔）—— 但要注意中间态是否可用 ✔。
判断标准 ✔：每次发布后，如果指标变差，能否定位到具体某一项 ✔？
不能，就该拆 ✔。
四、该观测什么
- 发布频率与每次发布的规模（改动行数/文件数 ✔）；
- 发布后回滚率（高说明评测或灰度不足 ✔）；
- 发布后一周的失败类型变化 ✔；
- 用户投诉与发布时间的相关性（是否总在发布后 spike ✔）。
五、一条判据
你们上一次发布后指标变差 ✔，用了多久定位到原因 ✔？
超过一天，说明批次太大或改动混合了 ✗。