wang-q-l 发版说明撰写
支持两种受众版本
- 面向用户（外部）：App更新说明、产品公告、营销导向
- 面向团队（内部）：Changelog、技术变更记录、部署说明
工作流程
Step 1: 采集版本信息
用 AskUserQuestion 收集：
- 版本号？
- 主要更新内容（功能列表）？
- 受众（用户/开发团队/运营）？
- 发布渠道（App Store/微信公众号/内部系统）？
- 有无重要Bug修复或Breaking Change？
Step 2: 对外用户版本
写作原则：
- 用用户语言，不用技术术语
- 突出用户收益，而非功能描述
- 语气友好、简洁，控制在300字以内
- App Store 说明需简短（100-200字）
模板A：App Store 更新说明
v[X.X] 更新内容
[简短的整体描述，1-2句]
✨ 新功能
- [用户语言描述功能，聚焦用户收益]
- [新功能2]
🔧 优化改进
- [改进点，如"优化了搜索速度，让您更快找到想要的内容"]
- [改进点2]
🐛 问题修复
- 修复了[描述问题场景，如"某些情况下页面白屏"]的问题
感谢您的使用和反馈，如有问题请联系[联系方式]。
模板B：产品公告（微信/官网）
# [产品名] [版本号] 正式发布
[开头1-2句话，说明本次更新的核心价值/主题]
---
## 本次更新亮点
### [功能1名称]
[配图建议: 截图或示意图]
[描述用户能做什么，带来什么价值，2-3句话]
**如何使用**：[简短的操作引导]
---
### [功能2名称]
[同上格式]
---
## 其他优化
- [优化点1]：[简短描述改进效果]
- [优化点2]：[简短描述改进效果]
- 修复了[X个]已知问题
---
**如何升级**：[App端：前往应用商店更新 / Web端：刷新页面即可]
感谢每一位用户的陪伴与反馈，[下一步的期待或展望]。
[产品团队] | [日期]
Step 3: 内部技术 Changelog
# Changelog
## [版本号] - [发布日期]
### Added（新增）
- feat: [具体功能描述] ([issue/PR编号])
- feat: [功能2]
- feat: [功能3]
### Changed（变更）
- refactor: [变更描述] - 影响：[影响范围]
- style: [UI/样式变更]
### Deprecated（废弃警告）
- [接口/功能X] 将在 v[X+1] 中移除，请迁移到 [替代方案]
### Fixed（修复）
- fix: [Bug描述] ([issue编号])
- fix: [Bug2描述]
### Security（安全）
- security: [安全修复描述]
### Breaking Changes（破坏性变更）
⚠️ **需要迁移操作**
- [变更描述]
- **迁移方式**：[具体步骤]
---
## [上一版本号] - [日期]
...
Step 4: 内部发版通知（钉钉/飞书/邮件）
**[产品名] v[X.X] 已发布上线** 🚀
**上线时间**：[日期时间] **版本号**：v[X.X] **发布环境**：生产环境
---
**本次主要更新：**
1. [更新1]
2. [更新2]
3. [Bug修复：X个]
---
**需要关注：**
- ⚠️ [需要特别说明的注意事项，如有数据库变更、配置更新等]
- 相关业务方：[@相关人员]
**回滚预案**：[是否有回滚方案，联系人]
如发现问题请及时联系：[联系方式]
写作要点
用户版本写作技巧
把功能描述转化为用户收益：
- ❌ "新增批量导出功能"
- ✅ "批量导出报告，一次操作搞定月度总结"
避免的表达：
- 避免：性能优化、架构升级、代码重构（用户不关心）
- 改为：加载更快了、更稳定了
用数据说话：
- ✅ "搜索速度提升 60%"
- ✅ "减少了 80% 的重复操作步骤"
版本号规范（语义化版本）
- 主版本 X.0.0：不兼容的重大变更
- 次版本 X.Y.0：向后兼容的新功能
- 修订版 X.Y.Z：向后兼容的问题修复