前幾天一路測下來，我已經讓 Codex 做過讀專案、找問題、修改程式，也開始慢慢習慣把比較完整的任務交給它，不再每次都先自己找到檔案，再把其中幾十行程式碼貼出去。

到了 Day 6，我想換一種方式測它。

前面幾天的任務都有一個共同點，就是「我要做什麼」其實還是由我決定，Codex 負責的是進入專案之後找到相關程式，接著完成修改，所以今天我乾脆把任務再放寬一點，不指定 Bug、不指定功能，也不告訴它該改哪個地方，只讓它先檢查整個專案，告訴我目前最值得處理的問題有哪些。

先讓它當一次 code reviewer

以前自己檢查專案時，我通常會從最近修改的地方開始看，因為那些檔案最熟，也比較容易知道哪裡可能出問題，但這種方式有一個缺點，很多已經存在很久的程式碼反而很容易被忽略。

所以這次我給 Codex 的任務很簡單，大概就是：

請先閱讀目前專案，不要直接修改程式碼。

檢查目前可能存在的問題，包含：
1. 容易造成 Bug 的地方
2. 重複或難維護的程式碼
3. 缺少錯誤處理的流程
4. 可能造成安全問題的寫法
5. 可以改善但目前不影響功能的地方

先整理問題與原因，並依照優先程度排序。

我刻意加上「不要直接修改」，因為今天想看的不是它可以改多少程式，而是它到底能不能先理解專案，再判斷哪些地方值得動。

這跟前幾天直接叫它完成任務的感覺差很多，因為當修改目標很明確時，只要找到相關檔案就可以開始處理，但現在整個 repository 都可能是檢查範圍，它必須先決定要看哪些地方，也要判斷哪些問題只是程式寫得不好看，哪些是真的可能影響系統。

它開始看的地方跟我不太一樣

Codex 開始分析之後，我第一個注意到的地方，是它不會只盯著某一支程式看。

它會沿著實際使用流程去找相關檔案，例如 Controller 收到資料之後往哪裡送、Service 怎麼處理、Model 有哪些欄位、錯誤最後怎麼回到前端，有些地方單獨看沒有明顯問題，但把前後流程接起來之後，就會發現某些情況其實沒有被處理。

這也是直接把 repository 給 Coding Agent 之後，我覺得很有意思的地方。

如果只是把一個 function 貼到聊天視窗裡，AI 能看到的世界就只有那個 function，很多問題其實發生在 function 外面；現在它可以自己往其他檔案找，能參考的 context 變大之後，提出來的問題也開始比較接近「專案層級」。

不過這不代表它列出的每一項都值得改。

AI 覺得有問題，不代表現在就該改

Codex 列出一些問題之後，我原本很想直接叫它全部修掉，但仔細看會發現裡面其實混著不同程度的事情。

有些確實可能造成錯誤，像是某個輸入沒有檢查、例外狀況沒有處理，這類問題通常優先程度比較高；另外一些則比較像程式品質問題，例如命名可以更一致、部分邏輯可以抽成共用 function，這些修改可能會讓程式更乾淨，但現在不處理也不一定會出事。

還有一種最需要小心，就是 AI 根據一般開發習慣提出的「理想做法」。

那些建議本身可能沒有錯，可是放回目前專案不一定適合，尤其學生專案、公司內部系統或已經存在一段時間的專案，常常都有自己的限制，如果只是看到「可以改善」就全部接受，很容易讓一次原本很小的整理變成大規模重構。

所以我最後沒有直接叫它全部修改，而是先把問題分成三類：

現在要修
之後可以修
目前先不要動

這個分類看起來很普通，實際用起來卻滿重要，因為 Coding Agent 很容易讓人產生一種錯覺，好像既然它能改，那就順便全部改掉，但專案維護真正困難的地方，常常就是判斷「哪些東西現在不要碰」。

我開始比較在意它怎麼判斷

做到第六天之後，我發現自己看 Codex 的方式也有一點變化。

Day 1 的時候，我最在意的是它能不能看懂專案；後來開始測修改、Bug、實際任務時，我會看它最後產生的程式能不能跑，到了今天，我反而花更多時間看它在修改之前做了什麼。

它先讀哪些檔案、為什麼認為這裡有風險、找到問題之後有沒有繼續確認其他相關程式，甚至它提出修改時，有沒有考慮這個修改會影響哪些地方。

因為如果未來真的要把 Coding Agent 放進日常開發流程，我不可能每次都重新把整個專案檢查一遍，那樣其實沒有省下多少時間，我需要的是一套可以快速確認它判斷是否合理的方法。

今天先從 code review 開始，至少我第一次沒有告訴 Codex「答案在哪裡」，而是讓它自己在專案裡找值得處理的問題。

明天我想再往前一步，從它今天找到的問題裡挑一個，看看能不能讓它自己完成修改、測試，再確認修改有沒有影響原本功能。