上一篇文章讨论了 Anthropic《AI-Native SDLC Playbook》的核心诊断代码不再是瓶颈SDLC 才是。当 agent 开始批量产出 PR 时逐行人工审查从“质量保障”变成了“吞吐量杀手”。LinearB 的数据显示AI 使用强度高的团队合并 PR 数量增加了 98%但审查时间涨了 91%PR 等待第一次审查的时间是普通代码的 4.6 倍。出路不是放弃审查而是把审查本身也变成一条 agentic 流水线。阿里巴巴开源的open-code-review简称 OCR正是这条流水线的一个工程落地。它源自阿里内部经过两年生产验证的 AI 代码评审系统已服务数万名开发者识别过数百万代码缺陷。而它的 GitHub Actions 集成方式简单到只需要在 workflow 里加一个uses: alibaba/open-code-reviewmain。这篇文章从工程实践角度完整拆解如何把这个工具接入你的 PR 流程以及它在 AI-Native SDLC 中扮演的角色。一、先理解 OCR 做了什么确定性管线 LLM Agent在接入 CI 之前需要理解 OCR 的架构。它不是简单地把git diff丢给一个聊天模型。它的工作方式是两段式的第一段是确定性规则管线。OCR 先用一套内置规则集对变更文件做筛选和分类。这套规则集覆盖 NPE空指针风险、SQL 注入、XSS 漏洞、线程安全问题等常见缺陷模式。这一步不消耗 LLM token成本为零作用是先把明显低价值的内容排除掉让后续的 LLM 审查只聚焦在真正需要判断的变更上。第二段是LLM Agent 审查。通过规则筛选的文件进入 LLM 审查环节OCR 将每个文件的精确规则文本和 diff 内容组合后发送给配置的模型产出带有行号定位的审查意见。规则是按文件路径匹配的这意味着同一个仓库里不同目录可以遵循不同的审查标准。这种“先确定性过滤、再 LLM 判断”的混合架构是 OCR 区别于通用 AI 审查工具的关键。它把 LLM 最擅长的部分理解上下文、发现非显而易见的逻辑问题和确定性管线最擅长的部分模式匹配、成本控制分开了。二、GitHub Actions 集成从零到可用的最短路径OCR 仓库在examples/github_actions/下提供了一个可直接复制的工作流模板ocr-review.yml。整个集成只需要三步。2.1 复制工作流文件mkdir -p .github/workflows cp ocr-review.yml .github/workflows/ocr-review.yml这个模板的核心是一个 composite action 调用- uses: alibaba/open-code-reviewmain with: llm_url: ${{ secrets.OCR_LLM_URL }} llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }} llm_model: ${{ vars.OCR_LLM_MODEL }} llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }}这个uses步骤内部完成了所有事情checkout 代码、安装ocrCLI通过 npm、配置 LLM 连接、计算merge-base(from, to)..to的 diff 范围、运行审查、解析 JSON 输出、通过 GitHub Pull Request Review API 把每条意见发布为行内审查评论并将无行号信息的意见写入汇总评论。2.2 配置必要的 Secrets 和 Variables需要配置两类凭据LLM 凭据作为 Secrets 或 Variables 传入 actionllm_urlLLM API 端点。兼容 OpenAI 格式和 Anthropic 格式。如果使用 Anthropic设置为https://api.anthropic.com/v1/messagesOpenAI 兼容端点则填对应 chat completions URL。llm_auth_tokenAPI key。llm_model模型名称如claude-opus-4-6。llm_use_anthropic设为true时走 Anthropic 原生格式否则按 OpenAI 兼容格式请求。GitHub 令牌模板默认使用${{ github.token }}不需要额外配置。如果你希望审查评论以独立 bot 身份发布可以配置一个 PAT 并传给github_token输入。2.3 理解触发机制模板监听两类事件on: pull_request_target: types: [opened, synchronize, reopened] issue_comment: types: [created]pull_request_target的选择是一个关键设计决策。用pull_request时fork 仓库发起的 PR 无法读取仓库 Secrets审查会因缺少 LLM 凭据而失败。pull_request_target让 workflow 在基仓库上下文中运行可以访问 Secrets。安全性由 OCR 的设计保证它只读取 diff 内容从不执行 PR 中的代码。但需要注意如果 workflow 中有其他步骤 checkout 了 PR 的代码并执行仍然存在安全风险。OCR 模板本身是安全的但不要在这个 workflow 中随意添加执行 PR 代码的步骤。issue_comment触发器让审查者可以在 PR 评论中输入/open-code-review或open-code-review来按需重新审查。对于大型 PR 或 agent 修复后需要复查的场景这比等待下一次 push 触发的自动审查更灵活。三、参数详解与可调项3.1from/to的工作方式你给出的配置with: from: main to: ${{ github.head_ref }}from和to对应 OCR CLI 的--from和--to标志。OCR 计算的是merge-base(from, to)..to的 diff而不是简单的from..to。这意味着如果 feature 分支是从 main 的某个旧提交拉出来的审查范围只包含 feature 分支真正引入的变更不会把 main 上已有的历史变更算进来。在 CI 环境中from更稳妥的写法是使用远端引用from: origin/main to: origin/${{ github.head_ref }}原因是 runner 上 checkout 的本地main可能不是最新的。使用origin/main确保 diff 的基准是远端最新状态。不过 OCR 的 action 模板内部已经处理了 checkout 策略直接使用main和github.head_ref也可以工作。3.2 其他值得关注的输入action.yml定义的输入还包括ocr_version固定ocrCLI 的版本。默认是latest。如果你希望审查行为在多次运行中完全可复现应该同时固定 action 的 commit SHA 和ocr_version例如uses: alibaba/open-code-reviewfull-commit-sha配合ocr_version: 1.9.3。因为 action 本身只是一个 orchestrator它在运行时从 npm 拉取 CLI不固定 CLI 版本的话审查逻辑会随新版本发布而改变。sticky_summary设为true时汇总评论以“sticky”方式发布——每次审查更新同一条评论而不是不断新增评论。incremental增量审查模式。当 PR 被 push 新提交后只审查新增的变更范围而不是重新审查整个 PR。upload_artifacts是否将审查 session 和 JSON 输出作为 GitHub Actions artifacts 上传便于后续排查。llm_extra_body向 LLM API 请求中注入额外参数比如 temperature 或 max_tokens。四、把审查结果接入 GitHub Code ScanningSARIFOCR 从 v1.9.3 开始支持SARIF v2.1.0输出格式。这是 OASIS 标准GitHub Code Scanning 可以直接消费。SARIF 的意义在于审查结果不再只是 PR 上的一次性评论而是变成了持久化的安全告警。如果一个 NPE 风险在 PR 审查时被标记为“建议修复”但团队决定先合并这条告警会进入 GitHub Security 标签页的 Code Scanning 列表不会被后续的 PR 活动冲掉。下一次有人在同一个文件同一行引入类似问题时Code Scanning 会显示历史关联。使用方式是在 workflow 中单独加一个步骤- name: Run OCR with SARIF output run: | ocr review \ --from origin/${{ github.base_ref }} \ --to origin/${{ github.head_ref }} \ --format sarif \ --output ocr-report.sarif - name: Upload SARIF uses: github/codeql-action/upload-sarifv3 with: sarif_file: ocr-report.sarif需要security-events: write权限。SARIF 输出包含规则 ID、严重级别、文件位置和修复建议。对于安全敏感的项目这是把 AI 审查从“PR 评论”升级为“安全质量门禁”的关键一步。五、自定义规则让审查标准跟着团队走OCR 的规则解析遵循一个四级优先级链从高到低CLI--rule标志单次执行覆盖适合临时调整。仓库根目录的.opencodereview/rule.json项目级规则跟随代码库版本化。用户级配置~/.opencodereview/下的规则。内置规则集NPE、SQL 注入、XSS、线程安全等默认规则。对于团队实践把.opencodereview/rule.json提交到仓库是最重要的。它让审查标准成为代码的一部分——新成员加入时审查标准不需要口口相传rule.json本身就是文档。规则的内容可以是内联文本也可以指向一个 Markdown 检查清单文件让“审查标准”保持可读、可审查。一个典型的.opencodereview/rule.json结构大致是规则数组每条规则指定适用的文件模式如**/*.go、src/api/**和对应的审查指令。这意味着你可以为 API 层配置更严格的空指针和输入校验规则为前端目录配置 XSS 和敏感信息泄露规则互不干扰。六、回到 SDLC审查闭环在 AI-Native 流程中的位置把 OCR 接入 CI 的工程意义需要放在上一篇文章讨论的 AI-Native SDLC 框架里理解。Anthropic 的 Playbook 主张每个阶段的产物应该写入版本控制下一阶段从读取产物开始。在 Build 阶段产物是代码 diff 和plan.md在 Test/Review 阶段产物是带审查结论的 PR。OCR 做的事情正是把“审查结论”从一个人的主观判断变成一条结构化、可追溯、可版本化的产物——每条意见有规则来源、有行号定位、有 severity 等级。更重要的是它把人类的注意力从“逐行阅读”上移到了“判断意图和风险”。当确定性管线已经过滤掉低价值内容LLM Agent 已经生成了结构化意见人类审查者的工作从“这行代码有没有问题”变成了“这个 Agent 提出的风险是否在这个业务上下文中成立”。这是两种完全不同的认知负荷。当然OCR 不是替代人类审查。它处理的是模式可识别、规则可表达的问题——NPE、注入、线程安全。架构决策的合理性、产品逻辑的正确性、跨模块影响的判断仍然需要人类。但在 agent 大量产出代码的环境下先让机器处理机器擅长的事是人类审查者保持判断力的前提。Anthropic 的 Playbook 在度量一节留了一个空白如何把审查时间、审查深度、误报率这些指标关联起来。OCR 的 session 持久化机制ocr session list、session compare提供了在这个方向上做度量的基础。你可以追踪每次审查产出了多少条意见、哪些规则触发频率最高、随着规则迭代误报率是否下降。这些数据本身就是 SDLC 度量体系的一部分。结语从“工具可用”到“流程可用”uses: alibaba/open-code-reviewmain这一行代码的价值不在于它有多复杂而在于它足够简单让团队可以在一个下午完成从零到可用的集成。但真正的挑战在集成之后规则需要迭代误报需要校准人类审查者的角色需要重新定义。这正是上一篇文章的核心论点在工程层面的回声——工具已经就绪瓶颈在流程。OCR 提供了把 AI 审查嵌入 SDLC 的技术接口但“审查”从一个人类活动变成一条 agentic 流水线需要的是团队对工作方式的重新设计。从一个 PR 开始从一个规则文件开始从一条 SARIF 告警开始让审查闭环转起来比等一套完美的流程设计再动手更现实。
