自动生成的 changelog 全是 chore: bump deps，对谁都没用。好的 changelog Prompt 要按用户影响分组（New / Improved / Fixed），去掉内部琐事，每条 ≤ 15 字。
适合哪些场景
每周发布的独立创业者、剪发布的 OSS 维护者、给帮助中心写说明的产品工程师、把内容同步到 changelog.com 的 DevRel。
什么时候不建议这样写 Prompt
别拿这套写大版本市场稿——它针对增量。也别不经人审就自动发布。
Prompt 结构公式
每个 changelog Prompt 都要带这六个要素：
- 角色：AI 扮演谁（SRE / Release Captain / staff 工程师 / QA Lead）。
- 上下文：技术栈 / 分支 / 失败日志 / diff / dashboard URL。
- 目标：一个具体可交付物——根因、checklist、计划、ticket 列表、runbook。
- 限制：AI 不能做什么（别自动修、别瞎造文件路径）。
- 输出格式：编号清单、markdown 表格、JSON、unified diff、可运行代码。
- 示例 / 信号：1-2 条”好输出”示例，或反例。
这套 Prompt 适合用在哪
- 每周 / 每次发布的对外 changelog
- 给客服 / 支持的内部 release notes
- 应用市场”What’s New”文案
- 应用内 changelog 弹窗
- 破坏性版本的迁移指南
12 个可直接复制的 Prompt 模板
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, 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
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.6. 应用内 “What’s New” 弹窗
Write 3 bullets for an in-app changelog modal. Each: 7-10 words, with 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: 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), (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 last 5 changelog entries: (1) Any conventional-commit jargon leaking through? (2) Any bullets > 20 words? (3) Any entry that should've been merged into another? (4) Any release missing a date? Output a cleanup list.容易踩的坑
- 直接贴 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 复原。
实操加深
使用这些 prompt 时，不要只替换一个主题词就直接交付。围绕「Changelog 生成 Prompt：12 个让 release notes 有用的模板」先补齐受众、渠道、长度、语气、参考样例、禁止样式和成功标准，再让模型输出 2 个不同版本做横向比较。好的结果应该能被另一个人直接复用，而不是只有顺滑但空泛的表达。
如果输出看起来像通用模板，下一轮要增加一个真实场景、一个反例和一个可检查指标，例如点击率、转化动作、字数、平台限制或品牌禁区。这样改出来的内容才更像可用资产，而不是一次性的灵感草稿。
FAQ
- 要用 conventional commits 吗？: 建议——便于自动分类。发布前翻成用户语言。
- 发布频率怎么定？: 和发布节奏一致。SaaS 一周一次，OSS 每个 tag 一次。
- 要列每个 bug 吗？: 只列用户感知的；纯内部 bug 进 Internal。
- 安全修复怎么写？: 简短列出，必要时带 CVE 链接。补丁未广泛升级前别写攻击细节。
- GitHub Release Notes 有了还要 CHANGELOG.md 吗？: 建议有——可搜可在 PR 里 review。
- SemVer 让 AI 决定吗？: 只让它建议。最终由人定——AI 可能漏掉细微行为破坏。
相关阅读
标签: #Prompt #编程 #Changelog #发布