Back to Details

deliver-release-notes

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

Release Notes

版本说明

Release notes communicate product changes to users in a way that highlights value and builds excitement. Unlike changelogs (which document what changed technically), release notes translate changes into user benefits. Good release notes help users discover new capabilities, understand improvements, and trust that issues are being addressed.
版本说明以突出价值、激发兴趣的方式向用户传达产品变更。与技术变更日志（记录技术层面的改动）不同，版本说明将变更转化为用户价值。优质的版本说明能帮助用户发现新功能、了解改进之处，并相信问题正在得到解决。

When to Use

使用场景

  • Shipping product updates to customers
  • Communicating changes to internal stakeholders
  • Preparing app store update descriptions
  • Writing customer-facing email announcements
  • Documenting changes for support and sales teams
  • 向客户发布产品更新
  • 向内部利益相关者传达变更
  • 准备应用商店更新描述
  • 撰写面向客户的邮件公告
  • 为支持团队和销售团队记录变更

Instructions

操作步骤

When asked to create release notes, follow these steps:
  1. Gather the Changelog Collect all changes included in this release: features, improvements, and bug fixes. Work from engineering changelogs, completed tickets, or pull request descriptions.
  2. Identify the Highlights Select 1-3 changes that deserve top billing. These should be changes users will notice and care about most. Lead with the most impactful change.
  3. Translate to Benefits Rewrite each change in terms of user value. Instead of "Added pagination to search results," write "Find what you need faster with improved search that handles large result sets." Focus on what users can now do or what's now better.
  4. Categorize Changes Group remaining changes into clear categories: New Features, Improvements, and Bug Fixes. Within each category, order by impact (most valuable first).
  5. Write Scannable Descriptions Each item should be 1-2 sentences. Lead with the benefit, optionally followed by the "how." Users scan release notes . make each line valuable.
  6. Acknowledge Known Issues If there are known limitations or issues, be transparent. Users appreciate honesty, and it reduces support burden.
  7. Tease Coming Soon (Optional) If appropriate, hint at what's coming next. This builds anticipation and shows momentum, but don't over-promise.
当需要创建版本说明时，请遵循以下步骤：
  1. 收集变更日志 收集本次版本包含的所有变更：新功能、改进点和 bug 修复。可参考工程变更日志、已完成的工单或拉取请求描述。
  2. 确定重点内容 选出1-3项值得重点突出的变更，这些应该是用户最容易注意到且最关心的内容。优先展示影响最大的变更。
  3. 转化为用户价值 以用户价值的角度重写每项变更。不要写“为搜索结果添加分页功能”，而是写“改进后的搜索支持处理大量结果集，帮你更快找到所需内容”。聚焦用户现在能做什么或哪些方面变得更好。
  4. 对变更进行分类 将剩余变更分为清晰的类别：新功能、改进点、Bug修复。每个类别内按影响程度排序（价值最高的在前）。
  5. 撰写易读的描述 每项内容应为1-2句话。先讲价值，可选补充实现方式。用户会快速浏览版本说明，所以每一行都要具备价值。
  6. 告知已知问题 如果存在已知限制或问题，请保持透明。用户欣赏诚实的态度，这也能减轻支持团队的负担。
  7. 预告后续计划（可选） 如果合适，可以暗示接下来的更新内容。这能提升用户期待，展示产品的发展势头，但不要过度承诺。

Output Format

输出格式

Use the template in 
references/TEMPLATE.md
to structure the output.
使用
references/TEMPLATE.md
中的模板来构建输出内容。

Quality Checklist

质量检查清单

Before finalizing, verify:
  • Highlights feature the 1-3 most impactful changes
  • Each item leads with user benefit, not technical description
  • Language is jargon-free and accessible to all users
  • Items are concise (1-2 sentences each)
  • Bug fixes mention the problem that was solved
  • Tone is positive and professional
最终定稿前，请验证：
  • 重点内容包含1-3项影响最大的变更
  • 每项内容先讲用户价值，而非技术描述
  • 语言无专业术语，所有用户都能理解
  • 内容简洁（每项1-2句话）
  • Bug修复说明提及已解决的问题
  • 语气积极且专业

Examples

示例

See 
references/EXAMPLE.md
for a completed example.
可查看
references/EXAMPLE.md
中的完整示例。