十几年 Git 历史全是 add，一个 Skill 改掉了

2026年6月20日

Pull、Commit、Push，每个写代码的人每天都做。我的 commit message，十几年来基本上全写一个词：add。

不是夸张。翻几个老 Git 仓库，一屏的 add、add、add。

为什么？懒，也想不起来。

写代码时注意力全在代码上，调好了跑通了，赶紧提交收个尾。这时候回头想”刚才改了什么”，脑子里那些改动已经混在一起了。改了好几个地方，能想起来的往往只有一个。就算全想起来了，怎么写成一句有用的话，也是件难事。

知道不对，但放着

add 的代价不是没显出来过。

偶尔会有这种时刻：上周改的某个东西今天出问题了，想找一下当时改了什么。打开 git log，全是 add。只能一条条点进去看 diff，从最近往前翻。翻到第几条想起来”哦，是这个”，已经过去十分钟。

每次遇到都觉得这事不对。但下次提交，还是 add。

就这么放着。

转折是发现 Skill 这个东西之后。

我开始想工作流里有什么能做成 Skill，想到了 Git 提交。

随手搜了一下，网上现成的 Git commit Skill 有一堆。我没去看，直接自己从零写。

一个 Skill 就是一个目录加一个 SKILL.md 文件，给 Claude 读的说明书。说明书也是让 Claude 来写的，你描述要做什么，它生成，改两下就能用。几分钟。

写完跑起来是这样：暂存改动，让 Claude 读 diff，生成一句描述性的 message，提交。

它看的是实际改了什么，不靠我回想。

我从 add 解放出来。

跑了一周，回头看 git log，第一次能直接看出来这一周干了什么。

但很快发现 message 写得对，问题没完全解决。

新问题是：颗粒度。一次提交里塞了太多东西。修了一个 bug、顺手重构了一个函数，message 写得再准，浓缩成一句话也是含糊的。想追溯具体某个改动还是得翻 diff。

现在不是翻 add，是翻一堆范围太大的提交。

后来又加了一步：在生成 message 之前，让 Claude 先看 diff，判断这次改动应该拆成几次提交、每次提交包什么。拆完给我看，确认没问题，再分批 stage、分批 commit。

Skill 拆的不一定对，偶尔会把两件相关的事拆开，或者把不相关的归在一起。过一眼，调整一下，然后继续。

现在 git log 上一次”我以为只是改个东西”的工作，落下来可能是三条提交，每条管一件事。

现在大量用 AI Coding，带来另一个问题：AI 写的代码如果没人过一遍，要么靠人工 review，要么就这么提交出去了。所以 commit 完、push 之前，我又加了一步，让 Claude 按自己定的规则扫一遍。给 AI 生成的代码质量把一道关，顺带看看整体架构有没有越写越乱的迹象。

跑测试还是先 review，标准是什么，每个人、每个团队都不一样。我的 Skill 里写的是我自己那套，别人拿去用不了。

写 Skill 本身也是一堆改动：初始版本的 prompt、加拆分逻辑、调整边界情况。以前全打包一条 add。现在跑完是这样：

feat: 初始化 git-commit Skill，支持 AI 分析 diff 生成 message
feat: 添加改动拆分逻辑，按逻辑模块分批提交
fix: 优化模块边界判断，避免跨功能文件被归为同组

现在提交代码，我只说一个词：「提交」。读 diff、拆提交、确认、推，一套跑完。

转发给那个 commit 历史也是一片 add 的朋友。想看后续，点个关注。你工作流里有什么重复的痛点，一直没解决的，自己写一个 Skill 就行，几分钟。留言说说。