用 AI 做 code review：讓 ChatGPT 或 Claude 當你的第一位審查者

為什麼要讓 AI 先審一輪

Code review 是團隊維持程式品質的核心機制，但人工審查有兩個痛點：一是資深工程師時間寶貴，把時間花在挑錯字、命名、格式這類低階問題很浪費；二是人在審查時容易疲勞，長 PR 看到後面注意力下降。AI 剛好補上這塊：它不會累，能在幾秒內掃過整個 diff，把低階與中階問題先攔下來，讓人類審查者專注在架構、業務邏輯與取捨這些真正需要判斷的地方。

把 AI 當成「第一位審查者」，你在送出 PR 給同事之前先自己過一輪，能大幅提升 PR 品質，也減少來回修改的次數。

第一步：提供 diff 而非整份檔案

Code review 審的是「改動」，所以最好給 AI 看 diff，而不是整份檔案。你可以用 Git 指令產生 diff：

git diff main...feature-branch > changes.diff

然後把這份 diff 貼給 AI，並說明這次改動的目的。提問範例：

以下是一個 PR 的 diff，目的是新增使用者註冊時的 email 格式驗證。
請以資深工程師的角度審查，分成三類回報：
1. 必須修正（會導致 bug、安全漏洞或資料錯誤）
2. 建議改進（可讀性、命名、重複程式碼）
3. 可討論（設計取捨、風格偏好）
每一點請指出行號並說明原因。

(貼上 diff)

分級回報很重要，它讓你能區分「一定要改」和「見仁見智」，避免被一堆風格意見淹沒。

第二步：分層設定審查重點

Code review 有很多面向，一次全問容易讓 AI 回答浮泛。更有效的做法是分層審查，每一輪聚焦一個主題。

第一層是正確性。問 AI：「這段改動有沒有邏輯錯誤、邊界條件遺漏、例外沒處理的地方？」這是最重要的一層。

第二層是安全性。問：「這段程式有沒有常見安全問題，例如 SQL injection、XSS、未驗證的使用者輸入、硬編碼的密鑰、不安全的反序列化？」以下是一個 AI 應該要抓到的例子：

# 危險：字串拼接 SQL
query = f"SELECT * FROM users WHERE email = '{email}'"
cursor.execute(query)

AI 應指出這有 SQL injection 風險，並建議改用參數化查詢：

cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

第三層是可維護性。問：「命名是否清楚？有沒有重複程式碼可以抽出？函式是否過長該拆分？」

第四層是效能。問：「有沒有明顯的效能問題，例如迴圈內查詢資料庫（N+1）、不必要的重複計算？」以下是常見的 N+1 問題：

for order in orders:
    user = db.query(f"SELECT * FROM users WHERE id={order.user_id}")
    print(user.name)

分層的好處是每一輪的回答都深入，不會為了面面俱到而每項都只講一句。

第三步：善用審查清單提示詞

你可以維護一份團隊專屬的審查清單，每次都貼給 AI，確保審查標準一致。範例清單：

請依以下清單逐項檢查這份 diff：
[ ] 所有使用者輸入都有驗證與清理
[ ] 沒有硬編碼的密鑰、密碼、token
[ ] 錯誤有被適當捕捉並記錄，不會靜默吞掉
[ ] 沒有 console.log 或 print 除錯殘留
[ ] 資料庫查詢使用參數化，無字串拼接
[ ] 新增的公開函式有型別註記與註解
[ ] 沒有明顯的效能陷阱（N+1、迴圈內 I/O）
[ ] 命名清楚且與專案慣例一致
逐項回報通過或不通過，不通過請指出行號與修法。

這種清單式審查能讓 AI 的產出結構化、可預期，也方便你逐項確認。

第四步：整合進 Git 工作流

進階做法是把 AI 審查自動化。許多團隊在 CI 流程或 Git hook 裡串接 AI API，讓每次開 PR 時自動跑一輪審查並把意見貼回 PR。你也可以在本機用一個簡單的 pre-push hook：

#!/bin/bash
# .git/hooks/pre-push
git diff origin/main...HEAD > /tmp/pr.diff
echo "正在請 AI 審查改動，請稍候..."
# 這裡呼叫你的 AI 審查腳本，把 /tmp/pr.diff 丟給 API

不過要注意，自動化審查的意見僅供參考，最終合併與否仍要由人決定。不要設計成「AI 沒過就擋 PR」，因為 AI 會有誤報，那會拖慢團隊。

第五步：處理 AI 的審查意見

拿到 AI 的意見後，不要照單全收，也不要照單全改。對每一條意見，你要判斷它是不是真的問題。AI 有時會：

• 誤報：把正確的程式當成錯誤，例如它不了解你專案的特殊慣例。
• 過度謹慎：對不影響安全的地方提出過高要求。
• 遺漏脈絡：因為只看到 diff，不了解整個系統，給出不適用的建議。

對於技術上站得住腳的意見，就採納；對於你不確定的，可以追問 AI「為什麼這樣比較好？有沒有反例？」；對於明顯不適用的，直接忽略。這種「批判性接收」的態度，能讓你從 AI 審查中獲益，又不被它誤導。

AI code review 的界線

要清楚 AI 審查能做什麼、不能做什麼。它擅長：抓語法與邏輯的低階錯誤、辨識常見安全模式、指出可讀性問題、發現重複程式碼。它不擅長：理解你的業務需求是否被正確實作、判斷架構層級的設計取捨、掌握整個系統的隱性約束、評估這個改動對團隊長期維護的影響。這些需要脈絡與判斷的部分，仍然是人類審查者無可取代的價值。所以最佳實踐是「AI 打底，人做決策」。

小結

用 AI 做 code review，最大價值在於把人類審查者從瑣碎低階的工作中解放出來。透過提供 diff、分層審查、清單提示詞與工作流整合，你能建立一套穩定的品質防線。但永遠記得，AI 是第一位審查者，不是最後一位；它的意見要批判性接收，最終判斷權在人。