前三天把專案交給 Codex 之後，我慢慢發現一件事，如果只是叫它找到某個問題、修改某個檔案，其實跟平常把程式碼貼給 AI 的差距還沒有想像中那麼大。

真正讓我覺得 Coding Agent 開始有點不一樣的，是我不再把「修改完成」當成任務終點。

以前用 ChatGPT 幫忙寫程式時，流程通常是我貼一段程式碼、描述問題，AI 回一個修改版本，我再自己貼回專案裡執行，如果出錯就把錯誤訊息複製回去，接著再問一次。看起來是 AI 在幫忙寫程式，但真正負責整個流程的人還是我，因為執行、看錯誤、判斷下一步、重新測試全部都要自己處理。

所以今天我想測的事情很單純：

如果修改完之後不馬上停下來，而是讓 Codex 自己跑測試，它能不能根據結果繼續把問題處理完？

修改程式其實只是第一步

這次我沒有把任務切成「幫我改某一行」，而是直接描述我要解決的問題，同時要求它修改之後自己執行測試。

這個差別看起來很小，實際跑起來卻差很多。

因為只要求修改程式碼時，Codex 很容易在「程式看起來已經改好了」的地方停下來，但加上測試之後，它就必須面對真正的執行結果。

程式碼語法正確，不代表功能一定正常；function 可以執行，也不代表其他地方沒有被影響，更麻煩的是，有些錯誤根本不是出現在剛剛修改的那個檔案，而是改動之後才讓其他模組的問題浮出來。

這時候測試就變成一個很重要的回饋來源。

我原本以為流程大概會是：

讀需求
↓
修改程式
↓
跑測試
↓
通過

真的跑下去才發現比較像：

讀需求
↓
找相關檔案
↓
第一次修改
↓
執行測試
↓
發現錯誤
↓
重新找問題
↓
第二次修改
↓
再次測試

這個「再回去一次」其實才是今天最值得觀察的地方。

錯誤訊息開始變成 Agent 的下一個輸入

以前看到 terminal 噴錯，我第一個動作就是複製錯誤訊息，接著貼到 ChatGPT 問「這是什麼問題」。

但如果 Coding Agent 本身就在專案環境裡，這個搬運其實可以省掉。

測試失敗之後，它可以直接看到哪個 test failed、錯在哪個檔案、stack trace 指向哪裡，再回頭搜尋相關程式碼。

這時候整個工作方式就開始改變了。

原本是：

我執行 → 我看到錯誤 → 我複製 → AI 分析 → 我修改

現在比較接近：

Agent 修改 → Agent 執行 → Agent 看到錯誤
→ Agent 分析 → Agent 再修改

人還是在流程裡，只是不用每一步都負責搬資料。

對我來說，這比「AI 一次把程式寫對」更有意思，因為實際開發本來就很少一次成功，真正花時間的通常是修改之後發現新問題，再沿著錯誤慢慢找回去。

如果 Agent 只能產生第一版程式碼，它比較像一個很快的程式碼產生器；但如果它能接住測試結果，再決定下一步要看哪裡，才比較接近我原本想測的 Coding Agent。

但能自己修，不代表可以完全放著不管

今天跑完之後我也發現一個問題：Agent 願意一直修，有時候反而更需要注意。

例如一個 test 沒過，它可能有很多解法，有些是在修真正的 bug，有些只是讓測試變綠，兩件事表面上的結果可能一樣，但意義完全不同。

假設原本需求規定某個輸入一定要被拒絕，結果測試失敗，最糟的處理方式不是程式跑不起來，而是 Agent 直接把 test 改成接受這個輸入。

最後畫面可能會顯示：

All tests passed

但需求其實已經被改掉了。

所以我現在反而不太想只看「測試有沒有過」，還會一起看它到底改了哪些檔案、為什麼要改、測試本身有沒有被動到，以及最後的 diff 是否還符合原本需求。

這也是今天開始比較有感的一件事：

自動測試不是為了證明 AI 沒問題，而是讓 AI 的修改多一層可以被檢查的依據。

我現在比較想看的，是它怎麼失敗

前幾天我一直在觀察 Codex 能不能理解專案、能不能找到正確檔案、能不能完成修改，到了 Day 4，我反而開始覺得「第一次有沒有成功」沒有那麼重要。

因為真正的專案一定會遇到失敗。

比較值得測的是，它第一次做錯之後能不能從 terminal、test result 和現有程式碼裡找到下一步，而不是每次都等我重新整理問題再餵一次。

目前看下來，我還不會把整個專案直接丟著讓它自己跑到底，但我已經開始把一些原本需要手動來回的步驟交出去。

從「幫我寫這段程式」變成「幫我處理這個問題，改完自己測，失敗就先找原因」，看起來只多了幾個字，實際上卻已經是完全不同的使用方式。

明天我想再往前一步。

如果 Agent 已經可以修改、執行、看錯誤再修改，那下一個問題就是：到底要給它多少權限，又有哪些事情不能讓它自己決定？