OpenCodeReview AI Code Review 實測：自動檢查 Git Diff、Bug、安全漏洞和程式碼品質，真實專案能發現多少問題？

先對齊：OpenCodeReview 到底審什麼

中文圈常把它和 OpenCode（opencode serve 那種編碼 Agent）混成一個詞。不是同一件事。OpenCodeReview 是阿里內部用了兩年的 AI 程式碼審查助手開源出來的 CLI：讀 Git 變更，輸出結構化行級評論，內建多語言規則（空指標、執行緒安全、XSS、SQL 注入等），模型端點相容 OpenAI 與 Anthropic。官方倉庫見 alibaba/open-code-review，文件入口在 open-codereview.ai。

它解決的不是「再找一個會誇你好程式碼的機器人」。普通聊天模型只看見你貼進去的那一小段 diff，既不讀呼叫端，也不知道隔壁檔案有沒有同一把鎖。OpenCodeReview 的設計是確定性工程做分診，Agent 做深度：先決定哪些檔案該審、哪些該丟掉，再依檔案類型注入規則清單，最後讓 Agent 自己 file_read、搜倉庫、對照其它變更檔案。

站內已有一篇講 OpenCode 自託管時 4GB / 8GB / 16GB 怎麼選——那是編碼 Agent 的記憶體帳單。這篇只談 ocr review：自動檢查 Git Diff、Bug、安全漏洞和程式碼品質時，真實專案能發現多少問題。

官方口徑是：內部服務過數萬開發者、識別過數百萬缺陷。那是阿里規模下的累計數字，不是你下一個 PR 的承諾。你要的如果是「合併前多一雙眼睛」，它合適；你要的如果是「機器簽字就能上正式環境」，README 和這篇實測都不會幫你簽字。

它怎麼讀 Git Diff：三種審查模式

讀者搜「自動檢查 Git Diff」，通常只關心「我改了什麼」。CLI 把這件事拆成三種互斥模式，混用會直接報錯。完整旗標見 CLI Reference。

範圍模式算 merge-base，這一點比「把兩個分支硬 diff」更接近人審 PR 的方式：main 上後來合進來的無關提交不會灌進審查。GitHub Action 官方實作也是先算 merge-base，再跑 ocr review --from MERGE_BASE --to HEAD_SHA --format json，把行級評論貼回 PR。

還有第四條路：ocr scan。沒有有意義的 Git 歷史、或你要稽核一整棵不熟悉的目錄時，它審完整檔案而不是 diff。代價是 token 和雜訊都會上去。日常合併審查，先用 diff；接手遺產倉庫，再考慮 scan。

審查前一定要先跑 ocr review --preview。它只走過濾管線、不花模型錢，會告訴你每個檔案 will_review 還是因為副檔名、刪除、測試路徑被丟掉。我們實測時，一個帶圖片和 lockfile 的 PR 會先丟掉一半「看起來改了很多」的檔案——那些本來就不該送給 LLM。

五分鐘跑起來：安裝、配模型、preview

建議安裝是 npm 全域套件。也可以用官方 install.sh 或 GitHub Release 靜態二進位。Git 要 ≥ 2.41，因為 diff、搜程式碼、倉庫操作都走 Git。配好模型之前，ocr review 不會憑空工作（除非走 Delegation Mode，把審查交給你已經在用的編碼 Agent）。

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider          # 選內建或自訂端點，填 Key
ocr config model
ocr llm test                 # 不通就別往下燒 token

cd /path/to/your-repo
ocr review --preview         # 不花模型錢，看哪些檔案會進審查
ocr review --from main --to HEAD --format json --audience agent

設定落在 ~/.opencodereview/config.json。CI 裡用 ocr config set 寫 provider / model / api_key，或直接沿用既有的 ANTHROPIC_* / OCR_LLM_* 環境變數。評論語言用 ocr config set language 中文，不設則預設英文。專案規則可以提交 .opencodereview/rule.json；全域規則在家目錄，別把 Key 寫進倉庫。

npm 安裝預設會背景自動更新（大約 18 分鐘冷卻）。CI 映像裡請 export OCR_NO_UPDATE=1，並釘死版本號，避免週一和週五審出來的規則不是同一套。工作階段記錄在 ~/.opencodereview/sessions/，ocr viewer 預設開在 localhost:5483，用來回放某一次審查，而不是對外提供服務。

本機記憶體怎麼估，不要照搬那篇 OpenCode 自託管文。OpenCodeReview 的重活在 LLM API 和並發 Git 子行程，CLI 本身不常駐一套 LSP。--concurrency 預設 8。筆電合蓋、key 跟日常聊天搶同一把額度時，審查會半路斷；需要常開、可重現的 runner，比在出差電腦上賭一次 ocr review 更誠實。

真實專案實測：三個變更包發現了什麼

我們用同一套設定（OpenAI 相容協定、中等體量對話模型、系統規則 + 專案規則合併）對照了三類真實會進 PR 的變更，不是玩具倉庫裡的十行範例。每包先 --preview，再 ocr review --from --to --format json，人工把評論標成：必須改、應該改、風格/建議、誤報。數字是一次快照，換模型或換規則會漂，但類別比例比「總共幾條」更有用。

必須改（7 條）裡，安全 3、缺陷 4。安全側是：字串拼接查詢、未跳脫輸出進 HTML、以及一處把內部錯誤文字直接回給用戶端。缺陷側是：空值當物件用、並發寫 map 沒鎖、錯誤沒有 %w 包一層導致上層丟原因。這三類正好落在官方宣傳的規則集裡——NPE、執行緒安全、XSS、SQL 注入——不是模型「靈光一現」寫出來的散文。

應該改（6 條）多數是：逾時沒設、重試會把非冪等請求打兩遍、日誌裡帶了信箱或請求本文。人審也該提，但週五下午容易被「先合再說」壓掉。AI 的價值在這裡：它不累，也不看你臉色。

風格/建議（10 條）是最大的桶。命名、提前返回、某段可以抽函式。有用，但會稀釋訊號。不治理的話，團隊會在第三週開始把整段審查摺疊掉——這和業界對較吵的 PR 機器人抱怨同一病理：召回高、訊噪比掉。

誤報（4 條）很典型：把測試夾具裡的拼接 SQL 當成正式注入；把已經參數化的查詢再罵一遍；把 Go 1.22 之後已修復的迴圈變數問題又提一次。四條裡有三條，用 ocr review --preview 加一條排除測試目錄的專案規則就能消掉。別先怪模型，先看規則有沒有把測試檔送進去。

和官方文件裡的示例規模對得上：一次範圍審查常見是「9 個檔案、十幾條評論、一兩分鐘、兩萬 token 量級」。我們這三包合計大約這個量級的三倍，因為是三個獨立範圍，不是一個巨型 PR。單檔 diff 超過模型視窗約 80% 會被直接丟掉——超大產生檔、鎖檔、打包產物，preview 階段就該消失，不該出現在帳單上。

Bug、安全、品質：哪些抓得住、哪些抓不住

把 27 條按題目裡的四個詞切開，比只報「發現了多少問題」更接近你怎麼用它。

Agent 能讀完整檔案，所以比「只看綠色行」的審查強一檔。官方示例裡那條「map 寫入沒加鎖」就是典型：diff 只改了一行賦值，真正的問題在檔案上頭已經存在的共享狀態。純 diff 機器人經常放過；帶 file_read 的審查會把上下文拉進來。這也是它和「只看 PR 補丁的 Copilot Review」在宣傳上的差別——後者快、雜訊低，跨檔是弱項。

它抓不住的，我們刻意放進變更包裡對照過：錯誤的折扣計算公式、把新台幣當美元的欄位、以及「這個介面不該在未審核狀態可調」。這三處零評論。模型沒有你們的領域詞典，--background 把 PR 說明和驗收標準餵進去會好一點，但替代不了人審需求。

安全類評論要當線索，不當判決書。它指出「這裡在拼 SQL」，你還是要自己確認驅動、權限和資料分級。文章不會示範怎麼利用這些漏洞，只記錄審查器有沒有把風險行標出來。需要把 Agent 改檔的邊界也收緊時，對照站內 AI Agent 如何安全修改檔案——審查是唯讀的，編碼 Agent 才寫碟。

接到 CI：GitHub Actions、規則與誤報

本機跑通之後，團隊要的是 PR 上自動出現行級評論。官方 composite Action 會：檢出可信的 base（不是把 fork 的工作樹直接鋪開）、拉 head 的 git 物件、算 merge-base、跑 ocr review --format json、再透過 Pull Request Review API 貼行評和一條 sticky 摘要。觸發詞可以是 PR 開啟/同步，也可以是評論裡的 /open-code-review。

權限給最小集：contents: read，真要寫評論再開 pull-requests: write。模型 Key 進 Secrets，模型名進 Variables。Fork 預設拿不到倉庫 Secrets——這是保護，不是故障。不要為了「讓外部貢獻也能自動審」就把不信任的程式碼檢出來和 pull_request_target 拼在一起；那是洩密組合，不是整合技巧。GitHub 自己的加固說明見 Security hardening for GitHub Actions。

規則是四層：自訂 --rule、專案 .opencodereview/rule.json、全域家目錄、內建系統規則。用 ocr rules check path/to/File.java 看某一檔到底吃了哪一層。專案規則設 merge_system_rule: true，避免你寫了兩條「關注日誌」就把 Java 空指標清單整個蓋掉。排除測試、產生程式碼、vendor，比事後抱怨誤報便宜。

macOS 上要給 iOS / Xcode 變更做同一套審查，runner 本身比 ocr 更難養。自託管怎麼搭、怎麼驗收，走 GitHub Actions macOS 自託管 Runner；機器不睡、金鑰不跟筆電搶額度，審查才穩定。