Codex 可以長時間穩定運作，尤其當你透過 /goal 為它設定一個持續性的目標時。比較困難的部分是，當它連續工作數小時或數天、發現新的實作細節、並經歷多種驗證方式時，如何保持方向感。
一旦開始實作，早期的假設往往會改變。協作模式需要在保留目標的同時，讓你和 Codex 都有空間根據新發現來調整計畫。
在過去幾週，我採用了五種做法：
- 讓 Codex 規劃工作並維護路線圖。
- 讓主執行緒專注於協調工作。
- 在每個里程碑完成後審查路線圖並檢視程式碼。
- 使用本機執行緒進行 Computer Use 測試。
- 透過簡潔的更新和儀表板報告進度。
使用 Codex 中的 GPT Image 2 生成
1. 讓 Codex 規劃工作並維護路線圖
我通常會先進行對話，而不是直接使用 /plan 模式。我會描述我想建立的東西、口頭說明粗略的想法、分享限制條件，然後讓 Codex 提問，直到它擁有足夠的脈絡來提出初步計畫。
這樣可以讓早期的討論保持彈性。我不需要在 Codex 開始提供幫助之前，就把不成熟的想法變成正式的規格書。它可以訪談我、反饋它理解到的內容、找出缺口，並逐步將對話轉化為可行的計畫。
隨著專案逐漸成形，我會要求 Codex 設定當前的 Goal。Goal 模式為 Codex 提供一個持續性的目標，讓它能夠在多次對話中持續朝同一個成果努力，直到目標完成、受阻或被取代。
我可以自己使用 /goal 來設定目標，但我通常會讓 Codex 來做。Goal 模式是透過 harness 暴露出來的，因此 Codex 可以綜合我們的對話、專案脈絡以及它目前學到的一切，形成一個清晰的目標。它也可以定義在認為目標完成之前所需的證據。
對於較大的專案，我會要求 Codex 將更廣泛的路線圖寫入 GOALS.md。這是一個專案慣例，而非 Codex 的內建功能，而且你可以隨意命名這個檔案。
我通常會圍繞里程碑來組織 GOALS.md，而不是使用扁平的任務列表。每個里程碑記錄：
- 預期的成果
- 目前範圍內的工作
- 重要的決策
- 已知的阻礙
- 繼續進行前所需的證據
Codex 會隨著專案的進展維護這個檔案。新的發現可能會改變某個里程碑的範圍、引入新的里程碑，或改變完成所需的證據。
一次只能啟動一個 Goal 模式的目標。當里程碑完成時，Codex 會更新 GOALS.md，啟動下一個目標，並繼續朝它努力。
2. 讓主執行緒專注於協調
一旦路線圖建立起來，我會讓主執行緒專注於目標、限制條件、決策和當前的專案狀態。
它決定接下來應該發生什麼事、委派有邊界的任務，並評估結果。它不需要承載每一個實作細節。
一個工作執行緒可能會花一個小時閱讀不熟悉的程式碼、嘗試多種方法，或追蹤一個失敗的測試。協調者只需要影響整個專案的資訊：
- 工作執行緒學到了什麼
- 什麼改變了
- 支持性的證據
- 接下來應該做什麼
Codex 可以將這項工作委派給 subagent 或建立一個新的執行緒。從功能上來說，它們可以執行相同的任務。當我預期之後會再次檢視這項工作時，我會使用一個新的執行緒，因為它在 Codex 應用程式中保持可見，並保留自己的歷史記錄。
當多項工作同時進行時，這會變得特別有用。主執行緒可以繼續協調專案，同時每個調查、實作或審查都易於檢查。
3. 在每個里程碑完成後審查路線圖並檢視程式碼
GOALS.md 反映的是 Codex 上次更新時所知道的資訊。到一個里程碑結束時，專案通常會發現一些新東西。
在繼續前進之前，我會要求另一個執行緒將路線圖與當前狀態進行比較：
- 這個里程碑真的完成了嗎？
- 下一個目標仍然是正確的嗎？
- 有沒有遺漏任何里程碑？
- 新的證據是否改變了工作的順序？
- 「完成」的定義是否仍然成立？
我會在每個里程碑結束時執行這次審查，以及每當有新證據從根本上改變專案方向時。
我也會在實作上執行 /review。
假設登入流程的實作和遠端測試都完成了。路線圖審查可能會注意到沒有人曾在真實的已登入瀏覽器中測試過這個流程。同時，/review 可能會發現，即使遠端測試通過，新的路徑卻錯誤地儲存了 token。
協調者會更新 GOALS.md，委派修復 token 的工作，加入遺漏的瀏覽器驗證，然後才啟動下一個里程碑。
我通常會將審查和檢視放在不同的執行緒中。Subagent 也可以執行相同的工作，但一個獨立的執行緒會留下可見的記錄，方便我之後回頭查閱。
4. 使用本機執行緒進行 Computer Use 測試
我的大多數 Codex 工作階段都在遠端實例上運行，這樣即使我關上筆電，工作也能繼續進行。但有些檢查仍然依賴於我的本機電腦：
- 已登入的瀏覽器
- 本機憑證
- Xcode
- macOS 權限
- iOS 模擬器
遠端的協調者可以為其中一項檢查建立一個本機執行緒。我會套用遠端的 diff 或檢出相關的分支或提交，以便本機執行緒測試正確的程式碼。
本機執行緒會操作瀏覽器或應用程式，並回傳螢幕截圖、日誌和發現。當檢查失敗時，遠端的工作執行緒會修復問題，然後本機執行緒再次測試。
一個典型的循環如下：
- 一個遠端工作執行緒實作了登入流程。
- 遠端測試通過。
- 一個本機執行緒使用 Codex Chrome 擴充功能。
- 瀏覽器測試發現了一個重新導向的錯誤。
- 一個遠端工作執行緒修復了它。
- 本機執行緒重複檢查。
專案預設保持在遠端。我的電腦只在需要進行檢查時才加入。當我重新打開筆電時，遠端執行緒也可以持續檢查本機執行緒是否再次可用。
5. 透過簡潔的更新和儀表板報告進度
工作執行緒通常只報告單一任務。當我回到專案時，我需要一個整體狀態的概覽：
- 什麼完成了
- 什麼改變了
- 還有什麼待辦
- 哪些需要決策
每當專案狀態改變時，我會要求 Codex 使用三個簡短的章節來報告：
**已完成的事項
接下來要做的事
任何阻礙**
這幾乎就像與 Codex 進行每日站立會議，只不過是每小時一次。
Codex 可以透過 Slack 發送相同的更新，無論是直接訊息還是在專屬的專案頻道中。
當我在 Codex 應用程式中時，我也會使用 /side 來確認狀態，而不打斷主執行緒。從側邊執行緒，我可以要求總結已完成的事項、待辦事項，以及是否有任何需要我協助的地方——例如，一個手動點擊、批准，或其他 clickops 操作。
從側邊執行緒取得摘要
要求側邊執行緒將我的指示傳遞給主執行緒
然後我可以澄清指示、解決阻礙、補充脈絡，或要求側邊執行緒將更新後的指引發送回主執行緒。
對於包含多個里程碑或平行工作流程的專案，我也會維護一個 progress-dashboard.html。這是一個自訂的專案產出物，而非 Codex 內建的 UI。它可以顯示：
- 活躍的目標
- 已完成的里程碑
- 證據
- 阻礙
- 決策
- 最近的更新
當我在數小時後回來時，無需閱讀每個工作執行緒就能了解專案狀態。Codex 也可以將儀表板部署為一個 Site，使其可以遠端存取。
總結
當一個專案可能會發現新資訊、涉及多項獨立的工作，或需要來自多個環境的證據時，我就會使用這個結構。
這個工作流程遵循一個簡單的循環。Codex 將最初的對話轉化為路線圖，啟動一個里程碑，委派工作，並在繼續前進之前檢查結果。本機執行緒處理需要我電腦的檢查，而更新和儀表板則幫助我回到專案時，無需從頭重建一切。
重要的是保持專案狀態足夠新，以便下一個決策能反映 Codex 實際學到的東西。
試試看
將以下內容貼到一個新的 Codex 執行緒中：
將此作為一個長期運行的專案來協調。
首先訪談我，了解我想建立什麼。讓我以對話方式描述粗略的想法和限制條件，然後將該討論轉化為初步計畫。
建立 GOALS.md 作為共享路線圖。圍繞里程碑來組織，並包含每個里程碑的預期成果、範圍、決策、阻礙和所需證據。
一次設定並維護一個 Goal 模式的目標。活躍的目標應對應到當前的里程碑。
讓此執行緒專注於目標、限制條件、決策和專案狀態。將實作委派給 subagent 或新的執行緒。
要求工作執行緒回傳結論、變更和證據，而不是完整的記錄。
當我之後可能想要檢查、繼續或審查工作時，使用獨立的執行緒。對於不需要自己可見歷史的有邊界工作，使用 subagent。
在每個里程碑之後，使用一個獨立的執行緒來審查 GOALS.md 與當前狀態的對應情況，並對實作執行 /review。在啟動下一個目標之前更新路線圖。
對於依賴於我的瀏覽器、桌面應用程式、權限、憑證或裝置狀態的 Computer Use 測試，使用本機執行緒。
*當專案狀態改變時，僅報告： - 已完成的事項 - 接下來要做的事 - 任何阻礙*
當專案橫跨多個里程碑或多個工作執行緒時，維護 progress-dashboard.html。在約定的證據存在之前，不要宣告完成。
或者，你也可以對這篇文章拍一個 Appshot，然後要求 Codex：
從這篇文章建立一個名為 orchestrate-projects 的可重複使用 Codex 技能。
保留以下做法：
*- 讓 Codex 訪談我並建立初步計畫 - 使用 GOALS.md 作為基於里程碑的路線圖 - 一次只保持一個活躍的 Goal 模式目標 - 讓主執行緒專注於協調 - 在每個里程碑後審查路線圖並執行 /review - 對於我之後可能想重新檢視的工作，使用獨立的執行緒 - 對於 Computer Use 測試，使用本機執行緒 - 透過簡潔的更新、Slack 和 progress-dashboard.html 報告進度*
