--- title: "阿里 Open Code Review 零评论，审了哪些文件？" canonical: https://wavect.io/zh/blog/alibaba-open-code-review-no-comments/ language: zh description: "阿里 Open Code Review 没有评论，可能是关键测试未入选，也可能是整次审查被跳过。用同一份支付改动复现两次预览，再核对最终报告、警告与已审文件，判断能否合并。" image: "https://wavect.io/img/blog/headers/header_alibaba-open-code-review-no-comments.png" author: ["Kevin Riedl"] published: "2026-11-13" updated: "2026-11-13" reviewed: "2026-11-13" --- # 阿里 Open Code Review 没有评论，怎样确认它审了哪些文件？ [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 分钟 阅读 · 2026年11月13日 最近审核 2026年11月13日 [**下一篇**](/zh/blog/qa-for-ai-generated-code/) 要点速览 阿里 Open Code Review 返回零评论时，先核对运行状态和实际审过的文件。我们用 1.13.8 版预览一处支付改动，默认规则选中了实现，跳过了相应测试。显式纳入测试后，两个文件都进入审查范围。合并之前，仍需验证同一笔支付超时重试后只扣款一次。 一张账单，两次扣款请求，应该用同一个支付幂等键吗？我们做了一个只有两个文件的改动，让每次重试都生成新键，同时改了单元测试。Open Code Review 的默认配置选中了 Go 实现，却跳过了测试。恰好是那条被改写的断言，最能说明这次改动改变了什么约定。 ## 怎样查看 Open Code Review 选中了哪些文件？ 对这次合并请求的 Git 提交范围执行 `--preview`。预览会列出入选的文件和其余文件被排除的原因，无需调用模型。我们在 2026 年 11 月 13 日使用 1.13.8 版做了下面的实验。复现时可以先不配置 API 密钥。 [阿里发布的 v1.13.8 版本](https://github.com/alibaba/open-code-review/releases/tag/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 的文件筛选规则与优先级](https://github.com/alibaba/open-code-review/blob/v1.13.8/pages/src/content/docs/en/review-rules.md) ``` {"include":["billing/retry_test.go"]} ``` [下载双文件实验脚本](/downloads/alibaba-open-code-review-preview.sh) ，用 Bash 和本地的 v1.13.8 二进制文件运行。脚本会新建 Git 仓库并核对两次预览的结果。这次实测可以回答文件筛选问题。要判断模型能否发现支付约定被改写，还需要单独运行评审。 ## CI 报告里的 comments 是空数组，该怎么处理？ 先看最终 JSON 报告中的 `status` 和 `warnings`。跳过审查也可能得到 `"comments": []`，而退出码 0 允许出现非致命警告。把报告、Git 文件列表和预览放在一起核对，三者都应对应即将合并的提交。 [CLI 文档中的 JSON 状态、警告与退出码](https://github.com/alibaba/open-code-review/blob/v1.13.8/pages/src/content/docs/en/cli-reference.md) 我们又创建了一个只改动被排除测试文件的分支，这次去掉预览参数，直接运行评审。进程退出码为 0，报告返回 `status: skipped`、`comments: []`，实际审查文件数为零。本地服务也未收到任何模型请求。另一种情况是本地报告里明明有发现，GitHub 上却没有评论，这时应检查 Action 的发布设置和日志。 [GitHub Action 评论发布设置](https://github.com/alibaba/open-code-review/blob/v1.13.8/examples/github_actions/README.md) | 报告或进程状态 | 合并前怎么做 | | --- | --- | | `skipped` | 核对比较基准和筛选规则。关键文件被排除时，将其纳入后重新运行，或指定一人审阅。 | | `partial`、`completed_with_warnings` 或 `completed_with_errors` | 查看警告和涉及的路径。保留已完成部分的发现，对遗漏部分补跑评审或安排人工检查。 | | `failed`、致命错误或缺少报告 | 本次评审无法作为依据。查看标准错误输出，并核实磁盘上已有的报告是否来自本次运行。 | | `complete` 或 `success`，预期文件均已覆盖且零评论 | 记录本次评审在该范围没有发现问题。对扣款逻辑仍需模拟超时重试，检查账本里是否只有一笔扣款。 | 报告包含运行清单时，把 `manifest.coverage.selected` 与 `completed`、`reused`、`failed`、`waived` 中的文件路径逐一核对。对于标记为 `waived` 的文件，还要确认豁免理由是否可以接受。保存报告时记下基准提交和分支最新提交的 ID。 [v1.13.8 运行清单记录的文件覆盖情况](https://github.com/alibaba/open-code-review/blob/v1.13.8/internal/session/manifest.go) ## 选定文件后，哪些工作交给模型？ 阿里的 Go CLI 负责筛选文件、匹配规则、约束执行过程，以及把评论定位到具体的改动行。相关文件可以分在一组，各组可以并行评审。智能体则能读完整文件、查找调用方、搜索代码库，再判断是否值得指出问题。未被选作评审目标的文件，仍可能被读取以了解上下文。 [阿里的架构、集成与安装说明](https://github.com/alibaba/open-code-review/blob/v1.13.8/README.md) 据阿里介绍，这套系统的内部前身在两年间服务了数万名开发者，识别出数百万个代码缺陷。开源项目采用 Apache-2.0 许可证，GitHub 星标已超过五万。团队评估它时，可以先拿一个曾经通过现有检查、上线后才暴露的缺陷来试。 [Open Code Review 官方仓库](https://github.com/alibaba/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](https://arxiv.org/html/2608.09290v2) | 指标 | 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 生成代码的上线前测试指南](/zh/blog/qa-for-ai-generated-code/) 。如果要算托管评审服务升级审查深度的成本，可以看 [Greptile 评审预算比较](/zh/blog/greptile-base-plus-apex-review-budget/) 。 ## Open Code Review CLI 常见问题 ### 怎样安装实验使用的版本？ 准备好 Git 2.41 或更新版本，运行 `npm install -g @alibaba-group/open-code-review@1.13.8` ，再用 `ocr version` 核对。复现实验还需要 Bash 和 jq，并确保能直接调用本地 ocr 命令。只运行预览时无需配置模型。 ### 只想审查一个提交，应该用什么参数？ 给 `ocr review` 传入 `--commit` 和提交 SHA。审整个 PR 时，用 `--from` 和 `--to` 指定已拉取的两个版本。范围比较从两者的共同祖先开始，便于看到该分支引入的改动。 ### PR 只改了测试文件，也要检查筛选规则吗？ 先预览这个提交范围，再看每条排除原因。若改动的断言定义了业务规则，应显式纳入这个文件或由人工审查。即使产品代码一行未动，修改测试也会改变发布流程允许通过的行为。 ### 没有可比较的 Git 改动，能扫描整个目录吗？ 用 `ocr scan --path billing` 可以按完整文件扫描支付目录，适合了解已有代码。若要判断某个 PR 改了什么，使用该 PR 的提交范围，便于把结果追溯到具体改动。 ### 能复用现有编程智能体的模型配置吗？ 普通 CLI 评审使用 OCR 内配置的服务商和模型，支持 Anthropic 或兼容 OpenAI 的端点。委托模式则使用宿主智能体现有的模型与认证信息。比较不同运行结果时，记下各自使用的模式。 **独立性与商标声明:** 本页由 Wavect 发布，Wavect 自身也是服务商，因此我们对本页存在商业利益。我们与本页提及的其他公司没有关联，未获得其背书，也不是其合作伙伴；所有第三方公司名称、品牌与商标均归各自所有者所有。关于其他服务商的陈述来自公开可查的来源，主要是其自己发布的页面，以本页标注的核查日期为准，此后可能已经发生变化。做决定前请自行直接核实。本页依据我们所知的情况撰写，并力求保持客观。如果你认为其中有不准确或不公平之处，请写信告诉我们，我们会更正： [office@wavect.io](mailto:office@wavect.io) QA 与生产就绪 ## 接下来读什么 可靠生产软件所需的测试、审计、维护与加固。 [从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/) - [采购 LoRaWAN 水表前，如何现场验证读数和漏水报警？](/zh/blog/lorawan-water-meter-field-acceptance-test/) - [两家供应商都说开发完成，软件该怎么验收？](/zh/blog/multi-vendor-software-acceptance-testing/) - [README ZIP 恶意软件：审查 AI 工具的实际安装内容](/zh/blog/readme-zip-malware-install-review/) - [AI 生成的 Odoo 模块：先审业务规则，再谈上线](/zh/blog/ai-generated-odoo-module-audit/) - [Odoo 迁移验收：逐条核对业务记录与余额](/zh/blog/odoo-migration-acceptance-reconciliation/) [下一篇文章**采购 LoRaWAN 水表前，如何现场验证读数和漏水报警？**](/zh/blog/lorawan-water-meter-field-acceptance-test/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 5 分钟 阅读 · 2026年11月13日 最近审核 2026年11月13日 [**下一篇**](/zh/blog/qa-for-ai-generated-code/)