Codex 云任务与 Git Worktree 并行实战

嘿，朋友们，我是小枫同学。你有没有遇到过这种情况：想让 AI 在后台帮你修个 bug，又怕它把你正在写的代码搞得一团糟？或者同时起了两个云任务，结果合回来的时候冲突到怀疑人生？今天咱就来聊聊怎么用 Codex 的 worktree 和云任务，让并行工作真正变成加分项，而不是给自己挖坑。

先说一个核心问题。并行工作的坑，大多不是工具不够快，而是多个任务的文件状态搅在一起。两个代理同时改同一个目录，不出事才怪——覆盖、冲突、改完之后你根本说不清楚哪段代码是谁改的。解决这个问题的关键，就是让每个任务有自己独立的文件空间和清晰的合并边界。

三种执行位置

先搞清楚你的代码到底跑在哪儿。Codex 给了你三个选择：

位置	文件在哪里	适合什么
Local	你的日常工作目录	前台调试、真实设备、已有本地服务
Worktree	同一 Git 仓库的独立 checkout	本机并行任务、后台修改、独立分支
Cloud	OpenAI 管理的隔离环境	远程长任务、并行尝试、云端 PR

简单来说，Worktree 跟你本地共享 Git 对象（所以不会重复占用磁盘），但每个 worktree 有自己独立的文件副本。云环境就完全是另一台机器了，依赖、环境变量、网络策略都得单独配。这个区别后面还会反复提到，记住就行。

什么时候应该用 Worktree

适合的场景：

• 你正在本地写代码，想让 Codex 在后台修另一个问题；
• 两个任务改的是不同模块，井水不犯河水；
• 定时任务不应该干扰你日常工作的目录；
• 想比较两个实现方案，各跑各的；
• 任务可以在独立 checkout 里验证通过。

不适合的场景：

• 两个任务必须频繁改同一个核心文件——这种情况大概率互相踩脚；
• 项目依赖只能在一个全局实例里跑（比如只有一个本地数据库）；
• 大量没跟踪的文件没有准备好复制规则，worktree 里直接缺胳膊少腿；
• 任务连起始分支和合并顺序都没想清楚就开干。

我自己就踩过一个典型的坑。有一次我心血来潮同时开了三个 worktree 任务改同一个服务层的代码，想着"各改各的方法应该没事"。结果三个任务分别改了同一个 order_service.go 的不同方法，合并的时候 Git 倒是没冲突，但逻辑上互相矛盾——A 任务改的返回值类型 B 任务完全不知道，集成测试直接炸了。从那以后我学乖了：改同一个文件的任务，老老实实排队。

在桌面应用创建 Worktree 任务

1. 项目必须是 Git 仓库。
2. 新建任务时选择 Worktree。
3. 选择起始分支或明确的当前状态。
4. 发送任务，并在任务头部确认运行位置。
5. 完成后选择在 worktree 中创建分支，或通过 Handoff 移回 Local。

有个容易踩的坑：Codex 管理的 worktree 默认可能处于 detached HEAD。你要是需要提交或推送，一定记得先创建明确分支。另外 Git 不允许同一个分支同时在两个 worktree 中 checkout，这个硬限制别忘了。

给并行任务分配文件所有权

说说怎么避免"互相踩脚"。核心思路就是提前划地盘。主任务提示可以这么写：

把工作拆为两个互不重叠的 worktree 任务：

任务 A：只修改 backend/orders/** 和对应测试，完成导出接口。
任务 B：只修改 frontend/orders/** 和对应测试，完成下载 UI。

共享 API 契约先由主任务确定并写入 docs/order-export-contract.md。两个任务都不得修改该文件。等待两边完成后再统一集成和端到端验证。

你看，这个提示的精髓在于：先定契约，再分地盘，最后集成。如果两边确实都需要改同一类型或配置，那就先让一个任务把接口基线搞定，另一个任务再基于新基线开始。别两路同时冲锋，那样只能两路同时阵亡。

Worktree 中的依赖和 ignored 文件

新 worktree 不会天然拥有这些东西，你得心里有数：

• node_modules、虚拟环境和构建缓存；
• .env.local 等 ignored 文件；
• 本地数据库和正在运行的服务；
• 未提交但不在起始状态中的文件。

我第一次用 worktree 的时候，任务跑一半报 module not found，我愣了半天才反应过来——新的 worktree 里压根没有 node_modules。从那以后我养成习惯了，在桌面应用的 Local environments 里给 worktree 配好 setup scripts，把共享配置放在仓库根目录的 .codex/ 下。

对于确实需要复制的 ignored 文件，用官方支持的 .worktreeinclude 规则。但记住只包含安全且必要的本地文件，千万别把真实密钥复制到不受控目录——这属于基本安全素养。

命令行手动创建 Git Worktree

不依赖桌面应用的话，直接用 Git 命令也行：

git worktree add ../project-feature -b codex/feature-name main

进入新目录开搞：

cd ../project-feature
git status --short --branch
codex

完成之后，先确认没有未提交的修改，再按 Git 官方流程移除 worktree。说句实在的，清理命令别写成自动脚本跑在还有工作的目录上——我有一次手滑差点把自己写了两天的分支给清了，幸好 Git 的 safety check 救了我一命。

什么时候使用 Cloud

云任务适合这些情况：

• 本机不想长时间占用，该关机睡觉就睡觉；
• 任务可以在标准容器中重现；
• 需要多个尝试或并行分支，想广撒网；
• 希望直接形成云端 diff/PR；
• 仓库和依赖可以安全授权给云环境。

云环境的 setup 阶段可以安装依赖并访问配置的秘密；代理工作阶段默认离线，除非你主动开启互联网访问。这里有个细节容易忽略：秘密在 setup 和 agent 阶段的可用边界不一样，一定要按当前官方说明来设计，别假设云环境和本地 shell 一样随心所欲。

用 CLI 提交和检查云任务

先看看有哪些环境和任务：

codex cloud list

提交任务：

codex cloud exec --env <ENV_ID> --branch <BRANCH> "实现已确认的里程碑 1，并运行相关测试"

想要多个候选方案对比的话：

codex cloud exec --env <ENV_ID> --attempts 2 "比较两种最小实现，保持公开 API 不变"

检查状态和差异：

codex cloud status <TASK_ID>
codex cloud diff <TASK_ID>

确认差异没问题后应用到本地：

codex cloud apply <TASK_ID>

应用之前一定要跑一遍 git status --short --branch，确认本地没有未保存的并行修改。多个 attempt 的时候用 --attempt <N> 指定你已经审查过的那个结果，别一股脑全合进来。

我踩过云任务的一个坑：云端跑得好好的，diff 看起来也漂亮，结果 apply 到本地之后编译不过。原因很简单——云端装的依赖版本跟我本地不一样。所以现在我的铁律是：云端通过 ≠ 本地通过，后面会细说。

云结果回本地后的验证

这句话值得刻在脑门上：云端通过不代表本地通过。 至少检查这三步：

git status --short
git diff --stat
git diff

然后在本地真实环境跑相关测试、构建，该上设备上设备，该开浏览器开浏览器。云环境可能缺你本机的服务、私有网络、硬件环境，以及那些你忘了提交的上下文信息。

常见失败

Worktree 缺少 .env 或依赖

把可共享的 setup 写进 Local environment；敏感变量走安全方式注入，别直接把整个 .env 文件复制过去。我的做法是在 .codex/ 下放一份模板配置，worktree 起来之后跑一个 setup 脚本自动生成。

两个任务互相覆盖

说明文件所有权，避免共享核心文件，或者老老实实按依赖顺序串行。别同时改同一个文件，血的教训前面讲过了。

云任务无法访问私有包

在 setup 阶段配置最小网络、凭证和源。关键是确认凭证不会泄漏到 agent 输出和仓库里——这个翻过车的人不在少数。

应用云 diff 时冲突

先停掉自动应用，比较起始基线和本地当前状态。必要时在独立分支或 worktree 里先应用再合并，给自己留条退路。

完成门槛

• [ ] 每个并行任务有独立目录和明确基线。
• [ ] 文件所有权和合并顺序已定义。
• [ ] 依赖、ignored 文件和秘密边界已处理。
• [ ] 云/worktree diff 已人工审查。
• [ ] 结果回到本地后重新验证。

下一步

把稳定的重复工作交给 Codex 定时任务与持续目标。

事实来源

• OpenAI：Worktrees
• OpenAI：Cloud environments