用 AI 生成提交信息：让每次 commit 都讲清楚改了什么

好的提交信息是写给半年后的你和 review 你代码的同事的说明书：这次改了什么、为什么改、影响面多大。但写提交信息又烦又常被跳过，于是仓库里挤满了「 fix bug 」「 update 」这种事后谁也看不懂的废话。 AI 编程助手能把 git diff 直接变成清晰、一致的提交信息，还能按团队规范出力。本文讲清怎么用 AI 生成提交信息、怎么定规范、以及哪些事必须人来拍板。

为什么提交信息值得认真对待

提交信息是代码库的可追溯骨架。出了问题要 bisect 定位引入点、要写变更日志、要 review 别人的改动，第一步都是读提交信息。一句「修复了一个问题」等于没说，真正的事故复盘往往卡在「这行是谁、为什么改的」。把提交信息写好，不是形式主义，是给未来的自己省下几小时的考古时间。它和 AI 生成单元测试 是同一思路：用 AI 把重复又重要的活做扎实，人只管最关键的那层判断。

AI 怎么把 diff 变成提交信息

原理很简单：把本次改动的 git diff 喂给模型，让它总结「做了什么、为什么、影响面」。模型擅长从代码事实里提炼要点，比人空想快得多，而且风格天然统一。理想用法是让它出草稿，你过一眼再提交——既省时间又保留人的最终责任。对于跨文件的较大改动，模型还能把零散修改归并成一条有逻辑的提交，而不是你手动拼凑。

定一套规范，让 AI 照着写

没有规范，AI 每次写出来的格式都不一样，等于没用。最实用的是 Conventional Commits：用 feat、fix、docs、refactor 等前缀标明改动类型，再配一句话摘要。把这套规范写进你的提示词或 commit 模板，让 AI 每次都按同一套出力。规范定了，提交历史才可被工具解析、可自动生成 changelog 。

别让 AI 替你「编」动机

这是最容易翻车的地方。 AI 能看到「改了什么」，但看不到「为什么改」——那背后的业务背景、需求来源、权衡取舍，它一概不知。如果放任它补动机，它会编一个听起来合理的故事，而这个故事往往是错的。正确分工是：AI 只描述代码事实，动机由你补。生成的草稿里，事实部分可信，原因部分一定要人改。

接进工作流：钩子与 PR

别把生成提交信息当成偶尔手动跑一次。把它接进日常：用 prepare-commit-msg 这类 Git 钩子，在提交前自动填入 AI 草稿，你改完再确认；或在开 PR 时让 AI 把多次提交汇总成一段变更说明。无论哪种，AI 是助手不是替身——最终那行字得是你认可并愿意署名的。提交信息写好，AI 代码审查 时 reviewer 也能更快抓住重点。

常见坑与规避

• 太长或太短：一句话摘要讲清「什么」，正文补「为什么和影响」；别写成小说，也别惜字如金。
• 漏掉破坏性变更：有 breaking change 必须显式标出，否则别人升级时一头雾水。
• 把密钥写进信息：diff 里若误含密钥，AI 可能原样复述，提交前务必检查并轮换。
• 完全不信 AI：另一个极端是手写一切，等于放弃效率。草稿可信、动机人改，才是平衡。

常见问题