一堆未提交改动拆成3个提交：AI辅助审diff的做法

一句话结论

先按文件和功能把 diff 归成 3 组，再让 AI 逐组写提交说明，最后用 git add -p 分批落地，全程通常 20 分钟内。

这篇解决什么问题

周五下午改一个退款流程，顺手动了格式化、补了两行调试输出、又加了个新字段，收工时 git status 一片红，你自己都说不清哪几行属于哪件事。

这篇讲的是把这堆混在一起的改动切成 3 个能独立跑起来的提交，每个提交说清一件事。适用于改动散在多个文件、隔了一两天才回头整理的情况；如果你只动了两个文件、逻辑本来就单一，直接 git add -p 手工挑更快，不用绕这一圈。

开始前要准备什么

• 一个还带着未提交改动的本地仓库，动手前先整目录复制一份备份
• Cursor 免费版或 Claude 免费版都能用，免费额度跑完这一轮足够
• 一条能验证的测试或构建命令，比如 npm test，每提交一次就跑一遍
• 预计耗时：熟悉流程后 20 分钟上下，第一次做翻倍也正常

具体怎么做

第 1 步 · 先摸底，别急着写提交说明

很多人上来就把 diff 甩给 AI 说「帮我写提交说明」，顺序反了。说明是基于分组写的，分组错了说明再好也是废的。所以先用两条只读命令把家底摊开：git status 和 git diff --stat，输出量小，AI 一次吃得下。

你是我的代码审查助手。下面是我一个仓库里尚未提交的改动清单，来自 git status 和 git diff –stat 的原始输出。请帮我做三件事：
1. 按「同一件事」的标准把这些文件归成若干组，每组要能独立成为一个可运行的提交；
2. 指出哪些文件同时牵扯两件不同的事、需要按 hunk 再切一刀，例如同一个文件里既有格式化又有业务逻辑；
3. 给每个分组起一个不超过 12 个字的中文短名。
这一轮只做分组，不要写提交说明。
项目背景：订单服务，TypeScript，最近在改退款流程。
输出内容：
【粘贴 git status 和 git diff –stat 的完整输出】

预期产出：一张 3 组左右的文件归属表，外加一份「需要二次拆分的文件」名单。

第 2 步 · 让它读真 diff，确认边界

文件清单只能看出「谁动了」，看不出「动了什么」。这一步把每一组的完整 diff 贴进去，让它挑夹带。我在实操中发现，最容易夹带的是顺手做的格式化、忘了删的 console 输出，和被注释掉的旧代码——这三样不挑出来，提交历史就变成一团浆糊。

下面是一个提交分组的完整 diff，请逐条编号回答四个问题：
1. 这个分组做的事能不能用一句话说清？把这句话写出来；
2. diff 里有没有和这件事无关的改动？例如顺手的格式化、调试输出、被注释掉的旧代码，指出文件名和大致位置；
3. 有没有删掉但不该删的逻辑；
4. 如果这组混进了两件事，告诉我怎么按文件或按 hunk 再切一刀。
分组名：【第 1 步得到的组名】
diff：
【粘贴这一组的 git diff 输出】

预期产出：每组一句结论，加一份具体的「夹带清单」，告诉你哪几处要踢出去。

第 3 步 · 一次生成三条提交说明

分组定稿了再写说明。我一般要求首行遵循 Conventional Commits，正文写「为什么改」而不是「改了什么」——半年后回头看历史，能救命的是前者。另外让它顺手排个顺序，这条比说明本身还值钱。

按下面的分组结果，为每个分组写一条提交说明，格式要求：
– 首行 type(scope): 中文概述，type 从 feat / fix / refactor / style / test / chore 里选，概述不超过 50 个字符；
– 空一行后写 2 到 4 行正文，说明「为什么这么改」，不要复述「改了什么」；
– 不要出现「优化代码」「提升性能」这类空话，也不要提到任何工具名；
– 额外告诉我这三条提交该按什么顺序落地，才能保证中间任何一条单独检出来测试都不挂。
三个分组：
1. 【组名一】：【一句话说明】
2. 【组名二】：【一句话说明】
3. 【组名三】：【一句话说明】

预期产出：三条可直接粘贴的提交说明，外加一个不会让测试中断的提交顺序。

第 4 步 · 分批落地，每条当场验

到了写盘这一步，别用 git add .。按文件 add，同一个文件跨两件事的就 git add -p 逐 hunk 挑。每提交一条立刻自检，出问题改起来成本最低——用 --amend 补，或者 git reset HEAD~ 退回来重拆。

我刚落地了一条提交，下面是 git show –stat 和这条提交的完整 diff。请帮我做提交后自检：
1. 这条提交是否只包含它声称的那一件事；
2. 有没有可能导致测试挂掉的改动，例如改了函数签名但没改调用处、改了配置默认值、删了对外导出；
3. 如果发现问题，判断该用 git commit –amend 补进去，还是用 git reset HEAD~ 撤回重拆。
提交说明：【粘贴第 3 步生成的说明】
输出：
【粘贴 git show 的输出】

预期产出：每条提交的通过或拦截结论，以及具体的补救命令。

实测记录

省下来的时间主要不在写说明，在「回忆这行改动当时为什么加」。AI 帮你把上下文从 diff 里读出来，你只做确认。

返工那次也值得说：它第一轮把两个文件归成一组，看着都是退款相关，实际一个改金额计算、一个改日志格式。是我自己在第 4 步自检时发现测试挂了才退回来的。所以别省自检。

最容易错的 3 个地方

1. 跳过分组直接要提交说明。边界错了，说明再漂亮也是给错的东西写墓志铭。纠正：第 1、2 步单独跑，第 3 步才提笔。
2. 按文件路径分组，而不是按「能不能独立跑通」。两个文件改的是同一件事，被拆进两条提交，中间那条必然挂测试。纠正：分组时先问这句。
3. 图省事用 git add . 一把梭。夹带进去的调试输出会跟着进主干。纠正：老老实实按文件 add，跨事的文件用 add -p。

可复用的东西

四段提示词其实是一个模板：摸底分组 → 逐组验边界 → 批量写说明 → 逐条自检。换项目只需要改两处——第 1 步里的项目背景，和第 2 步贴进去的 diff 内容，其余原样复制。我把它存在一个纯文本文件里，放在仓库根目录的临时文件夹下，用完就删，不进版本库。

补一句：提交数量别硬凑。改着改着发现只剩两件事，那就提两条，历史干净比数量整齐重要。

你上一次把一堆改动一起提交，是因为分不清哪几行属于哪件事，还是单纯懒了一下？

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接