怎麼做具備程式碼庫知識的 AI PR 審查器
這篇教你把團隊規則寫進倉庫，做出能讀懂程式碼庫脈絡的 AI PR 審查器。
這篇教你把團隊規則寫進倉庫，做出能讀懂程式碼庫脈絡的 AI PR 審查器。
這篇給技術主管、資深工程師和平台團隊看。你會一路做出一套可重複的 AI PR 審查流程，讓它先讀懂專案規則，再檢查變更差異，最後抓出你們團隊最常漏掉的審查問題。
照做完，你會得到一個具名、可執行、可回饋的審查系統，而不是只會泛泛建議的聊天機器人。這套做法可搭配 Claude Code、Cursor、Cline 或 GitHub Copilot 使用，重點是把團隊記憶放回倉庫裡。
開始之前
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
- 一個可存取目標儲存庫的 GitHub 帳號。
- 一個 AI 編碼工具帳號，例如 Claude Code、Cursor、Cline 或 GitHub Copilot。
- Node 20+，如果你要在本機腳本化審查命令。
- Git 2.40+，並且已完成基本設定。
- 一個已有慣例文件、ADR 或架構筆記的專案。
- 可在倉庫根目錄新增 AGENTS.md 或 CLAUDE.md 的權限。
Step 1: 蒐集審查漏網規則
目的是先把人類常常晚才抓到的錯誤整理出來，因為這些就是 AI 審查器最先要學的規則。請找出重複出現的問題，例如舊 middleware 路徑、重複元件、層級違規，或該用 enum 卻寫成字串常值的地方。
把每個問題寫成一句可檢查的短規則，再依領域分組，例如 auth、UI、backend layering、命名或 migration 行為。這份清單就是後續指令與文件的來源。
驗收標準：你應該看到一份 5 到 10 條的審查規則清單，而且每條都來自你自己的程式碼庫，而不是通用風格建議。
Step 2: 建立倉庫級記憶文件
目的是把團隊知識放進 AI 在審查前就能讀到的檔案。若你使用 Claude，先看 Claude Code 文件 與 Claude Code GitHub repo，然後在倉庫根目錄建立 AGENTS.md 或 CLAUDE.md，用精簡條列寫下規則。
# AGENTS.md
- 新 API endpoint 必須使用 v2 auth middleware。
- 不要從 /hooks 複製共享 hooks。
- Controllers 不可直接 import repo functions。
- 建立新 UI 元件前先檢查 /design-system。
- 狀態判斷要用 enums，不要用字串常值。語句要具體，而且要能被驗證。只要某條規則無法產生明確的 yes-or-no 審查意見，就改寫到可以檢查為止。
驗收標準：你應該能打開這個檔案，逐條指出每一條都是 AI 在審查時可以直接檢查的規則。
Step 3: 補上服務層指令文件
目的是讓審查器理解各服務的例外與局部慣例，而不是靠整個倉庫去猜。請在它所管理的程式旁邊新增服務層文件，例如 backend 服務資料夾內的說明，或 UI 套件中的元件備註。
例如，在某個服務目錄加入短文件，說清楚哪條 auth 路徑是標準、哪一層負責 orchestration，以及哪些共享元件目錄要先檢查。migration 規則與架構邊界也應該放在這裡。
驗收標準：你應該能打開一個服務資料夾，並看到一份只描述該區域規則的本地指令文件。
Step 4: 寫出可重複的審查命令
目的是讓 AI 只做一次可重複、唯讀的程式碼庫感知審查。這個命令要讀入倉庫規則、檢查 diff，並且只在違反規則或與既有模式衝突時輸出發現。
如果你要寫本機腳本，保持簡單即可：傳入 diff、包含相關記憶文件，並要求輸出 file、line、issue 和 rationale。審查階段不要讓模型改寫程式碼。
node scripts/review-pr.js --base origin/main --head HEAD驗收標準：你應該拿到一份具體審查結果，能指出檔案與行號，而不是只有稱讚或空泛建議。
Step 5: 用真實 PR 跑一次審查器
目的是拿一個真實 PR 來測試，最好是會碰到敏感區域的變更，例如 auth、共享 UI 或 backend layering。請選一個近期變更，而且人類審查者已經很熟的案例，這樣你才能對照 AI 輸出與真實團隊規則。
檢查審查器是否能抓到資深工程師憑記憶會看到的問題。如果漏掉重要項目，就把缺少的規則加回 AGENTS.md 或對應的服務文件，然後再跑一次。
驗收標準：你應該看到至少一則有意義、而且帶有團隊脈絡的評論，這種評論一般的審查器很可能抓不到。
Step 6: 用人類回饋收斂規則
目的是讓審查器每次被人類修正後都變得更好。每次真實 PR 審查後，請記錄誤報、漏報，以及哪些規則太模糊，無法提供幫助。
接著更新記憶文件，讓下一次審查更準。真正的價值在於累積效應：每次人類修正都會變成審查器的永久上下文。
驗收標準：你應該看到重複評論變少，而且同一類錯誤在第一輪就更常被抓到。
| 指標 | 基準／優化前 | 結果／優化後 |
|---|---|---|
| 審查瓶頸 | 只有資深審查者記得團隊規則 | 規則已移入倉庫文件，AI 可直接讀取 |
| 通用審查品質 | 常漏掉程式碼庫專屬規則 | 能抓到 auth、層級與共享元件違規 |
| 審查一致性 | 取決於當下誰有空 | 用固定命令與穩定指令重複執行 |
常見錯誤
- 規則寫得太大而無法檢查。修法：改寫成可驗證句子，例如「controllers 不可直接 import repo functions」。
- 重要指引只放在聊天紀錄。修法：移到 AGENTS.md、CLAUDE.md，或放進服務層指令文件，並保留在倉庫內。
- 讓審查器在審查時改寫程式。修法：把命令維持唯讀，只輸出發現，不進入實作流程。
接下來可以看什麼
當這個審查器已經能在單一儲存庫穩定運作後，可以把同一套模式擴展到其他服務，再加入 PR 模板、ADR 與自動化檢查，把原本靠口耳相傳的規則變成可持續執行的流程。