【2026 最新】OpenCodeReview 教學：同一個 PR 驗證 1/9 Token 與低 Recall

OpenCodeReview 教學不該從「裝好就跑」開始，而要先回答一個更難的問題：如果同一個 PR 裡明明埋了 10 個缺陷，它用更少 Token 留下較少評論，究竟是更準，還是只是漏得更多？2026 年 9 月 16 日，RepoRadar 的 GitHub API 快照記錄 alibaba/open-code-review 有 31,553 stars、單日增加 2,756；這證明關注度升高，卻不能替工具品質背書。

這篇專為第一次做 AI Code Review 驗收的開發者寫。我會帶你固定 OpenCodeReview 1.12.4，在拋棄式 Repo 建立 10 個已知缺陷，讓 OpenCodeReview 與 Claude Code 使用同一個完整模型 ID、同一組 commit，並各自固定 effort 設定，再量 Precision、Recall、F1、Token 與牆鐘時間。本文不把專案方 benchmark 冒充 AlphaLab 的獨立重現；你會拿到的是一套可自己執行、可抓出低 Recall 代價的公平比較方法。

先說結論：1/9 Token 不是免費午餐

🧭 記憶把手：可信的 AI Code Review＝同一個 PR × 同一模型 × 同一份 ground truth × 同一套計分規則。

• 「約 1/9」是聚合摘要，不是固定常數：專案論文中五組可配對的 Claude Code 後端，Claude Code 的 Token 約是 OpenCodeReview 的 5.4–14.7 倍；各組差異很大。
• Precision 高，不代表找得完整：論文的五組同後端標籤配對裡，OpenCodeReview 的 Recall 全部低於 Claude Code。評論比較少、較常匹配 benchmark ground truth，仍可能漏掉更多 ground truth。
• 公平比較的是產品管線，不是裸模型：即使模型 ID 一樣，兩邊仍有不同 prompt、工具、檔案分流、Agent 迴圈與停止條件。
• CI 先只留言：在你自己的 Repo 通過 Recall、完成率與失敗處理驗收前，不要讓它單獨決定能不能 merge。

如果你想先理解「一個 Agent 為什麼不只是模型」，可搭配 AI Agent Harness 白話指南；若你已在做大型 PR，則先看 Claude Code 大型 Repo 安全改版，把 blast radius 與冷審查概念補齊。

OpenCodeReview 教學第一課：它省在哪裡？

OpenCodeReview 不是把完整 Repo 一口氣塞進聊天框。它先用規則處理 diff、include／exclude 與檔案分組，再讓子 Agent 用受限工具讀取相關上下文，最後用同一模型、但只看 diff 的 filter，僅刪除可由 diff 直接證偽的 finding；無法判定或解析失敗時保留。白話說：先把問題縮小，再把算力花在可疑區，最後只移除能直接證明不成立的評論。

目前官方 架構文件列出六種受限工具，包含讀檔、找檔、搜尋程式碼、讀 diff、提交評論與結束任務；預設 effort 為 medium，會跑兩輪審查，low／high 則是一輪／三輪。這些設計能減少漫無目的的 context 消耗，但最後的過濾器只能刪 finding，不能替你補回沒看到的缺陷。

為什麼「1/9 Token」不能直接當成你的答案？

OpenCodeReview 論文 v2自報的 paper-era snapshot 包含 200 個 PR、50 個 Repo、10 種語言與 1,505 個 ground-truth comments，用來比較 OpenCodeReview 1.3.1、Claude Code 2.1.169 與 Codex 0.140.0。這是專案作者自己的評測，不是第三方稽核；截至 2026 年 9 月 17 日，論文與官方公開 artifacts 沒有附上模型端點、硬體、平行度、原始 reviewer output 與完整 run manifest，因此它適合形成假說，不適合直接變成你公司的 SLA。

論文 Table 3 的五個共同 Claude Code 後端，Token 比率依序約為 14.7×、8.2×、5.9×、13.8×、5.4×。把五組平均 Token 分別加總後，Claude Code 的 22,367K 除以 OpenCodeReview 的 2,499K，得到約 8.95×；這很接近 README 寫的「約 1/9」，但聚合公式是本文依公開表格重建，README 沒有說它怎麼算。換模型、effort、PR 大小、規則或 cache，都可能改變倍率。

更重要的是 Recall。以圖中的配對來看，OpenCodeReview 對上 301 個 ground truth，Claude Code 對上 435 個；只能說前者的 matched count 少 134，不能說兩邊剛好差了同一批 134 個 bug，因為論文沒有公開配對重疊。這就是你必須自己做 10 缺陷 PR 的原因：省多少是成本問題，漏掉什麼才是風險問題。

實驗前準備：固定版本、權限與比較邊界

先在拋棄式 Repo 操作，不要直接把新 reviewer 接到正式 monorepo。官方 quickstart 目前要求 Git 2.41 以上與 Node.js 18 以上；本文固定 OpenCodeReview 1.12.4，Claude Code 則使用支援下列隔離旗標的 2.1.259，避免 latest 在兩輪測試之間移動。

EVAL_DIR=$(mktemp -d /tmp/ocr-ab.XXXXXX)
mkdir -p "$EVAL_DIR/source"
cd "$EVAL_DIR/source"
git init

export OCR_NO_UPDATE=1
npm install -g @alibaba-group/open-code-review@1.12.4
CLAUDE_CODE_VERSION=2.1.259
curl -fsSL https://claude.ai/install.sh | bash -s "$CLAUDE_CODE_VERSION"

ocr version
claude --version
git --version
node --version

把 ground truth、settings、log 與結果都存到工作樹外的 $EVAL_DIR，並在 manifest 記下：兩個 CLI 版本、base/head 完整 SHA、provider、endpoint、protocol、完整模型 ID、兩邊各自的 effort／budget／timeout、開始／結束時間與 exit code。模型別用 opus、sonnet這種會移動的 alias；Claude Code 官方模型設定文件也明確提醒 alias 會隨 provider 更新。

最小權限不是一句 prompt

Reviewer 只需要讀取工作樹與執行 read-only Git 指令。不要允許測試程式、安裝 script、deploy command 或 PR 內新增的任意 shell。Claude Code 端要同時限制 built-in tools、MCP、外部路徑與環境憑證；--permission-mode dontAsk只負責拒絕需要額外核准的動作，不能取代 OS 沙盒。高敏感 Repo 請再放進一次性 container／VM。OpenCodeReview 端先跑 --preview確認哪些檔案會進入模型。想看完整的帳號與沙盒驗收思路，可參考 Agent-Reach 安全驗收。

Step 1：植入 10 個缺陷，先寫 ground truth

先提交一個安全 baseline，再用第二個 commit 植入缺陷。不要在程式碼裡寫「BUG 1」提示 reviewer；答案要放在 Repo 外，等兩邊完成後才拿來評分。初學者可用一個 150–300 行的小服務，覆蓋十種常見失敗：

1. 授權條件從「本人或 support」改成「不是 guest」。
2. SQL 參數綁定改成字串插值。
3. 匯出檔名移除 path traversal 邊界檢查。
4. 分頁 end index 多加 1。
5. 退款函式把 cents 與 dollars 混用。
6. 到期時間把毫秒與秒比較。
7. 例外路徑不再關閉 file／socket handle。
8. 庫存扣減移除 transaction，產生 race condition。
9. retry backoff 移除上限。
10. audit payload 開始記錄 access token。

ground truth 每筆至少保存 id、path、start_line、end_line、side、category、severity、root_cause與failure_scenario。路徑與行號負責定位，root cause 才負責判斷兩句不同文案是不是同一個問題：

{
  "id": "D03",
  "path": "src/orders.js",
  "start_line": 21,
  "end_line": 21,
  "side": "right",
  "category": "security",
  "severity": "high",
  "root_cause": "未限制匯出路徑必須留在 root 內",
  "failure_scenario": "reportName 為 ../secret 時可寫出指定目錄"
}

把 ground truth 寫到 $EVAL_DIR/ground-truth.jsonl，最後記錄 BASE_SHA=$(git rev-parse HEAD~1)與HEAD_SHA=$(git rev-parse HEAD)。兩個 reviewer 都必須只看這個 range；任何一邊看了未提交檔案、後續修正 commit、另一個 reviewer 的輸出或 ground truth，整輪作廢。完成 fixture 後建立兩份獨立乾淨 clone：

git clone --no-hardlinks "$PWD" "$EVAL_DIR/ocr-repo"
git clone --no-hardlinks "$PWD" "$EVAL_DIR/claude-repo"

test -z "$(git -C "$EVAL_DIR/ocr-repo" status --porcelain)"
test -z "$(git -C "$EVAL_DIR/claude-repo" status --porcelain)"

Step 2：設定同一個模型端點，不把 API Key 寫進 Repo

OpenCodeReview 同時支援 Anthropic protocol 與 OpenAI-compatible endpoint。若只想使用 OCR，兩種都可以；但若要跟 Claude Code 宣稱「同後端模型」，最乾淨的做法是讓兩邊走同一個 Anthropic Messages gateway、同一個完整模型 ID，並檢查輸出實際使用的 model。若 OCR 走 OpenAI serialization、Claude Code 走 Anthropic serialization，你比較到的還包含 tool schema 與 prompt 序列化差異。

# Anthropic-compatible：兩邊共用同一個 base URL
export SHARED_ANTHROPIC_BASE_URL="https://gateway.example.com"

ocr config set provider anthropic
ocr config set model "$FULL_MODEL_ID"
ocr config set providers.anthropic.url "$SHARED_ANTHROPIC_BASE_URL"
ocr config set providers.anthropic.api_key ""
ocr config set providers.anthropic.api_key_cmd \
  "security find-generic-password -s ocr-anthropic -w"
ocr llm test

# 或建立 OpenAI-compatible 自訂端點（只選一條路）
ocr config set provider lab-gateway
ocr config set custom_providers.lab-gateway.url "$BASE_URL"
ocr config set custom_providers.lab-gateway.protocol openai
ocr config set custom_providers.lab-gateway.model "$FULL_MODEL_ID"
ocr config set custom_providers.lab-gateway.api_key_cmd \
  "security find-generic-password -s ocr-gateway -w"
ocr llm test

後續 A/B 命令刻意使用 anthropic路線；OpenAI-compatible 範例只適合 OCR 單獨使用，或另行標成不同 protocol 的產品層比較。固定 commit 的設定文件說明 config 位於 ~/.opencodereview/config.json且寫成 0600；靜態 api_key會優先於api_key_cmd，所以要用空字串明確清除舊 key。一般 session JSONL 已包含 prompt、response 與 tool result；開 OCR_RAW_LOGGING=1還會另外保存更原始的 request／response body，兩者都要當敏感資料。

Step 3：先 preview，再跑同模型 A/B

痛點：規則先把關鍵檔案排除，後面再精準都沒有用。解法：先用不呼叫 LLM 的 --preview驗證選檔。操作：

cd "$EVAL_DIR/ocr-repo"
test -z "$(git status --porcelain)"

ocr review \
  --from "$BASE_SHA" --to "$HEAD_SHA" \
  --preview --format json --audience agent \
  > "$EVAL_DIR/ocr-preview.json"

確認 10 個缺陷所在檔案全都標成 will_review: true。若被排除，先讀 preview JSON 的 files[].exclude_reason；ocr rules check path/to/file只診斷 prompt rule 的來源與 pattern，不負責解釋 file filter。不要直接加 --no-filter，它關掉的是 reflection 過濾，適合做 ablation，不是正常產品模式。官方 Review Rules 文件列出 CLI、專案、全域與內建四層優先序。

接著固定並記錄兩邊各自的 effort。OCR 的 high 是三輪，Claude /code-review high調整的是 review coverage／confidence，Claude 的 --effort high又是模型推理深度；同名的 high 不代表相同算力、輪數或停止條件。以下是在 Ubuntu／CI runner 用同一個外層 wall-clock timeout 跑原生產品管線的範例；macOS 可用 GNU coreutils 的 gtimeout代替：

TIMEOUT_SECONDS=1800
export OCR_NO_UPDATE=1

cd "$EVAL_DIR/ocr-repo"
test -z "$(git status --porcelain)"
/usr/bin/time -p -o "$EVAL_DIR/ocr-time.txt" \
  timeout --signal=TERM "${TIMEOUT_SECONDS}s" ocr review \
  --from "$BASE_SHA" --to "$HEAD_SHA" \
  --provider anthropic --model "$FULL_MODEL_ID" \
  --effort high --format json --audience agent \
  --output "$EVAL_DIR/ocr.json"

export ANTHROPIC_BASE_URL="$SHARED_ANTHROPIC_BASE_URL"
export ANTHROPIC_AUTH_TOKEN="$TOKEN"
export ANTHROPIC_MODEL="$FULL_MODEL_ID"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$FULL_MODEL_ID"
export CLAUDE_CODE_SUBAGENT_MODEL="$FULL_MODEL_ID"
export CLAUDE_CODE_SUBAGENT_MODEL_FORCE=1
export CLAUDE_CODE_EFFORT_LEVEL=high
export DISABLE_UPDATES=1
export CLAUDE_CODE_SUBPROCESS_ENV_SCRUB=1
export CLAUDE_CODE_SKIP_PROMPT_HISTORY=1
export CLAUDE_CONFIG_DIR="$EVAL_DIR/claude-config"

cd "$EVAL_DIR/claude-repo"
test -z "$(git status --porcelain)"
/usr/bin/time -p -o "$EVAL_DIR/claude-time.txt" \
  timeout --signal=TERM "${TIMEOUT_SECONDS}s" claude --restricted \
  -p "/code-review high ${BASE_SHA}...${HEAD_SHA}" \
  --model "$FULL_MODEL_ID" --effort high \
  --output-format json --no-session-persistence \
  --permission-mode dontAsk \
  --permission-prompts none \
  --settings "$EVAL_DIR/claude-settings.json" \
  --tools "Read,Grep,Glob,Bash,Agent" \
  --allowedTools "Read" "Grep" "Glob" \
    "Bash(git diff *)" "Bash(git show *)" "Bash(git log *)" \
  --disallowedTools "Edit" "Write" "WebFetch" "WebSearch" "mcp__*" \
  > "$EVAL_DIR/claude.json"

$EVAL_DIR/claude-settings.json也放在工作樹外，將下列 REPLACE_WITH_FULL_MODEL_ID換成同一個完整 ID。這會關閉 fallback、限制可選模型並阻擋工作目錄外讀取；managed policy 仍可能生效，所以企業環境要另外把它記進 manifest：

{
  "fallbackModel": [],
  "switchModelsOnFlag": false,
  "availableModels": ["REPLACE_WITH_FULL_MODEL_ID"],
  "enforceAvailableModels": true,
  "permissions": {
    "blockReadsOutsideWorkingDirectories": true
  }
}

Claude Code CLI 文件是旗標的最新依據。ANTHROPIC_AUTH_TOKEN使用 Bearer auth；若 gateway 要的是 X-Api-Key，改用 ANTHROPIC_API_KEY，不要同時留下兩者。正式記錄時保存 claude --version，先 smoke-test 固定版本能在 --restricted下呼叫/code-review；若旗標不支援就停下調整，不要靜默刪除隔離條件繼續跑。完成後檢查 JSON 的 per-model usage，只要出現別的模型 ID，就把該 run 標成 multi-model。

這仍是同後端模型的產品層 A/B。Claude Code 的 /code-review技能、OpenCodeReview 的 file dispatch、兩邊工具與停止規則都不同，正是你要比較的「整套 reviewer」；不要把結果寫成哪個裸模型比較聰明。若你想看雙 reviewer 互相挑錯的另一種架構，可延伸閱讀 Claude＋Codex 對抗式 Reviewer。

Step 4：用 Precision、Recall、F1 計分

先把兩邊 finding 正規化成相同 schema，再去重複。同一路徑、同一 root cause、只差措辭的兩則評論只能算一則。配對順序預先寫死：先比 path 與 side，再比行號重疊或你事前登記的容忍值，最後由看不到工具名稱的人判斷 root cause 是否等價。不能看完結果才把行號容忍度從 ±1 改成 ±20。

• TP：finding 與一個尚未配對的 ground-truth root cause 相符。
• FP：finding 找不到相符 ground truth。人工覆核若證明它是真 bug，另標記為 novel valid finding；不要為了保住 benchmark 分數把它硬算成 TP。
• FN：10 個 ground truth 中沒有被配對的缺陷。
• Precision：TP ÷ (TP + FP)，回答「產生的 finding 有多少能匹配預先定義的 ground truth」。
• Recall：TP ÷ (TP + FN)，回答「已知缺陷有多少被找到」。
• F1：2PR ÷ (P + R)，把 precision 與 recall 合成一個等權指標。

Token 必須拆出 input、output、cache read／write；牆鐘時間另記，不要拿 Token 直接換算美元，因為不同 provider 的輸入、輸出與 cache 價格不同。OpenCodeReview JSON 的 summary會回傳 token 與 elapsed，但 OCR 只在 provider 回傳 usage 時採用 API 數字，否則會用本機 tokenizer 估算，JSON 又不標示 provenance；無法證明來源的 run 要標成 estimated，不能和另一邊的帳單級 usage 混算。max_tokens_budget只計 input＋output，不含 cache read／write。Claude Code JSON 會提供 usage與 per-model usage，兩邊都先保存完整 envelope，再由固定 script 解析。Timeout、拒絕工具、budget stop 或未覆蓋完整檔案，一律標記 completion=false，不能解讀成「模型確認沒有問題」。端到端主指標仍保留該 instance：用實際產生的 findings 計分，所有未命中的已知缺陷照算 FN；另外再報只含 completed runs 的條件式指標與 completion rate。

一個 10 缺陷 PR 只適合 smoke test。要做採購或部署決策，至少再加入乾淨 PR，否則你不知道 reviewer 會不會在沒有 bug 時大量幻覺。AACR-Bench 的公開 evaluator提供 path → side → line → semantic 的框架，但目前會把缺少結果檔的 instance 排除分母；而且該固定 commit 的 positive data 已是 196 records／1,506 comments，和論文的 200／1,505 snapshot 不同，不能直接拿來重現 Table 3。實驗要另行固定資料 commit／hash，你自己的報表也必須公開 completion rate，不能讓失敗 run 消失。多 PR 時以 pooled micro P／R／F1 為主，另報 per-PR macro、乾淨 PR 誤報率與 paired bootstrap 95% 信賴區間。

Step 5：把 OpenCodeReview 接進 advisory CI

OpenCodeReview 沒有一個名叫「advisory mode」的開關；目前 CLI 找到 finding 時仍回傳 exit 0，fatal error 才回傳 1，所以官方 GitHub Action 的正常行為本來就是「留言但不因 finding 擋 merge」。這裡的 advisory 是你的部署政策：保留 reviewer comment，不把 AI 意見當唯一合併門票。要注意，綠燈只表示沒有 run-level failure 或全部項目失敗，不代表完整覆蓋。

name: OCR advisory review
on:
  pull_request_target:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    env:
      OCR_NO_UPDATE: '1'
    runs-on: ubuntu-latest
    steps:
      - uses: alibaba/open-code-review@f1101fd7f51304c82e4a4f292bbee88aea0823cf
        with:
          ocr_version: '1.12.4'
          llm_url: ${{ secrets.OCR_LLM_URL }}
          llm_auth_token: ${{ secrets.OCR_LLM_TOKEN }}
          llm_model: ${{ vars.OCR_LLM_MODEL }}
          llm_use_anthropic: 'true'
          effort: 'high'
          max_tokens_budget: '200000'
          upload_artifacts: 'true'
          sticky_summary: 'true'

這份範例把 Action pin 到 1.12.4 的 release commit，關閉 wrapper 自動更新，且只有 contents: read與pull-requests: write。Anthropic protocol 的 OCR_LLM_URL要放完整 /v1/messages endpoint；它和前面的 base URL 不是同一種字串。官方 workflow 使用 pull_request_target，由可信任的 base 啟動，再讀取 PR head 的 blob；不要 checkout 後執行 PR 內程式，也不要讓 PR 修改帶著 secrets 執行的 reviewer 規則。細節以固定版本的 CI 文件與官方範例為準。

max_tokens_budget超過後會停止繼續 dispatch，保留 partial results，而且 CLI 仍可能 exit 0。因此 merge gate 不能只看綠燈；還要解析 status、summary.budget_exceeded、manifest.terminal_state，以及 manifest.coverage內的 selected、completed、reused、failed 與 waived。Budget stop 會出現在 failed[].classification = "budget"，不是一個通用的 skipped-files 陣列。把下列條件先寫進 policy，再跑至少一批歷史 PR：

eligible_to_promote =
  completion_rate == 100%
  and critical_recall == 100%
  and overall_recall >= TEAM_RECALL_FLOOR
  and precision >= TEAM_PRECISION_FLOOR
  and p95_wall_time <= TEAM_CI_BUDGET

前四週建議只留言、人工標記「有用／誤報／漏報」，每週重算門檻。即使達標，也把 AI reviewer 當第二道訊號，不要移除測試、靜態分析、CODEOWNERS 或資深 reviewer。你也可把評論過多視為一種 CI budget，延伸到 Code Sloppiness 與 CI Budget的治理方式。

低 Recall 的真正代價：沒有留言，不等於沒有缺陷

高 Precision 的體驗很好：工程師少看垃圾評論，更願意相信 bot。但信任升高後，團隊可能反過來把「bot 沒說話」理解成「PR 安全」。這正是低 Recall 最危險的地方。對付款、權限、資料刪除與 secret handling，漏掉一個 critical defect 的成本，常比多看三個 FP 高得多。

• 把 severity 分層：總 Recall 之外，另外要求 critical／high recall；10 個 fixture 至少要含安全、資料一致性與資源生命週期。
• 保留雙通道：OCR 負責高信心留言；測試、SAST、dependency scan 與人工 review 補它看不到的區域。
• 追 silent failure：沒有評論但 run 不完整、檔案被 exclude 或 token budget 用完，必須顯示醒目狀態。
• 定期冷審查：每月抽取已 merge PR，由不知道原 reviewer 結果的人重新審一次，估計 production miss。
• 版本變動就重跑：CLI、模型 snapshot、gateway、rule、effort 或 prompt 任一變動，都代表舊門檻不再自動成立。

這套思路和 Agent Prefix Cache 驗證相同：能跑完、數字漂亮，還不等於 harness 有效。你需要能抓錯的 oracle、固定分母，以及把「未完成」留在報表裡。

最常讓 A/B 失真的 8 個坑

1. 只寫同一個模型名稱：不同 gateway 可能把同一字串映射到不同 snapshot；保存 endpoint、protocol 與實際 usage model。
2. effort 不同：更多輪次通常提高成本，也可能改變 recall；兩邊設定與實際子 Agent model 都要記錄。
3. 讓 reviewer 看到答案：ground truth、修正 commit 或既有人工評論會造成 contamination。
4. 只測有 bug 的 PR：沒有 clean PR，就看不到真正的 false-positive rate。
5. finding 沒去重：同一 root cause 被寫三次，會同時扭曲 precision 與工程師負擔。
6. 失敗 run 被排除：timeout、缺檔與 budget stop 必須留在固定分母，另報 completion rate。
7. 拿 wall time 當純效率：OCR 會並行 file subagent；硬體、rate limit 與 concurrency 不同時，時間不是等量 compute。
8. 用一次結果宣稱穩定：至少重複多輪並保存每輪輸出；reviewer 本身不是 deterministic。

如果這是你第一次把 Agent 工作流產品化，可把本篇 fixture、scorer 與 CI policy 收進 AlphaLab AI 課程與實作路線的 eval 模組：每次改 prompt 或模型，都先過同一批可反駁的測試。

常見問題 FAQ

1. OpenCodeReview 真的只用 Claude Code 的 1/9 Token 嗎？

不一定。約 1/9 可由論文五組共同後端的加總平均重建；個別配對約落在 5–15 倍，GPT-5.5 對 Codex 的差距又只有約 1.24 倍。你的 PR、模型、effort 與規則會得到不同結果。

2. Precision 高就可以直接擋 merge 嗎？

不可以。Precision 只表示已留言內容比較可信；是否適合當 gate 還要看 critical recall、整體 recall、完成率與 silent failure。先跑 advisory，保留人工覆核。

3. 為什麼一定要同一個完整模型 ID？

因為 alias 會移動。opus或sonnet可能在不同時間、provider 指向不同 snapshot。完整 ID 仍不能證明 gateway 背後權重相同，但至少移除一個明顯變因。

4. 可以用同一個 OpenAI-compatible 模型比較 Claude Code 嗎？

可以，但前提是同一後端另外提供 Anthropic Messages 相容介面給 Claude Code。Claude Code 不能直接把 ANTHROPIC_BASE_URL指向只支援 OpenAI protocol 的端點。若兩邊使用不同 serialization，只能稱為同後端標籤的產品層 A/B；最嚴格的比較應讓兩邊通過同一個 Messages-compatible gateway 並核對實際 usage model。

5. 10 個缺陷夠不夠？

只夠 smoke test。它能快速抓出設定、選檔與明顯 recall 問題；正式決策還要增加多語言、多 Repo、乾淨 PR、重複 run 與信賴區間。

6. OpenCodeReview 找到問題時，CI 會自動失敗嗎？

預設不會因 finding 失敗。目前 CLI 在有評論時仍回傳 0，fatal error 才回傳 1；官方 Action 因此天然偏 advisory。你若另寫 threshold gate，必須清楚區分「有 finding」與「review 執行失敗」。

7. 超過 max token budget 後，exit 0 代表完成嗎？

不代表。1.12.4 會保留 partial results，把未完成項目放進 manifest.coverage.failed[]並標記 classification: "budget"，仍可能 exit 0。CI 必須另外檢查 manifest 覆蓋率與 summary.budget_exceeded。

8. API Key 放進 ~/.opencodereview/config.json安全嗎？

能避免就不要。檔案雖是 0600，仍建議使用 api_key_cmd從 Keychain 或 secret manager 取出；CI 則使用平台 secret，並避免在 log 印出環境變數。

給新手的 7 個驗收重點

1. 固定兩個 CLI、commit SHA、完整模型 ID、endpoint 與 protocol。
2. 先做 --preview，確認缺陷所在檔案真的會被 review。
3. 使用兩份乾淨 clone；ground truth 與兩邊輸出都放在工作樹外。
4. 同時報 Precision、Recall、F1、Token、時間與 completion rate。
5. 失敗 run 仍用已產生 finding 計分，未命中的已知缺陷照算 FN。
6. CI 先只留言，通過自己的 critical recall 門檻後再談升級。
7. 模型、rule、effort 或工具版本一變，就重跑整套 fixture。