半年前的发布说明，能否看出当时改了什么、效果如何、为什么这么改？
发布说明里该有"评测结论"
版本发布说明常写"优化了回答质量""修复若干问题" ✗ —— 这些话无法验证 ✔，
半年后回看也不知道当时到底改了什么、有没有效果 ✔。
把评测结论写进发布说明 ✔，改动就变成了可追溯的证据 ✔。
一、一条发布说明该有的六项
```
① 改了什么（一句话，具体到能力 ✔）
② 为什么改（动机 + 证据来源：事故/反馈/评测 ✔）
③ 评测结论（哪批评测集、指标前后、区间 ✔）
④ 影响面（哪些功能、哪些用户、要不要用户操作 ✔）
⑤ 回滚方式（怎么退回去 ✔）
⑥ 未解决（如实写 ✔）
```
第 ③ 项是分水岭 ✗→✔：有它才叫"发布说明" ✔，没它只是"变更通知" ✔。
二、评测结论怎么写（三条要求）
1. 带上对比基线（"相对上一版" ✔ 而不是孤立的绝对数字 ✔）；
2. 带上不确定（区间或样本量 ✔ —— 见小样本那篇 ✔）；
3. 带上失败类型变化（总量没变但编造变多，也是退化 ✔ —— 见失败分类 ✔）。
示例 ✔：
```
主指标：可接受率 88% → 91%（+3 点；n=120；净胜 4 条，区间跨 0，未达显著）
失败类型：格式错 -2 条；该拒答却作答 0 → 1 条（新增，已在冒烟集加重）
成本：单位成本 +6%（在预算 ×1.2 内）
```
这段比一千字"优化了体验"都有用 ✔。
三、让这件事不靠自觉
· 发布说明模板（六项固定 ✔ —— 与"改动检查清单"同一套 ✔）；
· 门禁挂钩（没有评测结论不许合并 ✔ —— 见发布门禁 ✔）；
· 集中存放（一处能看全部历史 ✔）；
· 季度回看（哪些改动真的有效？哪些白做了？✔ —— 这是很有价值的复盘 ✔）。
四、三个反模式
· 只写"优化/提升" ✗（无法验证 ✔）；
· 只给绝对数字 ✗（没有基线，无法判断好坏 ✔）；
· 报喜不报忧 ✗（失败类型新增也不写 ✔ → 后人踩坑 ✔）。
一条判据
> 随机打开半年前的一条发布说明 ✔，能否知道"当时改了什么、效果如何、为什么这么改" ✔？
> 不能，说明发布说明还没接入评测 ✗。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把提示词当接口来设计：输入输出契约
下一篇：AI 功能的并发控制：同一用户重复提交怎么办 →
第 139 / 171 篇