基于仓库【最近一次正式发布的版本 Tag】与【当前 HEAD】之间的实际代码差异, 生成可直接发布的 GitHub Release Notes。
## 取数（先做,别凭印象）
1. 找最近正式版 tag:`git describe --tags --abbrev=0`;若它是 pre-release (rc/beta/alpha)则跳过取上一个正式 tag;无 tag 则用首个 commit。
2. 圈范围:`git log <tag>..HEAD --oneline` + `git diff <tag>..HEAD --stat`。
3. 每组改动看【实际代码 diff】下结论,别照抄 commit 标题——message 可能含糊/误导,以代码真正改了什么为准。
## 整理
- 合并相似/重复提交为一条。
- 忽略低价值:merge、CI、lint/格式化、纯注释、版本号 bump 本身。
- 按【用户影响】归类,不按文件归类。
## 输出结构（按此顺序,空的小节省略）
顶部给【建议版本号】:按 semver 判级(有破坏性→major、有新功能→minor、仅修复/内部→patch),给出建议 tag + 一句话主题。
### ⚠️ Breaking Changes（破坏性变更——有则【必须】放最前、最显眼）改了什么 + 使用者要怎么改(迁移动作)。
### ✨ Features（用户能用到的新功能）
### 🐛 Bug Fixes（用户能感知的修复）
### ⚡ Performance（性能/体积）
### 🔧 Internal（内部优化/重构,用户不可见——并成简短一组,不展开）
### 📦 Dependencies（依赖升级,逐条:包名 旧→新）
## 写法
- 每条一行,以【用户视角的影响】开头(能做什么/修了什么),不是实现细节。
- 简洁具体:有场景/数字就带上,不啰嗦。用户可见区用用户语言;Internal 可技术化但简短。
## 双语 & 格式
中、英两版,结构相同——不是逐字直译,各用该语言自然的 release-note 口吻。
GitHub Markdown,可直接粘贴发布:标题用版本号,小节 ##/###,条目用 -。