「資料工作區空間」從一句模糊的業務描述出發，經過需求釐清、架構與API設計、技術學習到程式碼審查（Code Review）初篩，最後得到的結論是：ChatGPT 可以協助我把問題整理成可討論、可驗證的規格，但測試證據與是否採用的決定仍要由人負責。接下來的案例換成「資料匯入貼標程式」；資料工程團隊已經定下技術規格、資料表與技術棧，需求書第九節也列出已知缺陷與待確認事項。問題不再是「這句話是什麼意思」，而是「誰要進入專案，把修正做完並留下證據」。這正是 Codex 要上場的地方。

上一週我在主導，這一週換 Codex 動手

上一週我跟 ChatGPT 的關係比較像是我在主導：我決定問什麼、分幾輪問、每輪要哪個層面的答案，ChatGPT 負責把散在對話裡的想法組織成看得懂的段落。它不會自己去改需求書，也不會自己開專案。Codex 不一樣，它能直接讀我的程式碼庫、動手改檔案、跑測試、留下 diff。分工換了，我要練習的動作也跟著換：不是「我問得夠不夠精準」，是「我劃的界線夠不夠清楚」。

協作不是誰聽誰的，是誰在哪一步接手

好的協作不是全程由一方發號施令，而是分段接手，各自在自己擅長的階段負責。我負責定義這批任務的範圍與停手條件——只能改動指定的邏輯，不能動資料庫連線設定，測試沒過就不算完成；Codex 負責在這個範圍內找出缺陷成因、寫修正、跑 mvn test 驗證。我退場的時機，是它已經清楚知道邊界在哪之後；我回場的時機，是它交出結果、我要核對證據的時候。這條界線劃得越清楚，中間需要來回確認的次數就越少。

這一週，會從最基本的動作開始

需求書留給我的不只是一個 bug，還有一整套排程、水位（watermark，記錄上次同步到哪個時間點）、雙資料庫寫入與 upsert 去重的設計。我不會第一天就把整包丟給 Codex，而是從能獨立驗收的最小任務開始：先看懂 Codex 在沙箱環境裡怎麼工作、怎麼讀專案、怎麼回報結果，再逐步把 AGENTS.md、issue 描述、測試回報、權限邊界與 Git 工作流一一補齊。任務範圍先小、驗收條件先明確，才有機會在後面幾天把整套需求逐步交接完整，而不是一開始就賭一個看不到底的大任務。

我也提醒自己一件事：Codex 動作再流暢，最後要不要把改動合併進主分支，仍然是我的判斷。它能加速的是找出問題、寫修正、跑測試這幾步，不會替我承擔「這個改動能不能上線」的責任。

小結：先講清楚分工，再談節奏

今天沒有打開 Codex，只先想清楚這週的角色分配：規格清楚的任務交給它動手，範圍與驗收條件仍由我先劃定。Day 11 會實際打開 Codex，用一個具體的缺陷，觀察代理迴圈怎麼從讀取、修改走到留下可驗證的證據。

參考資料

• 資料匯入貼標程式——需求書（技術規格・v1）