背景：为什么这个问题值得关注

传统 Git 开发模式：基于主分支创建 feature 分支 → 完成开发 → 提 PR → 审核者逐行审查 → 合并。

人工开发时代，这个流程是合理的——代码是稀缺资源，审查是保护性检查，每一行代码都承载着开发者的意图。

智能体时代，这个模式失效了。Claude Code、Copilot 等工具让代码产出速度提升 10 倍以上：

  • 一次 prompt 可以生成数百行代码
  • 一次任务可以产出数个文件
  • PR diff 从几百行变成几千行，甚至上万行

结果是：代码生产速度 » 代码审核速度。 审核者成了瓶颈，PR 堆积，团队陷入"提 PR → 审核不了 → 阻塞 → 继续提"的恶性循环。

具体表现为：

  • PR 大量堆积，无法及时审核
  • 前序 PR 未合并，后续功能开发直接阻塞
  • 审核者认知超载，审查质量下降

核心理念：探索阶段与提交阶段分离

传统模式的根本问题，是把"探索"和"提交"混在同一个流程里。

AI 编程的特点是：快速产出，不惧怕失败。让 AI 写 100 行探索性代码几乎是零成本的，但它不应该直接进入审核流程。

解决方案是物理分离两个阶段：

探索阶段          提交阶段
（AI 自由发挥）    （规范输出）
      ↓
 exp/feature-xxx  →  feature/xxx  →  PR  →  master
  • 探索阶段：在长命 exp/ 分支上自由推进，不提 PR，不审核，可以随时丢弃重建。AI 可以尽情尝试，失败了就换方向。
  • 提交阶段：把成熟的部分以规范的方式输出到 feature/ 分支，每个 commit 对应单一功能，做好代码拆分，再提 PR 走审核。

这样审核者只在"摘桃子"的阶段介入，看到的是经过整理的产出，而不是 AI 的全部思考过程。

Git 分支策略

分支命名规范

exp/{负责人}-{功能名}      ← 个人探索分支，每人一个，平行推进
feature/{负责人}-{功能名}  ← 准备交付的分支，通过 cherry-pick 从 exp 摘取

示例：

master
    ├── exp/zhangsan-payment
    ├── exp/wangsi-auth
    ├── feature/zhangsan-payment    ← 从 exp/zhangsan-payment 摘取
    └── feature/wangsi-auth         ← 从 exp/wangsi-auth 摘取

完整开发流程

1. 拿到需求
   └── 从 master 切出 exp/{功能名}，开始探索
   └── AI 在 exp/ 分支自由产出代码，不限制数量和规模

2. 确认交付
   └── 从 exp/ 分支切出 feature/{功能名}
   └── 指令 AI 在 feature/ 分支按"最小 commit 原则"整理代码
   └── 单个 commit 对应单一功能或单一修改

3. 提 PR
   └── feature/ → master
   └── PR 描述模板化

4. 合入 master 后
   └── exp/ 分支可保留作为备份，或清理删除
   └── 继续下一个功能的探索

最小 commit 原则

AI 在 feature/ 分支整理代码时，应遵循：

  • 一个 commit 对应一个逻辑改动（不是按文件数量，而是按"做了一件事"）
  • 不要把不相关的改动混在一个 commit 里
  • 每个 commit 附带清晰的 commit message

这样后续 cherry-pick 和追溯时会清晰很多。

PR 审核优化

PR 大小限制

类型行数限制处理方式
小 PR≤300 行简化审查，1 人通过即可合入
中 PR300-500 行标准审查
大 PR>500 行拒绝原路合入，打回让 AI 拆分

AI 生成代码的 prompt 里可以直接写这个限制，让它自己知道不要一次生成太多。

PR 描述模板

## 这次改了什么（≤3 句话）

## 为什么要这样改

## 影响范围
- 改了哪些文件/模块
- 是否破坏性变更

## 自测情况
- [ ] 单元测试通过
- [ ] 集成测试通过（若有）
- [ ] 手动验证（若需）

审核者先读这段，脑子里有框架再去看 diff，认知负担大幅降低。

依赖关系声明

用 GitLab 的 ! 引用把 PR 串成链：

!42 依赖 !41
!43 依赖 !42

审核者可以清楚看到先审哪个，合并顺序也不会乱。

潜在风险与局限

公共基础模块问题

探索阶段如果多个功能依赖同一个基础模块，可能会出现：

  • A 在 exp/a 里写了公共模块，B 在 exp/b 里也写了同一模块的另一种实现
  • 两者都成熟后，合入 master 时产生冲突

解法：公共基础模块优先摘取。谁先摸到公共代码，谁负责尽快把这个模块做成 feature PR 合入 master。其他人基于 master 继续探索。

如果公共模块复杂，可以考虑共建一个 exp/shared 分支专门放公共代码，探索成熟后同样走 PR 流程。

代码一致性风险

探索阶段代码不经过审核直接产出，如果 AI 生成的代码有隐蔽问题，可能在后续使用中才发现。

解法：

  • 合入 master 前必须通过 CI（单元测试、集成测试）
  • 高风险模块（支付、认证、核心业务逻辑）强制要求人工审核
  • 上线后有回滚能力，快速回退

过度探索的浪费

AI 高产能可能导致"探索了 10 个方向，最后只发了 2 个"的情况。探索阶段虽然没有审核成本，但代码维护本身有成本。

解法：定期盘点 exp/ 分支状态，明确哪些探索是确定要交付的，哪些是已放弃的，及时清理。

总结

AI 智能体让代码开发效率发生量变，但代码审核仍然是人力密集型工作。当生产速度提升 10 倍，审核模式必须跟着变，否则就会陷入堆积和阻塞。

「探索-提交」两阶段分离的核心思路是：

  1. 不让 AI 的全部产出直接冲击审核流程
  2. 用物理隔离代替流程压缩
  3. 让审核者只看"值得看"的部分

这不需要推翻现有的 Git 协作模式，只需要基于智能体的能力，优化分支管理与 PR 拆分流程，就能实现"高效开发"与"规范审核"的双赢。

下一步行动

对于想尝试这个方案的团队，最小化行动清单：

  • 约定团队 Git 分支命名规范（exp/、feature/）
  • 约定：exp/ 分支不提 PR、不审核，自由推进
  • 约定 PR 大小限制（建议 ≤300 行）
  • 配置 GitLab PR 描述模板
  • 选定一个小的探索功能，走一遍完整流程

找到卡点后再迭代，不要一开始就设计完美流程。