Open Code Review：审查范围、文件过滤与模型调用
评价 Open Code Review 成本时，也要记录漏掉的缺陷
设计固定条件的审查对比，记录 token、延迟和人工验收，避免把项目基准中的节省比例当作保证。
你将学会
- 先读清楚基准里的取舍
- 区分上下文上限与累计开销
- 把人工核对时间算进去
开始前需要
- 理解 Git 改动与合并基点比较
- 会使用命令行并理解模型凭据的用途
选择审查范围，解释文件排除原因，设计受控试验，并区分源码审阅和运行证据。
先看结论
- 上游基准包含召回率取舍。
- 输入上下文大小不等于累计费用。
- 人工检查时间也是评价的一部分。
先读清楚基准里的取舍
README 报告其基准中精确率和 F1 较好、token 用量更低，同时承认召回率低于所比较的通用助手。这些是项目在特定评估中的报告结果，我们没有在本次固定版本上复现该基准。
如果只统计评论减少了多少，就可能奖励一个因为漏报而显得安静的审查器。准备带人工标注的小变更集，在不同配置间保持模型和范围一致，同时统计误报、已知缺陷的漏报和被接受的问题，并交代样本限制。
区分上下文上限与累计开销
架构文档分别说明输入上下文上限、模型输出上限、审查轮数和累计 token 预算。这些控制针对运行的不同部分。调整上下文窗口数值时，不应把它写成已经设置了完整的货币消费上限。
文件分组、规划、重试和后续审查轮数都可能增加模型工作。委派模式把推理交给宿主账号，相关费用或额度仍然存在。记录提供商与宿主实际报告的用量；某项集成没有暴露的数据，要明确留空。
把人工核对时间算进去
每次试验记录墙钟时间、模型用量、被接受的问题、漏掉的已标注缺陷，以及人工检查评论的分钟数。输出波动明显时做重复试验。评价重复评论和不确定问题的标准也应固定，不能在结果出来之后改变口径。
采用结论应该描述这份样本里的实际取舍。如果用量下降却漏掉了严重的已知缺陷，账单更低并不能单独决定是否采用。下面的记录是试验建议，其中没有填入虚构的性能或费用数据。
如何选择
| 比较维度 | 方案 A | 方案 B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
实施步骤
- 1
准备固定的小变更集，由人工独立标注缺陷。
- 2
比较配置时保持模型、范围和验收规则一致。
- 3
记录用量、耗时、漏报及人工检查时间。
可复制示例
{
"proposal": true,
"sample": "固定的人工标注变更",
"model": "记录准确型号",
"tokens": null,
"elapsedSeconds": null,
"falsePositives": null,
"missedDefects": null,
"humanMinutes": null,
"benchmarkExecuted": false
}常见问题
能否直接套用 README 的节省比例？
不能。需要使用自己的改动、模型和配置做受控比较。
委派模式免费吗？
它使用宿主助手的模型权限与额度，仍然取决于账号规则和实际用量。
资料来源
- Open Code Review / README.md来源核查 2026-09-18
- Open Code Review / pages/src/content/docs/en/architecture.md来源核查 2026-09-18
- Open Code Review / pages/src/content/docs/en/integrations/delegate.md来源核查 2026-09-18
- Open Code Review / pages/src/content/docs/en/configuration.md来源核查 2026-09-18