昨天第一次讓 Codex 自己從專案裡找 Bug，最後確實有找到問題，也完成了修改。

如果按照我以前使用 AI 寫程式的習慣，做到這裡大概就結束了。AI 給我修改後的程式碼，我看一下 Diff，覺得沒有什麼奇怪的地方，接著自己跑起來測，能動就繼續做下一件事。

但如果真的把 Codex 當成 Coding Agent，這個流程其實有點奇怪。

因為前面都已經讓它自己讀 Repository、追程式執行流程、找 Root Cause，最後卻還是停在「程式碼改完了」，剩下的全部丟回給我。

所以今天想繼續測一件很基本，但我以前其實很少完整交給 AI 的事情。

修改完成之後，讓它自己證明這次修改沒有把專案弄壞。

「看起來改對了」其實不代表真的修好了

昨天找到 Bug 之後，我讓 Codex 做的是最小修改。

這樣確實可以降低影響其他功能的機率，但降低不代表完全沒有，所以今天第一件事不是繼續加功能，而是回頭看這個修改到底能不能被驗證。

我先讓 Codex 自己找專案目前有哪些測試。

請先閱讀目前 Repository 的測試結構與相關設定。

告訴我：
1. 目前有哪些測試
2. 哪些測試與昨天修改的功能直接相關
3. 應該先執行哪些測試
4. 是否缺少可以驗證這次 Bug 的測試

先不要新增或修改測試。

我原本以為它大概就是找一下 tests 資料夾，結果實際上它還會一起看 package script、測試框架設定，以及跟修改檔案有關的既有 Test。

這其實又碰到前幾天一直出現的同一個差別。

如果只是把一段 function 貼給 AI，它根本不知道專案原本怎麼測，但當整個 Repository 都在它手上的時候，它可以先理解這個專案原本的規則，再決定下一步怎麼做。

第一輪測試沒有全部通過

接著我讓它執行跟這次修改最相關的測試。

結果沒有想像中順利，第一輪就出現 Failed Test。

看到紅字的時候，我第一個反應其實還是很習慣地想自己把錯誤訊息複製出來，然後開始找是哪裡出問題，但這次既然本來就在測 Agent，我就先忍住沒有動。

我只補了一個要求：

測試失敗了。

先不要直接修改程式碼，請分析失敗原因，並區分：

1. 是昨天的修改造成 regression
2. 是原本測試就存在問題
3. 是環境或 dependency 問題
4. 是測試預期結果需要更新

說明判斷依據後，再提出下一步。

這裡我覺得很重要。

因為「Test Failed」跟「程式寫錯」其實不是完全一樣的事情。

如果直接跟 AI 說「測試失敗，幫我修」，它很可能會想辦法把測試弄綠，但最糟的情況就是直接去改 Test，讓錯誤的程式也可以通過。

所以我現在開始很常在 Prompt 裡加一句「先不要修改」。

不是因為不相信它寫程式，而是我想先知道它準備改什麼。

它開始從錯誤訊息往回追

這次 Codex 的處理方式跟昨天找 Bug 有點像，只是入口變成測試結果。

它先看 Failed Test 的 Assertion，再回頭找被測試的 function，接著比對昨天修改的內容，確認輸入和預期輸出到底在哪裡開始不一致。

這時候 Agent 的優勢又比單純聊天明顯一點。

以前如果我要問 ChatGPT，通常會變成：

複製 Error
↓
貼 Test
↓
貼 Function
↓
發現還缺另一個檔案
↓
再貼一次

最後對話裡會出現一大堆程式碼，我自己也要一直判斷哪些 Context 應該補給它。

Codex 可以自己沿著 Dependency 找下去，我需要做的事情少很多。

當然，它的分析還是要看。

尤其看到「這個測試可能需要更新」這種結論，我現在會特別小心，因為有時候不是 Test 過時，是 AI 剛剛真的把行為改壞了。

我開始要求它補一個 Regression Test

確認問題之後，我沒有只讓它把原本測試跑過，而是多做了一件以前自己也很常偷懶的事。

把昨天那個 Bug 變成一個新的 Test Case。

概念其實很簡單：

昨天會壞掉的輸入
↓
寫成 Test
↓
修正後應該通過
↓
未來再次出現同樣問題時直接失敗

這樣昨天花時間找到的 Bug 才不會只存在聊天紀錄裡。

我給 Codex 的要求也很單純：

根據昨天確認的 root cause，新增一個最小 regression test。

測試目標只需要覆蓋這次 Bug，
不要順便重構其他測試，也不要擴大修改範圍。

完成後執行：
1. 新增的 regression test
2. 相關測試
3. 專案目前可執行的完整測試

最後整理結果。

做到這裡之後，整個流程才開始比較像我原本想像中的 Coding Agent。

它不只是「幫我寫一段修正版程式」，而是從問題開始，一路找到原因、修改、測試，再把這次錯誤留下來變成之後可以自動驗證的東西。

測試真正有趣的地方是它會讓 Agent 被限制住

前幾天我一直在想，要怎麼避免 Coding Agent 改太多。

Prompt 當然可以一直寫「只做最小修改」「不要動其他功能」，但這些終究都是文字要求。

Test 不太一樣。

只要原本的行為已經被測試固定下來，Agent 修改之後就必須面對結果。它不能只跟我說「我已經完成修改」，因為 Test 到底有沒有過就在那裡。

這讓我開始覺得，如果真的要把 Coding Agent 放進比較完整的開發流程，Test 可能比 Prompt 還重要。

Prompt 是告訴它我希望怎麼做，Test 則是在它做完之後告訴我，專案到底還是不是原本那個專案。

今天開始比較像真的把工作交出去

前幾天其實都還有一種「我在看 AI 表演」的感覺。

叫它讀 Repository、叫它分析、叫它找 Bug，雖然都很有趣，但最後我還是會一直盯著它做了什麼。

今天第一次把「修改 → 測試 → 分析失敗 → 再修改 → Regression Test」串起來之後，感覺開始有點不一樣。

我不需要每一步都自己操作，但也不是完全放著讓它亂跑，中間還是有幾個很明確的檢查點。

現在我的流程大概變成：

Issue
↓
分析 Repository
↓
找 Root Cause
↓
提出修改
↓
最小修改
↓
執行相關測試
↓
分析 Failed Test
↓
Regression Test
↓
完整測試
↓
Review Diff

這比一句「幫我修 Bug」長很多，可是我反而比較願意真的拿它處理專案。

明天我想再往前走一步。

因為現在 Issue、修改跟 Test 都已經開始串起來了，下一個很自然的問題就是：如果我真的讓 Codex 完成一個任務，我到底敢不敢直接讓它準備一個可以 Review 的 Commit？

到了那一步，它才真的開始碰到我平常使用 Git 的工作流程。