去年團隊開始用AI編程工具，大家都覺得寫代碼變快了。但一年下來我發現一個怪現象：寫代碼的時間確實少了，可Code Review的時間卻越來越長。以前review一個PR，掃一遍邏輯、提兩個問題就過了。現在每條改動我都要反覆確認：這段是AI寫的還是人寫的？邊界條件處理了嗎？有沒有隱藏的性能問題？review到後來，比我自己重寫一遍還累。

一、AI寫代碼快，但review起來慢

今年初，我接手了團隊的核心項目。組裡幾個同事都用Cursor和Copilot，產出確實高。但輪到我來review的時候，總覺得不對勁。

舉個例子，有個同事提交了一個功能模塊，代碼跑起來沒問題，但我逐行看的時候發現：一個組件裡掛了三個useEffect，其中兩個功能重疊。作者說他沒注意，是AI自動補全的。這類問題成了常態：AI生成的代碼往往能跑，但結構混亂、邏輯重複、缺少邊界判斷。

以前人工寫的代碼，你能感覺到作者的思路。AI寫的代碼像一鍋大雜燴，看起來什麼都有，但就是不舒服。review的時候，你不能只看邏輯對不對，還得幫作者刪冗餘、補缺失、理結構。這一套下來，時間不知不覺就翻倍了。

二、幾種AI代碼的“通病”

我總結了幾類經常在review時遇到的AI痕跡：

1. 邏輯正確，邊界全無

AI很擅長把主流程跑通，但空指針、超時、併發這些問題它不太會主動處理。比如一個查詢接口，AI會寫data.list.map(...)，但不會判斷data是不是空。review時要幫它補上data?.list?.map，或者if (!data) return null。

2. 過度設計，簡單問題複雜化

有時候AI會把一個很簡單的事搞得特別“高端”。比如加個防抖，它給你寫一個完整的自定義Hook，裡面用了useRef、useCallback、useEffect，洋洋灑灑四五十行。但實際上只需要一個debounce函數。review這種代碼，你得先理解它的實現，再判斷是不是過度了。

3. 註釋和命名像“機器翻譯”

AI生成的變量名經常是data、items、config，看不出具體含義。函數註釋要麼沒有，要麼是“獲取數據”這種廢話。review時要幫忙改成有意義的命名，或者補上必要的註釋，否則下一個人看不懂。

三、我的個人策略：怎麼讓review不那麼痛苦

經過大半年，我摸索出幾條還算管用的辦法：

• 讓AI先審AI：提交PR前，要求作者把代碼再給AI（換一個模型）審一遍，根據建議改一輪。
• 差異化對待：工具類、單元測試、文檔註釋可以放心讓AI寫；核心業務邏輯建議手寫或深度修改。
• 建立小規範：比如“useEffect必須有清理函數”、“API調用必須有loading和error狀態”。AI不一定會遵守，但review時可以快速對照。

這些辦法不能根除問題，但至少能把review時間拉回到可接受的範圍。

四、反思

我現在對AI編程的態度很矛盾。一方面，它確實幫我省了不少重複勞動；另一方面，它又把負擔轉移到了review環節。以前一個人寫代碼，大家一起審；現在一個人寫AI代碼，另一個人替他審漏洞。

這不是AI的錯，也不是工具的錯，而是我們還沒學會怎麼和AI協作。也許未來會有更好的review流程，或者AI能自己審自己。但就目前而言，AI沒有讓我少加班，只是讓我加班的內容從“寫”變成了“審”。

五、最後

如果你也在經歷類似的感受，點個贊讓我知道不是一個人。評論區聊聊：你的團隊有沒有因為AI代碼而review變慢？