前幾天把專案交給 Codex 之後，我慢慢發現一件很有趣的事，每次它完成修改，最後幾乎都會整理一段看起來很完整的說明，告訴我改了哪些檔案、修掉什麼問題、做了哪些調整，有時候甚至會直接寫「測試已通過」，如果只是快速掃過，很容易就會覺得這個任務應該可以收掉了。

但真正把它當成一個工程工具使用之後，我開始不太相信「改好了」這三個字。

改完程式只是第一步

以前自己寫程式的時候，我其實也常犯同一個問題，某個 Bug 找到原因、程式重新跑起來，就會下意識覺得事情結束了，但真正麻煩的通常在後面，這個修改有沒有影響別的功能、原本可以跑的流程是不是還正常、輸入換一種情況會不會又爆掉，這些問題如果沒有真的測，很難只靠看程式碼確認。

Codex 也是一樣，它可以很快找到一個看起來合理的修改方式，甚至連相關檔案一起處理，但「合理」跟「真的可以用」之間還有一段距離，所以這幾天我開始刻意要求它不要只修改程式，也要自己把測試跑完。

最簡單的做法就是先把專案原本已經有的測試交給它，例如專案裡如果有 unit test、integration test 或既有的 build command，就要求它修改完成之後全部執行一次，測試失敗的話不要停在錯誤訊息，而是繼續找是哪個修改造成問題。

這時候 Coding Agent 跟一般聊天式 AI 的差別就開始變得比較明顯，因為它不只是給我一段程式碼，我還可以讓它修改、執行、看到錯誤，再回去修正，整個過程比較接近真的在操作專案。

測試通過也不代表一定沒問題

不過跑了幾次之後，我又遇到另一個問題，有些修改所有測試都通過，但實際打開網站操作還是怪怪的。

原因其實很簡單，測試只能檢查「有被寫進測試的東西」，如果某個畫面、操作流程或例外情況從來沒有測試案例，那全部綠燈也只能代表目前這些案例沒有壞掉。

所以後來我開始多加一個要求，請 Codex 在修 Bug 之前先找出這個問題應該對應到什麼測試，如果原本沒有，就先補一個可以重現問題的案例，再去修改程式。

這個順序對我來說差很多，因為如果直接叫它修，它很容易找到一個讓目前畫面恢復正常的方法，但先寫測試之後，它就必須把「什麼情況才算修好」描述得更清楚。

例如原本某個 API 在特定輸入下會回傳錯誤，如果只是叫 Codex 修正，它可能調整一個 if 判斷就結束，但如果先要求建立測試，就會變成先準備輸入、確認原本會失敗，再修改程式讓測試通過，至少我知道這次修改真的有對到一個可以被重現的問題。

我開始看它怎麼證明自己改對了

做到 Day 10，我現在看 Codex 的方式已經跟第一天有點不一樣。

一開始我最在意的是它能不能讀懂整個 GitHub 專案，接著開始觀察它會不會找對檔案、會不會亂改架構、能不能處理 Bug，到了現在，我更在意的是它完成修改之後，可以拿出什麼證據證明這次修改真的有效。

這個證據可能是一個新增加的測試案例，也可能是原本失敗的測試重新通過，或者是 build、lint、type check 全部正常，甚至只是很清楚地告訴我哪些地方目前沒有測試覆蓋，都比一句「已完成修正」有用很多。

因為程式真正進到 GitHub 之後，最後留下來的不是 Codex 說過什麼，而是那一次 commit 到底改了哪些東西，以及其他人把專案拉下來之後還能不能正常跑。

所以接下來我也想繼續測一件事，如果我開始把「測試」當成每個任務的固定要求，Codex 的修改品質會不會慢慢變得比較穩定，甚至能不能讓它自己發現原本專案裡缺少的測試。