用户更新说明

发版时你在对谁说

版本说明往往来自 git log、PR 标题或研发清单：重构、依赖升级、内部服务迁移——对终端用户要么看不懂，要么被写成「优化体验」「提升性能」这类无法核对的事实。应用商店、小程序公告和站内信需要的是用户能感知到的变化，以及升级后要不要重新登录、清缓存。

技能如何组织输出

输入通常是版本号、可选平台（iOS / Android / 小程序 / Web）、变更原文和语气偏好。技能会先把每条变更问一句：「用户怎么感知到？」再归入固定分区：

1. 新能力
2. 改进
3. 修复
4. 需要你做的事（无则写「无需额外操作」）
5. 已知限制（无则省略或写「暂无」）

技术表述会降级：例如仅在确有可感知结果时，才把支付模块重构写成「支付步骤更短」；纯内部重构且无 API 行为变化时，整区省略，不在可粘贴文案里写「本版本无」等元说明。还可附带 80 字内推送摘要与「待确认」清单。缺版本号或素材时会追问，禁止编造输入中未出现的功能。

适用边界

| 适合 | 不适合 |
| --- | --- |
| 手里只有 commit/PR 列表，要写成用户向更新日志 | 研发迁移手册、API breaking runbook、数据库升级步骤 |
| 发版前整理商店/公告文案 | 故障事中通报、营销种草长文 |

不写接口字段级 changelog，不代发商店，不联网抓仓库。全是内部重构时可输出极短说明并标明无可感知功能变化，不虚构卖点。