项目如何使用 AI 并行开发，其实是一个挺头疼的问题。

流水潺潺可穿石

项目如何使用 AI 并行开发，其实是一个挺头疼的问题。

比如让 Claude 和 Codex 同时改代码，经常会出现一种很荒诞的场景：Claude 不小心读到了 Codex 正在修改的代码，而那段代码刚好还没改完，里面还有一点小 bug。Claude 看不下去，直接把文件接手过来，一通修改。Codex 很快也意识到自己的代码被改了，于是又把代码修正回来。

于是控制台上就会出现两个 AI 的拉锯战，你改一版，我改一版，来回循环，token 在疯狂消耗，事情却没有往前推进一步。

Codex 客户端给出的一个解决方案，是利用 Git 的 worktree 机制。简单说就是把代码拆到多个目录里，每个 AI 在自己的目录里干活，互相隔离，最后再通过 merge 的方式合并代码，并手动处理冲突。这个方法在中小规模任务里还算有效，不过如果项目里有一个比较激进的规则，比如边改代码边做架构优化和工程优化，就会遇到新的问题。当多个 worktree 分支同时在做结构调整时，最后合并的冲突复杂度会非常高，有时候解决冲突的时间，甚至比 AI 写代码还要长。

GitHub Copilot CLI 的思路稍微不一样，它更偏向任务隔离，而不是代码隔离。通常会通过一次 Request 定义一个比较完整的任务边界，让 AI 在一个任务上下文中完成修改，尽量避免多个会话同时在同一片代码区域频繁改动。简单理解就是减少并发编辑，增加任务粒度。

不过说实话，这个问题目前看起来还没有特别完美的解决方案。我现在的做法主要是从流程上做一些约束，比如在编码之前就约定好规范，要求 AI 在 Coding 之前先评估影响面；项目目录尽量做隔离，让功能尽量收敛到单个目录中；提前做好抽象和组件复用，减少多个模块同时修改同一层代码的概率。同时也尽量避免多个 AI 同时编码，例如 Claude 写代码的时候，让 Codex 去写设计文档或者系统分析，把文档编程和代码编程拆开。

现在的感觉是，AI 并行开发看起来很像多核 CPU，真正跑起来之后才会发现，很多问题其实来自锁竞争和资源争抢。

不知道大家现在是怎么解决这个问题的。