Open Code Review：审查范围、文件过滤与模型调用
部署 Open Code Review：分开管理模型凭据和评论权限
准备固定版本的 CLI 部署，保护配置文件，并在 CI 中分别管理模型访问和发布审查评论的权限。
你将学会
- 记录发行版本与配置
- 区分两种凭据的职责
- 提前准备回退步骤
开始前需要
- 理解 Git 改动与合并基点比较
- 会使用命令行并理解模型凭据的用途
选择审查范围，解释文件排除原因，设计受控试验，并区分源码审阅和运行证据。
先看结论
- 模型调用和评论发布使用不同权限。
- 凭据读取命令让配置文件成为执行输入。
- CI 发布结果需要单独验收。
记录发行版本与配置
可复现部署需要记录 CLI 版本、运行环境、Git 版本和提供商协议。固定源码的 go.mod 声明 Go 1.25.5；从源码编译的准备过程，与安装发行二进制或 npm 包并不相同，应按实际路径记录依赖。
把配置放在只有指定操作人员能够写入的位置。文档中的 api_key_cmd 会执行命令来读取凭据，因此修改配置可能影响执行内容。审阅这类部署输入时，要像审阅其他可执行配置一样检查来源与写权限。
区分两种凭据的职责
CI 使用模型凭据生成问题报告，使用代码平台权限发布评论。这是两项不同的权限。试运行可以先关闭评论发布，只保存私有产物，让团队检查结果质量和数据处理，再决定是否授予评论写入能力。
上游 CI 文档介绍了 pull_request_target 和评论触发方式。这些任务可能处于有权限的运行上下文，复制示例前需要检查检出策略、依赖安装和密钥访问。读取不可信拉取请求时，不应顺带执行其中代码并把高权限凭据交给它。
提前准备回退步骤
先在一个仓库中启用有限触发条件，保存原来的包版本、配置与权限设置。若试运行产生大量噪声或意外数据访问，可以停用触发器并恢复这些设置，同时保留脱敏后的诊断记录，避免只能边运行边猜测。
分别检查进程是否成功、JSON 是否有效，以及评论是否真正发布。CI 文档包含内联评论发布失败后的回退处理，所以一次完成的审查可能最终显示为汇总评论。把平台返回结果纳入验收，才能解释用户实际看到了什么。
如何选择
| 比较维度 | 方案 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
固定经过审阅的发行版本，记录 Git 和提供商配置。
- 2
先使用合成或获准代码试运行，关闭自动评论发布。
- 3
验证失败处理，并保留旧版本和权限配置用于回退。
可复制示例
{
"proposal": true,
"release": "记录经过审核的发行版本",
"modelAccess": "获准的模型凭据",
"commentPublication": false,
"rollback": "旧版本及原配置",
"executed": false
}常见问题
首次部署是否应该自动发布所有问题？
先保存私有产物，有助于检查准确性和数据处理，再决定是否启用发布。
审查成功是否等于内联评论发布成功？
不是。需要另外检查平台响应，以及是否回退到了汇总评论。
资料来源
- Open Code Review / README.md来源核查 2026-09-18
- Open Code Review / go.mod来源核查 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