企业官网建设流程全解析

上一篇文章讨论了 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-review@main。

这篇文章从工程实践角度，完整拆解如何把这个工具接入你的 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-review@main 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 传入 action）：

• llm_url：LLM API 端点。兼容 OpenAI 格式和 Anthropic 格式。如果使用 Anthropic，设置为https://api.anthropic.com/v1/messages；OpenAI 兼容端点则填对应 chat completions URL。

• llm_auth_token：API 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-review@<full-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 Scanning（SARIF）

OCR 从 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-sarif@v3 with: sarif_file: ocr-report.sarif

需要security-events: write权限。SARIF 输出包含规则 ID、严重级别、文件位置和修复建议。对于安全敏感的项目，这是把 AI 审查从“PR 评论”升级为“安全质量门禁”的关键一步。

五、自定义规则：让审查标准跟着团队走

OCR 的规则解析遵循一个四级优先级链，从高到低：

1. CLI--rule标志：单次执行覆盖，适合临时调整。

2. 仓库根目录的.opencodereview/rule.json：项目级规则，跟随代码库版本化。

3. 用户级配置：~/.opencodereview/下的规则。

4. 内置规则集：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-review@main这一行代码的价值，不在于它有多复杂，而在于它足够简单，让团队可以在一个下午完成从零到可用的集成。但真正的挑战在集成之后：规则需要迭代，误报需要校准，人类审查者的角色需要重新定义。

这正是上一篇文章的核心论点在工程层面的回声——工具已经就绪，瓶颈在流程。OCR 提供了把 AI 审查嵌入 SDLC 的技术接口，但“审查”从一个人类活动变成一条 agentic 流水线，需要的是团队对工作方式的重新设计。从一个 PR 开始，从一个规则文件开始，从一条 SARIF 告警开始，让审查闭环转起来，比等一套完美的流程设计再动手更现实。