Codex Worktrees 适合把多个开发任务隔离开。你可以在同一个仓库基础上开出多个工作目录，让不同分支、不同任务、不同 AI 会话互不干扰。对于频繁让 Codex 改代码的人来说，worktree 能明显降低文件互相覆盖的风险。
最常见的场景，是同时处理两个需求。一个需求正在重构后端接口，另一个需求只改前端样式。如果都放在同一个目录里，Codex 读到的 diff 会混在一起，测试结果也不好判断。分成两个 worktree 后，每个任务都有自己的文件状态。
创建 worktree 前，要先确认主仓库干净。未提交改动、未跟踪文件和临时生成物都可能带来混乱。最好先提交、stash 或清理当前状态，再基于明确分支开新的工作目录。隔离任务不是用来掩盖混乱工作区的。
命名要有规律。目录名可以包含日期、任务编号或简短目标，比如 fix-login、refactor-api、docs-update。不要用 new、test、tmp 这种名字。过几天再看时，清楚的目录名能帮你快速判断哪个任务该继续。
让 Codex 进入某个 worktree 后，要在会话开始说明当前任务边界。它能看到这个目录里的文件，但仍然需要知道目标、限制和验证方式。worktree 提供物理隔离，任务说明提供语义隔离，两者都需要。
定时任务也适合放在独立 worktree。比如每天检查文档链接、每周生成代码审查建议、定期跑迁移分析。自动任务如果直接在主工作区运行，一旦写文件失败或产生临时改动，会干扰日常开发。
如果大家想体验一线 AI 编程模型 codex 和 claude，用它们帮你完成并行开发、自动化任务和效率提升，可以参考以下教程文档进行接入配置，接入配置好后即可使用。文档教程：https://my.feishu.cn/wiki/NIgLwuuj1ibzJIkLGM0cgVNinzg
多人并行时，worktree 不是替代分支管理，而是让本地同时存在多个分支。每个 worktree 仍然应该对应清楚的分支和提交记录。要交给同事审查，最终还是通过 commit 和 PR。
使用 Codex 改代码时，worktree 能减少误改主目录的概率。一个会话只负责一个 worktree，一个 worktree 只放一个任务。不要在同一个会话里频繁切换目录，让模型一会儿处理 A 任务，一会儿处理 B 任务。
测试也要在对应 worktree 里跑。不要在 A 目录改代码，却在主目录跑测试。路径错了，结果就没有意义。脚本里如果写了相对路径，要确认当前工作目录正是任务目录。
依赖安装需要注意磁盘空间。多个 worktree 可能共享 git 对象，但构建产物、node_modules、缓存和日志仍然会占空间。大型前端项目开太多 worktree，硬盘会很快膨胀。定期清理已经合并的任务很重要。
如果任务失败，不要直接删除目录。先看 diff，保留有价值的修改或调查记录，再决定删除。AI 改坏的任务里也可能有一两个有用片段，盲目清理会把线索一起丢掉。
团队可以约定 worktree 的使用规则。比如高风险重构必须在独立 worktree，自动化任务必须只读运行，临时实验不得直接推送远端。规则明确后，AI 会话和人工开发更容易共存。
合并前要回到普通工程流程：看 diff，跑测试，整理提交，写 PR 描述，处理冲突。worktree 只是把任务分开放，不会自动保证代码质量。真正的质量还是靠审查和验证。
Codex Worktrees 的价值，是让并行开发变得可控。它把不同任务放在不同目录里，把不同会话限制在不同边界内。任务越多、AI 修改越频繁，这种隔离越值得提前建立。
worktree 用久以后，要养成清理习惯。已经合并的分支、失败的实验目录和过期构建缓存都要处理。否则隔离目录越开越多，最后自己也分不清哪一个还在使用。
如果一个任务需要 AI 和人工交替处理，可以约定每次交接前都看一次 diff。这样人工知道 AI 改了什么，AI 也能基于当前改动继续，不会重复编辑同一块代码。
定时任务放在 worktree 里时，输出目录也要固定。报告、日志和临时文件不要散落在仓库各处。路径固定后，清理和审计都更容易。
多人并行开发还要注意远端分支命名。每个 worktree 对应的分支最好能从名字看出负责人和目标，避免两个同事基于相似任务各推一个难以区分的分支。
如果某个 worktree 里任务已经跑偏，先停止自动修改。把有价值的发现整理出来，再决定重开干净分支。隔离环境的好处，就是失败不会污染主工作区。
落地到 Codex 工作流时，建议保留一份简短检查表。检查表不用复杂，只要写清任务目录、分支、关键文件、验证命令和最后一次成功时间。以后重复处理类似任务时，这些信息会比临时记忆可靠。
如果任务涉及多个配置入口，要把优先级写出来。命令行参数、项目配置、用户配置和环境变量可能同时存在，谁覆盖谁必须清楚。很多看似模型不听话的问题，其实是配置来源没有理顺。
每次完成一轮修改，都要让 Codex 说明改了什么、为什么改、还没验证什么。这个习惯能把 AI 输出变成可审查的工程记录，而不是一段看完就丢的聊天内容。
遇到异常时，不要立刻扩大范围。先用最小任务验证能力是否正常，再逐步加回真实项目的复杂条件。最小复现能把工具问题、项目问题和环境问题分开。
如果准备把流程推广给团队，先在一个低风险项目里连续跑几天。记录成功率、失败原因、人工修正时间和测试结果。只有这些数据清楚，才知道流程是否值得推广。
Codex 的优势是能读上下文、改文件、跑命令和整理结果，但它仍然需要边界。边界越清楚，输出越稳定；验证越及时，返工越少。把工具放进工程流程，而不是把工程流程交给工具，才是长期好用的关键。
