讓 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。隨稿附有 重現指令碼 和 原始結果，可檢查每一步。