企业官网建设流程全解析

open-code-review 的 --effort low/medium/high 怎么选，平衡评审成本与问题召回？

【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review

跑ocr review时经常遇到两个相反的需求：一次评审花费太多 token，想压低成本；或者评审结果太浅，明显漏掉了问题。open-code-review（OCR）用--effort预设直接控制这两端的平衡点：它决定每个文件组（file group）执行多少轮 review round，轮数越多召回越好，token 成本也大致按轮数等比上涨。本文基于项目文档说明三个档位的实际含义、怎么选、单次运行和持久化两种设置方式，以及如何用内置 telemetry 核对成本差异。

--effort到底控制什么

--effort接受low/medium/high三个值，默认medium，对应每个文件组的 review 轮数：

轮数的作用在 架构文档 中有明确说明：主循环不是只跑一次，而是对每个文件组最多跑MAX_REVIEW_ROUNDS次，目的就是在大文件组上提升问题召回。第一轮之后的每一轮会重新执行MAIN_TASK，把前几轮已确认的发现作为{{confirmed_comments}}注入，并且不再附带 plan——文档指出 plan 在明显问题被发现后反而会成为覆盖上限。

轮数并非总是跑满，存在三种提前停止条件：某一轮没有新增发现、confirmed comment 达到上限、或--max-tokens-budget设定的总 token 预算耗尽。所以high不一定恰好是low的 3 倍成本，但量级关系成立。

CLI Reference 对成本与召回的表述是："More rounds improve recall at proportionally higher cost."（轮数越多，召回越高，成本按比例上升）。

怎么选：按你的首要目标选档位

项目文档在两处给出了明确的选型依据：

• 想更便宜的运行：--effort low是"单一最大的杠杆"（the single biggest lever if you want a cheaper run），因为成本大致与轮数成正比；
• 感觉评审太浅：--effort high是"最便宜的质量杠杆"（the cheapest quality lever when a review feels shallow）。

对应的判断路径是：

• 快速 sanity check、批量跑小改动、token 预算紧张：用--effort low。文档在 Tips & gotchas 中量化了这个档位的效果：相对默认的medium，--effort low大约把成本减半（roughly halves cost）。
• 常规 PR 评审：保持默认medium（2 轮），不显式传--effort即可。
• 评审结果漏问题、大文件组：用--effort high，用多一轮评审换取召回提升。

注意区分：CI 文档中的llm_reasoning_effort输入是另一回事，它作用于带可调节reasoning_effort请求字段的模型（如 GLM-5.x、OpenAI 推理模型），取值是minimal/low/medium/high/max，与--effort的轮数预设不是同一个概念，不要混用。

设置方式：单次覆盖与持久化

单次运行覆盖

--effort只对当前调用生效，并覆盖已保存的effort配置：

ocr review --effort low ocr review --from origin/main --to HEAD --effort high

CLI Reference 中ocr review的完整标志还包括--format json、--audience agent等，可与--effort组合用于脚本化调用。

持久化为默认值

对每次运行都生效的档位，用ocr config set写入~/.opencodereview/config.json：

ocr config set effort high ocr config unset effort # 清除后恢复默认 medium

unset effort会恢复默认的medium预设，这是 Configuration 中 Review effort 一节给出的原文行为。单次的--effort优先级高于保存值，两者冲突时以命令行参数为准。

可选分支：GitHub Actions CI 输入

如果评审跑在 GitHub Action 里，action 提供独立的effort输入，透传给ocr review --effort，取值同样是low/medium/high（大小写不敏感）；留空则保持 CLI 默认（已配置值或medium）。文档明确要求 OCR v1.10.0 或更新版本，旧版本会提前报错，见 CI 集成文档。

调整 effort 时连带影响的参数

• --timeout：per-group 截止时间，默认 15 分钟，会按 effort 轮数线性放大（low/medium/high 对应 15/30/45 分钟）。也就是说切到high后组级超时会随之放宽，一般不需要手动再改--timeout。
• --max-tokens-budget：限制整次运行的总 token 用量（默认0即不限）。设置该值后，预算耗尽会提前终止评审轮次，且已产生的部分结果仍会输出——它和 effort 的交互点就是上面提到的第三种提前停止条件。

验证：核对两档之间的成本差异

验证成本侧用 OCR 自带 telemetry（默认关闭），FAQ 的 Performance & cost 一节给出的核对方法是：

ocr config set telemetry.enabled true ocr config set telemetry.exporter console ocr review

LLM 调用不单独生成 span，而是记录为 metrics。重点看三个指标：

• ocr.llm.tokens_used：counter，按model+type打标签；
• ocr.llm.requests_total：counter，按model+status打标签；
• ocr.llm.request_duration_seconds：histogram，按model打标签。

consoleexporter 会在输出中内联打印这些聚合值，同一份变更分别用--effort low和--effort high各跑一次，比较两次的 token 用量即可确认成本差距是否符合预期的轮数比例；要上仪表盘可换 OTLP exporter，配置细节见 Telemetry 文档。

召回侧的判断依据是评审输出本身的评论数量与覆盖范围：由于轮次在"没有新增发现"时会提前停止，high档位若与medium输出完全相同，说明后续轮次没有再挖出新问题，这次运行加轮次没有带来额外召回。

边界与其他成本杠杆

• 文档对成本关系的表述是"roughly"（大致）随轮数线性，不要把它当作精确的 2 倍/3 倍换算。
• 降低 token 消耗不止--effort一个杠杆，FAQ 中列出的其他项包括：plan 阶段阈值（每组一次额外 LLM 调用）、MAX_TOOL_REQUEST_TIMES（默认 100，用--max-tools调高会使每组成本大致线性增长）、memory compression 本身也是 LLM 调用、以及用include列表缩小评审范围。本文只展开 effort 这一个档位选择问题。
• 评审开始前可用ocr llm test验证 LLM 连通性，避免把 LLM 调用失败误判为档位问题。

选定档位后，单次调用用--effort覆盖，长期默认用ocr config set effort <level>，再用 telemetry 的 token 指标复核实际花费，就构成了"选档位 → 生效 → 核对成本"的完整路径。

【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review