“Bug 修复与改进”对发布说明，相当于”我们激动地宣布”对营销文案——告诉你你发布了，但没传任何信息。结果就是真正会读这些说明的核心用户开始跳过。能打的版本会点名特性、点名修复、链接到文档、还承认哪里翻车了。下面 12 个 Prompt 强制这种形态。长文版配 用 AI 写发布说明。
这套 Prompt 适合用在哪
- 移动 App 发布（App Store / Play Store）
- SaaS changelog 和站内 what’s new
- OSS 发布（GitHub releases 页）
- 内部发布通知（Slack / 邮件）
- 大版本迁移指南
1. 标准 3 节 release notes
下面是 {version} 的工程 changelog。请按此结构写面向用户的发布说明：
- 新增（3-5 个最面向用户的新增，点名，每条 ≤25 字）
- 改进（3-5 个能感知到的改进，不要内部重构）
- 修复（3-5 个具名 bug，写用户看到的症状，不写工单号）
跳过噪声：依赖升级、CI 改动、内部重构、纯文档修改。
有独立文档页的特性给链接。
changelog：{粘贴}2. 有品牌语气的版本
品牌语气：{粘贴 2-3 句描述，或 1 个现有帖子作示例}。
下面是 changelog。请用该语气写发布说明。
约束：每条 ≤25 字、对话式不官气、不要"激动地介绍"、不要"颠覆性"等大词、点名具体特性和 bug。
changelog：{粘贴}3. 移动 App 发布说明（300 字符上限）
为 App Store / Play Store 发布说明，硬上限 300 字符。
请写 4 个变体总结本次更新。每个突出不同角度：
- 头牌新特性
- 用户抱怨过的修复
- 性能 / 速度
- 细节体验改进
每个给：300 字符文本 + 对应哪类用户。
changelog：{粘贴}4. 大版本公告
为大版本 {N.0} 写 200 字公告博客，结构：
- 第 1 段：最高层面变了什么（1 句框架 + 单个最大事件）
- 第 2 段：为什么做这个改变（解决的用户问题）
- 第 3 段：需要怎么迁移（迁移不简单就链接迁移指南）
- 第 4 段：这条线后续做什么
不要营销大词。对范围和取舍诚实。5. 破坏性变更段
下面是 {version} 的破坏性变更（粘贴）。请写"破坏性变更"段，每个变更按此结构：
- 坏了什么（改了哪个 API / 行为）
- 谁受影响（哪类用户，怎么判断自己中招）
- 迁移步骤（3-5 条具体命令或代码改动）
- 废弃时间表（什么时候开始 warn、什么时候真破、旧 API 什么时候完全消失）
- 为什么改（1 句，诚实）
破坏性变更：{粘贴}6. Beta release notes
{feature} 的 Beta 发布说明，要求：
- 第一行明确标 BETA 状态
- 点名要测什么（具体用户流程或特性）
- 列出已知问题（避免重复反馈）
- 给 1 个具体反馈渠道（issue tracker / 表单 / Discord）
- 设定预期：什么时候出 Beta、下一里程碑是什么
≤200 字。语气坦诚，不要营销腔。7. 不同受众版本
下面是 changelog。请给两类受众分别生成版本：
- 终端用户版：无技术词，聚焦"现在能做什么"或"以前坏的不再坏"
- 开发者 / 管理员版：完整技术细节、API 改动、配置项、废弃
同变更不同框架。交叉引用：用户版给开发者版链接，谁想看细节自己点。
changelog：{粘贴}8. 没大动作时的诚实版本
本次发布主要是小修和调整，没有新特性。
请写诚实的发布说明：
- 承认这是维护版本（不要硬吹）
- 挑 2-3 个对真实用户最重要的修复（不是内部最复杂的）
- 每条点名用户之前遇到的症状
- 末尾 1 行前瞻：下一个大动作是什么
changelog：{粘贴}9. 仅安全更新的发布说明
本次发布是安全修复。严重程度：{低 / 中 / 高 / 关键}。CVE 编号（若有）：{ID}。
请写发布说明：
- 开头点出升级紧迫性（不要制造恐慌）
- 用用户影响语言描述问题（攻击者本来可以做什么）——在补丁普及率上来之前不要透露利用细节
- 给确切升级命令
- 致谢报告者（若适用）
- 链接 CVE / advisory 给完整技术细节
安全问题：{粘贴}10. 回滚 / 热修复发布说明
{version} 引入了回归，已回滚。热修是 {hotfix version}。
请写发布说明：
- 公开承认回归（坏了什么、什么时候坏的、谁受影响）
- 解释热修（改了什么、为什么这次安全）
- 说明用户要做什么（自动升级 / 手动升级 / 无需动作）
- 1 行说"我们做了什么避免再发生"
诚实，不防御。用户欣赏坦白超过 spin。
回归细节：{粘贴}11. 从原始 commit log 生成
下面是 {tagA} 到 {tagB} 之间的原始 git log（粘贴）。
为每个 commit 分类：新增 / 改进 / 修复 / 内部（跳过）/ 破坏性。
不跳过的 commit，把 commit message 改成面向用户的一条 bullet。
输出：
- 建议发布说明（按类别分组）
- 单独列出你判为"内部"的 commit，让我核对
- 用户影响不清楚的 commit 标出来让我澄清
git log：{粘贴}12. 发布前审计
下面是 {version} 的发布说明草稿。请发布前审：
- 所有破坏性变更都顶部点出了吗？
- 内部改动（CI、重构）有漏进来吗？
- 每条修复写的是用户看到的症状，还是内部工单名？
- 文档链接是否活、是否指向正确锚点？
- 语气和往期一致吗？
每个问题给具体改写。
草稿：{粘贴}
往期参考语气：{粘贴}容易踩的坑
- “Bug 修复与改进”——零信号，核心用户彻底跳过这一栏
- 小变更用”颠覆性""革命性”——可信度透支会复利
- 漏写或把破坏性变更埋到”新特性”下面——保证产生愤怒工单
- 写内部工单 ID 而不是用户看到的症状——除了团队内没人能看懂
- 跨版本语气不一致（这周正式、下周开玩笑）——看着像没人负责