我同時開了三個 Codex task：三個和尚沒水喝，還是三個臭皮匠勝過一個諸葛亮？

我常常同時想到幾篇文章要怎麼改。

如果全丟進同一段 AI 對話，前一篇還沒處理完，後面又排了好幾個想法；不同文章的背景也開始混在一起。我開兩到三個 Codex task，首先是想讓不同文章各有一個幫手，讓想法早一點開始被處理。

這裡的 task，就是 Codex 裡各自保有對話與工作背景的任務。你可以想像三個助手各寫一篇文章，卻共用同一本工作簿：正文分開，目錄和出版紀錄仍只有一份。

2026 年 8 月 30 日，三個 Codex task 就這樣同時在同一個網站專案開工。

一個改既有文章；一個修草稿內鏈的共用邏輯；另一個寫新文章，之後還要接手私人預覽。

最先救到我的，不是更聰明的 prompt，而是一則很樸素的訊息：

協作提醒：我準備修改 <精確路徑>，目的為 <一句話>；請告訴我是否重疊。

幾分鐘後，真的有人回覆：兩份共用紀錄撞到了，先不要動。另一個 task 又補了一句：整站 build 與 preview 也先別重建，否則大家看到的會是施工中的混合版本。

它們共用同一份本機專案副本，也看得到彼此尚未提交的變更。

題目雖然不同，仍可能一起碰到站務紀錄、Git 暫存區、全站建置或私人預覽服務。

後來每個 task 動手前，都會先說自己準備改哪些檔案；碰到重疊就先讓開，完成後再通知其他人接手。

我負責分流，task 負責把施工邊界說清楚

我先把不同文章的想法交給不同 task；開始平行處理後，才需要補上誰能改哪些檔案、誰負責整合的規則。這不是三個視窗一打開，就會自動互相合作。

本次保存的紀錄確認：task 之間傳出了協作訊息、收到回覆，而且依回覆改變了施工順序。例如，主 task 指出共用紀錄重疊，寫稿夥伴便暫停那兩份紀錄，先寫自己的文章。

要照這個方式分工，就得先確認 task 之間能收到彼此的訊息。當發送端顯示「已通知」後，我們還要去看對方有沒有回覆，才能再安排接下來的工作。

我決定文章要寫什麼，task 回報改了哪些檔案、哪裡撞到，以及驗證結果。內容看過後，再由我決定是否發布。

題目不同，不代表資源不同

我原本以為，三個 task 各寫不同文章，工作自然就分開了。

第一個被攔下的碰撞卻不是文章正文，而是共用紀錄：兩個 task 都準備更新同一份題目清單與站務紀錄。

如果它們各自默默動手，同一份本機專案未必會出現 Git 衝突。兩邊改到不同段落時，甚至可能照樣暫存、提交，卻有一邊依過時的篇數、標題或預覽狀態寫錯。

協作提醒讓其中一方先放掉兩個重疊路徑，其他不重疊的文章、素材與測試照常施工。

這個細節很重要：發現一處重疊，不等於三個 task 全部停工。

我實際使用的四種訊息

四種訊息不是四篇長報告，而是一個從認領到釋放的閉環。

1. 動手前宣告：不要只說「我來寫文章」

「我負責第二篇」不夠精確。

一篇文章不只會改正文，也可能更新素材、題目清單、測試或預覽設定。只按題目分工，無法看出這些共用資源會不會撞到。

這裡的精確路徑，就是要改的具體檔名與所在位置，而不是只說「首頁」或「文章區」。因此，我要求 task 在動手前列出精確路徑與一句目的。途中若新增路徑，原本的「不重疊」就失效，必須重新提醒。

2. 回覆重疊：只凍結撞到的部分

好的回覆不只說「收到」。

它會直接指出哪幾個路徑重疊、目前由誰持有，以及哪些路徑仍可繼續。

因此，一個 task 可以先寫自己的新文章，卻暫時不碰共用題目清單；另一個可以修文章內容，但先不重啟私人預覽。等待被縮小到真正有風險的地方，平行工作的價值才留得住。

如果沒人回覆呢？ 以下是我會補進下一次操作的規則：沒收到回覆，不算取得共用資源的操作權。先等目前負責人明確交回；其他已確認不重疊的工作可以繼續。若兩邊都說自己在負責，先由主 task 或我確認分工，再動那一部分。

3. 風險廣播：檔案沒撞，驗證仍可能混在一起

共用內鏈方案的單元測試通過，但用現有站點設定做隔離建置時，才發現它和 Markdown 工具不相容。

這不是兩個 task 同時改同一檔造成的 conflict。

可是其他 task 若同時建置，可能誤以為自己的文章壞了，也可能對施工中的混合版本下結論。

所以施工者主動廣播：「先暫停整站 build；我正在修共用設定，新的 checkpoint 完成後再放行。」

這則廣播不是在防撞檔，而是在說清楚：目前的錯誤會影響哪些人。

4. Checkpoint 釋放：完成不等於別人已經可以接手

Checkpoint 是一次存進 Git 版本紀錄的工作點，可以讓接手者指認、核對同一版檔案。「好了」仍然不夠。

交棒訊息至少要讓下一位知道：

• checkpoint 與實際包含的路徑；
• 已完成哪些驗證；
• 現在釋放什麼，仍由誰持有什麼。

接手者再從磁碟重讀最新版，而不是靠聊天裡記得的舊內容繼續。

這次三個 task 的相關網站 checkpoints 最後形成線性的 parent chain，沒有額外的合併提交。我核對到的已提交路徑，也落在當時宣告或更新過的認領範圍內。

兩份共用紀錄則由前一位完成並釋放，下一位重讀最新版後再追加。

Checkpoint 在這裡不只是備份；它同時是可以接手的版本座標。為什麼我平常不看 Git log，仍要求 AI 留 checkpoint，另寫在〈我幾乎不看 Git log，為什麼仍要求 AI 每次留下 checkpoint？（尚未公開）〉。

【動手前】
協作提醒：
我準備修改 <精確路徑>。
目的：<一句話>。
請告知是否重疊。

【發現重疊】
重疊項目：<路徑／資源>。
請先暫避。
其餘路徑可繼續。

【風險廣播】
<共用資源> 正在施工。
請暫停 <受影響動作>。
新 checkpoint 後放行。

【完成與釋放】
Checkpoint：<commit>。
路徑：<清單>。
驗證：<結果>。
現在釋放：<路徑／資源>。

這套分工靠 task 遵守約定。外部編輯器和背景程序仍可能改動檔案，接手前還是要重讀最新版。

所有權不明或目標重疊時，Fork 為什麼仍應只交提案，留在前一篇〈我讓 AI 分身幫忙，結果它直接改了主線（尚未公開）〉。這一篇只處理已經能互相溝通的 task，如何真的一起施工。

最容易漏掉的共用資源，不在文章路徑裡

精確路徑能攔住多數同檔碰撞，卻攔不住下列共用狀態：

• Git 暫存區與提交：一次操作可能誤收別人的變更。
• 全站建置：會一起讀到施工中的設定與半成品。
• 私人預覽服務：同時重建或重啟，容易驗證到錯版本。
• 最終站務紀錄：要等服務終態確定後再更新。

這次的做法是把 preview 當成一把只有一人暫時持有的鑰匙。

預覽分兩次驗證，各自對應不同 checkpoint：第一次核對當時完成的部分，第二次等所有工作整合後，再一起確認。

接手者在動手前連續檢查失敗，因此沒有修改預覽服務。它回報碰過什麼、沒碰什麼，再把操作權交還熟悉啟動流程的 task。

這也是交棒的一部分：不只成功後要釋放；確定自己不適合繼續時，也要說清楚做過什麼、沒做什麼，再交回去。

Codex 提供了手，但沒有替我發明這套交通規則

Codex 能平行派出 subagents；worktree 則提供另一份獨立 checkout。Worktree 是隔離工作檔的一種方式，讓各任務在不同工作目錄修改；它不會自動協調最後的整合或共用預覽服務。官方也提醒，多個 agent 平行寫入會增加衝突與協調成本。

本文的三個 Codex Desktop tasks 不等同官方文件裡由單一主線派出的 subagents。它們都留在同一份本機專案，所以更依賴路徑認領；而這個專案共用的整合分支與單一預覽服務，仍另外指定一位目前負責人。

這次的結果，放在一起看

我開三個 task 的最根本理由，是想讓不同的 idea 能夠並行處理，同時也讓各自的討論背景分開。這次遇到重疊時，一邊先讓開共用紀錄，繼續寫自己的文章；等對方完成，再回來接手。不同工作因此能各自往前走。

外部經驗能補充什麼？

Git 的 worktree 官方文件說明，每個工作目錄有自己的暫存區，但仍共享部分版本庫資料。這有助於理解兩種不同的問題：工作檔分開，可以減少直接互相覆寫；共用的服務與最後整合，仍需要指定負責人。

Anthropic 在 2025 年分享多 agent 研究搜尋系統的開發經驗時，也遇到任務邊界不清、重複工作的問題。需要共享大量背景、彼此高度相依的任務，協調起來尤其麻煩。回頭看這次分工，不同文章可以分頭寫，共用紀錄和預覽服務就需要輪流處理。

隨著同時進行的工作變多，session 之間的互相聯繫，也逐漸成為我工作流裡不可或缺的一環。Claude Code 在 8 月也加入了跨 session 傳訊功能，讓不同工作階段能直接交換訊息。

因此，我會先問：這幾件事真的能各自前進嗎？如果三個想法都在改同一篇文章，交給同一個 task 依序處理，通常更容易維持一致；若是不同文章已各自有清楚方向，才值得嘗試分流。

下一次，不要一開始就開三個寫入 task

如果要試這套方法，我會先從兩個低風險 task 開始：

1. 讓兩邊在動手前都列出精確路徑與目的。
2. 指定同一檔案只有一位目前負責人，另一位先做不重疊部分。
3. 把 Git commit、全站 build 與 preview 明列為共用資源。
4. 任一路徑集合改變，重新宣告，不沿用舊的「不重疊」。
5. 結束時檢查是否有 task 在收到釋放前碰過重疊資源。

不必先造一套排程器，也不必把每個 task 都塞進 worktree。

平行工作的關鍵，不僅僅是多開幾個視窗。

更重要的是讓每個 task 都知道何時該報到、何時該讓路，以及哪一句訊息代表可以重新開工。