此页面正在建设中！
请点击这里以获得帮助 大卫·麦克穆雷 支付他的网络托管账单：
捐赠您能够的任何小额金额！
在线技术写作将继续免费。
以下信息经appcues.com的文章授权改编（如下所引）。
为什么大多数版本更新说明无人问津（以及如何解决这个问题）
大多数发布说明很少被阅读。并不是因为用户不关心产品中发生了什么变化，而是因为这些说明是为发布功能的团队撰写的，而不是为需要理解它的人撰写的。
你可能以前见过这样的情况：一条发布说明以“实施了增强的数据持久层以提高吞吐量”开头，而用户实际上需要听到的是“你的报告现在加载速度快了一倍。”第一种说法只是勾选了一个框，而第二种说法则推动了使用和接受。
这个差距比大多数团队意识到的更重要。发布说明是产品沟通的时刻。它是交付与采用之间的窗口。做好它，用户会探索你构建的东西。错过了，这个功能就好像没有发布一样。
本文为您提供了弥补该差距所需的内容：13 个来自做得好的公司的发布说明示例（按每个示例的研究价值进行组织），一个您可以今天带走并进行调整的模板，以及一份涵盖基础知识的逐步写作指南。无论您是编写第一份发布说明的产品经理，还是正在完善流程的产品营销人员，您都会带走一些可以立即使用的内容。
发布说明是什么？
发行说明是与新软件或更新软件一起发布的简要用户报告。它解释了发生了什么变化，为什么这很重要，以及它影响谁。对于新版本，发行说明为用户提供了产品功能的概要。对于现有产品的更新，说明解释了自上一个版本以来有什么新内容，哪些地方得到了改善，以及修复了哪些问题。
版本说明示例，显示以前的版本
发布说明与变更日志
这些术语常常被混用，但它们是不同的。发布说明详细描述了特定版本或更新的内容：什么改变了，为什么重要，谁受到影响。理解变更日志与发布说明之间的区别是值得的：变更日志是所有发布说明随时间的记录。可以把它看作是档案。许多产品同时维护这两者：每次更新的独立发布说明，以及一个变更日志页面，将所有内容按时间倒序排列。
保持运行记录很重要。它向客户展示产品在不断改进，最近的变化是建立在之前的基础上的。它也表明公司听取反馈，并致力于用户体验。
发布说明的类型
不是每个更新都值得相同的对待。您的发布说明的格式和深度应与变更的范围相匹配：
主要版本说明：新功能、重要的用户界面变化、新能力。这些值得更详细的介绍，包括视觉效果、变更原因的背景信息，以及清晰的使用指南。
小更新说明：渐进式改进，细微的用户体验变化。通常每项内容一到三行，简洁格式最佳。
Bug修复说明：已解决的问题。列表格式，简单明了，重点是用户之前的体验与现在的变化。
安全补丁说明：简明扼要。优先说明被攻击的部分和修复的内容，避免复杂的技术细节造成混淆。
发布说明的重要性
它们是运输和使用之间的桥梁。理解变化的用户更有可能探索和采用新功能。发布说明是产品沟通的时刻，你将工程团队所构建的内容转化为用户实际想尝试的东西。没有这种转化，功能就会被忽视，功能的采用也会受到影响，因为你团队在构建它们上投入的努力无法实现其潜力。
它们减少了你的支持团队的工作量。主动发布的更新说明减少了关于为什么某些东西看起来或运作不同的来电咨询。当用户遇到未曾预料的变化时，他们会打开支持工单。若他们已阅读过清晰的解释，则不会。这个道理很简单：在用户遇到变化之前记录下这些变化。
他们建立了客户信任和忠诚度。可见的、定期的发布说明表明产品正在积极改进。对于评估是否续订或扩展的客户来说，健康的变更日志是产品在不断进步的证据。对于提交了功能请求的客户来说，看到他们的反馈反映在发布说明中会加深忠诚度。
它们提升了内部对齐。编写良好的发布说明的规范，特别是回答“发生了什么，谁受益，以及这为何重要”，迫使产品团队在整个组织内清晰沟通。当发布通讯简洁且一致时，产品营销、客户成功和销售都能受益。发布说明通常成为其他团队在与客户谈论新内容时引用的真实依据。
发布说明中应包含的内容
将其视为发布说明的结构。每份良好的发布说明都涵盖这些要素，尽管深度因宣布重大功能还是例行修复而有所不同：
标题行：产品名称、版本号或日期，以及相关环境（网页、iOS、API 等）。
更改摘要：这一版本主要解决了用户反馈的问题，影响所有使用该软件的用户。务必阅读以获取关键信息。
新功能：命名，并简要说明用户影响。开头说明用户现在可以做什么，而不是技术实现。
改善：从用户的角度看改变了什么。“搜索结果现在加载速度快40%”比“优化了搜索索引管道”更好。
错误修复：用简单易懂的语言描述用户之前的体验和现在的情况。“仪表板在按日期范围过滤时不再卡顿”清楚地告诉用户之前的问题以及已修复的情况。
已知问题或限制：如果某些问题尚未完全解决，请说明。用户更尊重透明度，而不是对不完美感到不满。
如何撰写发布说明
了解应包括什么是基础。你的写作方式决定了是否会有人真正阅读它。这七个步骤的顺序是为了流畅：先说内容，然后说表达方式，最后说如何呈现。
1. 关注用户，而不是功能
这是发布说明写作中最重要的原则。每个更改都是为了为用户解决问题或解锁功能。以此为先。
本能是描述你的团队所建立的东西。抵制这个冲动。相反，描述用户现在可以做什么（或不再需要处理什么）。
之前：“实现了可配置块大小的数据导出批处理。”
现在您可以导出大型数据集，而不会出现超时问题。以前在 10,000 行后失败的导出，现在可以处理多达 500,000 行。
第二个版本描述用户的体验。
2. 明确变更的意图
用户浏览发布说明时希望了解两件事：更改了什么，以及这是否影响他们。在每个项目的第一句话中让这两个答案都明显。
清晰度很重要，因为网络用户不会线性阅读。他们会扫描。因此，让你的发布说明易于扫描。突出重要的关键词。对功能名称和更改类型使用粗体字。将每行中最重要的信息放在前面。
修复了错误并应用了更新。
修复了一个导致在应用切换时意外崩溃的错误。现在，所有支持的设备上的应用切换都很稳定。
第一个版本很简短，但对用户没有任何帮助。第二个版本依然简洁，但回答了用户真正关心的问题。
使用简单明了的语言
发布说明可以有不同的目的：宣传新功能、建立与用户的关系、帮助人们找到解决方案。但当说明充满只有你的工程团队理解的技术术语时，这些目的都不起作用。
除非你知道你的听众能容易理解专业术语，否则请减少行业术语的使用。使用直白、易懂的表达方式。一个好的测试方法：将发布说明大声读给一个不了解技术背景的人听。如果他们能理解，你的用户也会明白。
之前：“我们已经实现了能够使用图形互换格式位图图像的功能，包括文件压缩、透明度、交错和在单个文件中存储多个图像，以供我们的消息服务使用。”
现在您可以在我们的消息服务中使用 GIF。
简单语言并不是在降低内容的深度，而是尊重用户的时间。
4. 为复杂的变化添加视觉效果
如果你的发布说明需要长篇文字解释，那就是添加视觉元素的信号。一个简短的 GIF 或带注释的截图展示功能运作，比两段关于任何 UI 更改的描述更能传达信息。
这特别适用于：
新的用户界面元素或布局更改（显示前后对比）
新的工作流程或多步骤功能（15秒的屏幕录制）
数据可视化功能（实际输出的屏幕截图）
视觉效果可以减轻读者的负担，使您的发布说明更易记忆。当变化本质上是可视化的时，应该以视觉方式展示它。
5. 整理以便扫描
用户在阅读大量文本时会感到麻木。保持内容有序和分段，使用副标题、类别、项目符号和段落间隔。将大块文本拆分有助于用户找到适合他们的变更，而无需阅读所有内容。
好的组织模式包括：
按类型对变更进行分组：新功能、改进、错误修复
使用标签或标记（如“新”、“改进”、“修复”）以便快速浏览
为只想要重点的用户在顶部添加简要总结。
使用可折叠部分来提供仅部分用户需要的详细技术说明
6. 使用模板并坚持它
一致性是一个特性，而不是限制。当您的发布说明遵循可预测的结构时，用户会知道在哪里寻找他们关心的信息。这样，他们将花更少的时间解析信息，而更多时间理解内容。
选择一个模板（下一部分有一个可以复制），为您的产品进行自定义，然后每次使用。这样也能加快您团队的写作过程，因为结构已经确定。
7. 匹配你的品牌声音，而不是你的工程声音。
您的发布说明应该听起来像您的品牌，而不是像提交信息。如果您的品牌温暖而亲切，那么您的发布说明也应该如此。如果您的品牌精确而专业，请与之相符。
关键在于真诚而不过度。你可以在不牺牲清晰度的前提下，添加个性。一点温暖会有很大作用，但过度自我宣传会破坏信任。一条有用的指导原则：80%的内容应是真正有用的信息，只有20%可以反映品牌定位或声音。
需要避免的内容：“我们在这里颠覆您的工作流程，这是我们每次更新成功做到的。谢谢您。我们的新热修复包括减少50%的能耗。”
修复：软件现在将最终用户的能耗减少了 50%。这是我们朝着更可持续未来努力的众多方式之一。
第一个版本夸大了品牌的效果并过度承诺，然后才提到改变。第二个版本先告诉你解决方案，然后自然地加入品牌角度。
发布说明模板
这是一个您可以复制和调整的发布说明模板。它涵盖了大多数更新的基本内容。根据发布的范围调整深度：主要版本对每个功能提供更多细节，次要版本可以压缩各部分，而仅修复错误的版本可以完全跳过“新内容”部分。
[产品名称] 发布说明 - [版本号或日期]
摘要：[1-2句概述此发布解决了什么问题以及影响了谁]
有什么新鲜事？
- [功能名称]: [它的作用及其对用户的重要性]
- [功能名称]: [它的作用以及对用户的重要性]
改善
- [改变了什么] - [这如何影响用户体验]
错误修复
- [用户之前的经历] - [现在发生的事情]
已知问题
- [问题描述] - [如果有，解决方法或时间表]
有问题吗？[帮助文档或支持联系方式的链接]
如何调整模板：对于包含三个新功能的重大版本，用每个功能的一段文字扩展“新内容”部分。对于包含五个小改进的小版本，可以将“新内容”和“改进”合并为一个列表。对于仅包含修复的版本，首先列出修复内容，完全去掉功能部分。结构应服务于内容，而不是反之。
13 个发布说明示例，按其最佳功能组织
以下示例分成五个类别，基于每家公司发布说明做得特别好的地方。对于每个示例，您将找到：公司做了什么、他们的发布说明做得好的地方，以及一个具体的、可转移的教训，您可以应用到自己身上。
相关信息
https://learn.microsoft.com/zh-cn/microsoft-365/copilot/release-notes?tabs=all 真实示例！ https://learn.microsoft.com/zh-cn/sharepoint/dev/spfx/release-1.23.0 真实示例！ https://slite.com/learn/release-notes https://documentero.com/templates/it-engineering/document/release-notes/ https://projectmanagers.net/7-free-release-notes-templates/ https://www.smartsheet.com/content/release-note-examples https://clickup.com/blog/how-to-write-release-notes/ https://www.releasenotes.io/ https://clickup.com/blog/release-notes-software/ https://www.launchnotes.com/blog/release-notes-examples https://www.geeksforgeeks.org/software-engineering/overview-of-software-release-note/ 13 个发布说明示例（以及它们有效的原因）. appcues.com由提供的信息和程序 admin@mcmassociates.io.