前幾天測 Codex 的時候，我其實還是把開發流程拆成很多小段，看到 Issue 之後先自己判斷要改哪裡，再請 Codex 修改，修改完之後自己跑測試，最後才進到昨天做的 Code Review，雖然每一個階段都有用到 Codex，但真正負責把這些事情串起來的人還是我。

做到這裡之後，我開始想試另一種方式，既然 Codex 已經可以讀 Issue、找相關程式碼、修改檔案、跑測試，也能對 Pull Request 做第一輪 Review，那能不能乾脆把這幾個原本分開測試的步驟接起來，讓它從一張 Issue 開始，一路做到一個可以交給我檢查的修改結果。

這次我想測的重點也就從「Codex 能不能完成某一個任務」，慢慢變成「Codex 能不能處理一段完整的開發流程」，因為真正開發專案的時候，很少有人只叫工程師改一個 function 就結束，通常都是先看需求、找到影響範圍、修改、測試，再確認修改有沒有帶出新的問題。

先讓它從 Issue 自己找入口

這次我沒有直接告訴 Codex 要修改哪一支檔案，只給它 Issue 的內容，另外補上幾個限制，例如不要改動跟這張 Issue 無關的功能、修改前先閱讀現有架構、完成後要執行相關測試，如果發現 Issue 描述和目前程式碼有落差，也要先把差異列出來。

這跟我前幾天直接指定檔案的方式差很多，因為當我把檔名拿掉之後，它第一個要做的工作其實就變成「理解專案」，必須先搜尋跟 Issue 有關的關鍵字，看看資料從哪裡進來、經過哪些 service 或 controller，最後才決定修改位置。

我自己在看這個過程時也發現，Codex 找到正確檔案其實只是第一步，更重要的是它有沒有看懂影響範圍，有些需求表面上只是一個欄位調整，實際上可能同時碰到 model、API、validation 和前端顯示，如果只看到第一個符合關鍵字的檔案就開始改，很容易出現「功能看起來完成了，但整條資料流沒有接好」的情況。

修改完先不要急著交答案

以前用 ChatGPT 寫程式時，我最常做的事情就是拿到程式碼之後直接貼進專案，再由我自己負責驗證，但這次我刻意要求 Codex 修改完成之後不要直接結束，而是繼續檢查它剛剛動過的內容。

它會先看 git diff，確認到底改了哪些檔案，再跑跟這次修改有關的測試，如果測試失敗就回頭讀 error message、重新定位問題，這其實跟前面幾天測 Debug 的流程很像，只是現在 Debug 已經不再是一個單獨的實驗，而是被放進整段開發流程裡。

我覺得這個差別滿明顯的，因為單獨叫 AI 修一個 Bug 時，我很容易只注意最後有沒有修成功，但當它自己完成修改又自己跑測試之後，我開始更在意它中間做了哪些判斷，例如它有沒有只為了讓測試通過就改掉原本的邏輯，或者看到錯誤之後，有沒有跑去動一個根本不應該碰的地方。

最後再讓它自己 Review 一次

測試通過之後，我又把昨天的 Code Review 接進來，讓 Codex 重新以 Reviewer 的角度看一次剛才自己完成的修改，檢查可能的 bug、邊界情況、重複程式碼，以及這次變更有沒有超出 Issue 原本的範圍。

這一步其實有點有趣，因為前一分鐘它還是寫程式的人，下一分鐘就要開始挑自己程式碼的問題，當然這不代表它真的變成另一個獨立 Reviewer，但至少可以逼它重新掃一次 diff，不要在測試通過之後就直接把「能跑」當成「完成」。

實際跑下來也會發現，有些問題測試真的不一定抓得到，例如某段程式雖然功能正確，但寫法跟專案原本的結構不太一致，或是一個判斷條件現在沒問題，以後資料量變大之後可能變得很難維護，這些東西比較接近人工 Review 時會注意的地方。

Codex 開始有點像在走開發流程了

跑完這次之後，我第一次比較明顯感覺到，前面十三天測的能力開始接在一起了，Issue 理解、搜尋專案、修改程式、執行測試、處理錯誤、查看 diff、Code Review，原本每一天都像是在測不同功能，現在則慢慢變成一條可以重複執行的流程。

當然我還是不會直接讓它做完就 Merge，尤其是牽涉資料庫、權限或核心邏輯的修改，我一定還是會自己看過，但我現在比較能想像 Coding Agent 真正進入開發流程之後的位置，它可以先把大量「讀、找、改、測、整理」的工作往前做，最後把一個相對完整的修改結果交到人手上。

接下來我想繼續往更接近真實團隊開發的地方測，因為只要開始同時處理很多 Issue，就會遇到另一個問題：每一張 Issue 都能叫 Codex 做，但到底哪些事情適合一起跑、哪些修改可能互相衝突，Agent 能不能自己處理這些依賴關係，才會決定它最後能不能真的變成開發流程的一部分。