iDWong 流程位置：
dev-master阶段12 文档与发版（已不在pm-master流程内）；也可单点直接调用。 （两条流程的阶段号不同，按当前在跑的那条读。） 流程内落盘路径prd/release/release-notes-{产品名}-{版本}.md（流程门禁按 glob 匹配，命名带产品名/日期是正常的）。 本技能是纯对话输出不写文件，流程内使用时由流程代写到该路径。
发版说明撰写
支持两种受众版本
- 面向用户（外部）：App更新说明、产品公告、营销导向
- 面向团队（内部）：Changelog、技术变更记录、部署说明
Step 0: 主动扫描项目上下文（必须第一步，不要等用户提供）
不要等用户手动描述需求，先主动用工具扫描项目，找到已有文档后再开始工作。
扫描顺序（优先级从高到低）
| 优先级 | 文件类型 | Glob 查找方式 |
|---|---|---|
| 最高 | 需求说明书 | Glob("**/*需求*说明书*.md") / Glob("**/*spec*.md") / Glob("**/*requirement*.md") |
| 高 | 设计方案 | Glob("**/*设计*方案*.md") / Glob("**/*系统设计*.md") / Glob("**/*design*.md") |
| 高 | 功能清单 | Glob("**/*功能*清单*.md") / Glob("**/*功能清单*") / Glob("**/*feature*.md") |
| 高 | CHANGELOG | Glob("**/CHANGELOG*.md") |
| 中 | README | Glob("**/README*.md") |
| 低 | 路由配置 | src/router/modules/ |
| 低 | 项目代码 | src/views/、src/api/、src/mock/ |
扫描完成后
- 汇报找到了哪些文档（文件路径 + 一句话说明内容）
- 直接基于文档内容开始工作，不需要用户再重复描述
- 如果没找到任何文档，再用 AskUserQuestion 向用户询问必要信息
- 如果文档内容不足以完成任务，只询问缺失的部分，不要重复问已有的信息
工作流程
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：向后兼容的问题修复