“Bug 修复与改进”之于发布说明，就像”我们激动地宣布”之于营销文案——它告诉你发布了，却没传递任何信息。结果是真正会读这些说明的核心用户开始跳过整栏。好的发布说明会点名特性、点名修复、链接文档，并承认哪里翻了车。下面 12 个 Prompt 强制这种形态。长文版可搭配 用 AI 写发布说明。
一句话总结
- 把你的原始工程 changelog 或
git log粘进这些 Prompt，就能得到按”新增 / 改进 / 修复”分组、并自动剔除噪声（CI、重构、依赖升级）的面向用户版本。 - 标准 SaaS changelog 用 Prompt 1；App Store / Play Store 的更新框用 Prompt 3（截至 2026 年 6 月，Google Play 每个语言的发布说明上限是 500 字符）；有东西破了用 Prompt 5。
- 任何当前模型都能胜任。批量改写我们用 Claude Sonnet 4.6 或 GPT-5.5；破坏性变更和安全这种”用错一个词就来工单”的场景，用 Claude Opus 4.7。
- 几条不可让步的原则（来自 Keep a Changelog 标准）：写用户看到的症状（不是工单号）、破坏性变更放最上面、每个版本结构保持一致。
该用哪个模型跑
这些 Prompt 都很短、素材又是你自己的 changelog，所以选模型主要看成本和判断力，而非纯能力。截至 2026 年 6 月：
| 模型 | 适合 | 备注 |
|---|---|---|
| Claude Sonnet 4.6 | Prompt 1、2、7、8、11 的默认主力 | 免费档够轻量使用；Claude Pro（$20/月）已含 |
| GPT-5.5 | 同样的批量活，兼做语气第二意见 | 约 2026 年 4 月起为 ChatGPT 默认；免费档限额很紧 |
| Claude Opus 4.7 | Prompt 5（破坏性）和 9（安全） | 一句话失误会引发工单或风险时，多花的钱值 |
| Gemini 3.1 Pro | 批量改写，1M token 上下文 | 粘很长的多版本日志时好用 |
Prompt 本身的措辞越短越具体越好：粘进真实素材、点名要的输出结构、写清要跳过什么。
这套 Prompt 适合用在哪
- 移动 App 发布（App Store / Play Store）
- SaaS changelog 和站内 what’s new 面板
- 开源发布（GitHub Releases 页）
- 内部发布通知（Slack / 邮件）
- 大版本迁移指南
下面每个 Prompt 里，把 [方括号] 占位符换成你自己的内容。
1. 标准 3 节 release notes
下面是 [version] 的工程 changelog。请按此结构写面向用户的发布说明：
- 新增（3-5 个最面向用户的新增，点名，每条 <=25 字）
- 改进（3-5 个能感知到的改进，不要内部重构）
- 修复（3-5 个具名 bug，写用户看到的症状，不写工单号）
跳过噪声：依赖升级、CI 改动、内部重构、纯文档修改。
有独立文档页的特性给链接。
changelog：[paste]2. 有品牌语气的版本
品牌语气：[粘贴 2-3 句描述，或 1 个现有帖子作示例]。
下面是 changelog。请用该语气写发布说明。
约束：每条 <=25 字、对话式不官气、不要"激动地介绍"、不要"颠覆性"等大词、点名具体特性和 bug。
changelog：[paste]3. App Store / Play Store 发布说明
请写本次更新在应用商店的"What's New"文案。
硬上限：500 字符（Google Play 的上限）；App Store 上只有前约 100-150 字符会显示在"更多"之前，所以把头牌放最前。
请写 4 个变体，每个用不同角度开头：
- 头牌新特性
- 用户抱怨过的修复
- 性能 / 速度
- 细节体验改进
每个给：不超过 500 字符的文本 + 对应哪类用户。
changelog：[paste]4. 大版本公告
为大版本 [N.0] 写 200 字公告博客，结构：
- 第 1 段：最高层面变了什么（1 句框架 + 单个最大事件）
- 第 2 段：为什么做这个改变（解决的用户问题）
- 第 3 段：需要怎么迁移（迁移不简单就链接迁移指南）
- 第 4 段：这条线后续做什么
不要营销大词。对范围和取舍诚实。5. 破坏性变更段
下面是 [version] 的破坏性变更（已粘贴）。请写"破坏性变更"段，每个变更按此结构：
- 坏了什么（改了哪个 API 或行为）
- 谁受影响（哪类用户，怎么判断自己中招）
- 迁移步骤（3-5 条具体命令或代码改动）
- 废弃时间表（什么时候开始 warn、什么时候真破、旧 API 什么时候彻底消失）
- 为什么改（1 句，诚实）
破坏性变更：[paste]6. Beta release notes
[feature] 的 Beta 发布说明，要求：
- 第一行明确标 BETA 状态
- 点名要测什么（具体用户流程或特性）
- 列出你已经知道的已知问题（避免重复反馈）
- 给 1 个具体反馈渠道（issue tracker / 表单 / Discord）
- 设定预期：什么时候出 Beta、下一里程碑是什么
<=200 字。语气坦诚，不要营销腔。7. 不同受众版本
下面是 changelog。请给两类受众分别生成版本：
- 终端用户版：无技术词，聚焦"现在能做什么"或"以前坏的不再坏"
- 开发者 / 管理员版：完整技术细节、API 改动、配置项、废弃
同变更不同框架。交叉引用：用户版给开发者版链接，谁想看细节自己点。
changelog：[paste]8. 没大动作时的诚实版本
本次发布主要是小修和调整，没有新特性。
请写诚实的发布说明：
- 承认这是维护版本（不要硬吹）
- 挑 2-3 个对真实用户最重要的修复（不是内部最复杂的）
- 每条点名用户之前遇到的症状
- 末尾 1 行前瞻：下一个大动作是什么
changelog：[paste]9. 仅安全更新的发布说明
本次发布是安全修复。严重程度：[低 / 中 / 高 / 关键]。CVE 编号（若有）：[ID]。
请写发布说明：
- 开头点出升级紧迫性（不要制造恐慌）
- 用用户影响语言描述问题（攻击者本来可以做什么）——在补丁普及率上来之前不要透露利用细节
- 给确切升级命令
- 致谢报告者（若适用）
- 链接 CVE / advisory 给完整技术细节
安全问题：[paste]10. 回滚 / 热修复发布说明
[version] 引入了回归，已回滚。热修是 [hotfix version]。
请写发布说明：
- 公开承认回归（坏了什么、什么时候坏的、谁受影响）
- 解释热修（改了什么、为什么这次安全）
- 说明用户要做什么（自动升级 / 手动升级 / 无需动作）
- 1 行说"我们做了什么避免再发生"
诚实，不防御。用户欣赏坦白超过粉饰。
回归细节：[paste]11. 从原始 commit log 生成
下面是 [tagA] 到 [tagB] 之间的原始 git log（已粘贴）。
为每个 commit 分类：新增 / 改进 / 修复 / 内部（跳过）/ 破坏性。
不跳过的 commit，把 commit message 改成面向用户的一条 bullet。
输出：
- 建议发布说明（按类别分组）
- 单独列出你判为"内部"的 commit，让我核对
- 用户影响不清楚的 commit 标出来让我澄清
git log：[paste]12. 发布前审计
下面是 [version] 的发布说明草稿。请发布前审：
- 所有破坏性变更都顶部点出了吗？
- 内部改动（CI、重构）有漏进来吗？
- 每条修复写的是用户看到的症状，还是内部工单名？
- 文档链接是否活、是否指向正确锚点？
- 语气和往期一致吗？
每个问题给具体改写。
草稿：[paste]
往期参考语气：[paste]容易踩的坑
- “Bug 修复与改进”——零信号，核心用户彻底跳过这一栏。
- 小变更用”颠覆性""革命性”——可信度透支会跨版本复利。
- 漏写或把破坏性变更埋到”新特性”下面——保证产生愤怒工单。按 Keep a Changelog 标准，破坏性变更放最前。
- 写内部工单 ID 而不是用户看到的症状——除了团队内没人能看懂。
- 跨版本结构不一致（这周正式、下周开玩笑；段落顺序乱换）——读者找不到地图，看着像没人负责。
- 跳过版本号契约。按 语义化版本，MAJOR 升号代表破坏性变更、MINOR 加向后兼容特性、PATCH 只修 bug；让你的说明对得上这份承诺。
常见问题
应用商店发布说明到底能写多少字符？ 截至 2026 年 6 月，Google Play 每个语言的”What’s new”发布说明上限是 500 字符，Apple App Store 的”What’s New”字段允许最多 4,000 字符。iOS 上的实际限制比技术上限紧得多：只有前约 100-150 字符会显示在”更多”链接之前，所以一定把头牌放最前。Prompt 3 直接对准两家都满足的 500 字符安全线。
该用哪套 changelog 分类？ 广为采用的 Keep a Changelog 标准定义了六类：Added、Changed、Deprecated、Removed、Fixed、Security。Prompt 1 里的”新增 / 改进 / 修复”是它更亲和的子集。选定一套，每个版本都保持一致。
该让 AI 写最终稿，还是只写草稿？ 当草稿用。模型擅长结构、分类和语气，但它不知道你的用户究竟抱怨过哪个修复，也判断不出某个”小”API 改动对某个关键客户是不是悄悄破坏性。务必人工过一遍，尤其是 Prompt 5（破坏性）和 Prompt 9（安全）。
这些能直接把原始 git log 变成发布说明吗？
能。Prompt 11 接收 git log [tagA]..[tagB] 的输出，把每个 commit 分类成 新增 / 改进 / 修复 / 内部 / 破坏性，再把保留的 commit 改写成面向用户的 bullet，并把含糊的标出来让你确认。
怎么让跨版本语气保持一致？ 粘一份往期发布作参考（Prompt 2 和 Prompt 12 都支持）。更好的做法是存一段简短的”语气”片段，每次复用，让措辞、格式和段落顺序都稳定。