写代码时，我把这个本地 AI Commit Message 生成器接进了工作流

写提交信息这件事，说大不大，说小不小。我周围大致分两派：一派是 git commit -m "fix bug"，另一派是严格按照 Conventional Commits 写长篇大论。我以前属于中间状态------想写好，但又懒得每次都动脑子，最后常常写成 update 或者 fix。

最近做 side project 时，我顺手在工具派上测了下它的 AI Commit Message 生成器。因为是浏览器本地跑模型，diff 不会上传服务器，这点对我这种有点代码洁癖的人比较友好。

我为什么会用它

团队项目里，commit message 是否规范直接影响后面生成 changelog、做 code review 的效率。我之前踩过两个坑：

写得太简单，两个月后回看根本不知道改了什么；
写得太随意，导致 git log 根本没法用脚本自动化处理。

Conventional Commits 格式虽好，但每次手动套 <type>(<scope>): <subject> 确实有点烦。所以我开始找能根据 diff 自动生成规范 message 的工具。

使用方式

这个工具的使用逻辑很直接：把 git diff 的输出贴进去，选择风格，点生成。

1. 准备 diff

我在本地改了一段校验逻辑，新增了一个 validateEmail 函数，顺手优化了手机号校验。跑完测试后生成 diff：

bash 复制代码

git diff -- src/utils/validator.js

把输出复制下来。

2. 粘贴并选择风格

打开工具的 AI Commit Message 页面，左侧是 diff 输入区，右侧会显示候选结果。

它支持几种风格：

Conventional Commits
GitHub 风格
Angular 规范
简洁风格

我平时用 Conventional Commits，所以保持默认。

3. 粘贴 diff

把刚才复制的 diff 贴到输入框里：

text 复制代码

diff --git a/src/utils/validator.js b/src/utils/validator.js
index 3a4f12c..8b9d21e 100644
--- a/src/utils/validator.js
+++ b/src/utils/validator.js
@@ -10,6 +10,10 @@ export function validatePhone(phone) {
   return /^\d{11}$/.test(phone);
 }
 
+export function validateEmail(email) {
+  return /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);
+}
+
 export function validateIdCard(idCard) {
   return /^\d{17}[\dX]$/.test(idCard);
 }

4. 生成结果

点击生成后，右侧会给出几条候选。我这次得到的三条分别是：

test(src): 更新 src/utils/validator.js
chore(src): 更新 src/utils/validator.js
style(src): 更新 src/utils/validator.js

说实话，第一条被标成 test 有点不太准，因为我是新增功能而不是补测试。我会倾向于手动改成 feat(src): 新增 validateEmail 函数并优化手机号校验。但这个工具至少帮我把 scope 和 subject 的格式搭好了，省了我从零开始组织的功夫。

实际接入工作流

我现在的用法是：

本地开发完成后，git add 准备提交的改动；
git diff --cached 生成 staged diff；
把 diff 贴进生成器，快速拿到一个初稿；
根据实际改动类型手动调整 type，然后复制到 git commit -m "..."。

这样比完全手写快，又比直接用 update 规范得多。

几点踩坑经验

diff 范围要控制好：不要把整个工作区的 diff 一次性贴进去，否则生成结果会太宽泛。我通常按一个逻辑改动来分。
type 需要人工校验 ：AI 对 feat、fix、chore 的判断不一定准，尤其是改动比较杂的时候。
不要完全依赖生成结果：它适合当草稿，最终 message 还是要自己看一眼。

写在最后

这个 AI Commit Message 生成器现在是我写提交信息时的一个辅助步骤，不是替代思考，而是减少格式化负担。像工具派这种把模型跑在浏览器里的做法，至少让我不用把公司代码 diff 传到外部服务，心里踏实一点。

如果你也在为 commit message 发愁，可以搜一下这个名字，自己试试效果。