一句话总结
把 git log 或 Jira 的 Done 导出粘进下面的 Prompt，AI 会把工程黑话翻成用户收益，按新增 / 改进 / 修复分桶，并丢掉内部噪音（依赖升级、lint 修复）。你只需手动做三件事：用 [BREAKING] 预标 breaking change、删掉模型给收益不清晰的 ticket 硬编的”收益”、最后过一遍语气。截至 2026 年 6 月，Claude Sonnet 4.6 或 GPT-5.5 一次就能吃下 92 条 commit 的 log——1M token 和约 320 页的上下文窗口意味着你基本不用分块。
任务场景
周五下午 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 的用户面收益不清晰，直接删掉，不要编。“
用哪个模型（2026 年 6 月）
一份 sprint 结束的 log 就是一次性的摘要活，三个前沿模型都干得不错：
| 模型 | 上下文（应用内） | 为什么选它 | API 价格（$/1M 进/出） |
|---|---|---|---|
| Claude Sonnet 4.6 | 1M token | 语气最克制最贴品牌，最不爱硬编收益 | 3 / 15 |
| GPT-5.5（Thinking） | Plus 约 320 页，$200 Pro 上 1M | 把乱 commit 聚成干净桶的能力最强 | 5 / 30 |
| Gemini 3.1 Pro | 1M token | API 最便宜；已经在用 Workspace 就顺手 | 2 / 12 |
92 条 commit 加上一版 release notes 远不到 2 万 token，所以上下文大小基本不是瓶颈——语气控制才是。默认推荐 Sonnet 4.6（免费档，或 Claude Pro 20 美元/月拿更高额度），因为它能稳住克制的语气，不会飘成”激动人心的更新！“那种腔。如果你想把这套接进 CI 而不是手动粘贴，就按上面表里的 API 价格做预算；按每百万输入 token 约 3 美元算，一整年每周发一次的开销还不到一顿午饭钱。
需要先给 AI 的信息
- 完整 changelog 或 Jira 导出（粘原文——模型会读 label、component、严重度）。喂 PR 标题和描述，别喂原始 diff——前者带着模型需要的”人意图”。
- 受众层级：终端 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]把 changelog 分类映射到用户分节
如果你团队已经在用 Keep a Changelog，你就有六个机器可读的桶。给人看的 release notes 会把它们压成三类。把这个映射告诉模型，免得它把你还没披露的 Security 条目 surface 出来：
| Keep a Changelog 分类 | 用户面分节 | 说明 |
|---|---|---|
| Added | 新增 | 以动词开头，不是 feature 名 |
| Changed / Deprecated | 改进（若 break 则归 Breaking） | Changed 的 API 合约通常就是 breaking change |
| Removed | Breaking | 任何移除都要配一行迁移说明 |
| Fixed | 修复 | 只放用户能感知的现象 |
| Security | 披露前压住 | CVE 公开后才 surface |
版本号本身就告诉你有没有可能存在 Breaking 分节。按 语义化版本 2.0.0，MAJOR 进位（1.x 到 2.0）代表向后不兼容的变化，MINOR 加向后兼容的功能，PATCH 只修 bug。一个 2.4.1 版本里不该有 breaking change——如果你的 changelog 暗示有，那是版本号错了，值得在 release notes 发出去之前抓住。
输出示例
一段好用的头条 + 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 不用写。
- 哪个模型写出来最贴品牌？ —— 截至 2026 年 6 月，Claude Sonnet 4.6 最能稳住克制、干的语气，也最不爱硬编收益；GPT-5.5 Thinking 把乱 commit 聚桶聚得最干净。给两个喂同一句品牌语气示范，选那个改得最少的草稿。
- 能接进 CI 自动跑，不用手动粘吗？ —— 能——每次打 tag 发布时用同一个 Prompt 调模型 API。按上面表里的按 token 价格做预算（Gemini 3.1 Pro 最便宜，$2/$12 每 1M）。git 历史里用 Conventional Commits 能让 AI 的归类明显更准。
- 截图 / GIF 呢？ —— “新增”项有用（尤其是用户要自己发现的流程）；“修复”项跳过——它的价值就是”现在好了”。视觉流程的话，一个 GIF 顶 50 字描述。
- Release notes 应该放 app 里还是 blog？ —— 都放，但只有一份是 canonical。Blog 是 canonical；app 内 changelog 链回去。搜索和 SEO 要长版；app 内只要短 list。