Open Code Review：审查范围、文件过滤与模型调用
运维 Open Code Review：不要把路径排除当成内容审计
理解路径过滤的保护范围、配置执行命令的风险，以及有权限 CI 审查需要单独检查的操作边界。
你将学会
- 检查常见文件名以外的敏感内容
- 把配置视为可能执行命令的输入
- 限制审查结果能够触发的操作
开始前需要
- 理解 Git 改动与合并基点比较
- 会使用命令行并理解模型凭据的用途
选择审查范围，解释文件排除原因，设计受控试验，并区分源码审阅和运行证据。
先看结论
- 路径排除不读取源文件里的敏感值。
- 凭据命令使配置具有执行作用。
- 评论结果不能自动授予合并权限。
检查常见文件名以外的敏感内容
内置敏感路径检查位于用户 include 之前，并同时检查旧路径与新路径。这保护了选择范围中已知的敏感文件名模式，但不能识别普通源文件内的每个秘密值；实现也明确将该函数限制为路径判定。
学习时使用合成数据，再定义哪些仓库和数据类型允许交给获准模型。检查入选材料与提供商的数据处理条件。对嵌在源码或历史变更中的凭据，另设内容检查流程，不依赖文件名是否看起来安全。
把配置视为可能执行命令的输入
文档中的 api_key_cmd 会运行命令，并把输出用作凭据。配置文件的归属和写权限因此很重要。不要接收拉取请求中未经审核的配置，再在有权限的 runner 内执行它指定的凭据命令。
配置指南还说明了静态密钥、密钥命令和提供商环境变量之间的优先级。诊断时应确认实际使用哪种来源，但不打印凭据。删掉一个设置后，另一个已配置来源可能开始生效，并不意味着访问能力已经被关闭。
限制审查结果能够触发的操作
生成的评论和仓库中的说明，对于后续自动化都属于需要检查的输入。合并代码等重要操作应保留人工审批。若要发布评论，只授予该发布步骤所需权限，并检查代码平台的实际返回结果。
日志和审查产物可能包含源码或敏感上下文，应按相应的数据级别保存。发生事件时停用触发器，保留脱敏诊断证据，并按正常账号流程轮换受影响凭据。隔离路径测试不能替代这些运维控制。
如何选择
| 比较维度 | 方案 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
分开管理评论发布与合并授权，并准备停用流程。
可复制示例
{
"policyExample": true,
"approvedRepositories": [
"synthetic-demo"
],
"publishComments": false,
"automaticMerge": false,
"configurationWritableBy": "指定操作人员",
"logSecrets": false,
"securityAuditExecuted": false
}常见问题
模板例外能证明文件没有密钥吗？
不能。例外取决于名称，不检查存储在文件里的值。
排查认证时能否直接打印完整配置？
避免输出秘密值。使用脱敏诊断确认提供商和凭据来源。
资料来源
- Open Code Review / internal/agent/selection.go来源核查 2026-09-18
- Open Code Review / internal/config/allowlist/secret_path.go来源核查 2026-09-18
- Open Code Review / pages/src/content/docs/en/configuration.md来源核查 2026-09-18
- Open Code Review / pages/src/content/docs/en/integrations/ci.md来源核查 2026-09-18