#Codex 工作流与 Worktrees

Codex 的威力不只在「单次把任务做对」，更在于同时推进多件事而互不干扰。本章讲清楚工作流模式（Local/Cloud、Hand off、并行线程、规划→执行→审查）与背后的 Git Worktree 机制。

#四种执行入口，按场景选

Hand off（接力） 把一个线程在入口/设备间交接：本地起草 → 云端跑长任务 → 移动端盯进度，最后 codex apply 拉回 diff。

#工作流模式：规划 → 执行 → 审查

把一次复杂任务分阶段，质量与可控性会显著提升：

① 规划（只读）        ② 执行（工作区可写）      ③ 审查（独立视角）
read-only            workspace-write          /review 或审查子代理
产出方案/文件树   →   按方案改代码、跑测试   →   对照方案逐行核对

• 规划阶段用 read-only，让它先给方案再动手，避免盲目乱改
• 执行阶段用 workspace-write + 越界询问
• 审查阶段用 /review 或独立审查子代理，不继承「我已改对」的偏见

#Goal 模式：朝目标长跑

Goal 模式让 Codex 朝一个持续目标自动推进数小时甚至数天，适合「把整套测试修绿」「迁移完一个大模块」这类长链路目标。启用见 斜杠命令 /goal。

#并行线程

桌面应用为并行而设计：每个任务是一个独立线程，可同时挂多个——一个重构后端、一个改前端、一个写文档。但若它们都改同一个工作区，就会互相踩脚。解决办法就是 Worktree。

#Git Worktree 是什么

git worktree 允许同一个仓库在不同目录上同时检出不同分支，共享同一份 .git 历史：

my-repo/                  ← 主工作区（分支 main）
my-repo-feat-a/           ← worktree（分支 feat-a）
my-repo-feat-b/           ← worktree（分支 feat-b）

每个 worktree 是独立的工作目录，互不干扰——非常契合「多个 Agent 任务并行」。

#手动创建（CLI 场景）

git worktree add ../my-repo-feat-a -b feat-a
cd ../my-repo-feat-a
codex --sandbox workspace-write --ask-for-approval on-request

完成后清理：

git worktree remove ../my-repo-feat-a

#桌面应用里的 Worktree

桌面应用内置 worktree 支持，无需手敲命令：

• 发起任务时可选择在新 worktree 中运行，与你正在改的工作区隔离
• 多个线程各自跑在独立 worktree，真正并行而不串味
• 任务结束后可归档/清理对应 worktree

在 自动化（Automations） 里同样可选「本地项目」或「新 worktree」：worktree 模式让定时任务的改动与你未完成的本地工作分开，见 自动化与 CI/CD。

#Local 项目 vs Worktree 怎么选

#一个并行工作流示例

1. 线程 A（worktree，分支 refactor/api）：重构后端 API
2. 线程 B（worktree，分支 feat/ui）：实现新页面
3. 线程 C（Cloud）：跑一个耗时的依赖升级，产出 PR
4. 你在主工作区照常开发，随时审查 A/B/C 的 Diff，满意再合并

#下一步

• 子代理：在一个任务内部再做分工
• 自动化与 CI/CD：把 worktree 用到定时任务
• 实战案例：端到端的多阶段流程