如何為 Pull Request 加上 AI Code Review
這篇教你把 AI code review 接到 Pull Request，讓它先抓出常見 bug，再交給人工審查收尾。
這篇教你把 AI code review 接到 Pull Request，讓它先抓出常見 bug，再交給人工審查收尾。
這篇給維護 GitHub、GitLab 或 Bitbucket 專案的開發者和團隊管理者看。照著做完，你會得到一套能在 PR 開啟時自動留言的 AI 審查流程，並且能依團隊規範調整它的判斷標準。
這不是概念介紹，而是實作指南。你會完成工具選型、PR 觸發器、政策上下文、雜訊調整與成效驗證，最後留下可持續維護的審查工作流。
開始之前
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
- 一個 GitHub、GitLab 或 Bitbucket 帳號，且對至少一個 repository 有管理權限。
- 一個 AI code review 工具帳號，或可自架的模型 endpoint。
- 對應供應商的 API key 或 OAuth 憑證。
- Node 20+ 或 Python 3.11+，用於本機腳本與 webhook 檢查。
- 一個正在運作、會產生 pull request 的 repository。
- 一份團隊 style guide 或 security policy。
官方文件先看 [GitHub Pull Requests docs](https://docs.github.com/en/pull-requests)，再看你選用的 review 工具 GitHub repository，例如 [OpenAI GitHub](https://github.com/openai) 或供應商專案頁。
Step 1: 選定 review engine
這一步的產出是「Review Engine Decision」。你要先決定使用託管服務，還是自架模型端點，避免後面接好流程才發現權限或資料保留不合規。
比較三件事：repository 存取方式、資料保留政策、是否能讀完整 repo 而不只看 diff。能拿到完整上下文的工具，較容易抓到跨檔案錯誤與重複實作。
驗收標準：你應該看到一個可登入的 vendor dashboard，或一個能成功回應的本機 endpoint，而且它能列出目標 repository。
Step 2: 連接 Pull Request 觸發器
這一步的產出是「PR Review Workflow」。目標是讓 AI 在 PR 開啟、更新、重新開啟時自動執行，先於人工分派完成初步審查。
name: ai-review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run AI review
run: ./ai-review --repo "$GITHUB_REPOSITORY" --pr "$PR_NUMBER"把這個流程放在人工指派之前，能先擋掉明顯的 null check、測試缺口與重複邏輯，讓資深工程師把時間留給架構與風險判斷。
驗收標準：你應該看到一則自動留言或 status check，在測試 PR 開啟後幾分鐘內出現。
Step 3: 載入團隊政策與程式上下文
這一步的產出是「Policy Pack」。把 style guide、安全規則、測試要求與專案慣例餵給審查工具，讓它依照你們的標準，而不是通用建議來評論。
請加入命名規則、錯誤處理、logging、依賴使用與禁用模式。如果有高風險路徑，像 auth、payments 或 infrastructure，也要明確要求模型把這些變更升級給人工審查。
驗收標準：你應該看到評論直接引用你們的規則，例如缺少測試、錯誤處理不一致，或使用了被禁用的 API。
Step 4: 調整訊號與雜訊比例
這一步的產出是「Noise Control Profile」。先只看變更檔案，再視需要擴展到相關檔案與測試；一般修補用小模型，複雜差異再交給較大的模型。
啟用真正缺陷的 inline comment，降低純風格建議的權重。如果工具支援 severity，請把安全與正確性問題設為 blocking，將輕微建議保留為 informational。
驗收標準：你應該看到重複性評論變少，而人類 reviewer 會想直接採用的可行建議變多。
Step 5: 量測審查品質與成本
這一步的產出是「Review Scorecard」。你需要追蹤 merge 時間、PR 前被抓出的缺陷數、false positive 比例，以及每個 repository 或每個 PR 的成本。
每週抽樣檢查被接受與被拒絕的建議，還有漏掉的 bug。若流程有效，你應該看到 review 週期縮短，且進入 production 的缺陷變少。
驗收標準：你應該看到 PR 等待時間下降，並且在第一次調整後，false positive 比例維持穩定或持續下降。
| 指標 | 基準／優化前 | 結果／優化後 |
|---|---|---|
| Time to merge | Human-only review | 20% 到 40% 更快的 AI-first review |
| Developer productivity on common tasks | Baseline coding workflow | GitHub Copilot research 顯示提升超過 50% |
| Defect escape rate | Manual review only | AI review 先跑時通常更低 |
常見錯誤
- 讓 AI 單獨批准高風險變更。修法：security、payments、auth、infrastructure 一律要求 human owner。
- 只看 diff，不看 repo context。修法：啟用 full-repository retrieval，或至少把相關檔案與測試一起送進上下文。
- 忽略隱私與保留設定。修法：確認 code 是否會被儲存、記錄或用於訓練；若政策要求，改用 self-hosted。
接下來可以看什麼
當 PR 審查流程穩定後，可以把同一套 policy pack 延伸到 test generation、security scanning 與 architecture rules，讓單次審查覆蓋更多風險。