AI Commit Message 生成器 - 根据 Git Diff 生成提交信息

功能特点

• 根据文件改动和代码差异判断提交类型、Scope 和变更目的
• 生成可直接复制的标题与完整 Commit Message
• 输出变更摘要并单独提示可能的 Breaking Change
• 提交差异经后端代理发送给 AI 服务，浏览器端不保存模型服务密钥
• 按 Conventional Commits 检查 type、scope、Breaking Change，并要求人工复核完整 staged diff

使用方法

1. 粘贴 git diff、PR 变更摘要或文件改动片段
2. 选择 Conventional Commits、GitHub 风格或中文提交规范，并补充 Scope
3. 检查 AI 生成的标题、正文和 Breaking Change，再对照完整 staged diff、测试与发布影响复制到 Git 工作流中

示例输入

• 新增按钮禁用状态

  diff --git a/src/components/Button.vue b/src/components/Button.vue
  +const isDisabled = ref(false);

  适合根据组件、接口或业务模块的实际改动生成 type(scope): description。 结果为说明性的 AI 文案示例，会随 diff、仓库规范和模型响应变化。

• 接口错误处理调整

  diff --git a/src/api/client.ts b/src/api/client.ts
  +return response.ok ? data : throwApiError(response);

  适合在提交前快速归纳错误处理、兼容性和潜在 Breaking Change。 结果为说明性的 AI 文案示例，会随 diff、仓库规范和模型响应变化。

• Breaking Change 与 staged diff

  diff --git a/src/api/orders.ts b/src/api/orders.ts
  -GET /orders 返回数组
  +GET /orders 返回 { data, nextCursor }
  +BREAKING: 客户端必须读取 data

  适合提醒接口响应结构变化，但必须与完整 staged diff、迁移说明、测试和仓库规范一起复核。 结果为说明性的 AI 文案示例，会随 diff、仓库规范和模型响应变化。

• 非 JSON AI 响应

  diff --git a/src/api/client.ts b/src/api/client.ts
  +return response.json();

  页面会优先解析 title、message、summary 和 breakingChanges；后端返回普通文本时只保留首行标题，并提示人工确认 Breaking Change。 结果为说明性的 AI 文案示例，会随 diff、仓库规范和模型响应变化。

示例输出

• 新增按钮禁用状态

  feat(button): add reactive disabled state

• 接口错误处理调整

  fix(api): throw structured errors for unsuccessful responses

• Breaking Change 与 staged diff

  feat(api)!: wrap order list in data envelope
  
  BREAKING CHANGE: clients must read response.data before the list.

• 非 JSON AI 响应

  普通文本响应：首行作为 title；message 保留全文；breakingChanges 提示人工确认是否存在 Breaking Change。

常见错误

• 只粘贴文件名或少量上下文时，AI 无法可靠判断提交类型和真实行为变化。
• 不要把生成的 Commit Message 当作代码审查结论，仍需确认 diff 是否包含未描述的改动。
• Breaking Change 需要结合公共 API、数据结构和配置兼容性判断，空数组不代表绝对没有风险。
• Conventional Commits 的 type、scope 和语言风格应与仓库现有提交规范保持一致。
• 生成的提交信息不能证明变更完整；提交前必须检查 staged diff、测试结果、迁移步骤和发布影响。

适用场景

• 根据 diff 生成 commit message
• Conventional Commits
• Pull Request 描述整理
• 发布前变更归纳

实操检查

• 验证最小 diff 校验

  固定输入：`diff`（少于 10 个字符）。步骤：打开 AI Commit Message，粘贴输入并点击“生成 Commit Message”。预期结果：页面显示“请先粘贴至少 10 个字符的 git diff”，且 requestSent 不会进入已发送状态。失败判断：仍发起 `/api/ai/commit-message`，或把校验失败显示成 AI 服务故障。

• 验证 Breaking Change 结果

  固定输入：`diff --git a/api.ts b/api.ts -GET /orders 返回数组 +GET /orders 返回 { data }`。步骤：提交并让流返回含 title、message、summary、breakingChanges 的 JSON。预期结果：页面分别显示推荐标题、完整提交信息、变更摘要和 Breaking Change 区域。失败判断：结构化字段没有映射到对应区域，或 breakingChanges 为空时没有显示“未发现 Breaking Change”。

页面专属核验

使用前与操作中

• 把 title、summary 和 Breaking Change 提醒当作基于 diff 的候选提交信息；先对照完整 staged diff、测试结果和发布影响，再决定是否采用。
• 页面会把 diff、style 和 scope 发送到 `/api/ai/commit-message`；粘贴前移除密钥、Token、Cookie、客户数据、私有 URL 和不应离开仓库的源码片段。
• 先选择 Conventional Commits、GitHub 风格、简短中文或团队规范，并确认 scope；diff 少于 10 个字符不会提交，不能用文件名片段推断完整变更。

结果出来后

• 生成的 type、scope、标题长度和正文是否符合所选规范，并准确描述 diff 中实际发生的文件与行为变化？
• Breaking Change 列表是否有 API、配置、数据或兼容性证据；空列表是否只是模型未识别，而不是自动证明没有破坏性变更？
• 提交信息、摘要和模型回显中是否没有泄露 diff 里的凭据或个人数据，并且已由人工结合测试与版本发布说明复核？

相关工具

• 文本对比：按行对比文本、配置、日志和接口响应差异
• 代码格式化：统一格式化和轻量压缩 HTML、CSS、JavaScript 代码
• AI 错误解释：AI 智能解析错误信息并提供排查方向
• Markdown 预览：Markdown 预览，并支持 Markdown 转 HTML / 纯文本

工具边界

• 模型只能概括提供的 diff，无法看到未暂存文件、测试结果、关联 Issue 或发布影响。
• Conventional Commit 类型、scope 与 Breaking Change 判断仍取决于仓库自己的规范和公共契约。

与相似工具的区别

• 文本对比：Commit Message 工具把 diff 概括为提交文案；Text Diff 逐行展示增删，不判断变更意图或提交类型。

安全与兼容性

• Diff 会发送到 AI 服务；生成前应移除密钥、真实客户数据、内部端点和不允许外发的源码。
• 提交前仍要人工检查 staged diff，确认文案没有遗漏破坏性改动、迁移步骤、安全影响或生成文件。

下一步排查

1. 生成文案后先用 Text Diff 检查完整 staged diff，再按仓库规范确认 type、scope 和 Breaking Change。
2. 用 Code 工具检查实现与测试，用 Markdown 工具整理发布说明或迁移文档。
3. 发现行为、环境或接口错误时，转到 AI 错误、AI 环境调试或 HTTP 状态工具补充证据。

常见问题