Open Code Review 把 AI 審查變準

Alibaba 的 Open Code Review 把 AI code review 做成可重複、可定位到行號的流程。

我用 AI 做 code review 一陣子了，越用越火大。它很會講話，看到 diff 也會裝得很懂，但一碰到真的要抓 bug，就開始亂飄：行號對不上、檔案漏看、評論像是隔著霧玻璃瞄過去寫的。最煩的是，它不是完全沒用，而是會先讓你以為有用，等你真的拿去放進團隊流程，才發現每次輸出的可信度都在打折。

我想要的是能進 CI、能進 PR 流程、能被工程師當成第二雙眼睛的東西，不是三分鐘 demo。後來我看到 Alibaba 的 Open Code Review 介紹，才覺得這方向對了：不要再逼模型自己決定一切，而是把該精準的部分交給程式。這種拆法，我比較買單。

不要再把 reviewer 當聊天機器人

“A purely language-driven architecture lacks strong constraints on the review process.”

翻譯一下就是：如果你讓模型自己決定看哪裡、怎麼對位、要不要嚴格，它就會不穩。今天看得很仔細，明天就漏一半；這次 line number 對，下一次直接飛到別的地方。

我自己看過太多「請仔細 review 這段程式」的 prompt，結果模型一開始很像回事，diff 一大就開始縮水。這不是它壞掉，是它本來就不是拿來做精準定位的。語言模型擅長生成文字，不擅長保證審查流程的穩定性。你拿它當 reviewer，等於把最需要一致性的工作交給最不一致的元件。

Open Code Review 的第一個重點，就是把工作切成兩半：規則、範圍、檔案選擇、評論落點，交給 deterministic logic；理解內容、抓上下文、判斷風險，才交給 agent。這個切法很務實。我不想讓模型決定哪些 generated files 要不要看，也不想讓它自己猜 review 範圍。那些事情應該先鎖死，再讓模型進場。

實操寫法很簡單：你如果也在做自己的 review assistant，先把「一個 prompt 解決全部」丟掉。先寫 pre-processing，決定哪些檔案要看、哪些排除、哪些要分組。等範圍縮乾淨了，再把模型丟進去做判斷。少一點自由發揮，多一點流程控制，結果通常會好很多。

檔案選擇要寫成規則，不要寫成祈禱

“Precise file filtering” and “important changes are never missed.”

OCR 把 file selection 當基礎設施，不是提示詞裡的建議。文章裡直接講可以用規則指定要 review 的路徑，例如 src/main/**/*.java，也可以排除 **/generated/**。這聽起來很無聊，但我反而覺得這才像真的工具。因為 review 最怕的不是多看一個檔案，是漏看該看的檔案。

白話一點說，這套東西不是靠模型「記得」所有變更，而是先用規則把 diff 過一遍。該進來的進來，不該進來的出去。這比「請幫我全面檢查」可靠太多，因為後者其實是在拜託模型自己別偷懶。

我碰過一個改動，裡面同時有 business logic 和 generated artifact。一般 AI reviewer 很愛把注意力花在垃圾檔案上，真正的服務層 bug 反而被掃過去。OCR 要避免的就是這種浪費：先用規則定義 review surface，再讓模型去看真正值得看的東西。

實操寫法：先列 include，再列 exclude。把 generated、vendored、lockfile、minified assets 先排掉；如果你們 repo 裡有不同標準，像 source code、SQL、config、migration 各自有不同規則，也別靠 prompt，直接寫進 filter stage。規則寫死，結果才會穩。

• 先定義要看的路徑，再補排除規則。
• generated、vendor、dist 這類檔案先排掉。
• 讓每次執行看到的 scope 都一樣。

bundle 不相關的檔案，模型就會開始胡扯

“Smart file bundling” groups related files into a single review unit.

這段我覺得很重要。OCR 不會把所有變更硬塞成一包，而是把相關檔案組成 review bundle，再交給子 agent。文章舉的例子是 message_en.properties 和 message_zh.properties 一起看，這就很合理，因為它們本來就是同一個語意單元。

也就是說，OCR 在幫模型減少上下文噪音。大變更不是一件事，是很多小事混在一起。你如果把它們全丟進同一個 prompt，模型很快就會從「檢查」退化成「摘要」，然後評論開始空泛，像在交作業。

我自己人工 review 也不會把整個 branch 當一坨看。我會把 API 變更、config 變更、migration、localization 分開看。OCR 這個 bundle 概念，其實是在逼工具照著工程師真正的 review 習慣走，而不是讓人遷就模型的上下文限制。

實操寫法：bundle 規則不要只看副檔名，要看 domain。translation 檔案一起、schema 與 migration 一起、controller/service/test 一起、設定檔一起。變更量大時最好能平行跑子 review，這樣 coverage 比較完整，也不會把所有資訊塞成一坨。

• 按 domain 分組，不要只按副檔名分組。
• 每個 bundle 用自己的 review context。
• 大 diff 可以平行化處理，別硬塞單一 prompt。

行號對不上，整份 review 就是廢的

“External location and reflection components” systematically correct location errors.

這裡才是 OCR 最像正經工具的地方。文章說它有獨立的 comment positioning 和 content reflection 模組。白話講就是：模型先提意見，但如果落點不準，系統會再校正一次；如果內容有問題，也能反射回去再修。

翻譯一下就是，OCR 不相信模型第一次給的位置。這很對，因為 line-level review 只有在行號真的正確時才有價值。錯的 line number 不叫 review，那叫把 reviewer 變成客服，還要工程師自己去找你到底在講哪一行。

我最受不了的就是工具說「這裡可能有 null pointer risk」，結果箭頭指到空白行，或是指到一個根本沒問題的 return。那種情況下，我先驗工具，再驗 code，順序整個反了。OCR 想做的，就是把這個負擔移回系統層，別讓人肉去補模型的位置錯誤。

實操寫法：挑工具或自己做 review 系統時，先確認它能不能把評論 anchor 回真實 diff 或 file snapshot。評論必須綁定實際檔案 offset，不是只靠語意相似度。再來，用已知 diff 測試它的穩定性，多跑幾次看行號會不會飄。如果會飄，那不是小瑕疵，是結構性問題。

如果你要讓團隊真的用起來，最好把測試 review output 當成測 code 一樣對待。拿幾個固定變更反覆跑，確認位置一致、評論一致、沒有亂飛。這種東西不先驗，後面只會一直吵。

模型可以用，但要關在短籠子裡

“Scenario-specific prompt tuning” and a “dedicated toolset” for code review.

OCR 不是把模型扔掉，而是把它放回該做的地方。文章提到他們有針對 code review 調整 prompt，也縮過工具集，根據真實 tool-call pattern 去刪掉不常用的東西。這種做法我很熟悉，因為 agent 系統最常見的死法，就是工具越加越多，最後模型在那邊亂跳。

也就是說，agent 可以讀檔、搜尋、看其他變更檔案來補上下文，但不需要一整包花俏工具。工具太多只會讓它更吵、更不穩。review 這種工作，重點不是「會不會很多」，而是「會不會每次都差不多」。

我看過不少系統，明明是 review agent，卻塞了一堆不相干的 helper。結果模型在工具間來回切，token 燒得很快，結論卻很碎。OCR 的方向比較乾脆：縮工具、調 prompt、把行為鎖在 review 任務上，不要讓它到處亂逛。

實操寫法：先盤點工具清單，把幾乎沒用到的先砍掉。如果 review 場景真的只需要 file reader、search、diff inspector，那就夠了。接著重寫 prompt，明確寫出要看什麼、要抓什麼、嚴重度怎麼排、什麼情況該閉嘴。別把「更多工具」誤認成「更聰明」。

CLI 要接進工作流，不要做成玩具

“Workspace mode,” “branch range mode,” and “single commit mode.”

OCR 是 CLI，所以整合方式很直接。文章把常見模式分成三種：看目前 workspace 的未提交變更、比對兩個 ref 的 branch diff、或是只看單一 commit。這三種其實就涵蓋了大部分團隊的真實使用情境：本地開發、分支審查、回歸排查。

白話說，這工具沒有硬要你改開發習慣。你在本地改 code，就看 dirty tree；你要送 PR，就比對 feature branch 和 main；你要查 bug，就盯單一 commit。這種設計我很喜歡，因為越少 ceremony 的工具，越容易真的被用。

我一直覺得 review 工具的價值，不只在準不準，也在會不會被持續使用。比起一個很厲害但大家懶得開的系統，我寧可要一個稍微沒那麼花俏、但每次都能跑的流程。穩定使用，比偶爾驚豔重要得多。

實操寫法：把 review 指令接進你們平常的 dev flow。local 開發前先跑一次，開 PR 前再跑一次，CI 裡對 branch diff 再跑一次。若你們本來就有 GitHub Actions、GitLab CI 或其他 pipeline，CLI 形態會比 web-only assistant 好塞很多。

• workspace mode 用在本地 pre-PR 檢查。
• branch range mode 用在 merge request / CI review。
• single commit mode 用在回歸追 bug。

安裝路徑要清楚，因為 adoption 一定會卡

“Install via NPM,” “download the binary,” or “build from source.”

文章把安裝方式列得很完整：可以用 npm 裝、可以抓 binary、也可以自己從 source build。這才像一個正常的 open source 工具。你想快點試，就走 npm；你想要鎖版，就抓 release binary；你要深度整合或 patch 行為，就從 source 下手。

這件事看起來普通，但其實很重要。團隊導入工具最常死在 boring stuff：安裝步驟、設定檔位置、auth header、預設行為不清楚。OCR 文章願意花篇幅講這些，代表它知道 adoption 不是靠功能堆出來的，是靠 setup 不要太煩。

我待過的團隊很多，最後沒推起來的工具，常常不是因為不夠強，而是因為一開始裝起來就一堆坑。這種東西最怕大家試一次就放棄。你如果真的想讓 review agent 被用，先把安裝流程寫乾淨，比多寫十個 fancy feature 更實際。

實操寫法：團隊內只選一條推薦安裝路徑，其餘當備援。若你支援多個 LLM provider，就把環境變數、config 檔位置、認證方式寫清楚。不要把 setup 藏在功能介紹後面，然後期待大家自己摸懂。

可抄的模板

# Open Code Review 導入模板（可直接改成你們自己的 repo 用法）

## 1) 安裝
擇一即可：
- npm install -g @alibaba-group/open-code-review
- 從 GitHub Releases 下載 binary
- 需要改行為就從 source build

## 2) 設定模型端點
先固定一種 provider，團隊不要每個人各玩各的。

範例 env：
export OCR_LLM_URL="https://api.anthropic.com/v1/messages"
export OCR_LLM_TOKEN="YOUR_API_KEY"
export OCR_LLM_MODEL="claude-opus-4-6"
export OCR_USE_ANTHROPIC=true

如果你走 Anthropic-style auth：
ocr config set llm.auth_header x-api-key

## 3) 定義 review scope
用 deterministic 規則先把範圍鎖死。

Include：
- src/main/**/*.java
- app/**/*.ts
- services/**/*.py

Exclude：
- **/generated/**
- **/vendor/**
- **/dist/**
- **/*.min.js

## 4) Bundle 規則
按 domain 分組，不要亂塞。
- localization 檔案一起
- migration / schema 一起
- controller / service / test 一起
- config 檔一起

## 5) 選對模式
本地工作樹：
ocr review

分支 diff：
ocr review --from main --to feature-branch

單一 commit：
ocr review --commit abc123

## 6) 讓輸出能被自動化
JSON 格式：
ocr review --format json

先預覽：
ocr review --preview

補背景：
ocr review --background "Add rate limiting to login API"

## 7) 把 agent 關小一點
- 只保留 file read、search、changed-file inspection
- 每個評論都要對得上真實 diff
- 不能 anchor 到 source position 的評論直接丟掉
- prompt 只針對 code review 調整，不要塞一堆通用任務

## 8) CI policy
- high-confidence issue 才 fail pipeline
- medium-confidence 交給人看
- low-confidence noise 不要一直吵，除非它重複出現

## 9) 團隊規則
如果一則 review comment 不能指到真實檔案的真實行號，它就不算 review finding。

這段就是我會直接拿去改的版本。它把 OCR 的核心想法收斂成一個 workflow：scope 先鎖、bundle 按 domain 分、模式選對、每則評論都要有真實錨點。你如果要自己做 review assistant，這個骨架很夠用了。

原始來源是 Efficient Coder on xugj520.cn，我這篇是根據那篇文章和 Open Code Review GitHub repository 的內容，整理成比較適合台灣開發者直接拿去用的拆解。

如果你想看安裝與版本，我也建議順手看 npm package 和 GitHub Releases；如果你在比對不同 AI coding workflow，Claude Code 的文件也很有參考價值。