快速結論

用 AI 做 Code Review 已經是台灣不少團隊的日常。飛飛實際拿三個工具（GitHub Copilot、Cursor、Claude Code）對同一批 PR 做過對照測試，這篇整理實際差異、能抓到什麼、抓不到什麼，以及把 AI 塞進既有 PR 流程時要注意的安全問題。

先講結論：三個工具都能抓出明顯的安全漏洞和程式碼異味，但沒有一個可以取代人類 Reviewer 對商業邏輯和架構決策的判斷。AI Code Review 是多一道防線，不是最後一道防線。

AI 在 Code Review 能抓到什麼

實測下來，AI 對以下幾類問題的抓取率很高：

語法錯誤與型別問題。少了 return、變數型別不一致、忘記處理 null。這是 AI 最擅長的部分，命中率接近 100%。

明顯的安全漏洞。SQL Injection（字串拼接組 SQL）、XSS（未跳脫的使用者輸入直接輸出到 HTML）、硬編碼的密碼或 API Key、路徑穿越（Path Traversal）。這些都有固定的程式碼模式，AI 訓練資料裡看過大量案例，抓取率高。

程式碼異味（Code Smell）。函式太長、重複程式碼、巢狀迴圈太深、命名不一致（同一個概念在不同檔案用不同變數名）。

命名慣例違反。變數命名沒有遵循專案的慣例（camelCase 混 snake_case）、未使用的 import、未使用的變數。

缺少錯誤處理。API 呼叫沒有 try/catch、Promise 沒有處理 reject、檔案操作沒有檢查是否成功。

AI 在 Code Review 抓不到什麼

這是團隊最容易誤判的地方，過度信任 AI 會漏掉真正嚴重的問題。

商業邏輯錯誤。AI 不知道你的退款規則是「超過 7 天不能退」還是「超過 14 天不能退」，它只能檢查程式碼有沒有語法問題，沒辦法判斷這段程式碼是否正確實現了業務需求。

架構決策。這個功能該不該拆成微服務、這張表要不要加索引、要不要引入 Redis 做快取——這些需要對整個系統的流量、成本、團隊維運能力有全盤了解，AI 看到的只是這次 diff 裡的幾百行程式碼。

大規模下的效能問題。單看一段程式碼，AI 很難判斷這個查詢在資料量 10 筆時沒問題，但資料量 1000 萬筆時會拖垮資料庫。這需要知道實際的資料規模、索引狀況、QPS，這些通常不在 PR 的 diff 裡。

複雜系統裡的競態條件（Race Condition）。單一檔案裡的邏輯 AI 看得出來，但涉及多個服務、非同步佇列、分散式鎖的競態條件，往往要追蹤跨服務的時序才看得出來，AI 很難靠一次 diff 判斷。

需要跑起來才知道的問題。記憶體洩漏、連線池耗盡、某個第三方 API 在特定條件下回傳異常格式——這些通常要實際執行、加壓測試才會浮現，靜態的程式碼審查看不出來。

三個工具實測比較

飛飛用同一份有意植入漏洞的測試 PR（包含 SQL Injection、硬編碼 API Key、缺少權限檢查三個問題），分別在 GitHub Copilot、Cursor、Claude Code 上做 Review，比較實際表現。

GitHub Copilot

Copilot 的 Code Review 分成兩種模式。寫程式時的 inline 建議，會在你打字的當下即時提示潛在問題，例如你打出字串拼接 SQL 的寫法時，它可能會直接建議改成參數化查詢。另一種是 GitHub 上的 PR Review 功能（Copilot code review），會在 PR 開出來後自動留言，逐行給建議。

優勢是跟 GitHub 生態整合最深，不需要額外工具，PR 一開就自動跑。缺點是它主要針對單一檔案或單一 diff 區塊做分析，跨檔案的脈絡理解比較弱，遇到「這個函式的呼叫方在別的檔案裡沒做權限檢查」這種需要串連多個檔案才能看出的問題，命中率明顯下降。

Cursor

Cursor 的優勢是可以把整個檔案甚至整個專案的上下文餵給模型，而不只是 diff 的片段。做 Code Review 時可以直接在 Composer 裡選取整個 PR 的變更範圍，讓它一次看完所有異動檔案。

實測中，Cursor 對「這個新函式跟專案裡其他地方的權限檢查模式不一致」這類問題的抓取率比 Copilot 好，因為它能同時看到新程式碼和專案既有的慣例。缺點是需要手動把 diff 或檔案餵進去，不像 Copilot 那樣自動掛在 PR 上跑，流程上多了一道手動步驟。

Claude Code

Claude Code 的差異在於它可以直接在終端機操作整個 repo，不只是讀檔案，還能執行指令、跑測試、用 grep 或搜尋工具追蹤一個函式在整個專案裡所有被呼叫的地方。

實測中，Claude Code 在「這個 API 端點新增了一個欄位，但呼叫方的三個地方有兩個沒有更新型別」這種需要跨檔案追蹤的場景表現最好，因為它會主動去搜尋相關檔案，而不是只看你貼給它的那一段。另外它可以直接執行測試指令，確認修改後測試是否還會過，這是前兩者做不到的。缺點是操作門檻稍高，需要在終端機或 IDE 整合環境下使用，不像 Copilot 那樣開箱即用。

比較表

面向 GitHub Copilot Cursor Claude Code
整合方式 GitHub PR 自動觸發 IDE 內手動操作 終端機 / CLI
上下文範圍 單一 diff 為主 整個檔案、可選多檔 整個 repo，可主動搜尋
能否跑測試 不行 不行（需另外操作終端） 可以直接執行
跨檔案依賴追蹤 弱 中等 強
上手難度 低 中 中高
適合場景 快速抓明顯問題、自動掛在 PR 需要看整包 diff 的中大型改動 跨服務、跨檔案的複雜變更

三者不是互斥關係。不少團隊的做法是 Copilot 做第一層自動掃描，遇到複雜的跨檔案改動再用 Claude Code 做深入分析。

實際 Prompt 範例

Code Review 的品質很大程度取決於 Prompt 給的方向夠不夠具體。以下是幾個實測有效的範例。

安全導向的 Review：

Review this code for security vulnerabilities. Focus on:
- Input validation
- SQL injection
- XSS
- Hardcoded credentials
- Path traversal
- Missing authorization checks

For each issue found, explain the attack scenario and provide the fixed code.

針對商業邏輯一致性的 Review（適合 Claude Code 這種能讀整個 repo 的工具）：

這個 PR 修改了訂單退款的邏輯（見 diff）。
請幫我做以下檢查：
1. 搜尋整個 repo 裡所有呼叫退款相關函式的地方，確認呼叫方的參數有沒有跟著更新
2. 確認退款金額計算是否可能出現負數或超過原訂單金額
3. 確認這個改動有沒有影響到現有的單元測試，如果有，跑一次測試確認結果

針對程式碼品質的 Review：

請 review 這段程式碼的可維護性，重點看：
- 函式長度是否超過 50 行，如果超過建議怎麼拆
- 是否有重複邏輯可以抽成共用函式
- 命名是否符合專案既有慣例（參考同目錄下其他檔案的命名方式）
- 錯誤處理是否完整（API 呼叫、檔案操作、外部服務呼叫）

實測心得是，給越具體的檢查項目，AI 遺漏的問題越少。只寫「幫我 review 這段程式碼」得到的回饋通常很籠統，指定具體類別（SQL Injection、XSS、硬編碼密鑰）才會讓 AI 針對性地檢查。

用 AI 做 Code Review 的安全風險

把 AI 導入 Code Review 流程，本身也帶來新的資安考量，這部分很多團隊容易忽略。

程式碼外流風險。把整份 PR 的程式碼貼給雲端 AI 服務做分析，等於把你的程式碼傳到第三方伺服器。如果你的專案是客戶專屬、含商業機密或受合約保密條款約束，這件事需要先確認公司的資安政策和 AI 服務商的資料處理條款（是否會被用來訓練模型、資料保留多久）。企業版方案（例如 GitHub Copilot Business、Claude 的企業方案）通常會承諾不把輸入資料用於訓練，但條款細節每家不同，導入前要看清楚。

Prompt 裡意外夾帶敏密資訊。工程師常見的習慣是把整段錯誤訊息或設定檔複製貼上到 Prompt 裡尋求協助，這段內容裡可能夾帶 API Key、資料庫連線字串、內部網域名稱。這些一旦貼進去，就已經送到第三方伺服器，無法收回。養成貼上前先掃一眼有沒有敏感字串的習慣。

過度信任 AI 的結論。AI 說「這段程式碼沒有問題」不等於真的沒有問題，只代表它在目前的上下文裡沒有發現問題。前面提過 AI 對商業邏輯和跨系統問題的判斷力有限，把 AI 的「通過」當成品質保證，是最常見也最危險的誤用方式。

自動合併風險。有些團隊把 AI Review 通過設成 PR 自動合併的條件之一，這等於讓 AI 的判斷直接影響上線流程。建議 AI Review 只作為輔助意見，關鍵路徑的程式碼（權限、金流、個資處理）仍需要人類 Reviewer 核准。

Code Review 檢查清單

把 AI 抓到的建議和人工複核結合，實務上可以用這份清單：

  • 有沒有使用者輸入直接拼進 SQL、Shell 指令或檔案路徑
  • 有沒有硬編碼的密碼、Token、API Key（就算只是測試用也不行）
  • 輸出到前端的內容有沒有做跳脫處理，防止 XSS
  • 敏感操作（刪除、修改金額、變更權限）前有沒有做授權檢查
  • 錯誤訊息有沒有洩漏內部細節（Stack Trace、資料庫結構）給使用者
  • 新增的第三方套件是否來自可信來源，版本是否鎖定
  • 這個改動是否符合原始需求（AI 判斷不了，需要人工對照 PR 描述）
  • 是否有對應的測試，測試是否涵蓋邊界情況
  • 效能敏感的路徑（高頻呼叫的 API、大量資料的查詢）是否有做過壓力測試或至少評估過複雜度

整合進現有 PR 流程

實務上常見的做法分三層。

第一層是自動化掃描。在 CI 流程裡加入 Copilot 的 PR Review 或串接 Semgrep 這類靜態分析工具，PR 一開就自動跑，結果直接留言在 PR 上。這一層負責抓語法問題和常見的安全模式，門檻低、速度快。

第二層是開發者自查。工程師在提交 PR 前，先用 Cursor 或 Claude Code 對自己的改動做一次 Review，用前面提到的安全導向 Prompt 檢查一輪，把明顯的問題在送審前就修掉，減少來回討論的次數。

第三層是人工審核。人類 Reviewer 專注在 AI 做不好的部分：這個改動是否符合需求、架構決策是否合理、跨團隊的影響有沒有考慮到。人工審核時可以直接參考前兩層留下的自動化意見，不需要重新檢查語法層級的問題，把精力放在判斷力需要的地方。

這個分工的重點是讓 AI 處理量大但規則清楚的檢查，人類處理需要脈絡判斷的部分，而不是用 AI 取代人工審核。

安全與限制

AI Code Review 不是萬能的檢查機制，使用時要記得幾個限制。

它只看得到你給它的範圍。如果只餵 diff，它看不到專案整體架構；如果只餵單一檔案，它看不到跨檔案的依賴關係。給的上下文越完整，判斷越準確，但上下文越大也代表越多程式碼被送到 AI 服務。

它會有幻覺。AI 有可能自信地指出一個不存在的問題，或是給出看起來合理但實際上錯誤的修正建議。任何 AI 給的修正都需要人工確認邏輯正確，不能直接複製貼上就合併。

它對新框架和內部工具的理解有限。如果你的專案用了自己開發的內部框架或比較新的技術（模型訓練資料截止日之後才出現的），AI 可能不熟悉正確的用法，給出的建議可能不符合框架的最佳實踐。

不要把 AI Review 通過當成安全稽核完成的證明。如果你的系統需要通過正式的資安稽核或滲透測試，AI Code Review 只能算是開發階段的輔助檢查，不能取代專業的資安測試流程。

知識檢測

讀完文章後，測試一下你對這個主題的理解。

常見問題

小團隊需要導入 AI Code Review 嗎？

如果團隊沒有專職的資安人員，AI Code Review 是一個低成本的第一道防線，至少能抓到明顯的漏洞模式（SQL Injection、硬編碼密鑰）。但不建議完全依賴它，關鍵程式碼還是需要有經驗的工程師複核。

GitHub Copilot、Cursor、Claude Code 只能選一個嗎？

不用。實務上可以並用，例如用 Copilot 做自動化的第一層掃描，複雜的改動再用 Claude Code 深入分析跨檔案的影響。差別在於使用情境，不是互斥的選擇。

AI Review 通過後是不是就可以直接合併？

不建議。AI 的判斷有限制，尤其是商業邏輯和架構層面的問題它看不出來。AI Review 通過應該視為「明顯問題已排除」，不是「這段程式碼完全沒問題」，關鍵路徑仍需要人工核准再合併。

用 AI Code Review 會不會洩漏公司程式碼？

有這個風險，特別是使用雲端版本的工具。導入前要確認你用的方案是否承諾不將輸入資料用於模型訓練，以及資料保留政策。含機密或受保密條款約束的專案，建議先跟資安或法務部門確認公司政策，必要時選擇企業方案或地端部署的選項。

免費版工具的 Code Review 能力和付費版差多少？

免費版通常在上下文長度、每日使用次數、能不能存取整個 repo 上有限制。以 Code Review 來說，上下文範圍直接影響判斷準確度，如果團隊經常處理跨檔案的複雜改動，付費版的效益會比較明顯。

相關文章

參考資料