前十天一直在想怎麼讓 AI 在寫 Code 前多理解一點需求，但今天突然想到另一個問題：

就算前面的 Prompt 寫得很好，我最後還是得 Review AI 寫出來的 Code。那到底要 Review 什麼？

以前自己寫功能時，很多決定其實是在開發過程中慢慢做的。哪個 State 放哪裡、這個判斷為什麼寫在這層、某個 Edge Case 怎麼處理，通常自己多少知道原因。

但 AI 寫 Code 的速度很快，有時候幾分鐘就改完好幾個地方。這時如果 Review 只是看看 Diff 有沒有很奇怪、Build 有沒有成功，好像很容易漏掉真正重要的問題。

第一層：它到底改了什麼？

我現在會先從最基本的開始，不急著逐行看語法，而是先確認修改範圍。

例如加入 Stopwatch 時，我會先想：

這次需求是什麼？
↓
AI 改了哪些檔案？
↓
每個修改跟需求有什麼關係？

如果只是改一個按鈕文字，結果突然動到 ViewModel 或 Timer 邏輯，就值得先確認為什麼。

反過來，如果新增一個會影響計時狀態的功能，AI 卻只改 Fragment，也可能代表它根本沒有看到真正持有狀態的地方。

所以第一步不是判斷 Code 寫得漂不漂亮，而是：

修改範圍和需求的影響範圍對不對得起來？

第二層：它有沒有偷偷幫我做決定？

這是前幾天最常遇到的問題。

最早讓 AI 實作 Stopwatch 時，我只說進入畫面後從 00:00 開始計時，AI 卻直接把它做成進入頁面就自動開始。

Code 本身沒有什麼語法錯誤，甚至功能也真的會動。

問題是：

「自動開始」根本不是我確認過的需求。

所以現在 Review AI 的 Code，我會特別注意那些「看起來合理，所以 AI 順手幫我決定」的地方。

例如：

什麼時候開始？
什麼時候結束？
不同功能能不能同時操作？
什麼情況建立紀錄？
錯誤或特殊狀態怎麼顯示？

這些通常比某一行 Kotlin 寫法更值得先看。

第三層：它有沒有破壞原本的功能？

這也是我這次 Timer 功能踩到最明顯的問題。

Stopwatch 自己可以正常計時，不代表功能就完成了。

因為它和 Pomodoro 共用 TimeManager，所以真正需要確認的是：

Stopwatch 正常
+
Pomodoro 還正常嗎？
+
兩個切換時正常嗎？
+
背景 / 前景正常嗎？
+
通知正常嗎？

這讓我慢慢把 Review 的單位從：

「這個新功能能不能用？」

改成：

「這個新功能放進原本的 Project 後，整體還是不是原本預期的行為？」

第四層：最後才是 Code 本身

前面都確認之後，我才會回頭看比較傳統的 Code Review 問題。

例如命名清不清楚、有沒有重複邏輯、是不是多做了一層不需要的抽象、能不能沿用現有寫法，還有之後的人看這段 Code 能不能理解。

這部分 AI 通常做得不差，但我現在反而不會把它放在第一順位。

因為一段很乾淨的 Code，如果做錯 Requirement，還是錯的。

一個很漂亮的 Architecture，如果根本不需要那層抽象，也只是增加維護成本。

我現在會用四個方向看 AI 的修改

目前可以先整理成：

Scope
修改範圍合理嗎？

Requirement
有沒有自己補了我沒決定的行為？

Integration
原本的功能有沒有被影響？

Code
最後才看可讀性、架構與維護性

這不是一份完整的 Code Review Checklist，比較像我這幾天實際踩過問題後，開始形成的檢查順序。

以前看到 AI 顯示：

Build Successful

很容易有一種「好像做完了」的感覺。

但現在我會把 Build 當成更前面的門檻而已。

Build Success 只能證明 Code 可以被編譯，不能證明我可以放心接受這次修改。

AI 寫 Code 讓 Implementation 變快之後，我反而覺得 Review 會變得更重要。

因為以前是我一邊寫、一邊做決定，現在很多 Implementation 可以直接交給 AI，我需要做的事情開始變成：

確認它理解的是不是我要的、改的是不是該改的，以及我願不願意為這份 Code 負責。

接下來我想試著把這幾個方向再整理得更具體，看看能不能變成一套真的能拿來 Review AI 修改的流程，而不是每次只靠「看起來好像沒問題」。