让 Claude Code 和 Codex 并行工作：一个 Git Worktree 小实验

让 Claude Code 改文案，同时让 Codex 修复导出逻辑，先要为它们准备各自的工作目录。

如果两个对话指向同一个目录，一个 Agent 刚改过的文件就会成为另一个的输入。你看到“测试通过”时，也可能已经说不清这份结果对应谁的修改。

一边调整设置说明，一边修复空日期导出：这两个任务可以同时推进，也需要分别检查。下面用一个可复现的小实验，演示如何准备独立目录、分配任务，再验证合并后的结果。实验由脚本完成；提示词供你在自己的项目中使用。

先确定每项任务的修改范围和完成标准

示例项目有一个设置文案文件，以及一个把时间戳转换为导出日期的函数。

文案任务只改 settings.zh-CN.json，将“管理设备”的说明文案修改为“查看已登录设备，并撤销不再使用的设备访问”。日期任务只修复缺失值行为，保持有效时间戳按 UTC 日期导出的规则。

原来的日期函数只有一行：

export function exportDate(value) {
  return new Date(value).toISOString().slice(0, 10);
}

它对 null 返回 1970-01-01，对空字符串抛出异常。这两种结果都不符合“没有日期就留空”的要求。

先运行四个测试：缺失值的两个用例失败，UTC 时间戳和带时区时间戳的两个用例通过。这个基线很有用——日期任务应该修好前两项，并保留后两项的行为。

从同一个提交，开两个工作目录

在已有 main 分支的仓库里，先确认起点提交。下面的命令要求新分支名和目标目录尚未被使用：

git worktree add -b feature/settings-copy ../project-settings-copy main
git worktree add -b fix/export-dates ../project-export-dates main
git worktree list

每个 worktree 有自己的检出目录和索引（暂存区），可以分别保留不同分支上的修改；它们仍属于同一个 Git 仓库。新目录从指定提交开始，原目录里未提交的改动不会自动带过去。依赖和本地配置需要按项目要求准备，详见 Git worktree 官方文档。

创建完成后，两个任务的目录和分支分别如下：

两个任务各用一个目录，同时保留各自的工作副本。只在同一目录里切换分支，无法做到这一点。

在 Tactic Remote 中为每个对话选对目录

连接开发主机，在 新建对话 中打开项目选择，必要时用 选择其他文件夹 指向对应 worktree 的实际路径，再选择 Agent。

如果已经为仓库建立了 worktree，直接选择对应目录即可。另建一个“独立工作区”并不会自动包含该仓库及其分支关系。

给 Claude Code 的第一条要求可以是：

只修改 settings.zh-CN.json 的设备说明，让用户理解这里可以查看已登录设备并撤销访问。先确认当前目录和分支。不要改日期导出逻辑。完成后列出文案差异，并检查 JSON 是否有效。

给 Codex 的第一条要求可以是：

修复 export-date.mjs：null 和空字符串应返回空字符串，有效时间戳继续按 UTC 日期导出。先确认当前目录和分支，运行现有四项测试，复现后做最小修改。不要改设置文案。报告修复前后的结果。

在提示词中限定文件范围，便于后续审阅，但它不是权限沙箱。Agent 实际能读写哪些文件，仍由它在主机上的运行权限决定。

分别检查，别让“都通过了”掩盖差异

示例中的最小修复，是在转换日期前先判断输入是否缺失：

export function exportDate(value) {
  if (value === null || value === undefined || value === '') return '';
  return new Date(value).toISOString().slice(0, 10);
}

这段代码只处理约定的缺失值。其他无效日期字符串应该如何处理，需要另行定义；有效时间戳仍按 UTC 日期导出。

在两个工作目录里分别检查：

git status --short
git diff --name-only
git diff

本次实验中，文案目录只出现 settings.zh-CN.json 的差异，日期目录只出现 export-date.mjs 的差异。我们也直接检查了文件内容，确认文案目录仍保留原日期函数，日期目录仍保留原文案。

验证结果如下：

文案分支的 JSON 检查通过了，日期逻辑则仍保留两个已知失败用例。把验证范围和测试基线一起记录下来，审阅时就能看清每项结果说明了什么。

最后，在一个明确的分支里整合

两项修改分别完成审阅并提交以后，可以在示例仓库的原目录创建整合分支：

git switch -c review/combine main
git merge --ff-only feature/settings-copy
git merge fix/export-dates
node --test export-date.test.mjs

这里假设原目录没有待处理的改动，且两个任务分支已提交。在实际项目中，继续遵循原有 PR 和合并流程；如果发生冲突，先看清双方意图，再运行组合后的验证。

合并后的验证同样必要：即使两个分支各自通过了检查，改动之间仍可能相互影响。工作目录分开后，共享配置、依赖、数据库和服务端口仍需协调。

确认修改已经保留、工作树干净且不再被使用后，用普通的 git worktree remove 清理目录。Git 如果拒绝删除有改动的工作树，先处理提示里的未提交内容。

回到手机时，先确认任务和验证结果

在手机上查看并行任务时，先确认主机、项目和对话，再读最新结果，找出需要你决定的事项。

对文案任务，你可能只需确认一个术语；对日期任务，你可能需要回答导出采用 UTC 还是当地时间。把决定留在对应对话里，后续审阅时就能找到原因。

这套方法从两个任务就能开始：给每项工作一个目录、一份明确要求和一份验证结果，再检查合并后的结果。任务数量可以增加，判断依据仍然应该保持清楚。

本文实验在本地临时 Git 仓库中完成，未调用 Agent。随稿附有 复现脚本 和 原始结果，可检查每一步。