发布说明（release notes）是对一次发布里「改了什么」的、给人读的总结——新功能、修复、破坏性变更——写给用产品的人，而不是造产品的人。这页把发布说明到底是什么、它和 changelog、发布计划有何不同、一份好的发布说明该包含什么讲清楚，并给你一份模板。然后是诚实的那部分：发布说明在上线那一刻写一次，随即就开始和它所描述的 spec 与决策对不上，因为没有任何东西把它连回去。
发布说明是面向用户、用人话写的「这次发布带来了什么」：新增了什么、改进了什么、修复了什么、以及任何需要用户采取行动的事（破坏性变更、迁移）。它的任务是让人不必读 commit 日志就能判断「这次更新我在不在意、我要不要做点什么」。好的产品发布说明以价值开头（「把 thread 导出为 PDF」），而不是实现（「加了一个 PDF 渲染服务」）。
它和两个常被混为一谈的东西不同。changelog 是简短、常面向开发者的「每一项改动」的流水清单（经常自动生成）。发布计划 是面向未来的文档——要发什么、何时、怎么灰度。发布说明是发布之后、回望的那份公告。
围绕一次发布的三种构件，容易混。区别在于受众和时间方向。
| 构件 | 给谁 | 方向 |
|---|---|---|
| 发布说明 | 用户 / 客户 | 回望——上线了什么 |
| changelog | 开发者，简短 | 回望——每一项改动 |
| 发布计划 | 内部团队 | 前瞻——将要发什么 |
这就是整份模板——它在应用内 changelog、邮件或文档页里都好使。下一节讲的是：当每一条说明连回它所描述的 spec 和决策时，会发生什么变化。
发布版本（或名称）和上线日期。其余一切都挂在这个锚点上，也是用户在反馈「上周二那个版本」上的问题时所引用的。
一两句话说清这次发布是关于什么的，以结果来表达。读者哪怕只读到这里，也该知道这次更新和自己有没有关系。
每个新能力都用用户的话讲——它让人能做什么，而不是它怎么实现。每条一两句，必要时链到更深的文档。
对既有行为的增强——更快、更清楚、更可靠。这是「我们听到了」那一节；尽量把它们连到促成它的反馈或请求。
用人话写值得一提的已修 bug。你不必列每一个补丁——只列用户注意到或问过的那些。
任何改变了他们所依赖行为、或需要迁移、重新登录、更新集成的东西。一旦适用，它就是最重要的一节——把它埋了，你就在制造工单。
这就是模板。下面：为什么发布说明会和「实际上线的东西」对不上——以及我们怎么让它保持一致。
发布说明是上线那一刻「这次发布本应是什么」的快照。但说明所描述的 spec、以及它底下的决策，一直在变——而没有任何东西把说明连回去。Draftlize 守住这条线。
在 Draftlize 里，发布说明不是凭记忆敲出的自由文本——它从真正上线的卡片生成：功能、修复、它们背后的决策。说明连到它所描述的 spec，于是「这次发布到底改了什么」是一次图查询，而不是在工单堆里做考古。
某个功能在上线前一天被撤，或某个决策在发布后反转。因为说明连着 spec，它自动标记 stale，而不是自信地公告一个根本没上线的东西——那个电子表格抓不到的、丢人的发布说明 bug。
让 Claude Code 或 Cursor 经 MCP 起草下一份发布说明，它读到的是这次发布里真正变动的卡片——于是草稿从决策和 spec 的真实差异出发，而不是某人在上线日傍晚五点重构出来的一份半记得的清单。
发布说明写一次、再不更新。麻烦在于它所描述的那次发布，一直变到上线那一刻。留着这个格式，让说明从「实际上线了什么」生成。
发布说明面向用户、经过编排——用人话解释一次发布意味着什么、以价值开头；changelog 是简短、常面向开发者、经常自动生成的「每一项改动」流水清单。发布说明是给用户的故事，changelog 是给造product 的人的记录。
发布计划面向未来——要发什么、何时、怎么灰度和回滚；发布说明回望——发布之后写「发了什么」。计划是内部的、执行性的，说明是对外的、公告形态的。
版本与日期、以价值开头的摘要、用用户话讲的新功能、改进、值得一提的修复，以及——一旦适用就最重要的——破坏性变更或需采取的行动。以「这次更新让人能做什么」开头，而不是「它怎么实现」。
匹配你的发布节奏。持续交付的团队常把用户可见的改动攒成周期性的汇总，免得每次部署都打扰用户；定期发布则每次发一份。原则是稳定，让用户学会去哪看。
用上面的模板，或让 Draftlize 从真正变动的卡片为每次发布起草说明——连着它们所描述的 spec，于是临门砍范围会去标记说明，而不是上线一句谎话。
$5 免费开始