目录一、先定规则AI 只写文案不碰仓库动作二、可复制 Prompt按 staged diff 用三、Conventional Commits 速查给 AI 也给你四、五个坑坑 1工作区全量当 staged坑 2一条 commit 揉进两件事坑 3复述 diff不写动机坑 4type 选飘坑 5自动提交 / 自动 push五、和 PR 描述怎么分工六、什么时候不用 AI小结写 commit message 这件事烦的不是「想不出来」是改了一堆文件之后已经懒得准确概括了。于是两种极端很常见要么随手来一句update/fix半年后git blame等于没有要么把 AI 生成的长文原样贴上去subject 80 个字body 里还在复述 diff 里一目了然的细节。这篇讲我怎么让 AI 写 commit以及五个真实踩过的坑。附可复制 Prompt 和 Conventional Commits 模板。一、先定规则AI 只写文案不碰仓库动作这是底线建议写进个人习惯甚至团队约定AI 可以做AI 不要做根据staged diff起草 message自动git commit除非你显式确认按团队规范改写 subject/body自动git push把乱七八糟的草稿收成规范格式擅自git add未审查文件提醒「这次 staged 像是混了两件事」改历史rebase/amend除非你要求一句话生成归生成提交的按钮永远在人手里。二、可复制 Prompt按 staged diff 用把git diff --cached的结果贴进去或让编辑器把 staged 变更喂给 AI根据下面的 staged diff写一条 Git commit message。 规范 - 使用 Conventional Commits - subjecttype(scope): 摘要不超过 72 字符祈使句不加句号 - type 仅用feat / fix / refactor / docs / test / chore / perf / ci - body 可选有则说明「为什么」和「影响」不要逐文件复述 diff - 中文或英文与团队现有 log 保持一致本仓库用____ 约束 - 只描述 staged 里真实存在的变更禁止猜测未出现的动机 - 若 staged 明显包含两件无关的事先指出并给出「拆成两条」的建议不要硬揉成一条 - 不要加入 Co-authored-by、emoji除非我要求 - 输出两个候选我来选 staged diff 粘贴 git diff --cached把「本仓库用」那一行改成中文或英文。候选给两条很有用一条偏短、一条带 body选起来快。我在 wescode 里会直接对当前变更说「按 Conventional Commits 写 commit message给两个候选」逻辑和上面一样关键是范围锁定在 staged别让它根据整个工作区幻想。三、Conventional Commits 速查给 AI 也给你type(scope): subject [body] [footer]常用 typetype何时用feat新功能fix修 bugrefactor行为不变的结构整理docs只改文档test只改测试chore构建/工具/杂项perf性能ciCI 配置好的 subject 例子feat(auth): 支持 refresh token 轮转 fix(download): 修复断点续传校验和为空 refactor(store): 拆分 ListBuilds 查询逻辑差的 subjectAI 也常写出来update code fix bug 优化了一些东西 Update auth.go and handler.go四、五个坑坑 1工作区全量当 staged未git add的文件、本地调试打印、半成品实验AI 若看到整个工作区会写进 message。结果是message 描述了你没打算提交的东西或反过来真正 staged 的要点被稀释。习惯先git add -p或按文件 add→ 再生成。只喂git diff --cached。坑 2一条 commit 揉进两件事改了登录又顺手格式化了无关包。AI 常会写feat(auth): 登录支持 MFA 并统一代码风格看起来完整回滚和 cherry-pick 会很痛。正确反应是让 AI 指出混杂然后拆 commit而不是追求「一条说完」。Prompt 里那句「两件无关的事先指出」就是为这个准备的。坑 3复述 diff不写动机AI 默认爱写- 修改了 a.go - 新增了 b.go - 删除了 c.go这是git show --stat就能看到的。body 该写的是为什么改缺陷表现、需求背景有意不做的取舍「暂不迁移旧接口」风险提示「需跑迁移」「兼容旧客户端」生成后扫一眼body 里如果全是文件名删掉重写「为什么」。坑 4type 选飘把「修文案」写成feat把「真的新接口」写成chore后面按 type 筛 changelog / 自动发版会乱。简单校准用户可感知的能力变化 →feat/fix只有开发者在意 →refactor/test/chore拿不准时看「用户会不会在发版说明里看到它」坑 5自动提交 / 自动 push部分工具或脚本支持「生成并 commit」。省事的代价是message 还没看就进历史了误 add 的文件一起进去了钩子lint-staged、测试失败时更难收拾我的做法永远先展示候选 → 人确认 → 再手动 commit。AI 加速的是措辞不是跳过审查。五、和 PR 描述怎么分工产物该写什么commit message这一小步「做了什么 为何」PR 描述整单动机、测试计划、风险、截图/关联 issue别让 AI 把 PR 长文塞进每一条 commit也别指望一条feat: ...能代替 PR。我的常用顺序本地多次小 commitAI 助写 message开 PR 时再让 AI 根据main...HEAD的 log diff 写 PR 描述PR 描述里单独要「测试计划」和「风险」commit 里不必重复六、什么时候不用 AI改动就一行、意图一眼能看清。自己敲fix(api): 纠正空指针更快。message 需要写进合规/审计语境。涉及安全修复措辞、对外披露口径时人定稿AI 最多给草稿。你还没 staged、自己都没理清改了什么。先整理 diff再写 message顺序反了AI 只会帮你把混乱写得很流畅。小结用 AI 写 commit message收益很大但只在三个前提下输入是staged diff不是整个乱七八糟的工作区输出遵守团队规范并且人确认后再 commit发现「一条里两件事」时选择拆分而不是硬概括Subject 写动机与范围body 写为什么别让 AI 当你的git status复读机。上面的 Prompt 和流程我是在日常提交里用的编辑器侧用的是 wescode官网是 weisyn.com。你们团队对 AI 写 commit 还有什么强制规范欢迎评论区贴出来一起抄作业。