AI 功能的发布节奏：多久发一次比较好

太快与太慢都伤，节奏应由风险与批次大小决定。本文给出按改动类型的节奏建议、四条纪律、合并与拆分的判断标准与该观测的四个指标。

发布太快与太慢都伤

**太快** ✗：评测跑不充分、回滚预案缺失、用户被频繁打扰 ✔；

**太慢** ✗：问题长期不修、改进堆积、团队失去节奏 ✔。

**发布节奏应该由"风险与批次大小"决定** ✔，而不是由心情或日历决定 ✔。

| 改动类型 | 建议节奏 | 理由 |

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

| 提示词/参数微调 | **随时**（走四道关 ✔） | 影响可评测、可回滚 ✔ |

| 模型版本更换 | **低频 + 灰度** ✔ | 影响面大、行为变化多 ✔ |

| 检索/切分变更 | **固定窗口**（如每周一次 ✔） | 需要重跑索引、观察质量 ✔ |

| 界面/文案 | 可随时（但仍要过门禁 ✔） | 风险低 ✔ |

| 权限/额度/默认值 | **谨慎 + 提前公告** ✔ | 影响用户预期 ✔ |

**关键**：**小步快跑**用于低风险 ✔，**低频有序**用于高风险 ✔。

1. **一次只改一类** ✔（见检查清单那篇 ✔ —— 便于归因 ✔）；

2. **每个批次可独立回滚** ✔（见灰度开关 ✔）；

3. **发布说明带评测结论** ✔（见发布说明那篇 ✔）；

4. **不在高峰前发布** ✔（尤其模型替换 ✔）。

**合并**：多个小改动一起上 ✔（减少用户打扰 ✔）—— 但必须是**互相独立**的 ✔，否则归因不了 ✗；

**拆分**：一个大改动拆成几次上 ✔（每次范围更小 ✔）—— 但要注意**中间态**是否可用 ✔。

**判断标准** ✔：**每次发布后，如果指标变差，能否定位到具体某一项** ✔？

不能，就该拆 ✔。

**发布频率**与**每次发布的规模**（改动行数/文件数 ✔）；

**发布后回滚率**（高说明评测或灰度不足 ✔）；

**发布后一周的失败类型变化** ✔；

**用户投诉与发布时间的相关性**（是否总在发布后 spike ✔）。

> 你们上一次发布后指标变差 ✔，用了多久定位到原因 ✔？

> 超过一天，说明批次太大或改动混合了 ✗。