昨天開始讓 Codex 自己整理 Pull Request 之後，整個流程已經比一開始完整很多，從理解需求、修改程式、執行測試，一直到最後整理修改內容，原本需要我一直在旁邊接手的事情，現在很多都可以讓它自己往下處理。

但 Pull Request 建出來之後，真正要合併以前還是有一個很重要的步驟，就是 Code Review。

以前我自己寫程式的時候，通常會直接打開 Diff 一個檔案一個檔案看，確認有沒有改到奇怪的地方，也會特別注意原本可以正常運作的功能會不會受到影響，但如果現在大部分程式都是 Codex 修改的，我其實很想知道，它能不能先幫自己的修改做一次 Review。

先不要急著幫它找問題

這次我沒有直接告訴 Codex 哪裡可能有錯，只把它剛完成的修改交回去，請它用 Reviewer 的角度重新檢查這次 Pull Request。

我希望它看的內容包含幾個部分，像是有沒有修改到需求以外的程式、錯誤處理是否完整、變數或函式命名有沒有變得難懂、原本的功能是否可能受到影響，以及目前的測試是不是足以證明這次修改可以正常運作。

這和前幾天請它「確認程式能不能跑」有一點差別，Build 和 Test 比較容易檢查明確結果，只要編譯失敗或測試沒有通過就知道有問題，Code Review 則需要重新看整個修改內容，很多問題其實不會直接讓程式壞掉。

像是一段程式現在可以正常執行，但它可能重複查詢資料庫，或者某個錯誤情況沒有處理，甚至只是把原本簡單的邏輯改得更複雜，這些事情 Build 都不會告訴你。

Codex 真的會抓到自己的問題嗎

我原本比較擔心的一點，是 Codex 剛剛才寫完這些程式，現在又叫它自己 Review，很可能只會重新解釋一次自己做了什麼，最後得到一個「看起來沒有問題」的答案。

實際試下來倒沒有這麼單純，只要 Prompt 明確要求它站在 Reviewer 的角度重新讀 Diff，而且不要預設原本的修改是正確的，它確實會開始挑一些自己剛剛沒注意到的地方。

有些是比較小的問題，例如重複程式碼、命名不一致、註解沒有一起更新，有些則會牽涉到實際行為，像是某個條件沒有涵蓋完整，或者只測到了正常輸入，錯誤資料進來時會發生什麼其實還沒有驗證。

最有趣的地方是，有些問題明明就是它自己前面產生的，但換了一個任務角色之後，它還是有機會重新找出來。

Review 完還是要有人看

不過我目前還是不會因為 Codex 說「Review 完成」就直接 Merge，因為它找到的問題不一定全部都真的需要修改，有時候只是 Coding Style 不同，有時候它提出的改善反而會讓這次 Pull Request 變得更大。

所以現在我比較喜歡的流程，是先讓 Codex 做第一輪檢查，把可能的問題整理出來，我再去看真正需要處理的部分。

這樣人工 Review 並沒有消失，只是我打開 Pull Request 的時候，手上已經多了一份可以參考的檢查結果，比起從零開始一行一行找問題輕鬆不少。

做到 Day 13，我開始覺得 Coding Agent 真正有用的地方也慢慢從「幫我寫程式」往後延伸了，它可以參與修改，也可以參與測試、整理 Pull Request，甚至先做第一輪 Code Review。

明天我想再往前一步，試著把 Issue、修改、測試、Review 這幾個原本分開的步驟串起來，看 Codex 到底能不能自己完成一個比較完整的開發流程。