任务场景
把 commit 信息复制成 release notes 的版本，用户根本不会看。“修复 OrderService 中的空指针”对他们毫无意义，几次之后就再也不打开发布日志了。一份好用的发布说明是说”用户语言”的：先讲收益，只有用户在乎的时候再提实现，并且按”需要什么样的注意力”分组。
这一步翻译刚好是 AI 擅长的。给一份干净的 changelog 加一段受众描述，它出的初稿 PM 改 10 分钟就能发，比从头写省一倍时间。
哪些情况适合让 AI 来做
- 工程团队每个冲刺末有 commit 信息或结构化 changelog。
- 清楚谁在读你的 release notes（管理员 / 终端用户 / 开发者）。
- 至少月更，需要一套可复用流程。
什么时候不要完全依赖 AI
AI 不知道哪些功能在做灰度、哪些修复涉及敏感披露（安全补丁的措辞要小心）、哪些改进只影响付费档。每一行都必须有一位人类 Owner（一般是 PM）审过再发。
它还有个习惯：过度承诺。没数字的”显著提速”是废话。如果你真有性能收益，就贴出真实百分比；没测量就别写这句。
需要先给 AI 的信息
- 自上一版本以来的完整工程 changelog 或 commit 列表
- 一句话描述受众（含技术水平）
- 语气（冷静 / 活力 / 正式 / 口语）
- 各项变更影响的付费档（如适用）
- 不能公开提及的内容（安全 / 合作方专属）
可直接复制的 Prompt
把以下工程 changelog 转成用户视角的发布说明。
受众：{audience}
语气：{tone}
产品：{product_name}
版本号：{version}
受影响付费档（已知）：{tiers}
不要公开提及：{do_not_disclose}
工程 changelog：
{changelog}
输出：
1. 标题一行：用普通话总结本次发布。
2. 新功能：每条包含
- 4-8 字的 benefit-led 标题
- 1-2 句描述用户能看见的变化
- 如果分付费档，注明
3. 改进：同样格式，针对让现有功能更好的项。
4. 修复：每条一行短句。把影响用户的修复聚到一起；
纯内部修复省略。
5. 已知问题：仍未解决、用户可能踩到的列出来。
6. 如果合适，加一句"下一步在做什么"。
规则：
- 先讲 benefit，不讲实现。
- 不要"超快""下一代"这种营销废话。
- 需要数字才可信的，要么补数字要么删句子。
- "不要公开提及"清单里的内容一律省略。建议让 AI 输出成什么样
- 标题
- 新功能
- 改进
- 修复
- 已知问题
- 下一步
这就是 Stripe、Linear、Figma 在用的结构。它有效是因为它对应用户扫读路径：先看标题、扫新功能、瞄一眼修复看有没有影响到自己、然后走。
怎么判断 AI 的结果能不能用
- 只读功能标题，每个能不能说清”用户得到了什么”。
- 任何百分比、耗时、数量，都对照真实测量数据。
- 把”不可披露”清单走一遍，确认没漏。
- 让 ship 了对应改动的工程师确认描述属实。
容易踩的坑
- 直接复制 commit 信息。
- 用户向和纯内部改动混在一起。
- 漏付费档说明——低档用户看到功能、点进去撞收费墙。
- 出大故障当天发新版本说明。能拖就拖。
下一步怎么改得更好
跟踪你 release notes 页面的读完率（多数文档平台都支持）。哪些区段被跳过——通常说明写得太技术。下个冲刺把这些反馈回 prompt 里。
FAQ
- 多久发一次合适？ 跟着发版节奏走。有料的话周更没问题；没料就月更。
- 要不要配截图？ 新功能和可见的 UI 改动要配。其他可选。
- 每个修复都列吗？ 不。只列影响用户的，纯内部的省。
相关阅读
标签: #工作流 #Release notes