deliver-release-notes

发布说明

发布说明以突出价值、激发用户期待的方式，向用户传达产品变化。与记录技术变更的变更日志不同，发布说明会将这些变化转化为用户收益。好的发布说明能帮助用户发现新功能、了解改进，并相信问题正在得到解决。

适用场景

• 向客户发布产品更新
• 向内部相关人员传达变更
• 准备应用商店的更新说明
• 撰写面向客户的邮件公告
• 为支持和销售团队记录变更

不适用场景

• 你要向内部相关人员汇报进度，而不是宣布已发布的变更 → 使用 foundation-stakeholder-update
• 你需要为开发者记录技术变更 → 保留工程变更日志；此技能会将变更转化为用户收益
• 你要协调发布准备工作，而不是传达已发布的内容 → 使用 deliver-launch-checklist
• 没有发布任何用户可见的内容（纯内部重构）：为了找到收益而勉强撰写发布说明会损害信任；跳过本次发布说明，或将其纳入下一次发布

说明

收到撰写发布说明的请求时，请按以下步骤操作：

1. 收集变更日志 收集本次发布包含的所有变更：功能、改进和错误修复。参考工程变更日志、已完成的工单或拉取请求说明。

2. 确定重点内容 选出 1-3 项值得重点介绍的变更。这些应当是用户最容易注意到、最关心的变更。将影响最大的变更放在最前面。

3. 转化为用户收益 将每项变更改写为用户价值。不要写“为搜索结果添加了分页”，而要写“改进搜索功能，轻松处理大量结果，更快找到所需内容”。重点说明用户现在可以做什么，或哪些方面变得更好了。

4. 为变更分类 将其余变更归入清晰的类别：新功能、改进和错误修复。每个类别内按影响排序，最有价值的放在最前面。

5. 撰写便于浏览的描述 每项内容写 1-2 句话。先说明收益，可选择接着介绍实现方式。用户通常会快速浏览发布说明，因此每一行都应有价值。

6. 说明已知问题 如果存在已知限制或问题，请如实说明。用户会欣赏坦诚的态度，这也有助于减少支持工作量。

7. 预告即将推出的内容（可选） 如有合适内容，可简要透露下一步计划。这能激发期待并展现发展势头，但不要过度承诺。

输出格式

使用 references/TEMPLATE.md 中的模板组织输出。完整的发布说明应包含以下部分：重点内容、新功能、改进、错误修复、已知问题、即将推出的内容（可选）和反馈。

质量检查清单

定稿前，请确认：

• 重点内容涵盖影响最大的 1-3 项变更
• 每项内容都以用户收益开头，而非技术描述
• 语言不含行话，所有用户都能理解
• 内容简洁（每项 1-2 句话）
• 错误修复说明已解决的问题
• 没有泄露内部行话、工单 ID 或代号；每一行都适合面向客户

示例

请参阅 references/EXAMPLE.md 中的完整示例。