自动生成的 changelog 全是 chore: bump deps，对谁都没用。好的 changelog Prompt 要按用户影响分组（New / Improved / Fixed），去掉内部琐事，每条尽量控制在 15 字以内。下面 12 个模板就是为此而写，任何聊天助手都能用：把 git log 或 PR 列表贴进去，得到一份非工程师也读得懂的 release notes。
一句话总结
- GitHub 自带的「Generate release notes」会按 label 列出已合并 PR，但绝不会替你重写糟糕的 PR 标题。AI changelog Prompt 正好补上这一步，把 commit 翻译成用户语言。
- 按任务规模选模型：上百个 commit 的大版本需要 1M token 上下文（Claude Sonnet 4.6、Gemini 3.1 Pro，或 ChatGPT 的 $200 Pro 档）。每周三十来个 commit 的小版本，任何免费档都够用。
- 按影响分组，不按 commit 类型。永远把破坏性变更摆出来。一次发布尽量控制在 7 条左右。
- 把 AI 输出当初稿。发布前由人审定用户可见的那一行，并确认 SemVer 版本号。
适合哪些场景
每周发布的独立创业者、剪发布的 OSS 维护者、给帮助中心写说明的产品工程师、把内容同步到 changelog.com 的 DevRel。
GitHub 自动 notes 和 AI Prompt 的区别
GitHub 的自动生成 release notes 会按 label 把已合并 PR 列出来，附带贡献者署名和完整 changelog 链接，免费、一键。但它不会重写任何东西：PR 标题若是 WIP: fix thing，这串原样就进了 release notes。AI Prompt 则会读 diff 和元数据，判断这是 feature、fix 还是 chore，再用读者熟悉的口吻重写。实践上：用 GitHub 自动 notes 拿到原始 PR 清单，再跑一个 AI Prompt 在上面生成面向人的摘要。
什么时候不建议这样写 Prompt
别拿这套写大版本的市场稿，它针对增量；也别不经人审就自动发布。
Prompt 结构公式
每个 changelog Prompt 都要带这六个要素：
- 角色：模型扮演谁（发布作者 / changelog 编辑 / 剪发布的 staff 工程师）。
- 上下文：commit 范围 / PR 列表 / 标签 / 目标读者（终端用户还是客服）。
- 目标：一个具体可交付物，按用户影响分组的对外 changelog（New / Improved / Fixed）。
- 限制：模型不能做什么（别写 ticket 编号、别瞎造变更、别自动发布）。
- 输出格式：分组 bullets、keep-a-changelog 分区、markdown 表格、JSON、RSS 条目。
- 示例 / 信号：1-2 条「好 changelog」示例，或直接贴
git log的反例。
这套 Prompt 适合用在哪
- 每周 / 每次发布的对外 changelog
- 给客服 / 支持的内部 release notes
- 应用市场「What’s New」文案
- 应用内 changelog 弹窗
- 破坏性版本的迁移指南
12 个可直接复制的 Prompt 模板
每个模板用方括号占位符，比如 [commits]，发送前替换成你的真实数据。
1. commits → 用户视角 changelog
Turn these commits into a user-facing changelog grouped by: New, Improved, Fixed, Internal (collapsed). Drop conventional-commit prefixes. Each bullet 15 words or fewer, in active voice, present tense. Skip merge commits and chore: bump deps unless major.
[commits]可替换变量： [commits] 是 git log --oneline v1.0..HEAD 的输出。
2. PR → changelog
Read these merged PRs and produce a changelog. Group by user impact. Skip PRs labelled internal / chore / tests. For each entry: title rewritten to user perspective + (optional) one-line context. Don't list PR numbers in the user version.
[prList]可替换变量： [prList]，比如 gh pr list --state merged --json title,labels,body 的 JSON。
3. 诚实的破坏性变更说明
For this release, list ONLY breaking changes. For each: (1) what changed, (2) who is affected (users / API consumers / integrators), (3) action required, (4) deadline if soft-deprecation. Skip non-breaking. If none, output "No breaking changes." and stop.4. 营销级 changelog（克制）
Pick the 1-2 changes worth a marketing line. Criteria: visible to users, valuable to many, demoable. Write each as: 6-10 word hook + 1-sentence "why you care". No "now you can..." filler. Skip if no change meets criteria.5. 客服支持版 release notes
Internal notes for support: (1) New features they might get asked about, (2) Behaviour changes that look like regressions, (3) Known issues we haven't fixed, (4) Workarounds. Tone: practical, no jargon. 200 words or fewer.6. 应用内「What’s New」弹窗
Write 3 bullets for an in-app changelog modal. Each: 7-10 words, verb-first phrasing ("Save searches to revisit"). Skip technical jargon. Add a single "See full changelog" link line.7. 从 diff 推导迁移指南
For breaking changes in this diff, write a migration guide: (1) Each break, (2) Find: old usage / Replace: new usage with code snippets, (3) Estimated effort per consumer, (4) Deadline. No prose intro.8. Keep-a-changelog 规范
Format the changelog per keepachangelog.com 1.1.0: sections [Added, Changed, Deprecated, Removed, Fixed, Security]. Each entry is past tense. Omit empty sections. Header includes version + YYYY-MM-DD. No emojis.9. 双语 changelog
Produce a changelog in EN and ZH. Keep both lists structurally identical (same order, same count). Don't translate technical terms (API, OAuth, SDK). Keep date and version line identical.10. SemVer 影响分析
Given these commits, recommend the SemVer bump: MAJOR / MINOR / PATCH. Justify with a one-line list of breaking / additive / fix changes. Don't recommend MINOR just to feel impactful; accuracy wins.11. RSS / Atom 友好
Produce a single changelog entry suitable for RSS: (1) Title (70 chars or fewer), (2) Date in RFC 822, (3) Body in HTML with ul/li bullets, (4) Single canonical URL. No styling, no inline scripts.12. changelog 卫生审计
Audit the last 5 changelog entries: (1) Any conventional-commit jargon leaking through? (2) Any bullets over 20 words? (3) Any entry that should've been merged into another? (4) Any release missing a date? Output a cleanup list.changelog 选哪个 AI 模型（2026 年 6 月）
每周 20-50 个 commit 的小版本，任何免费档都够：这活儿短，难点在格式而不在推理。模型选择真正重要的，是版本大到整份 git log 加 diff 要塞进一个 Prompt 的时候。
| 模型 | 上下文 | 适合 | 备注（2026 年 6 月） |
|---|---|---|---|
| Claude Sonnet 4.6 | 1M token | 大型 monorepo 发布 | 免费档有限；Claude Pro $20/月含 Claude Code，可在终端跑这些 Prompt |
| Gemini 3.1 Pro | 1M token | 大 diff、API 最便宜 | Google AI Pro $19.99/月（原 Gemini Advanced）；API 每百万 token 输入/输出 $2/$12 |
| GPT-5.5 | Plus 约 320 页 | 润色语气、写市场句 | 完整 1M 应用内上下文仅 $200 Pro 档；Plus 为 $20/月 |
工具搭配：多数团队是「确定性生成器 + AI 重写」。release-please 和 Changesets CLI（2026 年 monorepo 发布的主流工具）会解析 Conventional Commits 自动定 SemVer 并草拟原始 CHANGELOG；之后你再跑上面的模板 1 或模板 8 来润色成人话。让确定性工具管版本号和日期，让模型管措辞。
容易踩的坑
- 直接贴
git log，chore: bump deps满天飞。 - 把 ticket 编号写进对外版本，用户根本不知道是啥。
- 小版本里用「Introducing…」这种 marketing 腔。
- 为了不丢脸跳过 breaking change，结果售后更累。
- 不写日期 / 版本，搜索不友好。
- 一次写超过 7 条，读者扫两眼啥都没记住。
- 不审核就自动发，错字和尴尬措辞溜过去。
优化技巧
- 按用户影响分组，不按 commit 类型。
- 每条尽量 15 字以内，狠下手裁。
- 永远列出破坏性变更：隐瞒的代价比坦白更高。
- 用现在时、主动语态（「Adds search to settings」，不是「Search was added」）。
- 双语保持两侧结构一致，避免翻译漂移。
- changelog 要可发现：app、README、docs 都要链接。
- 给实际发布 commit 打 tag，changelog 可从
git diff复原。
FAQ
- 要用 conventional commits 吗？ 建议用，便于自动分类。但发布前要翻成用户语言，「feat: add OAuth」不是给用户看的句子。
- 发布频率怎么定？ 和发布节奏一致。SaaS 一周一次，OSS 每个 tag 一次。
- 要列每个 bug 吗？ 只列用户感知到的；纯内部 bug 进折叠的 Internal。
- 安全修复怎么写？ 简短列出，必要时带 CVE 链接。补丁未广泛升级前别写攻击细节。
- 有了 GitHub release notes 还要 CHANGELOG.md 吗？ 建议留着：可搜索、可在 PR 里 review，也不绑定单一平台。
- SemVer 让 AI 决定吗？ 只让它建议，最终由人定，因为模型可能漏掉需要升 MAJOR 的细微行为破坏。
相关阅读
标签: #Prompt #编程 #Changelog #发布