Day 1 訂了實驗規則，今天要先解決分工問題。如果把「幫我做任務追蹤 App」同時交給 ChatGPT 和 Codex，兩邊都可能給出看似完整的答案；真正的差異，是答案能不能直接進入專案、能不能留下可審查的修改，以及誰來確認需求沒有被誤解。

先看工作現場，而不是替工具貼標籤

ChatGPT 適合從尚未成形的問題開始對話：整理使用者痛點、追問缺漏、比較方案、解釋一段不熟悉的程式。Codex 作為程式開發代理，適合在有權限的工作目錄中閱讀檔案、修改程式並執行檢查。這是本文的起始分工，不代表兩者能力完全互斥；實際可用功能也會隨使用介面、設定與權限而變。

以「新增任務時標題不能是空白」為例，我會先和 ChatGPT 確認：空白包含純空格嗎？前後空白要不要裁掉？錯誤訊息顯示在哪裡？確認驗收條件後，再把具體任務交給 Codex，要求它找到輸入處理、修改實作、補測試並回報 diff。最後由我操作介面、檢查錯誤情況。這個流程讓需求決策和檔案修改各有清楚的入口。

用同一個任務看三種輸出

如果我只問「任務標題不能空白，怎麼做？」一份對話答案可能給我表單驗證的示意碼，一次代理任務可能直接修改現有檔案。兩者都可能有用，但評估方法不同：前者要檢查假設與邊界案例，後者還要檢查它實際動了哪些檔案、測試是否真跑過、是否順手改壞既有行為。使用者最後看到的效果相同，工程上的證據卻不同。

我會特別觀察「不知道」這件事。沒有看到 Repository 時，AI 應該說清楚它不知道目前用什麼框架、資料從哪裡來；看到 Repository 後，也不該把搜尋不到的東西當成不存在。把不確定性寫出來，常比快速給出一段自信的程式碼更有價值。

一份可以直接拿去用的分工規則

當問題是「我們要做什麼、為什麼這樣做」時，先用對話釐清；當問題是「這個 Repository 哪裡要改、改完能否通過檢查」時，讓能接觸專案的工具處理；當問題涉及資料刪除、公開部署、成本或使用者承諾時，交回人類決定。交接時不要只說「照剛才討論的做」，而要把已確認的目標、範圍與驗收條件寫在同一份任務描述裡。

今天的 Prompt 實驗設計

我先準備一個之後會在真實專案執行的同題比較。交給 ChatGPT 的版本是：「請根據『任務標題不可為空白』，列出需要澄清的問題、至少五個驗收案例，以及你目前無法從描述中確定的假設。先不要寫程式。」交給 Codex 的版本是：「先閱讀現有新增任務流程，找出前端與後端驗證位置。列出修改計畫、受影響檔案與測試方式；在我確認需求前，先不要修改。」

這兩個 Prompt 刻意都要求先產出可檢查的資訊。之後比較的不是哪個回答比較長，而是它們是否找到真正的缺口、是否引用了專案中的證據，以及能否避免過早寫出錯的功能。

比較時我會用同一份需求、同一個起始版本與同一組驗收案例。記錄欄位包括：是否先問到純空格等邊界、是否找到前後端的實際驗證位置、是否產生額外修改、測試是否通過，以及我修正了幾次。這些欄位會讓「我覺得比較好」變成可回頭檢查的觀察。

今天的結果與限制

今天得到的是一套工作分工與兩份可重跑的任務描述，尚未對同一個 Repository 執行比較，因此沒有速度、正確率或修改品質數字。等 Day 7 開始有實際 diff 和測試結果後，才有基礎檢驗這套分工是否有效。

今天學到什麼？

把 ChatGPT 當「會提問的討論夥伴」、把 Codex 當「能在專案裡交付修改的工程夥伴」，有助於安排工作，但不能取代驗收。下一步是把專案整理成兩者都能理解、也讓人類接手不痛苦的環境。

參考資料：OpenAI 的 ChatGPT 功能概覽與 Codex CLI 入門說明。