5 個讓 AI 程式碼審查少漏看的設計
5 個設計重點看 Open Code Review 如何把漏看率降下來，並在阿里巴巴內部找出 100 萬個缺陷。
Open Code Review 用規則和工程流程讓 AI 程式碼審查更穩定，也更少漏看問題。
看完這 5 個設計點，你可以判斷一套 AI code review 工具到底是「會聊天」還是「真的能抓 bug」。Open Code Review 的重點不是換更大的模型，而是用可預測的流程把審查結果拉回一致。
| 項目 | 規格 A | 規格 B |
|---|---|---|
| Open Code Review | Token 使用量 | 約為既有 agents 的 1/5 |
| Open Code Review | 內部採用規模 | 20,000+ 員工 |
| Open Code Review | 已發現缺陷 | 1,000,000+ |
1. Deterministic file selection
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
它先解決最常見的漏看來源：大型變更只看了一部分檔案。Alibaba 的做法不是加長 prompt，而是用確定性的流程決定哪些檔案一定要進入審查。
這種設計對多檔案 patch 特別重要，因為 bug 往往藏在依賴鏈或相鄰模組裡。當審查範圍先被工程規則固定下來，模型就比較不會看漏。
- 多檔案變更覆蓋更完整
- 不太依賴 prompt 寫法
- 審查範圍更可重現
2. Rule matching that stays fixed
第二個關鍵是規則匹配。Alibaba 認為只靠語言模型來判斷，審查標準容易飄，所以 Open Code Review 先用工程規則決定哪些檢查要套用。
這讓團隊能穩定套用已知風險，例如空值、執行緒安全、XSS、SQL injection。對多團隊、多倉庫環境來說，這比每次重新描述標準更可靠。
Examples of built-in rule areas:
- Null pointer exceptions
- Thread safety
- XSS
- SQL injection3. Line-level comments with fewer wrong references
很多 AI 審查工具不是沒抓到問題，而是標錯位置。Open Code Review 盡量輸出精準的行級註解，讓開發者能直接定位到出問題的檔案與行號。
這種精準度會直接影響修正效率。提醒對了但位置錯了，通常還是要來回確認；位置準了，review 到修正的時間就會短很多。
- 檔案引用更清楚
- 回饋更容易直接處理
- 減少作者與審查者來回溝通
4. Model flexibility without losing control
Open Code Review 可以搭配不同 AI 模型，包括 Anthropic 和 OpenAI 相容方案。Alibaba 想強調的是，模型可以換，但審查邏輯不必跟著變。
這對想長期維護工具鏈的團隊很實用。未來若要換模型或混用模型，只要規則層還在，審查行為就不至於整個失控。
5. Lower token use at Alibaba scale
成本也是這套系統能落地的原因之一。Alibaba 表示，Open Code Review 的 token 用量可降到既有 agents 的約五分之一，對每天大量跑審查的團隊差異很大。
更關鍵的是規模數字：它已在阿里巴巴內部被 20,000+ 員工使用，並累積找出 1,000,000+ 個缺陷。這表示它不是概念驗證，而是已經在大組織中運作。
- 20,000+ 內部使用者
- 1,000,000+ 缺陷發現
- Token 用量約降到 20%
哪種適合你
如果你的團隊在意的是一致性、可控性和大型 codebase 的覆蓋率，Open Code Review 這種「規則先行、模型後補」的做法最值得參考。它比較像審查系統，不像聊天機器人。
如果你只需要偶爾做輕量提示，簡單的 AI reviewer 可能就夠了；但只要你開始擔心漏看、標錯位置、或不同人審出不同結果，這套思路就會更適合。