AI 编码助手把代码生产的速度提高了十倍，但大多数团队的 Git 工作流还停留在”人写代码”的假设里。
这个假设很隐蔽，但它决定了我们怎么 commit、怎么 review、怎么分支合并。它默认：
- 一次 commit 的大小，应该反映一个人能在一段专注时间里理解的改动；
- PR review 的重点，是检查作者有没有写对；
- 分支存在的意义，是给人类协作争取并行开发的空间。
当一段代码可以在几分钟内从 prompt 变成几百行变更，这些假设就开始松动。问题不再是”AI 会不会取代程序员”，而是：如果代码的”作者”已经从”人”变成”人 + AI”，版本控制系统应该记录什么、验证什么、保护什么？
这篇文章想讨论的不是”怎么用 Git 更高效”，而是 AI 时代 Git 工作流需要被重写的三个底层问题：
- commit 的粒度应该按什么来切？
- PR review 到底在 review 什么？
- 分支策略还要不要存在？
一、先拆穿一个默认假设：Git 记录的是”变更”，不是”作者”
Git 的提交模型很简单：记录谁、在什么时候、把哪些文件改成了什么样。它不关心这些变更来自键盘、脚本还是大模型。在过去，这三者差别不大，因为绝大部分变更确实来自键盘。
但 AI 编码助手让”来源”重新变得重要。同样是 300 行新增代码，可能的生成路径完全不同：
- 人设计结构，AI 填充实现；
- 人描述需求，AI 一次性生成；
- AI 生成初稿，人逐行修改；
- 人复制粘贴 AI 输出，几乎未读；
- AI 在 Agent 模式下自动改动了十几个文件。
Git 的 diff 在这几种情况下看起来几乎一样。但它们的风险结构完全不同。
过去我们说”代码是人写的”，隐含了一层保证：作者至少读过自己提交的每一行。这层保证现在不成立了。AI 生成的代码，作者可能只读过 30%，甚至只读过 AI 的摘要。Git 没有为这种”半阅读作者”设计记录格式，但团队的工作流必须为这种新生产关系重新设计。
这不是要加一个”AI 生成”标签那么简单。真正的问题是：当”作者已读”这个前提失效后，Git 工作流必须补上什么新的验证环节？
二、commit 粒度：从”人能消化”变成”人能验证”
传统建议总说：commit 要小，要小步提交，要原子化。理由也很充分——小 commit 容易 review、容易回滚、容易 bisect。
但这个建议在 AI 时代被放大了，同时也被扭曲了。
1. AI 让”大 commit”变得过于容易
一个常见的新手陷阱是：对 AI 说”帮我实现用户认证模块”，然后看着它改十几个文件，最后潇洒地 git add . && git commit -m "add auth"。这个 commit 可能包含路由、模型、控制器、前端组件、测试、配置文件，全部裹在一起。
问题不是 commit 大，而是 commit 里塞进了太多不同性质的变更。一旦线上出问题，你很难判断是路由写错了、模型约束写错了，还是测试根本没覆盖到边界。回滚也变得粗暴——要么全回，要么硬扛。
AI 不会替你承担这种耦合成本。恰恰相反，它特别擅长生成”看起来一体但实际上杂糅”的变更。
2. 新的切分单位：意图闭环，而不是文件数量
在 AI 时代，commit 粒度的正确单位不再是”多少文件”或”多少行”，而是一个可验证的意图闭环。
一个意图闭环意味着：
- 这次提交只解决一个明确问题或完成一个明确步骤；
- 提交本身可以通过自动化测试或最小人工验证确认正确；
- 回滚这个提交不会连带破坏无关功能。
这和传统原子化 commit 看起来相似，但侧重点不同。传统建议关注”小”，而 AI 时代的建议关注”可验证”。AI 可以一次生成 500 行，但只要这 500 行服务于同一个可验证意图，且能通过测试，它仍然是一个好 commit。
反过来说，如果 AI 生成的 50 行里混了三个不同意图，那这个 commit 仍然太大。
3. 实践建议：把 AI 生成拆成”生成 → 审查 → 重组提交”
一个可行的三段式：
第一步：让 AI 在独立工作区生成。
不要让 AI 直接改你正在开发的分支。让它在临时分支或 patch 文件里输出，这样你可以先读、再决定怎么整合。
第二步：按意图重新分组。
读完 AI 的产出后，不要整体提交。把变更按意图拆成多个 commit：
- refactor: 先提取公共函数；
- feat: 再添加新接口；
- test: 再补充边界测试；
- chore: 最后更新配置或文档。
这一步不能交给 AI，因为它需要你对业务意图做判断。
第三步：每个 commit 附带验证证据。
不是每个 commit 都要有测试，但每个 commit 都要有能被验证的说法。可以是最小复现步骤、单元测试、截图，或者一句清晰的 commit message 说明”如果这步错了，会怎样表现”。
三、PR review：从”检查作者写没写对”变成”检查作者验没验对”
这是 AI 时代 Git 工作流最深刻的变化。
传统 PR review 的核心问题是：”你写的代码对不对？” reviewer 会看逻辑、命名、边界处理、性能、风格。它默认 reviewer 的知识密度高于作者，或者至少能发现作者没注意到的问题。
AI 让这个问题变得不一样了。
1. reviewer 不太可能比 AI 更懂 AI 生成的代码
如果一段代码是 AI 写的，reviewer 面对的是一个奇怪的局面：他可能没见过这个实现思路，也不知道 AI 为什么选择这种写法。他更不可能在有限时间内比 AI 读更多相关文档。
在这种情况下，让 reviewer 去”一行行检查代码对不对”，效率很低，也容易流于形式。
2. 新的核心问题：”你验证了什么？怎么验证的？”
AI 时代的 PR review 应该从”代码审查”转向”验证审查”。reviewer 不需要重复阅读每一行，而需要确认作者已经做了足够的验证：
- 这段代码的验收标准是什么？
- 你跑了哪些测试？有没有最小复现？
- AI 生成的部分，你人工抽查了哪些边界？
- 如果 AI 在这里 hallucinate 了，你有没有兜底检查？
- 变更的回滚路径是什么？
换句话说，reviewer 的注意力从”代码本身”转向”代码背后的验证链”。
3. PR 描述要比代码更重要
在 AI 时代，PR 描述不再是礼貌性的说明，而是 review 的主要对象。一个好的 PR 描述应该回答：
- 意图：这次改动要解决什么问题？
- AI 参与度：哪些文件/函数是 AI 生成的？哪些被人工修改过？
- 验证清单：作者已经检查过哪些事项？
- 风险点：AI 最容易在这个改动里犯什么错？你如何排除？
- 回滚策略：如果出问题，单独回滚这个 PR 是否安全？
如果 PR 描述写不清楚这些，reviewer 应该直接打回，而不是勉强去看代码。
4. 大规模 AI 生成变更应该拆分，而不是一次 review
如果一个 PR 包含 2000 行 AI 生成代码，即使它质量很好，也不应该被合并。不是因为 reviewer 懒，而是因为人类无法在一次 review 中建立对这么大变更的信任。
建议把 AI 生成的大特性拆成多个依赖清晰的子 PR：
- PR 1：接口定义和数据结构；
- PR 2：核心实现；
- PR 3：测试和文档；
- PR 4：配置和部署变更。
每个 PR 都能独立验证，reviewer 也能在每一层建立信任。
四、分支策略：长生命周期的 feature 分支正在变成负债
传统分支策略的出发点是：人类并行工作时需要隔离。每个人都在自己的 feature 分支上开发，完成后合并回主分支。这降低了冲突频率，也给了每个人稳定的开发环境。
AI 让这种模式变得危险。
1. AI 生成速度越快，feature 分支腐烂越快
一个 feature 分支如果只活一天，它的风险很小。但如果 AI 能在一天内生成过去一周的工作量，那么一个三天的 feature 分支里可能塞进了过去一个月的代码量。分支越长，与主干的差异越大，合并时越容易发生”AI 生成代码之间的隐性冲突”——不是 Git 层面的冲突，而是语义层面的冲突。
更麻烦的是，AI 生成的代码看起来往往”自洽”，因为它在一个固定上下文里生成。但和主干的最新代码合并后，旧的假设可能已经不成立。这种 bug 很难在合并时被发现。
2. 主干开发在 AI 时代更有优势
Trunk-based development 不是什么新东西，但它在 AI 时代有了新意义：
- 缩短反馈环：代码尽快进入主干，尽快被集成测试覆盖；
- 减少 AI 幻觉的累积：长期分支里的 AI 生成代码越多，幻觉越容易层层叠加；
- 强制小步验证：如果每个改动都要快速合入主干，团队自然会被迫把大特性拆小。
不是每个团队都能立刻切换到主干开发，但核心原则可以借鉴：AI 生成的代码不应该在分支里停留太久。
3. 新的分支用途：隔离 AI 实验，而不是隔离开发
在 AI 时代，分支更有价值的用途是”实验隔离”，而不是”日常开发隔离”。
比如：
experiment/ai-refactor-auth：让 AI 尝试重构认证模块，不管成功与否，最终只取被验证过的部分；ai-draft/feature-x：AI 生成初稿，作者在另一个分支里按意图重组后提交；prompt/v2-auth-prompt：记录一个特定 prompt 的输出结果，方便和下个版本对比。
分支变成了 AI 实验的沙盒，而不是代码的所有权边界。
五、Git 还需要新 metadata：我们到底在记录什么？
现有 Git commit 只有 author、date、message、diff。这些信息在 AI 时代不够用了。
一个更完整的提交元数据应该包括：
| 元数据 | 作用 |
| 人类作者 | 谁对这次提交负责 |
| AI 工具 | 使用了哪种 AI 工具或模型 |
| prompt 摘要 | 生成这段代码的核心提示词是什么 |
| 验证方式 | 测试、人工抽查、静态检查、运行日志 |
| 风险等级 | AI 改动比例、关键路径影响 |
| 回滚置信度 | 单独回滚是否安全 |
Git 本身不支持这么多字段，但可以通过 commit message 约定、PR 模板、CI 标签或外部工具来补充。关键不是技术实现，而是团队达成共识：代码不再只是”人写的”，Git 历史需要记录”它是怎么被生产出来的”。
六、一个可落地的最小工作流
如果你只想改一件事，就从这条最小工作流开始：
- AI 不直接提交。所有 AI 输出先进入临时分支或 patch，作者读完后再决定如何整合。
- 按意图重组 commit。不按文件大小切分，而按”一个可验证意图”切分。
- PR 描述包含验证清单。 reviewer 先看你怎么验证的，再看代码。
- 大特性拆成依赖链。不一次性 review 上千行 AI 生成代码。
- feature 分支不超过 2-3 天。AI 生成代码不要长期活在分支里。
- 回滚安全优先于提交美观。每个 commit 都要能独立回滚，不破坏无关功能。
七、结语：Git 工作流的本质没有变，但它在保护的东西变了
Git 工作流的核心任务从来没有变过：在多人协作中保持代码历史的可理解、可验证、可回滚。
但 AI 时代，”多人”里面多了非人类协作者。这些协作者写得快、不疲倦、不抱怨，但也会幻觉、会遗漏、会在边界处犯错。它们不承担责任，承担责任的是使用它们的人。
所以 Git 工作流需要回答的新问题是：当代码的生产速度远超人类的阅读速度时，我们用什么机制来保证，被合并进主干的代码仍然有人负责、可被审计、可以回滚？
答案不是禁止 AI，也不是盲目信任 AI，而是把工作流从”记录人写的代码”升级为”记录人验证的代码”。
commit 不再只是”我改了什么”，而是”我验证了什么”。 PR review 不再只是”你写对了吗”，而是”你验对了吗”。 分支不再只是”我的开发空间”，而是”AI 实验的沙盒”。
这个转变，是 AI 时代软件工程从”个人手艺”走向”可审计生产”的必经之路。
发表回复