Open Code Review：审查范围、文件过滤与模型调用
Open Code Review 会把哪些内容交给模型
理解代码审查 CLI 的用途、范围选择与执行结果，并在开放仓库权限前设计一个可检查的小试验。
你将学会
- 先确定要审查的改动
- 把准备工作与模型推理分开理解
- 用已知缺陷评价评论
开始前需要
- 理解 Git 改动与合并基点比较
- 会使用命令行并理解模型凭据的用途
选择审查范围，解释文件排除原因，设计受控试验，并区分源码审阅和运行证据。
先看结论
- 审查模式决定输入的改动范围。
- 委派模式使用宿主助手的模型访问能力。
- 评价时同时记录漏报和误报。
先确定要审查的改动
Open Code Review 读取 Git 改动，准备审查范围，再调用模型生成带文件和行号的评论。助手可以继续读取仓库上下文。第一次使用时，先写清楚要审查哪次改动，以及允许审查工具读取哪些文件，这比直接运行后再看评论更容易定位问题。
默认工作区模式包含已暂存、未暂存和未跟踪的改动。单次提交模式针对一个 commit；分支范围模式比较两个引用的合并基点到目标引用的变化。即使工作目录没有变化，切换这些模式也可能得到不同的输入。
把准备工作与模型推理分开理解
常规模式由 OCR 管理已配置的模型连接。委派模式则输出文件选择和审查规则，交给现有编码助手完成推理。模型任务在哪个系统里执行、使用哪个账号的额度，都会随之改变，接入时应明确记录。
README 声明项目采用 Apache-2.0 许可。项目许可并不包含模型凭据，也不代表公司允许向外部服务上传私有代码。开始审查业务仓库之前，仍然需要确认模型使用权限和源代码的数据处理要求。
用已知缺陷评价评论
准备一个可丢弃的小仓库，放入一个刻意构造的缺陷和一处无害改动。保存入选文件、模型评论及人工判断。这样可以区分两类漏报：文件根本没进入审查，或者文件进入了审查但模型没有识别出问题。
本系列固定在提交 189be5b，并执行了 15 个隔离 Go 案例，检查 .env 文件名函数及调用方的小写处理。没有执行完整 CLI 或真实模型调用，因此这些测试只能说明局部路径判定行为，不能证明审查准确率。
如何选择
| 比较维度 | 方案 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
保存入选文件，逐条核对评论与实际改动。
可复制示例
ocr delegate preview
ocr delegate rule src/example.go常见问题
安装 OCR 会附带可用模型吗？
常规审查需要配置模型提供商；委派模式需要宿主助手已经具备模型访问能力。
没有评论是否说明改动安全？
不能这样判断。还要检查文件选择、执行结果，以及所用审查方法的能力限制。
资料来源
- Open Code Review / README.md来源核查 2026-09-18
- Open Code Review / pages/src/content/docs/en/integrations/delegate.md来源核查 2026-09-18
- Open Code Review / internal/agent/selection.go来源核查 2026-09-18