AI写代码疯狂提交？教你搞定 Commit 炸弹问题

最近在折腾 AI 自动写代码的时候，遇到了一个让人哭笑不得的问题。

事情是这样的：我开了一个计划任务让 AI 帮我修补和完善一个项目的代码。本来想着挂机睡一觉起来验收成果，结果第二天早上一看，好家伙，仓库直接被刷屏了！仅仅跑了8个小时，AI 居然给仓库提交了 100 多次 commit。

仔细翻看记录，这 100 多次提交里，很多次只改了寥寥 30 行代码，甚至有时候只是调整了一下格式或者改了个变量名就迫不及待地提交上去了。虽然我提示词里明确说了“完成需求后再提交”，但它似乎完全把这个建议当成了耳旁风，依旧我行我素，把代码拆成一小坨一小坨地往上推。

这其实暴露了 AI 编程时的一个常见痛点：模型倾向于对每一个微小的“动作”都产生反馈，而不是理解整体的“任务”。为了避免这种像刷屏一样的 Commit 炸弹，我们需要从以下几个维度来优化我们的策略。

一、优化提示词：强调“原子性”和“验收标准”

既然简单的“做完再交”不管用，我们得把指令下得更死板、更具体。AI 其实是很听话的，关键在于你如何定义“做完”。

可以尝试在 System Prompt 或者任务描述中加入类似的强约束逻辑：

指令优化示例： “在此次开发任务中，严禁进行零碎提交。你必须将所有相关的代码修改、测试用例更新及文档调整在本地完成。只有在实现完整功能、通过自测且没有语法错误后，才能执行一次 git commit。每一次 commit 必须包含一个完整的功能点或修复，而不是中间过程。如果涉及多个文件修改，请使用 git add . 统一提交，严禁分批提交。”

通过强调“完整功能点”和“严禁分批”，可以强迫 AI 先在本地把活干完，而不是干一点就伸手要表扬（提交）。

二、工具链层面的限制：如果它不听，就由不得它做主

有时候光靠嘴说（Prompt）是不够的，毕竟大模型的幻觉和执行逻辑有时候比较飘。这时候我们可以从工具链层面进行“物理”限制。

1. 设置计划任务的轮次间隔 很多 AI 编程工具（如 Codex）的计划任务是可以设置触发频率的。如果你的任务是挂机跑8小时，不要让它在这个时间里无限循环。可以将任务设置为“单次执行”或“长间隔轮询”。强制让 AI 在思考更长时间、生成更多上下文后再进行操作，减少交互次数，天然就能降低 commit 频率。

2. 包装 Git 命令或限制权限 如果你是在本地脚本或服务器上跑，可以考虑对 git 命令进行简单的封装。比如写一个 shell 脚本 smart_commit.sh，设置一个时间锁（距离上次提交不足 30 分钟则拒绝提交），或者强制检测变更文件的数量（变更行数少于 100 行则警告并退出）。把 AI 的操作权限挂载在这个脚本上，它想乱交也交不上去。

3. 使用 squash 机制（事后补救） 如果是那种实在没法前置控制的场景，最简单的做法就是事后合并。既然 AI 喜欢碎屑提交，那我们就在人工验收环节，直接使用 git rebase -i 将这一百多个提交合并为一个（或几个有意义的提交）。虽然治标不治本，但这能保证主仓库的历史记录是干净的。

三、调整工作流：分阶段执行

最后，有时候问题出在任务分配上。如果你丢给 AI 的需求过于宽泛（比如“优化这个模块”），它可能会拆分成无数个步骤来执行。

建议的做法是： 将大需求拆解为明确的、独立的小任务。

• ❌ 不要说： “帮我优化这个项目，修复所有 bug 并提交。”
• ✅ 尝试说： “第一步，重写用户登录逻辑。完成后不要提交，等待下一步指令。”

通过这种“确认制”的交互，把“提交”这个动作的控制权重新拿回到自己手里。等它把所有步骤都跑完后，再由你手动或者指令它进行最终的汇总提交。

总结

AI 帮我们写代码确实爽，但如果没有约束，它那种勤勤恳恳写一行改一行提交一次的“卷王”作风，确实会把仓库搞得一团糟。

核心解决思路其实就是两点：Prompt 上给足约束，定义好什么是“任务结束”；工具上做好隔离，别让它随手就能推代码。 希望这几个小技巧能帮大家省去整理 git log 的痛苦，让 AI 真正变成高效的打工仔，而不是制造垃圾数据的机器。