open-code-review 的 --effort low/medium/high 怎么选平衡评审成本与问题召回【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas 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-reviewOCR用--effort预设直接控制这两端的平衡点它决定每个文件组file group执行多少轮 review round轮数越多召回越好token 成本也大致按轮数等比上涨。本文基于项目文档说明三个档位的实际含义、怎么选、单次运行和持久化两种设置方式以及如何用内置 telemetry 核对成本差异。--effort到底控制什么--effort接受low/medium/high三个值默认medium对应每个文件组的 review 轮数--effortreview 轮数low1medium默认2high3轮数的作用在 架构文档 中有明确说明主循环不是只跑一次而是对每个文件组最多跑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 评审保持默认medium2 轮不显式传--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 highCLI Reference 中ocr review的完整标志还包括--format json、--audience agent等可与--effort组合用于脚本化调用。持久化为默认值对每次运行都生效的档位用ocr config set写入~/.opencodereview/config.jsonocr config set effort high ocr config unset effort # 清除后恢复默认 mediumunset 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 时连带影响的参数--timeoutper-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 reviewLLM 调用不单独生成 span而是记录为 metrics。重点看三个指标ocr.llm.tokens_usedcounter按modeltype打标签ocr.llm.requests_totalcounter按modelstatus打标签ocr.llm.request_duration_secondshistogram按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 Alibabas 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
open-code-review 的 --effort low/medium/high 怎么选平衡评审成本与问题召回【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas 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-reviewOCR用--effort预设直接控制这两端的平衡点它决定每个文件组file group执行多少轮 review round轮数越多召回越好token 成本也大致按轮数等比上涨。本文基于项目文档说明三个档位的实际含义、怎么选、单次运行和持久化两种设置方式以及如何用内置 telemetry 核对成本差异。--effort到底控制什么--effort接受low/medium/high三个值默认medium对应每个文件组的 review 轮数--effortreview 轮数low1medium默认2high3轮数的作用在 架构文档 中有明确说明主循环不是只跑一次而是对每个文件组最多跑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 评审保持默认medium2 轮不显式传--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 highCLI Reference 中ocr review的完整标志还包括--format json、--audience agent等可与--effort组合用于脚本化调用。持久化为默认值对每次运行都生效的档位用ocr config set写入~/.opencodereview/config.jsonocr config set effort high ocr config unset effort # 清除后恢复默认 mediumunset 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 时连带影响的参数--timeoutper-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 reviewLLM 调用不单独生成 span而是记录为 metrics。重点看三个指标ocr.llm.tokens_usedcounter按modeltype打标签ocr.llm.requests_totalcounter按modelstatus打标签ocr.llm.request_duration_secondshistogram按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 Alibabas 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
