被 AI 糊的代码逼疯后，我们团队把 Git 工作流重构了

最近几个月，团队里用 Cursor 开发、甚至直接挂跑 AutoGPT 这类 Agent 的兄弟越来越多了。

一开始大家确实爽，“一句 Prompt 跑半小时，切回来功能都写完了”。但到了 Code Review 和发版的时候，灾难降临了。

我前几天 Review 了一个 AI 提的 PR：32 个文件改动，2500 行 Diff，而 Commit Message 只有轻飘飘的一个词—— Update。 里面混杂了业务逻辑、顺手做的重构、无意义的空格格式化，甚至还悄悄改掉了一个共享组件的入参。

合并没冲突，一上测试环境直接白屏。想回滚？抱歉，因为所有改动都在一个巨无霸 Commit 里，revert 直接把别的同事的正常代码也给卷没了。

经过这几次折腾，我们痛定思痛：AI 写代码确实快，但传统的 Git 工作流根本拦不住这头不受控的野兽。 今天就聊聊，在 Agentic Coding 时代，为了不被 AI 写的烂代码拉爆，我们到底该怎么管版本？

传统 Git 为什么管不住 AI？

在人的世界里，一次 Commit 代表“一次有意图的决策”。我们会自己把握粒度，动了公共代码会和同事打招呼。但 AI 没这个脑子，它带来了几个极其头疼的“新物种”：

1. “黑盒式”的巨型提交： AI 的探索是发散的，它修 Bug 时可能会顺手把依赖库升级了。Git 只记录了 Diff，却没记录 AI 的“推理链”。等代码出了 Bug，你完全不知道当时那个大模型是抽了什么风才这么写的。
2. 虚假的“合并无冲突”： Agent A 按照旧逻辑加了调用，Agent B 把底层逻辑改了。代码文本完美 Merge，但语义全错。
3. 被污染的工作区（Dirty Worktree）： Agent 在本地试错时极其奔放，各种测试桩、临时文件全堆在本地，一不小心就把你还没保存的 WIP 代码给覆盖了。

给 AI 戴上“紧箍咒”：我们的 4 条军规

为了活命，我们没有放弃 AI，而是给它立了规矩。我们在项目的根目录建了一个 AGENT.md（给 AI 读的规范），并配合 CI 做了强卡点。

1. 强制塞入上下文（Commit Trailer 规范）

现在的代码，光看 Diff 没用了，必须留下“案底”。我们强制要求 AI 在生成 Commit 时，必须使用 Git 自带的 Trailer 机制打上标签。

如果 AI 提的 PR 里没有这几个字段，我们配的 commit-msg 钩子直接把代码拒掉：

Plaintext

feat(auth): 接入刷新 Token 机制

Agent-Task: PROJ-234 
Agent-Model: Claude-3.5-Sonnet
Agent-Decision: 考虑了 Redis 存储，但为了降低依赖，最终采用 JWT 自动续期方案。

这招极管用。出了问题去搜 git log --grep="^Agent-Task:"，哪张工单、哪个模型闯的祸，一清二楚。

2. 用 Checkpoint 强迫 AI “小步存档”

AI 跑一个大需求，经常半路跑偏。我们在 System Prompt 里硬性规定：“每完成一个接口或测试，必须 commit 一次，前缀加上 [WIP]”。

等它全跑完，我们要么自己上，要么让 AI 再执行一次 git rebase -i，把那些细碎的 WIP 历史合并（Squash）成几个干净的原子提交（Atomic Commit）再推远端。

3. 物理隔离：并发 Agent 必须上 worktree

如果团队里几个人同时开着 Agent 跑任务，千万别在同一个目录里搞。我们在跑自动化脚本时，全部改用 git worktree：

Bash

git worktree add ../agent-task-01 -b feature/ai-auth

每个 Agent 拥有独立的物理目录，但共用底层的 .git 仓库。互相踩踏本地代码的概率直接降为零。

4. Stacked PR：大任务拆解大法

如果 Agent 真的干了一票大的（比如全站接入国际化），千万别让它提一个包含 100 个文件的 PR。我们在试用 GitHub 的堆叠 PR（Stacked PR）模式，让 AI 先提“基础配置 PR”，基于这个分支再提“业务替换 PR”。Review 变成了一层一层的闯关，心智负担小很多。

降维打击：扔掉 Git，拥抱新轮子？

说实话，上面这些招数都是在 Git 的现有限制里“螺蛳壳里做道场”。Git 诞生在 20 年前，林纳斯写它的时候可没想过有一天机器会自己提代码。最近为了搞定并发开发，我盯上了两个下一代工具，体验相当炸裂。

第一个是 Jujutsu (简称 jj)

这是 Google 工程师搞的开源工具，底层兼容你的 Git 仓库，但心智模型完全换了。

它最绝的一点是：工作区即提交。你改的每一行代码都会实时存入，再也没有那种“完了，不小心把暂存区搞乱了”的焦虑。而且它引入了固定不变的 Change ID 概念，就算你在底层偷偷改了一个 Bug，jj 会全自动把后面的提交全部平滑 Rebase 好。这简直是给疯狂试错的 AI 量身定制的时光机。

第二个是 GitButler

a16z 刚砸了 2000 多万美金投的玩意。它最硬核的功能是虚拟分支（Virtual Branches）。

以前我们要先切分支再敲代码；现在你可以让几个 Agent 在同一个目录下随便改，GitButler 能在底层按代码块（hunk）的粒度，把你这些改动自动分流到不同的虚拟分支里。脏工作区？不存在的。

写在最后

AI 带来的生产力爆发是毋庸置疑的，但引擎越猛，我们的刹车和底盘就得越稳。

不管是靠立规矩、配 CI 护栏，还是直接上 jj 这种新轮子，核心目的只有一个：让代码的演进历史依然是人类可读、可追溯的资产，而不是一堆机器拉出来的排泄物。

别让你的 Git 仓库，变成 AI 的垃圾桶。