中文规范化提交信息助手

中文规范化提交信息助手#

把一次改动（diff、工作记录或口述）整理成规范 Git 提交信息。纯指令技能：不带脚本、不联网、不写任何文件，产出为可直接使用的提交信息文本。

输出结构#

<type>(<scope>): <主题>

<正文：为什么改、改了什么、影响面>

<脚注：BREAKING CHANGE / 关联工单>

type 选择表（按第一个匹配项选）#

| type | 用途 | 判断问题 | | feat | 新功能 | 用户能感知到新能力吗？ | | fix | 修缺陷 | 这是让错误的行为变正确吗？ | | perf | 性能优化 | 行为不变、只变快或变省吗？ | | refactor | 重构 | 既不加功能也不修缺陷吗？ | | test | 测试 | 只动测试代码吗？ | | docs | 文档 | 只动文档吗？ | | chore | 构建与工具 | 只动构建、依赖、配置吗？ | | ci | 持续集成 | 只动流水线配置吗？ | | revert | 回滚 | 是撤销某次提交吗？ |

规则#

• scope：受影响的模块名，小写；拿不准就不写；
• 主题行：祈使语气，结尾不加句号，全行不超过 50 字符；写结果不写过程，如「登录接口改用长连接」而不是「对登录问题做了一些处理」；
• 正文：回答为什么改、影响哪里、有什么风险；每行不超过 72 字符；没有值得说的就不写正文；
• 破坏性变更：正文开头写 BREAKING CHANGE: 并附迁移方法；
• 一个提交只做一件事：整理时发现功能与格式化混装，先建议拆分再分别生成。

正反例#

• 好：fix(auth): 修复刷新令牌过期后静默登出
• 坏：修改了一些bug（无类型、无范围、无信息量）
• 坏：feat: 新功能以及修复bug和更新依赖（一次提交混装多件事）

工作流程#

1. 读 diff 或听口述，判断 type 与 scope；
2. 写主题行，检查长度与语气；
3. 正文回答三个问题：为什么改？影响哪里？有什么风险？
4. 有破坏性变更或关联工单时补脚注；
5. 输出最终文本，并附一句「为什么选这个 type」的解释。