團隊協作：AI 程式助理 Claude Code 與 Codex 的專案管理心法

大多數關於同時使用 Claude Code 和 Codex 的指南，都假設只有一個人操作兩組終端機。這種設定很簡單。困難的版本是兩三個人，每個人使用自己的筆電和自己的計畫，一人使用 Claude Code，另一人使用 Codex，但都將程式碼推送到同一個儲存庫。

當只有一個人時，代理不知道的一切都還存在於那個人的腦海中。但團隊則不然，每個代理只知道它自己的使用者告訴它的內容，別無其他。到了週三，兩個代理可能已經用兩種不同的方式做出了相同的決策，卻沒有人注意到，因為他們的 PR 觸及了不同的檔案。以下是我們在許多混合代理團隊於同一個儲存庫上運作後，所確立的設定，這些方法都不需要特殊的工具。

1. 一個指令檔案，供兩個代理讀取

Codex 會讀取 AGENTS.md。Claude Code 過去只讀取 CLAUDE.md，因此團隊會維護兩個檔案，導致它們逐漸產生差異。自 Claude Code 2.1.277 版本以來，這已不再是問題：在沒有 CLAUDE.md 的資料夾中，Claude Code 會改為讀取 AGENTS.md。您可以在「專案指令」下的 /config 中更改此設定。

如果您有 Claude 專屬的指令，請將 CLAUDE.md 保留為單行匯入加上額外內容：@AGENTS.md ## Claude Code only - 使用測試執行器腳本，而不是原始測試指令。使用匯入比符號連結更好，因為它在 Windows 上無需開發者模式即可運作，並且能避免被檔案複製工具破壞。

請保持 AGENTS.md 簡短，它應該包含每個代理在每個任務中都需要遵循的規則：如何執行測試、檔案存放位置、以及絕不能碰觸的內容。任何每週變動的內容都應放在下面的檔案中。

2. 規劃前先認領任務

團隊中最代價高昂的失敗不是合併衝突，因為合併衝突會發出明顯的警訊。真正昂貴的失敗是悄無聲息的：兩個代理從聊天訊息中發現同一個錯誤，卻以相反的方向進行修復。一個代理增加了重試機制，另一個則移除了它。兩個 PR 都顯示為綠色（通過測試），程式碼行也沒有重疊，但問題卻在正式環境中才被發現。

解決方案是在任何規劃之前進行任務認領：如果您使用 GitHub issues，代理會在撰寫計畫之前指派該 issue（或開啟一個命名該 issue 的草稿 PR）。如果您使用 TASKS.md，代理會將其使用者的姓名寫在任務旁邊，並首先推送這一行變更。

將這條規則寫入 AGENTS.md：「在規劃之前，請認領任務。如果其他人已認領，請停止並選擇另一個任務。」一旦寫下來，代理就會很好地遵循這條規則，但它們不會自行這麼做。

3. 決策記錄為一行日期條目

程式碼審查可以發現不良程式碼，但它無法捕捉到三天前在別人工作階段中做出的、你的代理從未聽說過的決策。請維護一個 DECISIONS.md 檔案，每項決策佔一行：

2026-10-14 重試機制僅存在於 HTTP 用戶端中，絕不應存在於呼叫端。拒絕：每次呼叫的重試旗標（隱藏失敗）。PR #212

2026-10-15 任務使用 Postgres，而非 Redis。拒絕：Redis streams（多一個要運行的東西）。PR #219

有兩個細節比看起來更重要。首先是被否決的替代方案：這正是下一個代理會自信地提出的方案，除非它能讀到為何被拒絕的原因。其次是代理在每次工作階段開始時都應讀取此檔案的規則，而不是等到有人想起才讀。這條規則也應寫入 AGENTS.md。任何會改變其他程式碼行為的決策（例如重試策略、資料結構、API 形式、身份驗證），在寫入此處之前都不能算是最終定案。

4. 交接時明確指出分支和提交版本

人們可能會在任務中途停下來，例如一天結束、開會，或是筆電進入睡眠狀態。在團隊中，下一個人的代理通常會接手這項工作。一個寫著「身份驗證大致完成」的交接，會讓下一個代理花費二十分鐘重新探索，甚至更糟的是，在過時的程式碼上重新開始。

一個有用的交接應包含五個部分：已完成：登入 + 更新權杖，測試通過。下一步：登出端點，然後在密碼變更時撤銷。請勿碰觸：權杖格式（參見 DECISIONS 10-15）。分支：feat/auth。提交版本：3f9c2e1。待解決問題：工作階段長度，詢問 Sara。提交版本是人們最常跳過的部分，但它卻能為您省下大麻煩。接收代理可以在任何基礎上進行建構之前，檢查其本地是否具有該提交版本。

5. 讓不同供應商的代理互相審查

這正是混合團隊的真正優勢。模型在審查自己撰寫的程式碼時，往往會錯過與撰寫時相同的盲點。而不同供應商的模型則會帶來不同的盲點。兩個 CLI 都有非互動模式，因此跨供應商審查只需一行指令。從 Claude Code 工作階段執行：codex exec "Review the changes on this branch against main. List bugs and risky changes only." 而從 Codex 工作的任何地方執行：claude -p "Review the diff between main and this branch. Bugs and contract changes only, no style notes."

每個指令都會在執行該指令的機器所有者的帳戶下運行。這引出了唯一一條與檔案無關的規則：每個人都應使用自己的計畫。每位隊友都應使用自己的 Claude 或 ChatGPT/Codex 訂閱帳戶登入。請勿共用登入資訊：這會違反供應商的條款，並且您會失去任何記錄誰的工作階段做了什麼的紀錄。

如果一個人的代理將工作交接給另一個人的代理，這就是協作。然後，該工作將在接收者的計畫下運行。這也能讓成本更透明，每個人都知道自己的使用量，而且沒有人的使用限制會因為別人在下午的使用而受到影響。

按領域劃分，先寫好合約

最後一個習慣，也是最簡單的。代理在負責特定領域時表現更好，而不是輪流處理相同的檔案。一個人的 Claude Code 負責前端，另一個人的 Codex 負責 API，而任何跨越界線的內容（請求形式、環境變數、錯誤代碼）都應在兩者開始之前寫下來。一個供兩個代理讀取的 CONTRACTS.md 或 OpenAPI 檔案就足夠了。

日常工作流程

四個檔案（AGENTS.md、TASKS.md 或 issues、DECISIONS.md、交接筆記）和 AGENTS.md 中的三條規則：規劃前先認領任務、開始時讀取決策、停止時撰寫交接筆記。這涵蓋了小型團隊所需的大部分協調工作。代價是紀律：必須有人注意到代理何時跳過了某個步驟。

Joxo 的角色

聲明：我正在開發 Joxo，因此請帶著這個背景閱讀這部分。Joxo 無需檔案即可處理上述的任務認領、決策和交接習慣。Claude Code、Codex、Cursor 和其他代理可以在一個專案和一個團隊聊天中協同工作。當一個代理認領任務時，其他代理會被告知誰認領了它。

決策和交接（包含分支和提交版本）會在所有人的代理之間共享，並且代理工作階段可以透過名稱互相傳送訊息。每位隊友的代理都在自己的電腦和計畫下運行，無需 API 金鑰。還有一個 iPhone 應用程式正在 TestFlight 測試中，當代理需要您的回應時會發送通知。

在 14 天無需信用卡試用期後，每月每人費用為 15 美元，網址是 joxo.ai。如果您更喜歡使用純檔案，那也沒問題。重點是，任務認領、決策和交接的資訊必須存在於每個代理都能讀取的地方。