Open Code Review：审查范围、文件过滤与模型调用
Open Code Review 架构：从文件选择追到审查结果
跟踪确定性范围选择、模型辅助分组和审查执行，并用固定源码解释架构文档与当前过滤顺序的差异。
你将学会
- 从当前实现读取选择逻辑
- 把后续决定单独记录
- 理解分组提供的帮助
开始前需要
- 理解 Git 改动与合并基点比较
- 会使用命令行并理解模型凭据的用途
选择审查范围，解释文件排除原因，设计受控试验，并区分源码审阅和运行证据。
先看结论
- 当前源码新增了五层图示未体现的敏感路径检查。
- 删除与大小处理位于静态过滤之后。
- 入选结果不能预测提供商是否调用成功。
从当前实现读取选择逻辑
整体流程先准备配置与 Git diff，再过滤文件、组织相关改动并分派审查。在 selection.go 中，selectFiles 对每个输入 diff 产生一个决定。函数注释明确说明它是纯逻辑，预览与实际运行共享这份选择结果。
架构文档仍使用五层静态过滤的说明。固定提交中的实现已经在用户 exclude 和 include 之前加入敏感路径检查。精确顺序应以函数为准：二进制、敏感路径、用户 exclude、用户 include、扩展名白名单及默认路径规则。
把后续决定单独记录
通过静态过滤之后，selectFiles 还处理已删除文件和单文件 diff 的 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
在固定版本中定位 selectFiles 和 whyExcluded。
- 2
按实际顺序核对预览排除原因，包含敏感路径检查。
- 3
把静态选择和运行结果保存为不同记录。
可复制示例
二进制 / 敏感路径 / 用户 exclude：排除
用户 include 命中：通过静态过滤
否则：扩展名 → 默认路径
之后：删除项与单文件 diff 大小
运行时：预算、恢复与提供商结果常见问题
用户 include 是否能覆盖全部排除规则？
不能。二进制和敏感路径检查更早执行，用户 exclude 也优先于 include。
为什么保留已删除文件的变更信息？
它仍能帮助描述改动，只是没有新的文件内容可以分派审查。
资料来源
- Open Code Review / pages/src/content/docs/en/architecture.md来源核查 2026-09-18
- Open Code Review / internal/agent/selection.go来源核查 2026-09-18
- Open Code Review / internal/config/allowlist/secret_path.go来源核查 2026-09-18