讓 AI 幫團隊把 Review 經驗留下來
前言
最近參加 Meetup 後，又重新整理了一下自己對 AI Review 的想法
過去我一直覺得 Code Review 很重要
它會找 bug、檢查格式，也會讓團隊對一段 code 有更多討論：這樣寫之後好不好維護？錯誤處理是不是一致？下一個人接手會不會看得懂？
這些問題看起來都很細，但累積久了，其實就是團隊對程式碼品質的共識
只是實際推起來，沒有想像中容易
我目前待的團隊，老實說還不算是一個很重視 Review 的團隊
大家其實都在意品質，不想要處理爛程式碼，只是每個人手上都有不同的事情在忙，Review 很容易變成一個需要額外花時間處理的流程
很多時候 PR 開了，有人快速看一下，確認功能可以跑、沒有太明顯的問題，就先讓它過了
但從維護的角度來看，功能可以跑只是第一步
有些程式碼現在看起來沒事，但之後會變得難改；有些邏輯這次先複製貼上，下一次就變成三四個地方都有類似寫法；有些錯誤處理不一致，等真的出問題時才發現不好追
這些東西當然可以靠 Review 慢慢提醒，只是成本其實不低
Review 最花時間的地方
我自己在 Review 時，通常會去思考如何把問題講清楚
如果只寫「這裡要改」或「這樣不好」，對方其實很難知道你真正想表達的是什麼
比較完整的 Review Comment，通常要先指出問題，再說明為什麼可能有風險，最後最好再給一個可以調整的方向
有時候甚至還要補一小段範例，讓對方看得出來這個建議背後有比較清楚的改善方向
但這件事本身很花時間
尤其當自己手上也有任務要處理時，不一定每次都有心力把 comment 寫得很完整
有時候明明知道這段 code 之後可能會出問題，但也知道如果要講清楚，就要多花十幾分鐘整理說法
久了之後，人其實會累
更現實的是，人的標準也不會永遠一致
忙的時候 Review 會看得比較快；有空的時候就會看得比較細
實務上，Review 很容易受到時間、壓力和專案進度影響
所以我後來開始想，如果每次都只靠人力維持 Review 品質，這件事其實很難長期穩定
AI Review 可以先幫忙整理方向
這也是我覺得 AI Review 有價值的地方
我不會把 AI 當成最後的裁判，也不期待它每次都講得完全正確
它比較像是一個可以先幫忙掃過一輪的助理
它可以先提醒一些可能的問題，例如：
- 命名不清楚
- 邏輯太複雜
- 重複程式碼
- 缺少錯誤處理
- 測試情境不足
- 某些寫法之後可能不好維護
這些建議不一定每個都要照單全收，但至少可以幫我省下「從零開始整理想法」的時間
以前可能是我看到一段程式碼，心裡覺得怪怪的，然後要自己想怎麼講才比較清楚
現在 AI 可能先幫我整理出一個方向，我再去判斷它講得合不合理
如果合理，就把它轉成比較適合團隊溝通的說法
這件事對推動 Review 文化其實滿有幫助
跟工程師討論時，我可以用比較中性的方式切入：「AI 也有提醒這段可能有維護上的問題，我看了一下覺得滿合理的，我們要不要一起看一下？」
讓討論比較聚焦在程式碼本身，感覺上也比較容易被接受或討論
好的 Comment 可以留下來
我覺得 AI Review 更有意思的地方，是它可以幫團隊把 Review 裡值得留下來的經驗，慢慢累積成規範
例如 AI 在某次 Review 裡提醒：「這裡呼叫外部 API 時，只有處理成功回應，沒有處理 timeout、錯誤狀態碼或回傳格式異常的情況」
如果團隊討論後覺得合理，那就可以把這件事整理進 Review Guideline
之後只要有類似的 API 呼叫，不管是人 Review，還是 AI Review，都可以提醒要確認錯誤處理是否完整
我想像的流程大概是這樣：
- AI 先提出一些可能的問題
- Reviewer 判斷哪些建議合理
- 合理的部分，團隊討論後寫進規範
- 之後 AI 和 Reviewer 再依照這些規範檢查
- 如果又發現新的好建議，就再補回規範
這樣 Review 經驗就可以從個人的記憶裡整理出來，慢慢變成一個可以被累積、被修正的東西
這點對團隊來說滿重要的
很多 Review 標準其實都存在工程師腦袋裡
只要那個人忙、請假、被調去別的專案，甚至只是隔一段時間再回來，就可能忘記當初這個專案有哪些約定
我自己也會遇到這種情況
離開某個專案一陣子再回來看，有時候真的會有點錯亂
以前討論過的規則，如果沒有被記錄下來，其實很容易就消失
所以我會希望 AI Review 可以跟團隊規範搭在一起
它幫忙看程式碼，也幫團隊把好的經驗留下來
AI 的建議需要被校正
當然，談 AI Review 一定會遇到一個問題：AI 會不會亂講？
我覺得這個擔心很合理
AI 的確可能提出不適合目前專案的建議，也可能對某些技術細節判斷錯誤
所以我不會建議完全相信 AI 的 Review 結果
AI 可能犯錯，所以更需要搭配人的判斷來使用
原因很簡單，因為人也會犯錯，而且人的標準也不一定每次都一致
有時候我自己很忙，Review 標準可能也會不自覺降低；有時候比較有空，就會看得比較細
所以與其期待 AI 一開始就完美，我覺得更實際的做法是建立一個流程，讓 AI 的建議可以被人校正，也可以被團隊吸收
AI 提出的 comment 需要先經過人的判斷
真的有價值的，才放進團隊規範
這樣 AI 會更像是一個幫助團隊發現問題、整理問題、累積共識的工具
結語
對我來說，AI Review 最吸引我的地方，是它可以同時省時間，也幫團隊累積經驗
省時間很重要，讓 Review 這件事有機會從「靠個人努力」變成「靠流程累積」，對我來說更有價值
以前如果要推動 Review 文化，可能要一直跟不同工程師解釋類似的事情：為什麼這段要抽出來？為什麼這裡要補測試？為什麼錯誤處理不要每個地方都寫得不一樣？
這些事情講一次還好，講很多次其實會累
而且只要換人、換專案、換情境，就可能又要重新講一次
如果有 AI Review 加上團隊規範，流程會更容易被維持
AI 可以先幫忙做基本提醒，Reviewer 再判斷哪些地方真的需要討論
當大家對某個建議有共識，就把它補進規範
久了之後，Review 經驗會慢慢變成團隊可以一起維護、一起調整的工程文化