AI编程正在从单纯追求代码生成速度，转向对项目管理的全新挑战。当开发者需要同时指挥多个AI会话处理不同项目时，传统工作流暴露出严重的版本控制缺陷。本文提出了一套基于worktree隔离与分支管理的解决方案，揭示在vibe coding时代，真正的核心竞争力已转变为设计AI协作现场的能力。

过去我们聊 AI 编程，经常会把重点放在“怎么让 AI 写得更快”“怎么写 prompt”“怎么让 AI 一次性生成更多代码”。

但我最近越来越强烈地感觉到：在 vibe coding 时代，真正的瓶颈已经不只是写代码了，而是项目管理。

AI 太快了。你开一个对话，让它改项目 A；再开一个对话，让它改项目 B；又开一个对话，让它改项目 C。表面上看，这是效率暴涨。但只要项目稍微复杂一点，很快就会出现几个问题。

第一，哪个 AI 改了什么，很难追溯。第二，不同会话可能在同一个目录里互相覆盖。第三，master 分支很容易被直接污染。第四，需求改动、项目改动、临时试验混在一起，最后很难判断哪些应该合并，哪些应该丢掉。

所以我现在更倾向于把 vibe coding 理解成一种新的协作方式：不是“人写代码，AI 辅助”，而是“人管理目标，AI 分头执行”。

既然是分头执行，就必须有工作区隔离。我的做法是：固定 worktree，临时分支，总需求分支收口，master 最后合并。

简单说：master 不直接开发，只做最终收口；每个项目有固定 worktree；每个新需求先从 master 拉出一个总需求分支；每个项目再开自己的项目子分支；AI 在各自项目 worktree 里改；改完后先合并到总需求分支；整体确认没问题，再合并回 master。

这套流程的关键不是 Git 技巧，而是把 AI 的工作边界变清楚。

比如一个需求涉及三个项目，我不会让三个 AI 都在 master 上直接改，也不会让它们共用一个 worktree。我会让它们分别在自己的 worktree 和项目分支里完成改动，最后统一合到一个总需求分支里看整体效果。

这样做有几个好处：AI 可以并行工作，但不会互相踩文件；每个项目的改动可以单独提交、单独追溯；总需求分支能看到这次需求的完整变化；master 始终保持相对干净；如果某个项目改错了，可以只回滚那个项目分支。

这其实对应了 vibe coding 时代的一个新能力：你不只是要会提示 AI 写代码，还要会设计 AI 的工作现场。

以前一个开发者面对的是 IDE、Git、需求文档。现在一个开发者面对的是多个 AI 会话、多个项目、多个分支、多个上下文。如果没有管理方法，AI 越能干，项目越容易乱。

所以我现在判断一个 AI 编程流程是否成熟，不看它能不能一口气生成 1000 行代码，而看它能不能回答这些问题：这次需求从哪个分支开始？哪个 worktree 负责哪个项目？哪个 AI 会话改了哪些文件？改动是否能单独追溯？最后怎么合并到总需求分支？什么时候合回 master？远程仓库里能不能看清这次需求的来龙去脉？

vibe coding 的爽点是“顺着感觉把东西做出来”。但工程化的价值，是让这种感觉不会把项目带进混乱里。

我越来越觉得，AI 时代真正重要的不是“写代码能力消失了”，而是“项目组织能力变得更重要了”。

未来个人开发者可能会同时指挥多个 AI，小团队也可能用 AI 把原本几个人的执行速度提升很多倍。但前提是，你得先有一套能承接这种速度的工作流。否则，AI 写得越快，技术债也来得越快。