我不逐行讀程式碼，那我要怎麼知道 AI 做對了？
整理規格、實作證據、測試、AI review 與人工操作等多層驗證，說明如何在無法逐行讀碼時逐步建立信任。
上一篇寫到，我現在已經可以沿著系統理解問題，知道一個需求可能會碰到哪些部分，也大致知道問題可能落在哪一層。
但真的進到 codebase，我還不能自己一路追出完整實作。
那 Codex 說「做完了」之後，我到底怎麼知道它真的把我要的東西做對了？
我現在不是靠單一方法判斷。
而是用幾個不同層次的證據一起看。
目前大致是：
SDD／規格 → Codex 依 TDD 實作 → AI review → 我自己實際操作 UI。
這幾層不是在重複檢查同一件事。
它們各自在回答不同問題。
第一層，先確認「到底要做什麼」
對我來說，驗證不是 Coding 完成之後才開始。
新的需求進來時，我通常會先走規格與 design，把這次到底要解決什麼、預期怎麼運作、哪些條件不能被破壞先整理清楚。
這一層最重要的是：
先確認我們做的是不是對的東西。
如果需求一開始就被理解錯，後面的程式就算完全照規格完成，也可能只是很正確地做出一個我根本不需要的東西。
所以在實作開始以前，我就會先確認：
使用者到底要完成什麼工作？
哪些條件必須成立？
這次修改會不會影響其他地方？
最後的操作方式是不是符合我對這段工作的理解？
這些我不需要先看程式碼才有辦法參與。
程式進入實作後，會留下另一批證據
規格確認後，Codex 才開始真正修改程式。
目前我的流程會搭配 TDD，所以實作本身不只是「程式跑起來了」，還會有測試結果可以對照。
完成後，我也會再讓 AI 從另一個角度重新檢查這次修改。
這些東西有一個共同點：
它們在檢查我自己只看畫面很難看到的部分。
我平常不會逐行閱讀全部程式，也不會逐條人工確認所有測試和 review finding。
但我不再只接受一句：
「已完成。」
我會要求實作留下可以被重新檢查的東西。
至於測試到底能證明什麼、review 又多檢查了什麼，後面兩篇再分開談。
最後，我還是會自己把功能操作一次
前面的流程都通過之後，我還是會真的把畫面打開。
因為有些問題只有把功能放回實際工作情境裡，我才看得出來。
最近就有一次。
使用者上傳文件後，需要打開內容，和系統原本的資料互相比對；如果一次上傳多份，也要能逐份切換確認。
這些功能本身都做出來了。
但我真的操作時，看到的是一個三欄工作台。
我的第一個感覺是：
為什麼確認一份文件，需要一次看這麼多東西？
功能沒有少。
真正有問題的是，這些功能最後被組成了一個太複雜的操作方式。
所以我把版本退回去，要求大幅簡化畫面。
這個問題不是：
程式有沒有照規格做。
更接近：
這些功能放回真正的工作裡，使用者會不會想用這種方式完成？
而這件事，我自己實際操作還是很重要。
前一層通過，不代表下一層不會發現問題
這也是我現在對這套流程最明顯的感覺。
有時候測試都過了。
review 也沒有留下重大問題。
但我自己一操作，還是會覺得：
不對。
反過來，也有些工程上的問題，我只走一次主要操作流程根本不會看到，卻會在前面的自動化檢查或 review 裡被找到。
所以這幾層不是互相取代。
更像是：
每一層都只看得到一部分。
規格幫我確認方向。
程式實作會留下可以重複檢查的證據。
AI review 再換一個角度看一次。
我自己操作，則把這些東西重新放回真正的工作情境。
前一層全部通過，下一層還是可能看到新的問題。
我現在建立的是「信任」，不是「完全確定」
這些方法並不能讓我得到一個結論：
我不用讀程式碼，也可以百分之百確定實作正確。
我目前做不到這件事。
更準確的是：
在我還不能自己沿著程式碼完整驗證實作的情況下，我開始要求每一次實作留下不同形式的證據。
我不是只看最後畫面有沒有動。
也不是只相信 AI 說它已經完成。
我開始用不同層次的證據，逐步建立對實作的信任。
但這個框架裡還有很多問題沒有回答。
測試通過，到底能告訴我什麼？
AI review 和測試又在看不同的什麼？
而我自己走過主要操作流程之後，那些沒有走到的情況又怎麼辦？
接下來三篇，我想把這幾層分開看。