Open Code Review 完整教學 2026：阿里巴巴開源的 AI 程式碼審查 CLI，34K 星、Token 只要 Claude Code 的 1/9（安裝、Agent 外掛、CI/CD 實戰）

Open Code Review（指令 ocr）是阿里巴巴把內部跑了兩年、月活 2 萬人的 AI 程式碼審查助手上線開源的 CLI 工具：它用「確定性工程 × Agent」混合架構，讀 git diff 後產生行級精準的審查意見，官方 benchmark 顯示在相同底層模型下精準度與 F1 都優於 Claude Code，token 消耗只要約 1/9，GitHub 34,425 星、Apache-2.0 授權。

如果你現在的日常是「AI 寫的 code 我不敢直接 merge、自己看又看不完」，那這篇就是為你寫的。以下從背景、架構、benchmark、安裝到 CI/CD 實戰依序講完，每個步驟都可以直接照著跑。

為什麼 2026 年大家都在找「審 Code 的工具」？

阿里團隊在開源復盤文中引用 Faros AI《The Acceleration Whiplash》報告（4,000 個團隊、22,000 名開發者、兩年遙測資料），數據很刺眼：

也就是說：產能上去了，品質兜不住。阿里自己的解法是內部先做一套 AI 程式碼審查系統，跑了兩年、20,000 月活使用者，官方數字是建議採納率 30%+、誤報率低於 5%、合併進基線的有效建議中近 8 成來自 AI。2026 年 5 月 18 日他們把這套系統重寫成 Go CLI 開源，就是 Open Code Review。

專案速覽

開源兩個月的復盤數據也值得一看：從 v1.0.0 到 v1.8.0 共 89 個正式版本、81 位貢獻者、一百多個 feature commit（其中 67 個來自外部 PR）；內建 provider 從 3 個長到 14 個（含 Ollama 本地推論、LiteLLM 閘道、Eden AI），支援 OpenAI／Anthropic／OpenAI Responses 三種協議。

核心設計：確定性工程 × Agent 的混合架構

這是 Open Code Review 跟「叫 Claude Code 幫我看一下」最大的差別。官方點出通用 Agent 審 Code 的三個痛點：

1. 覆蓋不全 — 變更量大時 Agent 會「偷懶」，只審部分檔案。
2. 位置飄移 — 回報的問題位置、行號跟實際程式碼對不上。
3. 品質不穩 — 純自然語言驅動的 Skill 難以除錯，換個 prompt 寫法結果差很多。

根本原因是：純語言驅動的架構，對「審查流程」沒有任何硬約束。OCR 的解法是把流程拆成兩半——不能出錯的步驟交給工程邏輯，需要動態判斷的才交給 LLM：

flowchart TD
    A["ocr review"] --> B["Diff 產出 工作區 Commit 分支區間"]
    B --> C["五重門檔案過濾 剔除 binary 排除路徑 不支援副檔名"]
    C --> D["語意檔案分組 每組最多 10 檔"]
    D --> E["平行子代理 先 Plan 再 Main 迴圈"]
    E --> F["定位與反思模組修正評論位置與內容"]
    F --> G["輸出 text JSON SARIF"]

具體分工是這樣：

確定性工程負責（不出錯的保證）

• 精準檔案選擇：五重門過濾（binary → 使用者排除 → 使用者包含 → 副檔名白名單 → 內建測試檔排除），決定哪些檔案該審、哪些該丟。vendor/、node_modules/、target/ 這類噪聲目錄在 diff provider 層就被剔除，根本不會進到過濾器。
• 智慧檔案捆綁：先做一次「只送檔案 metadata（路徑、狀態、+/- 行數），不送 diff 內容」的便宜 LLM 呼叫，把語意相關的檔案聚成一組（例如 message_en.properties 與 message_zh.properties、介面與實作、handler 與 service 與測試）。每組最多 10 個檔案，各自在獨立 context 中跑一個子代理——大變更量下更穩定，也天然支援並行（預設 --concurrency 8）。
• 細粒度規則匹配：依檔案特性套用對應的審查規則（內建涵蓋 NPE、執行緒安全、XSS、SQL Injection 等，並提供 50 多種副檔名／語言的專屬規則文件），用模板引擎匹配而非靠 prompt 描述。
• 外部定位與反思模組：獨立的評論定位與反思模組，專門修正 AI 回饋的「位置準確度」與「內容準確度」。

Agent 負責（動態決策）

• 為程式碼審查深度調校過的 prompt 模板（效果更好、token 更省）。
• 從大規模生產資料的工具呼叫軌跡蒸餾出來的專用工具集，而非通用工具箱。

除了審 diff，OCR 還有 ocr scan 可以整檔掃描——用來稽核陌生的程式庫、或根本沒有 diff 的目錄。

Benchmark：贏在哪、輸在哪（務必看清楚）

官方用 AACR-Bench 做實測：50 個熱門開源 repo、200 個真實 PR、10 種程式語言，由 80 位以上資深工程師交叉標註出 1,505 個 ground-truth 問題。

請注意那個「Recall 較低」：官方在 README 裡明講這是刻意用召回率換精準度，寧可少報也不要製造噪音讓你 triage。如果你的場景需要「寧可錯殺不可放過」的全覆蓋，OCR 不會單獨滿足你，適合當成第一道防線、而不是唯一防線。

安裝與第一次審查

前置需求

• Git ≥ 2.41（OCR 靠 git 做 diff、搜尋與 repo 操作）
• Node.js ≥ 18
• 一組 LLM API key（用「委託模式」時不需要）

第 1 步：安裝 CLI

npm install -g @alibaba-group/open-code-review
ocr version

其他安裝方式（安裝腳本、GitHub Release 二進位檔、從原始碼編譯）見官方安裝文件。

第 2 步：設定 LLM provider

ocr config provider   # 選內建或自訂 provider、填 API key、挑 model
ocr config model      # 之後想換模型
ocr llm test          # 測試端點連線

互動式 TUI 會帶你選 provider、填 key、挑 model，存檔後自動跑一次連線測試。在 CI 或無 TUI 環境改用非互動指令寫入同一份設定：

ocr config set provider                    anthropic
ocr config set model                       claude-opus-4-6
ocr config set providers.anthropic.api_key sk-ant-xxxxxxxxxx

設定檔位置是 ~/.opencodereview/config.json。內建 14 個 provider，要接自己的自架模型（Ollama、LiteLLM 等）也可以。

第 3 步：跑第一次審查

cd your-project

# 工作區模式 —— 審 staged + unstaged + untracked 變更（不加參數就是它）
ocr review

# 分支區間 —— 審 feature-branch 從 main 分岔後的變更（merge-base 模式）
ocr review --from main --to feature-branch

# 單一 commit
ocr review --commit abc123

# 整檔掃描 —— 不需 git 歷史
ocr scan
ocr scan --path internal/agent

想先看「它打算審哪些檔案」而不花 token：

ocr review --preview
ocr review -c abc123 --preview

五種模式怎麼選？

中斷了也不用重跑：ocr session list 看 session 清單，再用 --resume <session-id> 續跑。

輸出格式與 CI/CD 整合

三種輸出格式

搭配 --audience agent 會把人性化進度條全部關掉，讓 stdout 只剩乾淨的 JSON（進度訊息改走 stderr）：

ocr review --format json --audience agent > review.json

GitHub Actions：最短路徑

官方提供可重用的 composite action，貼進 workflow 就能用：

- uses: alibaba/open-code-review@main
  with:
    llm_url: ${{ secrets.OCR_LLM_URL }}
    llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
    llm_model: ${{ vars.OCR_LLM_MODEL }}
    llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }}
    effort: high
    max_tokens_budget: '10000000'
    stream_progress: 'true'

幾個實用 input：

• effort：low／medium／high。覺得審得太淺時，high 是最便宜的品質槓桿；只想快速掃一遍就用 low，成本大約少一半。
• max_tokens_budget：輸入＋輸出的 token 總上限，每輪 LLM 呼叫前檢查，超支的子任務會拿到最後一輪提交發現後停止派發，超支檔案記為 failed(budget)，已產生的結果仍會發布、流程以 0 結束。
• stream_progress：把 [ocr] 即時進度灌進 workflow log。

想在 CI 裡帶入 PR 標題當背景脈絡（--background 是效果最顯著的單一參數）：

- name: Run OCR review
  env:
    PR_TITLE: ${{ github.event.pull_request.title }}
    BASE_REF: ${{ github.base_ref }}
    HEAD_REF: ${{ github.head_ref }}
  run: |
    ocr review \
      --background "$PR_TITLE" \
      --from "origin/$BASE_REF" \
      --to "origin/$HEAD_REF" \
      --format json --audience agent

⚠️ 安全性注意：PR 可控的值一定要經過 env: 傳入，不要把 ${{ }} 直接插進 run:——GitHub 是在 shell 解析之前做文字替換，含 shell 元字符的 PR 標題或分支名會在你的 runner 上被執行。

其他 CI 平台也沒被漏掉：GitLab CI、Gerrit（Jenkins）、Bitbucket Pipelines、阿里雲 Codeup、GitFlic 都有現成範例放在 repo 的 examples/ 目錄。要做程式碼掃描報告就配 SARIF：

ocr review --format sarif --audience agent > results.sarif

再接 github/codeql-action/upload-sarif@v3 上傳即可（--preview 不支援 SARIF，因為預覽沒有完整發現）。

整合進你原本的 AI 開發流程

OCR 的定位不是「取代你的 Agent」，而是「補上它最弱的那一環」。三種接法：

1. Agent 外掛（推薦起手式）

2. 委託模式（Delegation Mode）：省下第二份 API key

ocr delegate preview 與 ocr delegate rule 讓 OCR 只負責檔案選擇與規則解析，實際審查交給你的宿主 Agent 用它自己的訂閱額度跑。對已經付了 Claude Code／Codex 訂閱的人來說，這是零額外成本的做法。

3. MCP 擴充：讓審查器看見 repo 以外的世界

OCR 自己可以當 MCP 客戶端，把外部 MCP server 的工具註冊給審查 Agent 使用，和內建的 file_read、code_search 並列：

# 本地 stdio server
ocr config set mcp_servers.docs.command npx
ocr config set mcp_servers.docs.args '["-y", "@acme/docs-mcp-server"]'
ocr config set mcp_servers.docs.tools '["search_docs", "get_page"]'

# 遠端 Streamable HTTP server
ocr config set mcp_servers.search.type remote
ocr config set mcp_servers.search.url https://mcp.example.com/mcp

典型用途：拉 Jira／GitHub issue 核對變更是否符合需求、拉內部 API 文件讓評論引用團隊真正約定、把 linter 或 schema 驗證器暴露成工具。

⚠️ 資料邊界提醒：MCP server 設定是使用者層級（所有 repo 生效），設定完成後 Agent 呼叫工具不會逐次徵求同意，查詢字串與 URL 會離開你的機器。官方文件明講：只在允許對外請求的場景開，且不要在請求中帶密鑰、私有程式碼或內網 URL。

4. 可觀測與檢視

• ocr viewer：開本機 Web UI（localhost:5483）瀏覽、回放歷史審查 session，可以把評論標記為已修或忽略。
• ocr session compare <before> <after>：比對兩次審查的發現——新增、持續、已解決、未審。
• OpenTelemetry 整合：把 trace 送到你公司既有的觀測系統。

常見陷阱與實務建議

小結：它適合誰？

• 一個人寫、AI 幫你寫的專案：ocr review 當 pre-commit hook，commit 前先過一輪，成本只要通用 Agent 的 1/9。
• 小團隊的 PR 守門員：GitHub Actions ＋ --background "$PR_TITLE"，讓審查意見有需求脈絡。
• 企業內部：資料不出本地（只給框架、LLM 自己選）、可接 Ollama／LiteLLM 自架模型，這在金融與製造業是硬需求。
• 已經在用 Claude Code／Codex 的人：走委託模式，把 OCR 當「便宜的檔案選擇與規則引擎」，用你的訂閱額度審，邊際成本接近零。

最值得學的其實不是工具本身，而是它示範的架構思路：不能出錯的步驟用工程邏輯做硬約束，需要判斷的部分才交給模型。這個「確定性 × Agent」的分工，2026 年正在變成 AI 工具設計的通用範式——你手上其他的 Agent 工作流，多半也可以照這個比例重新切一次。

延伸閱讀

• Agent Skills 完整教學：Addy Osmani 開源 8.5 萬星專案，讓 Claude Code、Cursor 自動遵循工程紀律——用 Skill 補上 Agent 的工程紀律。
• MCP 完整教學 2026：什麼是 Model Context Protocol？從架構、三大原語到 Python 實作第一個 MCP Server——想自己寫 MCP server 給 OCR 用，先看這篇。
• Orca 教學：AI 程式碼代理協調器完全指南 — 同時跑 Codex、Claude Code、Hermes 的多工神器——多代理協作的工作流安排。
• Claude Code Auto Mode 預設開啟：8 月 14 日起 AI 編碼代理自動執行時代來臨——當代理自己動手改 code，審查就變成唯一防線。

參考來源

• GitHub：alibaba/open-code-review
• 官方文件：open-codereview.ai
• 官方復盤文：連續五天登上 GitHub Trending 首頁的思考（2026-07-29）
• AACR-Bench 資料集（Hugging Face）
• 官方文件：CI/CD 整合
• 官方文件：MCP 伺服器