产品更新日志
用户能看懂，且知道这次更新对自己意味着什么
根据下面的改动记录写一篇更新日志。读者是已在使用产品的普通用户。结构：1）一句话说这次更新最值得注意的变化；2）按「新增 / 改进 / 修复」分组，每条写「改了什么 + 对你有什么影响」，不用内部术语；3）单独列出需要用户动手的事（重新登录、改配置等）；4）已知问题。不要写「优化了用户体验」这种空话。 [粘贴改动记录]
使用建议
写完把「对你有什么影响」那栏遮住读一遍，读不通说明还在用内部视角。
适合什么场景
- 这次更新有二十多条提交记录，其中三条会改变用户的操作习惯，必须在发布前说清楚。
- 客服团队要拿这份日志回答提问：写不清楚，他们会自己编一个解释给用户。
不适合的场景
- 内部技术复盘（给工程师看）：需要提交号和方案取舍，用户视角的日志恰好把这些抹掉。
- 这次更新含价格或条款变更：那不是日志能承载的内容，需要单独的通知和确认流程。
示例
输入
fix: 修复导出 CSV 中文乱码 / feat: 支持手机改头像 / breaking: 登录有效期 30 天改为 7 天
你会得到
首句直接说「超过 7 天没打开，需要重新登录一次」；按新增/改进/修复分组，每条补一句影响（「手机上换头像不用再回电脑」）；单列一节「需要你动手」；不出现「优化了体验」这类空话。
常见误用
- 把提交记录原文贴进去：`refactor: 抽取 useAuth hook` 要么被写成用户读不懂的句子，要么被硬编成一句好话。
- 只写改动、不写影响：用户知道了「登录有效期调整」，却不知道明天会被登出，第二天全来问客服。
可以这样改
- 把「按新增/改进/修复分组」改成「只写最重要的三条」，适合发在应用内弹窗而不是文档页。
- 加「每条后面补一句：如果你什么都不做，会发生什么」，适合涉及配置或权限变更的版本。