昨天整理了 AI 寫完 Code 之後，我會從四個方向 Review：
Scope
↓
Requirement
↓
Integration
↓
Code
但整理完之後我發現一個問題。
「記得檢查需求」、「記得看有沒有影響其他功能」這些話都很合理，但真的看到 AI 一次改了好幾個檔案時，我還是很容易直接開始看 Diff，最後變成哪裡有變就看哪裡。
所以今天想把這四個方向再往下整理成一份簡單的 Checklist。
目的不是讓每次 Code Review 都變得很重，而是至少不要只剩下：
Build 過了、畫面看起來正常、Code 沒有很奇怪，好像可以了。
第一個我想看的不是 Code 寫得好不好，而是 AI 到底動了哪些地方。
我會先問：
這次需求需要改哪些地方？
AI 實際改了哪些地方？
有沒有不必要的修改？
有沒有應該改卻完全沒碰到的地方？
例如只是修改 Dialog 按鈕文字，正常來說不應該突然出現 Timer 邏輯或 ViewModel 的修改。
但如果今天改的是 Stopwatch 計時行為，AI 卻完全沒有確認 TimeManager，也可能代表它只處理了 UI，沒有看到真正的狀態來源。
所以 Scope 不是越小越好。
而是：
修改範圍要和需求真正的影響範圍對得起來。
接下來才確認功能本身。
除了需求有沒有完成，我還會多看一件事：
AI 有沒有順手幫我決定我沒說的東西？
之前 Stopwatch 就發生過這件事。
我要的是正計時功能，但 AI 自己決定進入畫面就開始計時。這個實作看起來合理，也能正常執行，但不是我確認過的需求。
所以這一層我會檢查：
原本需求有沒有完成？
有沒有少做？
有沒有多做？
有沒有自行補上需求沒有決定的行為？
這裡的「多做」不一定是多寫幾行 Code，而是有沒有偷偷增加新的產品行為。
這是我這次 Timer 功能最容易漏掉的部分。
如果只測 Stopwatch：
Start
Pause
Resume
Finish
全部正常，很容易覺得做完了。
但 Stopwatch 和 Pomodoro 共用 TimeManager，真正放回 Project 後還要確認兩邊一起使用時會不會出問題。
所以這一層我會問：
有沒有共用 State？
有沒有共用資料或邏輯？
切換畫面後正常嗎？
背景再回來正常嗎？
相關的 Existing Feature 還正常嗎？
不一定每個需求都要全部檢查。
如果只是改字串，就不需要突然測整個 Timer Lifecycle。
重點還是回到前幾天一直在整理的原則：
只檢查跟這次 Change 有關的 Integration。
前三層確認完，我才會開始看實作本身。
這時才檢查：
命名看得懂嗎？
有沒有重複邏輯？
有沒有不必要的抽象？
有沒有沿用 Project 現在的寫法？
之後修改這段 Code 會不會很痛苦？
以前我很容易一打開 Diff 就先注意：
這個 function 要不要抽？
這段是不是可以寫得更漂亮？
但現在覺得這些其實應該放後面。
如果 Requirement 都做錯了，把 Code Refactor 得再漂亮也沒有意義。
最後先把它縮成一個真的能快速看的版本：
AI Code Review v0.1
□ Scope
改動範圍和需求相符嗎？
有沒有不必要或遺漏的修改？
□ Requirement
需求有完整做到嗎？
AI 有沒有自行增加沒確認過的行為？
□ Integration
有沒有影響共用邏輯或既有功能？
相關流程放在一起使用還正常嗎？
□ Code
有沒有符合目前 Project 的寫法？
Code 是否清楚、好維護？
有沒有不必要的複雜化？
我刻意沒有把它做得很長。
因為如果 Checklist 有三十項，我大概用幾次之後就不會想看了。
目前比較想要的是，在 AI 很快丟出一份修改後，我至少可以先用這四層快速掃過一次，再決定哪些地方值得深入。
整理到這裡，我覺得這份 Checklist 最重要的地方不是「以後照著勾就不會出錯」。
因為像 Integration 到底要測什麼，還是得先理解 Project。
如果不知道 Stopwatch 和 Pomodoro 共用 TimeManager，我甚至不會想到要測兩邊切換。
所以 Checklist 比較像提醒我：
不要因為 AI 寫得很快，就跳過原本應該做的判斷。
前面幾天我一直在調整怎麼讓 AI 更會分析需求，現在開始覺得另一邊也很重要。
AI 可以變得更會寫、更會找 Code、更會分析，但最後接受這份修改的人還是我。
所以比起期待 AI 每次都一次寫對，我更想先建立一個自己能穩定判斷：
這份 AI 寫出來的 Code，我到底敢不敢接下來？
這份 Checklist 還只是第一版，之後如果真的拿來 Review 幾次，應該還會再繼續調整。
iThome鐵人賽
看影片追技術