让 AI 写提交信息的正确姿势是：把暂存区的 diff 和团队的提交规范一起交给它，要求它描述“为什么改”而不只是“改了什么”，同时指出这次提交里是否混入了不相关的改动。 后一点往往比提交信息本身更有价值。

为什么提交信息值得认真写

半年后排查问题时，git log 和 git blame 是最常用的线索。“fix bug”“update”这样的信息几乎没有帮助。好的提交信息说明改动原因、影响范围和注意事项。

第一步：确定团队规范

许多团队采用 Conventional Commits 风格，例如：

<type>(<scope>): <简短描述>

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

<页脚：关联的 issue、不兼容变更说明>

常用 type 有 feat、fix、refactor、docs、test、chore。没有规范的团队，至少约定“标题一行说清改动、正文说明原因”。

第二步：获取 diff

git diff --staged

如果 diff 很长，可以加 --stat 先看涉及哪些文件，再分批提供。

第三步：提示词

以下是本次提交的 staged diff 和团队提交规范。请：
1. 判断这次 diff 是否包含多个不相关的改动，如果是，建议如何拆分成多个提交
2. 为每个（建议的）提交写一条提交信息，遵循规范
3. 正文说明“为什么改”，如果 diff 中看不出原因，用【原因待补充】占位，不要猜测
4. 指出可能需要在提交信息中提醒的风险（如配置变更、数据库迁移、接口不兼容）
规范：【粘贴】
diff：【粘贴】

示例输出（示意）

建议拆分：本次包含两类改动——登录超时逻辑修复，以及 README 格式调整，建议分为两个提交。

fix(auth): 延长会话刷新窗口，避免长表单提交时被登出

【原因待补充：关联的用户反馈或 issue】
将刷新判断从过期时才触发改为过期前提前刷新。
影响：仅 Web 端会话逻辑，不涉及移动端。

审查他人提交

在代码评审时也可以用 AI 检查提交信息与 diff 是否一致：

请对比提交信息和 diff，指出：提交信息未提到但 diff 中存在的改动；提交信息声称但 diff 中没有体现的内容。

注意事项

  • 原因必须由人补充：AI 只看得到代码，看不到需求背景。
  • 不要上传含密钥的 diff：提交前检查是否误加了 .env 等文件。
  • 拆分提交用 git add -p 按块暂存，比事后修改历史更安全。
  • 公司代码上传到外部 AI 服务前，确认符合团队的安全政策。

延伸阅读：用 AI 审查 diff 的提示词、先写失败测试再修 bug，以及 AI 代码评审清单。