版本发布说明 是做什么的？
将原始的 Git 历史记录转化为人类真正愿意阅读的发布说明。
功能
- 比较两个 Git 引用（标签、分支或
HEAD）之间的提交差异 - 按类型对变更进行分组：功能特性、Bug 修复、破坏性变更、杂项
- 从常规提交的
!标记和BREAKING CHANGE:脚注中检测破坏性变更 - 草拟重点变更部分（用户最关心的 3-5 个变更）
- 输出可直接用于 GitHub Release 的 Markdown 格式
使用方法
# 为即将发布的版本生成说明（上一个标签到 HEAD）
git log $(git describe --tags --abbrev=0)..HEAD --oneline
# 在两个标签之间生成
git log v1.2.0..v1.3.0 --pretty=format:'%h %s %b'
然后对 AI 助手说：“根据这些提交为 v1.3.0 起草版本发布说明。”
或者配合 GitHub CLI，直接进入发布草稿：
# 创建标签，然后根据差异生成发布说明草稿
git tag v1.3.0 && git push origin v1.3.0
gh release create v1.3.0 --generate-notes --draft
# 然后使用此技能完善生成的说明
处理流程
1. 收集提交
git log <上一个标签>..<新标签> --pretty=format:'%h|%s|%b|%an' --no-merges
如果仓库使用基于合并的工作流，应单独包含合并提交——合并标题通常比单个提交的信息更能概括 PR 的内容。
2. 对每个提交进行分类
| 前缀 / 信号 | 所属章节 |
|---|---|
feat、feat! | 功能特性 |
fix | Bug 修复 |
! 或 BREAKING CHANGE: | ⚠️ 破坏性变更（也会列在独立章节中） |
perf | 性能优化 |
docs、chore、ci、refactor、test | 归入“其他变更”或忽略 |
没有常规提交前缀的提交：根据消息内容进行分类。如果拿不准，宁可放在“其他变更”中，也不要静默丢弃。
3. 起草重点变更
挑选出对软件用户最关键的 3-5 个变更：
- 用户会注意到的全新功能
- 用户必须采取行动的破坏性变更
- 针对广泛报告问题的修复
每项用一句简单的话描述。避免使用营销形容词。
4. 编写发布说明
## v1.3.0
**重点变更**
- ...
- ...
### ⚠️ 破坏性变更
- ...
### 功能特性
- ...
### Bug 修复
- ...
### 其他变更
- ...
**完整变更日志:** <上一个标签>...<新标签>
5. 发布前的检查清单
- 每个破坏性变更都出现在 ⚠️ 章节中，并附有迁移提示
- 没有将仅供内部使用的杂项内容伪装成面向用户的功能特性
- 按照仓库惯例，对贡献者进行致谢
- 版本号与标签匹配
约定
- 如果仓库已有自己的版本发布说明风格，请遵循该风格——一致性胜过任何模板。
- 如果仓库使用
gh release --generate-notes，将其输出作为起始草稿并进行完善：它能正确列出变更列表，但重点部分通常不准确。 - 绝不发明提交范围中不存在的变更。当范围不明确时，应询问要比较哪两个引用，而不是猜测。