写代码最难的部分不是写完，而是半年后回头查「这行是谁、为什么改成这样」。提交信息本该承担这个作用，实际却常常退化成随手一句「fix」或者「update」。好消息是，这件事恰好是 AI 最能帮上忙的一类活：它有耐心读完整段 diff，也不嫌麻烦把改动归纳成一句人话。
为什么提交信息值得花这点功夫
提交信息有三个读者：未来的你、一起改代码的同事、以及出问题时要把改动回滚的人。前两个读者靠它判断「这段逻辑为什么这么写」，第三个读者靠它决定「这次能不能先撤掉」。一句含糊的提交，会把上面三件事全部推给阅读源码，代价往往是十几分钟起步。
把这件事交给 AI，不只是省事。人写提交信息时习惯描述动作（改了哪一行），而规范的提交信息描述意图（解决什么问题）。请 AI 帮忙时，提示词天然会把关注点从动作往意图上推，写出来的东西反而更有信息量。
好的提交信息回答「为什么改」，而不是「改了哪几行」——行内容 diff 里本来就有。
先让 AI 看懂 diff，再让它写字
第一步是喂料。把暂存区的改动摘出来最合适：提交前跑一次查看暂存差异的命令，得到一段只包含本次要提交内容的文本，再交给模型。不要直接丢整个工作区的差异——那里混着还没写完的实验代码，模型会把它们当成已完成的功能去总结。
如果改动很大，一次性塞进上下文容易丢细节。更稳的做法是按文件分批，让模型先给每块一个短标题，最后再合并成一条总述。长 diff 里那些纯格式变化、依赖版本号变动，可以提前告诉模型允许忽略，输出会干净很多。
提示词里的四条规矩
第一，指定格式。常见的写法是「类型 + 范围 + 一句话摘要」，类型从固定几个里挑（功能、修复、重构、文档、测试、构建），摘要不超过五十个字符。格式定死之后，团队里所有人的提交看起来就像同一个人写的，归档和筛选都方便。
第二，只描述事实。明确要求模型不许编造业务背景，diff 里没体现的东西不写。第三，摘要用祈使语气，比如「补齐重试上限」，而不是「补齐了重试上限」，这样和自动生成的历史列表放在一起读起来更顺。第四，需要补充说明时另起一段写正文，讲清影响范围和需要注意的地方。
最后加一条兜底：如果改动混杂了好几个不相关的主题，让模型直接提示「建议拆成多次提交」，而不是硬凑一句。这一条能反过来帮你发现自己的提交粒度太粗。
接进日常流程的两种做法
轻量的做法是留在终端里：提交前把差异复制到一个脚本，脚本拼好提示词、发到 https://api.aigcbreeze.cn 的对话接口，把返回的第一行填进提交信息，剩下的写进正文。整个过程不到十秒，比自己组织语言还快。选模型时不必用最贵的那档，这类任务对推理深度要求不高，选一个响应快、上下文够装下 diff 的模型就够。
另一条路是放在流水线里：合并请求创建时自动生成变更说明草稿，人只需要审一遍、改掉不准确的地方。这条路的好处是变更说明和代码一起被评审，坏处是多了一层自动化的维护成本，小团队初期未必划算。
常见问题
让 AI 写提交信息，会不会把敏感内容带出去？
取决于你发出去的是什么。只发差异文本、不发完整仓库，风险就小得多；差异里也不要包含密钥、内部地址这类内容，提交前先自查一遍。团队如果有明确的数据规范，把规范直接写进提示词，比事后靠人盯更可靠。
生成的提交信息总是太笼统怎么办？
多半是 diff 太大或者太杂。先缩小到单次提交的范围，再在提示词里加一条「指出具体涉及的模块或函数名」，模型会从概括转向定位，信息密度立刻上来。还不行就换个思路：先让它列三条候选摘要，你挑一条再扩写。
中文还是英文写提交信息？
看协作范围。全中文团队写中文最好读；有外部协作者或者用了国际化工具链，英文更通用。关键是全仓库统一，混着写会在检索时制造麻烦。真需要两种语言，就让 AI 一次生成两条，别分两次请求。