前幾天使用 Codex 的方式，大多還是我先決定要做什麼，再把任務交給它，例如修一個 Bug、調整某個功能、看懂專案結構，或是根據 Issue 去修改指定的地方，雖然已經比單純貼程式碼給 AI 多了不少專案背景，但仔細想想，工作的起點其實還是在我身上，我知道哪裡有問題，也知道下一步大概要往哪裡走，Codex 比較像是接手後面的工程工作。

到了第七天，我想把這個前提拿掉看看。

這次我沒有先指定某個檔案，也沒有直接告訴它哪裡有 Bug，而是讓它先閱讀目前的專案，從現有程式碼、資料夾結構、設定檔和功能之間的關係去找問題，再告訴我哪些地方值得優先處理。

先讓它自己看專案

以前叫 AI 寫程式時，我通常會把問題描述得很完整，例如「這個頁面的資料沒有正常顯示，幫我檢查 Controller」或是「這段 SQL 查詢速度很慢，看看能不能改善」，這樣做當然很有效率，因為範圍已經被我縮得很小。

但如果真的把 Codex 當成 Coding Agent，我更想知道它能不能處理範圍比較模糊的任務，所以這次我只給它一個方向：

「閱讀目前專案，找出你認為值得改善的地方，先不要修改，整理原因和優先順序給我。」

這個「先不要修改」其實很重要，因為我現在想看的不是它一次可以改多少程式，而是它怎麼理解這個專案，又會從哪些地方判斷問題。

它開始讀專案之後，看的範圍比我原本預期的大，除了主要程式碼之外，也會去注意設定、重複邏輯、錯誤處理和一些可能影響維護的地方，有些項目我平常開發時其實看過很多次，只是因為功能還能正常跑，所以一直沒有特別處理。

AI 找到的問題不一定都要改

這裡也是我今天覺得很有意思的地方。

Codex 可以一次列出不少改善項目，但「找到可以改善的地方」和「現在值得花時間改」其實還有一段距離，有些程式碼確實可以整理得更漂亮，可是如果它目前很穩定，也沒有影響其他功能，那優先度可能沒有想像中高；反過來，有些看起來只是小問題，卻可能在之後新增功能時一直被放大。

所以我沒有直接接受整份建議，而是開始看它提出每一項修改的理由，有沒有真的對應到目前專案的需求，修改範圍會不會太大，以及改完之後到底能解決什麼。

這跟前幾天的使用方式開始有一點不同，以前是我找問題、Codex 幫忙處理，今天則變成 Codex 先找出候選問題，我再決定哪些值得進入真正的修改流程。

任務開始從「執行」往前移

做到這裡，我開始比較能理解 Coding Agent 和一般程式碼生成工具的差別會出現在哪裡。

如果 AI 永遠只能等我把問題切成很小的任務，它確實可以幫我省下不少寫 Code 的時間，但我還是得自己一直盯著專案、找問題、切工作，再一個一個交出去；當它開始可以自己閱讀 Repository、整理問題、提出修改範圍之後，能幫忙的地方就往開發流程前面移了一點。

當然，這不代表我會直接把它列出的問題全部交給它修改，至少目前我還是希望保留「確認問題」這一關，尤其是牽涉到架構、資料庫或大範圍重構時，我會更想先知道它為什麼要動。

但光是能先幫我把可能的問題整理出來，就已經改變了一點我看 Repository 的方式。

Day 7 的感覺

前六天我一直在測 Codex 到底能不能把一個任務做好，第七天開始，我比較想測的是它能不能自己發現「下一個任務可能在哪裡」。

這兩件事看起來只差一點，實際上對我來說差很多，因為前者比較像是一個執行者，後者開始碰到工程師平常會做的判斷工作。

接下來我會從它今天提出的問題裡挑一個真的交給它處理，而且不只看最後程式能不能跑，我想把它從發現問題、規劃修改、實際動手到驗證結果的整段流程記下來，看它到底能自己走到哪一步。