前幾天我開始慢慢把比較完整的任務交給 Codex，從找 Bug、跨檔案修改，到後來要求它控制修改範圍、補測試，我原本以為做到這裡之後，最大的問題應該已經變成「它能不能把程式寫對」，但實際用久之後，我反而越來越在意另一件事，那就是 Codex 說自己完成了，到底代表什麼。

因為 Coding Agent 很容易給人一種任務已經結束的感覺，它會告訴我修改了哪些檔案、修掉什麼問題，有時候還會附上測試結果，看起來非常完整，但如果我只看到一句「Done」就直接接受，其實等於把最後的判斷一起交給它，所以今天我想把重點放在驗證，看看一個 AI 完成的修改，到底要經過哪些確認我才敢真的收下。

「完成」這兩個字其實很模糊

假設今天的需求是：

修正後台會員列表的日期格式，
將 CreatedAt 統一顯示成 yyyy/MM/dd，
不要修改資料庫欄位，也不要影響其他頁面。

Codex 很快就可以找到相關頁面，修改日期輸出的地方，接著告訴我：

Implemented the requested date format change.
Updated the member list page to display CreatedAt as yyyy/MM/dd.
No database changes were made.

乍看之下任務完全符合需求，但仔細想會發現，它其實只是描述「它認為自己做了什麼」，這跟「我確認需求真的被完成」還有一段距離。

所以我開始把驗證拆成幾個層次，第一個先看修改範圍。

先看 Diff，比先看說明更有用

以前 Codex 做完事情之後，我第一個看的通常是它最後的 Summary，現在我反而會先打開 Git Diff，因為 Summary 是 AI 對自己工作的描述，Diff 才是真正進入專案的修改。

例如這次只要求改會員列表的日期格式，我就會先確認它到底碰了哪些檔案，如果預期只需要修改一個 .aspx 或 .cs，結果 Diff 裡突然多出 Utility、Model、CSS，甚至資料庫相關程式，那就算畫面最後看起來正常，我也會先停下來看看為什麼需要改這麼多地方。

這個習慣對舊專案特別重要，因為很多程式碼之間其實有共用關係，一個看起來很簡單的格式調整，如果 Codex 選擇直接修改共用 Formatter，其他頁面可能會一起被影響，這種問題只看結果畫面很容易漏掉，看 Diff 反而一下就能發現。

測試通過，也不代表需求一定完成

接著才是測試。

如果專案本來有測試，我會要求 Codex 跑相關測試，至少確認修改沒有直接破壞原本功能，不過做到這裡之後我才發現，「測試全部通過」其實也不能直接等於任務完成，因為測試只能證明目前寫進去的測試案例沒有失敗，如果需求本身沒有被測到，那 Test Passed 只能說程式沒有踩到已知的地雷。

像日期格式這個例子，如果原本的測試只檢查會員資料有沒有成功載入，那日期最後顯示 2026/09/17、09/17/2026，甚至直接顯示完整時間，測試都有可能照樣通過。

所以我後來會再補一個問題給 Codex：

Which test or verification proves that the requested behavior is actually satisfied?

這句話比單純叫它「跑測試」有用很多，因為它必須開始把需求跟驗證方式連在一起，而不是只把現有測試全部跑一遍。

我開始要求它留下證據

今天最大的改變，是我開始要求 Codex 完成任務時一起附上驗證證據。

現在我的任務描述會多一段：

After making the change:

1. Show the files changed.
2. Explain how each change maps to the requirement.
3. Run the relevant tests.
4. State what still requires manual verification.

這樣做之後，它最後回報的內容就會從單純的：

Done.

慢慢變成比較像工程紀錄：

Changed:
- MemberList.aspx.cs

Requirement:
- CreatedAt is now formatted as yyyy/MM/dd

Verification:
- Existing member list tests passed
- No database files were modified

Manual check:
- Open the member list page and confirm the displayed date format

我覺得這個差異很重要，因為當 AI 開始清楚告訴我「哪些事情已經驗證、哪些還沒驗證」，我才比較知道目前任務真正完成到哪裡。

有些東西還是一定要自己看

到了今天，我已經不太期待 Codex 可以用一句話告訴我「這個任務百分之百完成」，因為有些東西本來就很難只靠程式碼或測試確認，例如 UI 有沒有跑版、操作流程順不順、需求文字是不是跟使用者真正想要的一樣，甚至有些舊系統根本沒有完整的自動化測試環境。

這時候 Coding Agent 能做的事情，是把可以自動確認的部分先完成，並且把剩下需要人工確認的地方清楚標出來，最後那一步還是由我自己打開系統實際操作。

這幾天一路用下來，我開始覺得真正影響 Codex 能不能進入實際開發流程的，已經不只是它寫程式的能力，還包括修改之後能不能留下足夠的證據，讓下一個接手的人知道它做了什麼、測了什麼，以及還有哪些地方沒有被確認。

如果 AI 只負責產生程式碼，那最後還是會留下很多人工整理工作，但當它連驗證、測試結果與修改依據都一起整理好，整個工作方式才真的開始有一點像工程協作。

明天我想再往下一步走，既然 Codex 已經可以修改、測試、驗證，那我想試著把這些東西整理成一個比較完整的 Pull Request，看看它能不能把「寫完程式」一路做到「讓別人可以 Review」。