昨天在處理 Context 的時候，我開始發現一件以前比較少注意的事，Codex 就算真的讀到了最新版本的 Repository，也不代表接下來做的修改一定符合我的預期，因為「知道現在專案長什麼樣子」跟「知道這個 Issue 應該怎麼改」其實還隔著一段距離。

前幾天我的做法比較直接，只要確認 Codex 已經讀過相關檔案，我就會讓它開始修改，這在小問題上通常沒什麼感覺，例如改一個欄位名稱、補一個判斷、調整某個頁面的顯示方式，修改範圍很小，就算方向錯了也很容易退回來。

但當 Issue 開始牽涉到多個檔案，甚至會動到原本的流程時，這種方式就有點危險了。

先讓它說準備怎麼做

所以今天我多加了一個步驟，在 Codex 開始動程式之前，先要求它把修改計畫列出來。

我沒有要求它寫很正式的設計文件，只需要回答幾件事情，包括這個 Issue 可能牽涉哪些檔案、目前程式的流程大概怎麼跑、它準備修改哪些地方，以及修改之後打算怎麼確認沒有把其他功能弄壞。

例如今天測試的 Issue 跟網站上的資料顯示有關，Codex 讀完之後先列出前端頁面、後端事件處理以及資料存取的相關檔案，接著說明資料目前從哪裡進來，又在哪一層被轉成畫面上的內容。

看到這份 Plan 的時候，我其實還沒讓它寫任何一行 Code，但已經能先判斷方向有沒有偏掉。

有些錯誤在寫 Code 前就看得出來

第一次測試很快就遇到一個問題，Codex 判斷某個功能應該直接修改資料存取層，但我原本專案裡已經有一層處理相同邏輯，如果照它最初的 Plan 做下去，很可能會讓同一個規則散落在兩個地方。

以前這種問題通常要等它真的改完，我看 Diff 的時候才會發現，接著再叫它重改一次。

現在則是在 Plan 階段就直接告訴它，原本已經有相關邏輯，請重新確認應該沿用哪一層，第二次產生的計畫就合理很多，而且真正開始修改之後，Diff 也比前幾次乾淨。

這讓我慢慢覺得，Plan 並不是為了讓流程變得更正式，它比較像是在 Codex 真正動手之前，多留一個可以攔截錯誤的地方。

Plan 也不能寫得太細

不過測了幾次之後又遇到另一個極端，如果 Prompt 裡要求 Codex 把每一個修改步驟都寫得非常詳細，它花在規劃上的內容會越來越多，有時候甚至開始推測還沒確認的實作細節。

這反而失去原本的目的。

我現在比較喜歡的做法，是讓它先回答「改哪裡、為什麼、可能影響什麼、怎麼驗證」，至於真正要寫成哪個 function、變數叫什麼名字，還是讓它進到 Code 階段再根據實際內容處理。

這樣 Plan 不會變成另一份超長文件，我也能在幾十秒內快速看完。

Issue 到 Code 中間多了一層

做到 Day 17，整個流程開始跟最前面的做法差很多。

一開始是我把需求直接丟給 Codex，接著看它能不能找到檔案、修改程式，後來加入測試、Diff、Pull Request、Code Review，昨天又開始處理 Repository Context 更新的問題，今天則把 Plan 放到了真正修改之前。

現在一個 Issue 進來之後，我會先讓 Codex 重新確認目前的 Repository 狀態，再理解 Issue、整理修改計畫，等我確認方向沒有問題之後才開始改 Code。

這中間多出來的步驟看起來會讓流程變長，但實際測下來，反而少掉不少「改完才發現方向錯了，再全部重來」的時間。

接下來我想繼續測一件更接近真實開發的情況，如果 Plan 已經確定、Code 也改好了，Codex 能不能自己根據這份 Plan 去檢查最後的修改有沒有漏掉東西，也就是讓原本寫在修改前的計畫，變成修改完成後的驗收依據。