E6.15.3concrete update notes设计
更新说明应指出实际影响而非泛泛的优化用语
别名: 更新说明 · changelog UX · 体验优化
概念解释
更新提示里的说明要回答「我这边会有什么不一样」，不是发布团队的心情。「性能优化」「体验提升」「多项修复」不指出任何实际影响：哪个按钮换了、哪条快捷键废了、哪类文件现在能打开、哪项权限现在要重新给。没有具体影响的说明，可选更新没有决策依据，强制更新没有可理解的理由，静默更新之后也没有可查的线索。说明的读者是正在做事的人，不是商店页的浏览者。
机制
人用影响清单来决定现在更新、稍后、或去改自己的工作方式。泛泛用语无法进入这张清单，于是决策退回习惯：总是稍后，或总是马上点掉。具体影响把更新从态度问题变成任务问题——「导出 CSV 的列变了」会让正在做周报的人选择稍后；「旧版无法再保存」会让同一个人马上更新。说明还在更新之后承担检索：技能失灵时，人会去翻「最近改了什么」。翻到「多项修复」，检索失败，问题被归因到自己。影响要写在用户的对象和动作上，而不是写在组件和内部模块上。
边界
安全修复有时不能写细节（以免暴露未打补丁的洞），可以说「修复了一个安全问题，建议尽快更新」，这比「体验优化」具体，又不泄漏。一次发布改动极多时，说明应挑对当前用户角色有影响的几条，其余放进可打开的完整清单，而不是用「等更多」把所有具体都藏起来。本地化不能把具体对象名译回套话。开发者日志和用户说明不是同一份：commit 列表可以留在关于页，提示里只要用户动作级的那几条。
怎么落地
- 每条用户可见说明写成「什么对象 / 什么动作 / 怎样变了」；禁止单独成段的「优化」「提升」。
- 若这次对某类用户毫无可见影响，说明就写「修复稳定性，使用方式不变」，让人可以安心稍后。
- 更新后仍能从设置或关于页打开同一份说明，供技能失灵时回查。
- 验证：把说明念给没参与发布的人，问「你明天做事要改什么习惯」。答不出，说明就是空的。