为什么 AI 编程更需要 git 纪律
人类程序员写坏一个函数，通常只影响一个文件；AI 代理解释错需求，可能同时改掉十个文件，而且每个文件看起来都"有道理"。这时候唯一的低成本人工检查点就是 diff——在合入之前看一遍改动，比合入之后在运行时代码里找问题便宜得多。另一个原因更实际：坏的中间状态会污染后续生成。AI 基于当前代码库继续干活，如果代码库已经是乱的，它只会越改越乱。可回滚，是让 AI 持续工作的前提。
三件套：分支、小步、审查
- 分支隔离：每个任务开一个分支（例如 feature/xxx），主分支永远保持可发布状态。AI 可以在分支上随便试，试坏了直接删分支重来，不影响任何人。
- 小步提交：不要等任务全部完成才提交，要求每完成一个逻辑单元就提交一次，提交信息写清"做了什么、为什么"。diff 小，审查就快；出了问题，二分定位也容易。
- 合入前审查：合入前不看 AI 的"我改好了"总结，看 git diff。重点核对三件事：改动是否超出任务范围、是否碰了不该碰的文件（配置文件、锁文件、生成物）、diff 里有没有混进敏感信息。
具体操作建议
把下面几条写进你的开发规范，AI 和人都照做：
- 任务开始前先 git status 确认工作区干净，再 git checkout -b feature/xxx 建分支；
- 每个逻辑单元完成后立即提交（可以让 AI 自己执行 git add 和 commit，但提交信息要按仓库约定写）；
- 合入前执行 git diff main...feature/xxx 全量审查，确认没有范围外改动；单文件出错用 git restore 回退，不要手动乱改；
- 合入后发现新问题，优先 git revert 回滚整个提交，而不是在坏状态上打补丁；
- 如果 AI 把格式化、重构和功能改动混在一次提交里，要求它拆开——审查和回溯都依赖提交的"单一职责"。
一次任务的正确姿势
以"给结算模块加导出功能"为例，完整流程是：
- git checkout -b feature/export 建分支，先让 Codex 只读排查模块现状，输出改动方案，确认后再动写；
- 实现过程按逻辑单元提交：数据结构一次、接口一次、页面一次、测试一次，提交信息写明改动原因；
- 合入前 git diff main...feature/export 全量审查，确认没有动到无关文件；
- 合入后跑一遍冒烟测试，再放 Codex 进入下一个任务。
这套流程多花的时间不到十分钟，换来的是"任何一步出错都能干净回退"。
什么时候可以简化
流程不必一刀切：单文件小改动、一次性脚本、纯文档修改，直接在主分支改或简化到一次提交都可以；但核心逻辑、生产路径、多人协作的分支，必须走全套。判断标准：这个改动出错的话，谁能最快发现、怎么恢复——答案越模糊，流程越不能省。
常见坑与应对
- "AI 说它只改了三个文件"但 diff 显示动了十五个：以 diff 为准，让 AI 解释每个文件改动的原因，说不清就回退重做；
- 合并时直接信任冲突解决结果：冲突是 AI 最容易出错的地方，解决冲突的 diff 必须人眼过一遍；
- 把测试文件排除在审查之外：测试改没改、怎么改的，直接决定"通过"是否可信；
- 生产分支上直接让 AI 改代码：哪怕只改一行，也走分支—提交—审查—合入，习惯比省事重要；
- 合入后不删分支、继续在旧分支上开发：分支会越漂越远，最终 merge 回来时冲突成堆。任务完成就删除分支，下个任务开新分支。
结论
Codex 负责速度，git 负责刹车。三件套里最反直觉的是"小步"：总觉得让 AI 一口气干完更高效，但实践证明，10 个干净的小提交永远比 1 个混乱的大提交好收场。把分支、小步、审查写进规范，AI 就能在不出乱子的前提下放开手脚。
来源：本文为常青实战技巧整理，基于长期使用 Codex 与 Git 的实操经验；Git 基础概念以 Git 官方文档 为准。最后更新：2026-08-15。