昨天做的事情其實還算安全，我只是把一個完整的 GitHub 專案交給 Codex，看看它能不能自己讀 README、找入口、追檔案之間的關係，最後整理出這個專案到底在做什麼，而結果比我原本預期的好一點，它確實可以自己在 repo 裡面走動，也不需要我像以前用 ChatGPT 一樣，把某一支 function 複製出來，再補一大段「這段程式前面發生了什麼、後面又接到哪裡」。

不過看懂專案跟真的會做事還是兩件事，所以 Day 2 我想把難度再往前推一點，這次不告訴它應該改哪個檔案，也不直接把有問題的程式碼貼給它，我只給一個比較接近平常開 Issue 的描述，看看它能不能自己把問題一路找到、改掉，最後再確認修改沒有把其他地方一起弄壞。

這次我刻意不告訴它 Bug 在哪裡

以前用 AI 修 Bug，我其實很常先自己做到一半，例如我已經透過 log 找到錯誤大概在某個 API，接著再把 controller、service 或相關 function 貼給 AI，請它幫忙看是哪裡有問題，這種方式當然很好用，但仔細想想，AI 真正負責的其實只有最後那一小段，因為「哪裡壞掉」、「可能跟哪些檔案有關」、「需要看哪些程式」，前面都已經被我處理好了。

這次我想反過來測，我只把使用者實際會遇到的現象告訴 Codex，例如某個操作完成之後畫面沒有更新、API 回傳的資料跟預期不同，或某個條件下功能會直接失效，至於問題到底在前端、後端、資料處理還是設定檔，我完全不提示。

我給它的任務大概只有這種程度：

目前這個功能在特定情況下會出現錯誤。

請先閱讀專案，找出這個功能相關的程式碼與資料流，
確認問題原因之後再修改。

不要先假設是哪個檔案造成的，
修改完成後請執行現有測試，並說明你改了什麼。

我沒有告訴它檔名，也沒有指定「去改這一段」，因為這次真正想測的不是它會不會改 Code，而是它能不能自己把一個 Issue 轉成可以執行的工程任務。

它第一件事不是直接改 Code

這點其實是我今天最有感的地方，以前我把一小段程式碼丟給 AI，通常很快就會開始看到修改建議，因為它眼前就只有這一段，自然很容易直接回答「這邊應該改成什麼」，但 Codex 面對整個專案時反而沒有那麼快動手，它會先搜尋跟功能名稱有關的程式碼，再往引用它的地方追，有時候也會一起看 route、資料型別、測試或設定檔，確認資料到底是從哪裡進來，又在哪一層被處理。

光是這個過程，就跟我平常自己 Debug 比較像了，因為真的接手一個陌生專案時，我也不可能一開始就知道問題在哪裡，通常就是先搜尋關鍵字，再一路追 function call、看資料怎麼流，最後才慢慢縮小範圍。

而且 Codex 有一個跟單純聊天很不一樣的地方，就是它看到某個 function 之後，可以繼續自己往下找，不需要我一直手動把下一份檔案貼給它。

以前的流程比較像：

我找到 A 檔案
↓
貼給 AI
↓
AI 說可能跟 B 有關
↓
我再去找 B
↓
貼給 AI
↓
AI 又說要看 C

現在則比較像：

我描述問題
↓
Codex 搜尋專案
↓
找到 A
↓
追到 B
↓
再找到 C
↓
整理可能原因

看起來只是少了幾次複製貼上，但實際使用上的差異滿大的，因為以前「找上下文」這件事幾乎都還是我在做，現在這一段開始可以交給 Agent 自己處理。

找到問題之後，我沒有讓它立刻大改

不過這裡我還是加了一個限制，我現在不太喜歡直接跟 Coding Agent 說：

幫我把這個問題修好。

因為這句話的自由度其實太高，如果它覺得重新整理整個模組比較乾淨，它真的可能順便幫你重構；如果它看到附近有一段寫法不漂亮，也可能一起修掉，最後原本只是要解一個 Bug，diff 卻變成幾十個檔案。

所以我這次多補了一個條件：

先找出造成問題的最小範圍，
優先做最小修改，不要順便重構不相關程式碼。

這句目前我覺得滿重要的，因為在真正的專案裡，「能改」跟「應不應該改」本來就是兩件事，有時候某段程式確實寫得不漂亮，但現在這張 Issue 只是要修一個錯誤，如果為了漂亮順便把架構一起翻掉，反而會讓 Review 變困難，也會增加新的風險。

Codex 最後找到問題之後，修改的範圍比我原本想像的小，沒有整支 function 重寫，而是只處理真正影響結果的那一段邏輯，至少這一次，它沒有因為有整個 repo 的權限，就開始到處施工。

改完不是結束，我更在意它會不會驗證

程式可以跑，不代表 Bug 真的修好了，這件事在人寫程式時很正常，但 AI 寫 Code 更需要注意，因為它很容易產生一段「看起來完全合理」的修改，語法沒錯、邏輯也講得通，甚至解釋得很有自信，可是真的跑起來結果就是不對。

所以我今天沒有只看 diff，而是要求 Codex 修改完之後，把專案原本有的測試跑過一次，如果這個 Bug 原本沒有測試可以覆蓋，就補一個最小的測試案例。

這裡我開始覺得「Coding Agent」跟「AI 幫我寫程式」之間的差異變得比較明顯，如果只是叫 AI 產生一段 Code，工作通常會停在：

這是修改後的程式碼。

但一個完整的工程流程應該更接近：

理解問題
↓
找到相關程式
↓
確認原因
↓
修改
↓
執行測試
↓
確認結果
↓
整理修改內容

Codex 今天第一次把這整條流程跑完，當然，它跑過測試也不代表我就可以完全不看，但至少「驗證」這件事不再全部留給我自己處理。

我還是會自己看一次 diff

這也是今天我沒有交出去的最後一步，Codex 改完之後，我還是會打開 diff，一個檔案一個檔案看，主要確認它有沒有改到跟 Issue 無關的地方、修的是根本原因還是只把錯誤藏起來，以及這個修改如果真的送給另一個人 Review，我敢不敢直接交出去。

最後這一點對我來說其實滿好用的，因為有時候 AI 給的修改 technically 沒錯，但寫法就是有點奇怪，或者多加了一層其實沒有必要的處理，這種 Code 自己測可能過了，可是一想到等等要送 PR 給別人看，就會開始覺得哪裡不太對。

今天這次修改，我最後還是有手動調整一點細節，不過主要的問題定位跟第一版修正，確實是 Codex 自己完成的，也就是說，我沒有先幫它 Debug 完，再叫它幫我打字。

這個差異比我原本想像中更重要。

到 Day 2，我開始改變自己丟任務的方式

用了兩天之後，我發現我跟 Codex 說話的方式，也開始跟以前問 ChatGPT 不太一樣。

以前我會很習慣把問題切到很小：

幫我修改這個 function。

現在我反而會比較像在寫一張 Issue：

目前發生什麼問題
預期應該是什麼
什麼情況下可以重現
哪些東西不要動
修改完成後要怎麼驗證

至於要去哪個檔案、要追哪一層、最後應該改哪一段，我開始刻意不寫，因為如果每次都是我先把這些事情全部找完，那其實也測不到 Agent 到底有多少能力。

而今天的結果至少證明一件事，只要問題描述夠清楚，它確實可以自己完成一部分以前必須由工程師先做的定位工作。

但我還不會說它已經是軟體工程師

Day 1 它證明自己可以讀一個陌生專案，Day 2 又進一步做到自己找問題、修改、跑測試，如果只看這兩天，確實已經比單純的程式碼生成工具更接近「一起工作的人」，但現在的任務仍然很單純，Bug 範圍不大、專案是現成的、需求也是我先整理過的，真正困難的情況其實還沒有出現。

例如需求本身很模糊怎麼辦、一次要改很多模組怎麼辦、測試壞掉時它能不能判斷是不是自己的修改造成的，甚至如果 Issue 的描述本身就是錯的，它會不會照著錯誤方向一路做到最後，這些問題我現在都還不知道。

所以 Day 2 我比較願意給它的評價是，它已經不只是等我把 Code 貼上來的 AI 了，而是開始有能力自己進專案找線索，完成一個範圍不大的工程任務。

至於能不能真的成為一個可以放心把事情交出去的軟體工程師，還要繼續往後測。

明天我想再把限制拿掉一點，這次修的是已經知道「有 Bug」的任務，下一步我想試試看，如果只給 Codex 一個新的功能需求，不告訴它應該怎麼實作，它能不能自己先理解現有架構，再決定新功能到底應該放在哪裡。