本文内容
阿里 Open Code Review 没有评论，怎样确认它审了哪些文件？
一张账单，两次扣款请求，应该用同一个支付幂等键吗？我们做了一个只有两个文件的改动，让每次重试都生成新键，同时改了单元测试。Open Code Review 的默认配置选中了 Go 实现，却跳过了测试。恰好是那条被改写的断言，最能说明这次改动改变了什么约定。
怎样查看 Open Code Review 选中了哪些文件？
对这次合并请求的 Git 提交范围执行 --preview。预览会列出入选的文件和其余文件被排除的原因，无需调用模型。我们在 2026 年 11 月 13 日使用 1.13.8 版做了下面的实验。复现时可以先不配置 API 密钥。阿里发布的 v1.13.8 版本
git diff --name-only main...HEAD
ocr review --from main --to HEAD --preview --format json两条命令比较的是同一对提交。在 main 分支上，账单 inv-42 的两次请求共用一个键。改动后，请求分别带上 inv-42-1 和 inv-42-2，测试也改成了要求两个键必须不同。如果支付渠道靠这个键识别重复请求，首次扣款成功但响应超时，重试便可能再次扣款。改后的测试会接受这种实现。
| 改动文件 | 默认规则 | 显式纳入该测试后 |
|---|---|---|
billing/retry.go | 选中 | 选中 |
billing/retry_test.go | 排除（default_path） | 选中 |
第二次预览沿用原来两个提交，只在本地 .opencodereview/rule.json 中单独纳入这个测试。待审文件从一个增加到两个。这样可以保留其他默认排除规则，只调整这条支付链路的审查范围。v1.13.8 的文件筛选规则与优先级
{"include":["billing/retry_test.go"]}下载双文件实验脚本，用 Bash 和本地的 v1.13.8 二进制文件运行。脚本会新建 Git 仓库并核对两次预览的结果。这次实测可以回答文件筛选问题。要判断模型能否发现支付约定被改写，还需要单独运行评审。
CI 报告里的 comments 是空数组，该怎么处理？
先看最终 JSON 报告中的 status 和 warnings。跳过审查也可能得到 "comments": []，而退出码 0 允许出现非致命警告。把报告、Git 文件列表和预览放在一起核对，三者都应对应即将合并的提交。CLI 文档中的 JSON 状态、警告与退出码
我们又创建了一个只改动被排除测试文件的分支，这次去掉预览参数，直接运行评审。进程退出码为 0，报告返回 status: skipped、comments: []，实际审查文件数为零。本地服务也未收到任何模型请求。另一种情况是本地报告里明明有发现，GitHub 上却没有评论，这时应检查 Action 的发布设置和日志。 GitHub Action 评论发布设置
| 报告或进程状态 | 合并前怎么做 |
|---|---|
skipped | 核对比较基准和筛选规则。关键文件被排除时，将其纳入后重新运行，或指定一人审阅。 |
partial、completed_with_warnings 或 completed_with_errors | 查看警告和涉及的路径。保留已完成部分的发现，对遗漏部分补跑评审或安排人工检查。 |
failed、致命错误或缺少报告 | 本次评审无法作为依据。查看标准错误输出，并核实磁盘上已有的报告是否来自本次运行。 |
complete 或 success，预期文件均已覆盖且零评论 | 记录本次评审在该范围没有发现问题。对扣款逻辑仍需模拟超时重试，检查账本里是否只有一笔扣款。 |
报告包含运行清单时，把 manifest.coverage.selected 与 completed、reused、failed、waived 中的文件路径逐一核对。对于标记为 waived 的文件，还要确认豁免理由是否可以接受。保存报告时记下基准提交和分支最新提交的 ID。 v1.13.8 运行清单记录的文件覆盖情况
选定文件后，哪些工作交给模型？
阿里的 Go CLI 负责筛选文件、匹配规则、约束执行过程，以及把评论定位到具体的改动行。相关文件可以分在一组，各组可以并行评审。智能体则能读完整文件、查找调用方、搜索代码库，再判断是否值得指出问题。未被选作评审目标的文件，仍可能被读取以了解上下文。阿里的架构、集成与安装说明
据阿里介绍，这套系统的内部前身在两年间服务了数万名开发者，识别出数百万个代码缺陷。开源项目采用 Apache-2.0 许可证，GitHub 星标已超过五万。团队评估它时，可以先拿一个曾经通过现有检查、上线后才暴露的缺陷来试。Open Code Review 官方仓库
使用同一个模型，Open Code Review 和 Claude Code 各找到了多少问题？
在阿里使用 200 个真实 PR 的评测中，Open Code Review 给出的评论更容易命中已标注缺陷，Claude Code 找到的已知缺陷总数更多。下表选取同用 Claude Opus 4.6 的两组结果。作者 8 月公布的评测涉及 50 个代码库、10 种语言，共有 1,505 个标注问题。OpenCodeReview 论文的实验设置与表 3
| 指标 | Open Code Review 1.3.1 | Claude Code 2.1.169 |
|---|---|---|
| 精确率 | 33.90% | 7.23% |
| 召回率 | 20.00% | 28.90% |
| F1 分数 | 25.10% | 11.57% |
| 每个 PR 平均消耗的 token 数 | 385,000 | 5,664,000 |
在这 1,505 个已标注问题中，Open Code Review 命中了 301 个，Claude Code 命中了 435 个。精确率较高意味着收到评论时更值得花时间核查。召回率较低，则说明对重复扣款这类代价高的错误，仍应保留独立测试。要知道当前版本在自己的支付系统上表现如何，还得用自己的样本验证。
这次支付改动要满足什么条件才能合并？
请支付业务负责人先确认重试的含义。第一次请求已经扣款，只是响应超时，那么对同一张账单再发一次请求后，账本仍应只有一笔扣款。执行这个场景，再查实际账目。改过的单元测试只验证了两次调用会返回不同的字符串。
试用这款工具时，可以选一个曾经修复过的重试缺陷，再找一份相似但正确的改动。向评审工具隐藏修复答案，记下它审过的路径，再让工程师核查评论。想把验证范围扩展到用户流程，可参考AI 生成代码的上线前测试指南。如果要算托管评审服务升级审查深度的成本，可以看Greptile 评审预算比较。
Open Code Review CLI 常见问题
怎样安装实验使用的版本？
npm install -g @alibaba-group/[email protected]，再用 ocr version 核对。复现实验还需要 Bash 和 jq，并确保能直接调用本地 ocr 命令。只运行预览时无需配置模型。只想审查一个提交，应该用什么参数？
ocr review 传入 --commit 和提交 SHA。审整个 PR 时，用 --from 和 --to 指定已拉取的两个版本。范围比较从两者的共同祖先开始，便于看到该分支引入的改动。PR 只改了测试文件，也要检查筛选规则吗？
没有可比较的 Git 改动，能扫描整个目录吗？
ocr scan --path billing 可以按完整文件扫描支付目录，适合了解已有代码。若要判断某个 PR 改了什么，使用该 PR 的提交范围，便于把结果追溯到具体改动。能复用现有编程智能体的模型配置吗？
独立性与商标声明: 本页由 Wavect 发布，Wavect 自身也是服务商，因此我们对本页存在商业利益。我们与本页提及的其他公司没有关联，未获得其背书，也不是其合作伙伴；所有第三方公司名称、品牌与商标均归各自所有者所有。关于其他服务商的陈述来自公开可查的来源，主要是其自己发布的页面，以本页标注的核查日期为准，此后可能已经发生变化。做决定前请自行直接核实。本页依据我们所知的情况撰写，并力求保持客观。如果你认为其中有不准确或不公平之处，请写信告诉我们，我们会更正： [email protected]