收藏｜一个人如何管理几十个 AI 程序员？

01 我为什么收藏这篇

原文从 OpenClaw 作者 Peter Steinberger 的一张 Codex 截图讲起。画面里同时跑着三十多个任务，工作还被分到多台机器上。看到这里，我最想弄明白的是这些任务怎样避免挤在同一个代码目录里互相覆盖。

刘小排把答案落到了 Git Worktree。这个功能已经存在多年，多 Agent 并行让独立工作目录变成了很实际的隔离手段。我收藏这篇文章，是因为它把一个看起来很夸张的并发场面，落回了 Git 里早已具备的基本能力。

02 Branch 和 Worktree 分别解决什么

Branch 保存的是一条独立开发线。新功能、修复和试验可以各自提交，完成以后再合并回主线。

Worktree 解决的是工作目录。一个 Git 仓库可以在硬盘上同时铺开多个目录，每个目录有自己的文件状态和当前检出内容，同时共享仓库对象。这样，一个 Agent 修改登录模块时，另一个 Agent 可以在另一个目录里修支付问题，不必轮流切换当前目录。

目录隔开以后，文件不会被另一个任务即时覆盖。合并时仍可能产生冲突：两个 Agent 如果同时改了同一段核心代码，Worktree 只能把施工现场分开，不能替你消除代码冲突。

03 我会怎么安排并行任务

我不会先决定开几个 Agent，再把工作硬塞进去。任务能不能独立完成，才决定要不要并行。

1. 几分钟的小改动：直接在当前工作目录完成，不为流程增加额外目录。
2. 一项较大的串行功能：开独立分支，仍由一个工作目录推进。
3. 多项互不依赖的改动：每项任务使用自己的分支和 Worktree，再分别测试、审查和合并。
4. 只想查看或测试旧版本：可以使用 detached Worktree，不占用正在开发的分支。
5. 准备扩到多台机器：先把测试、CI、审查和合并顺序固定下来，再增加并发数量。

Agent 数量上涨以后，检查代码、处理冲突和确认测试结果的工作也会一起增加。没有稳定的验证流程时，更多并行只会更快地产生一批没人敢合并的改动。

04 同一分支不能默认重复检出

这里需要补一个 Git 自己的限制。Git 官方文档写得很清楚：当一个分支已经被某个 Worktree 检出时，git worktree add 默认会拒绝在另一个 Worktree 再次检出这个分支。

git worktree add ../project-login -b feature/login main
git worktree add ../project-billing -b fix/billing main
git worktree list

上面两个任务分别从 main 建立自己的分支和目录。完成后，各自在对应目录里提交、测试，再回到主线逐项合并。这样既保留了 Worktree 的并行能力，也没有绕过 Git 的默认保护。

Git 官方文档：git-worktree ↗

05 开并行前先看三个条件

文件重叠要少。两个任务都要重写同一套基础组件时，拆成两个 Worktree 也会在合并阶段碰头。先把依赖关系理顺，再决定哪些部分能同时动。

完成标准要清楚。每个 Agent 都需要知道改哪些文件、跑哪些测试，以及产出到什么状态就停。没有退出条件的任务，很容易从实现一路扩张到重复检查。

必须有人负责合并。并行任务不会自动变成一个可靠版本。最终还要有人读 diff、确认测试范围、决定合并顺序，并在冲突出现时保留正确的业务判断。

这也是我读完原文后最想留下的边界。Worktree 能降低目录互相干扰的成本，能不能稳定地带更多 AI 程序员，最后看的是任务拆分和验收能力。

06 哪些内容值得回原文读

原文用五种开发场景逐步解释什么时候只用分支、什么时候增加 Worktree，又把讨论延伸到独立开发者怎样拆任务、补测试和维护基础设施。里面还有原始截图和配图，阅读节奏也比这份导读完整。

如果正在尝试让 Codex、Claude Code 或其他编程 Agent 同时处理多个任务，建议直接打开原文读完。这一页只负责帮忙记住文章入口、主要概念和 Git 的默认限制。

阅读刘小排r的完整原文 ↗