任务场景
周五下午 4 点，sprint 周一结束。Jira 的 Done 栏里 27 张 ticket，git log 92 条 commit、有一半是”fix lint”或”wip rebase”。PM lead 想在下班前看到 release notes 草稿。面向用户的变更是真的有——一个新的 bulk import 流程、search 变快、那个一直让你尴尬的 export 崩溃修了——但它们被埋在”重构 auth middleware”和”bump deps”下面。你要的 release notes 应该读起来像产品变好了，不是团队忙了。
什么时候适合让 AI 来做
AI 真的擅长把工程内部语言（“重构 auth middleware”）翻成用户收益（“登录更快更稳”），擅长把 30 条 commit 聚成 5-7 个用户可见的桶，并在”新增 / 改进 / 修复”之间保持一致的语气。它也能干净地过滤掉依赖升级之类的内部噪音——只要你告诉它什么算”用户可见”。
AI 做不到的：判断哪个是值得 surface 的 breaking change。这需要发布管理上下文——哪个 API 合约有外部依赖、UI 变化会不会让用户重新学习、support 团队这周还有多少 bandwidth。breaking change 必须在交给 AI 之前人工标好，否则会被埋进”改进”里，等 support ticket 涨起来才发现。
常见失败模式：AI 会乐于给”用户收益不清晰”的 ticket 编出一段收益说明（“改进了数据层” → “更快更顺滑的体验”——其实没任何性能 claim）。要明说：“如果某条 ticket 的用户面收益不清晰，直接删掉，不要编。“
需要先给 AI 的信息
- 完整 changelog 或 Jira 导出（粘原文——模型会读 label、component、严重度）
- 受众层级：终端 app、prosumer 工具、开发者 API，或三者混合（混合受众要分开写两份）
- 品牌语气——正式、随意、克制、俏皮——配一句示范句
- 已经人工预标的 breaking change（用
[BREAKING]标——任何需要用户迁移、重新学习、申请新权限的） - 哪怕小也要 surface 的项（一个用户催了很久的修复、一个有自己 GitHub 讨论的问题）
- 要压住不发的项（还没披露的安全补丁、还在内测的功能）
- 上一版的 release notes（用来保持语气连续性，并避免模型再 announce 一遍同一件事）
- 你最想 highlight 的那条用户收益——“如果只读一句话”的那一条
可直接复制的 Prompt
帮 {产品} 的 {x.y.z} 版本写 release notes。
受众：{终端 / prosumer / 开发者}。
语气：{品牌语气 + 一句示范}。
上一版 release notes（保持连续性，不要重新 announce）：{paste}
"如果只读一句话"的那条头条收益：{条目}
Breaking change（已预标，置顶 + 迁移步骤）：{清单}
Changelog：{paste 完整}
输出结构：
1）头条——一句话，直接点最大的那条收益。不要写版本号在头条里。
2）Breaking change（如有）——置顶，每条写：变了什么、影响谁、迁移步骤。没有就整节省掉。
3）新增——2-4 条。每条一句话、用户语言、≤25 字。开头是用户能做的那个动词，不是 feature 名。
4）改进——2-4 条。同格式。有数字（快了 X、小了 Y）就带上。
5）修复——2-4 条。只放用户能感知的 bug——纯内部修复不算。开头写用户注意到的现象，不是原因。
规则：
- 用户面收益不清晰的条目直接删，不要编。
- 把相关 commit 聚成一条（"export 崩溃修" + "export PDF 排版修" = "export 可靠性修复一组"）。
- 任何位置都不要写"Bug 修与改进"占位。
- 每条都要值得独占一行；重复的合或删。短版本——单段 patch note
这是一个 patch 版本（{x.y.z}）。写 60 字一段，只覆盖 1-2 条用户可见的变化。开头写用户注意到的现象。不分新增 / 改进 / 修复——一段就够。语气：{品牌}。
Changelog：{paste}输出示例
一段好用的头条 + breaking change 块：
“Bulk import 上线，10K item 以上的账号 search 速度约提升 3 倍。
Breaking change — API v1.4： /exports 接口现在返回 download_url 而不是 file_path。现有 integration 11/14 之后会 break。迁移：把 file_path 引用替换为 download_url（值格式一致）。1 行代码改动。需要更长窗口请联系。”
一条好用的”新增”：“最多一次性导入 10,000 行 CSV 或 Google Sheets——不用再 500 行一批了。校验在后台跑，导入时你可以继续干别的。”
一条好用的”修复”：“项目名带 emoji 或冒号时 export 不再崩溃。这个崩溃影响了约 4% 的 export；如果你上次失败是静默的，请再试一次。“
怎么改输出
- 以用户能做的动词开头 —— “每条改写成以用户能做的动作开头，不是 feature 名。‘Bulk-import 10,000 行’比’Bulk import 功能现已上线’强。”
- 删掉没收益的条目 —— “再过一遍 changelog，删掉所有用户收益靠脑补或一句话讲不清的条目。讲不清就不该出现在这里。”
- 有数字就 surface 数字 —— “如果改动有可量化提升（速度、大小、准确率），写出数字。‘Search 更快了’是废话；‘10K item 以上账号 search 快约 3 倍’是信号。”
- breaking change 正确置顶 —— “把每条
[BREAKING]移到最上，附迁移步骤和日期。它们不能藏在’改进’里——那是 support ticket 暴涨的源头。” - 每节砍到 5-7 条 —— “每节上限 5-7 条。多出来的放到’查看全部更新’里。长 list 会训练用户跳读。“
容易踩的坑
- “Bug 修与改进”占位——信号是零关心；哪怕一条具体修复也比这强
- 内部命名漏出——“OAuth middleware 重构”对用户毫无意义；上线前把每个术语翻成用户语言
- breaking change 埋在”改进”里——发布后 support 暴涨的最大原因；置顶 + 迁移步骤
- 给收益不清晰的 ticket 硬编收益——模型乐于干这事；明说”删掉，不要编”
- 重新 announce 上版已经发过的东西——发生在你没把上版 release notes 喂给模型时
- changelog 有 30 条就列 30 条——用户读不到第 7 条；剩下的放”查看全部”链接
- 没给品牌语气示范句——没有它模型默认写一种通用 SaaS 腔，不像你的产品
- AI 草稿不编辑直接发——release notes 是品牌 surface；一遍人工编辑（语气 + 准确性）是底线
FAQ
- 多久发一次 release notes？ —— 产品面变更每次发布都发（周或双周比较健康）。季度合成一份 “What’s new” 给市场和邮件用。
- patch notes 要不要？ —— 开发者面产品和 API 消费者要——他们预期看到每个行为变化。终端用户只在 patch 用户可见时写（崩溃修、UI 回归）。纯内部 patch 不用写。
- 截图 / GIF 呢？ —— “新增”项有用（尤其是用户要自己发现的流程）；“修复”项跳过——它的价值就是”现在好了”。视觉流程的话，一个 GIF 顶 50 字描述。
- Release notes 应该放 app 里还是 blog？ —— 都放，但只有一份是 canonical。Blog 是 canonical；app 内 changelog 链回去。搜索和 SEO 要长版；app 内只要短 list。
- 如果团队写 ticket 的方式不利于做 release notes 怎么办？ —— 给该入 release notes 的 ticket 打 label，并把”一句话给 release notes 用”作为 definition-of-done 的一部分。关 ticket 时 30 秒，省发布时 20 分钟。