企业官网建设流程全解析

5 分钟接入：把阿里 open-code-review 挂进 GitHub PR，AI 初审立刻上岗

【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review

如果你的仓库正在经历“PR 排队等评审、高级工程师时间被占满、初级开发者又急需反馈”的循环，那么把 AI 评审接入 GitHub PR 是最快见效的一步。过去几年社区里关于“AI 初审”的讨论很多，但大多数方案停在 Demo 阶段：要么是纯提示词驱动的 Skill，位置漂移、覆盖不全；要么是闭源 SaaS，代码不敢外发。阿里开源的 OpenCodeReview（CLI 命令ocr）走的是另一条路——它脱胎于阿里集团内部使用两年、服务过数万开发者的官方 AI 评审工具，在发现过数百万级代码缺陷之后才被孵化开源。本文不聊架构空谈，直接用仓库里的官方 Action 配置，带你完成“复制一个 YAML 文件 → 配置 3 个密钥 → PR 自动出评审意见”的完整闭环，并解读第一份评审结果里的每一个字段。

前置准备：两类凭据，缺一不可

接入 GitHub PR 评审涉及两类凭据：一类是OCR 用来生成评审意见的 LLM 凭据，另一类是GitHub 用来把评论回贴到 PR 的写权限 token。后者由 GitHub Actions 自动注入的GITHUB_TOKEN承担，你只需要在工作流里声明pull-requests: write；真正需要你手动配置的是前者。

在仓库的Settings → Secrets and variables → Actions下，按官方示例（examples/github_actions/ocr-review.yml）配置即可：

协议选择不必纠结：官方 action.yml 同时支持llm_use_anthropic布尔推导和显式的llm_protocol（anthropic/openai/openai-responses），显式协议优先。默认还会写入llm.extra_body为{"thinking": {"type": "disabled"}}，关闭 thinking 模式以兼容各家 provider；如果你的模型需要保留 thinking，覆盖这个 input 即可，或者用llm_reasoning_effort在 OpenAI 兼容协议上单独调节推理深度（minimal到max）。

关于权限有个常被忽略的细节：官方 Action 内部会先做git fetch完整历史（fetch-depth: 0）、计算git merge-base，再以--from <merge-base> --to <head>区间模式跑评审。评审本身只读 git 对象与 diff，不执行 PR 里的任何代码——这正是它敢用pull_request_target（fork 场景也能用 secret）的前提，安全边界写死在 action.yml 的 checkout 步骤注释里：checkout 可信的 base，只单独 fetch head 的 blob，避免把不受信任的 PR 文件物化到工作区。

接入 PR 事件的最小配置示例

把下面这份 YAML 保存到.github/workflows/ocr-review.yml，推一次分支，AI 初审就上岗了：

name: OpenCodeReview PR Review on: pull_request_target: types: [opened, synchronize, reopened] permissions: contents: read pull-requests: write jobs: code-review: runs-on: ubuntu-latest timeout-minutes: 30 steps: - 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: alibaba/open-code-review@main是官方提供的 reusable composite action：安装 OCR CLI（npm install -g @alibaba-group/open-code-review）、解析 PR 引用、校验输入、运行评审、上传原始 JSON 产物、把评论贴回 PR，全部封装在一个步骤里，你不需要维护任何内联脚本。

这份最小配置已经能覆盖完整评审链路，但官方示例（examples/github_actions/ocr-review.yml）里还有两个值得抄走的增强，各解决一个真实痛点：

按需重评审。在on里追加issue_comment事件，并在 job 的if条件里限定：评论必须出现在 PR 上（github.event.issue.pull_request）、作者不是 Bot、且author_association为MEMBER/OWNER/COLLABORATOR、正文以/open-code-review或@open-code-review开头。四层守卫缺一不可——最后那层关键字只是触发条件，前面几层防止任意路过的人刷掉你的 LLM 额度。

并发取消。concurrency配置让同一 PR 的新评审取消掉正在跑的旧评审（cancel-in-progress: true），同时用noop-<run_id>独立分组保证普通对话评论不会误伤进行中的评审。这两段逻辑在示例文件里有完整注释，复制即可。

如果想锁定评审行为，记得同时 pin Action 的 commit SHA 和ocr_version（如1.9.10）——Action 只是编排器，真正跑评审的是 npm 上的 CLI，只 pin 前者并不能冻结评审行为。

跑通第一个评审意见与结果解读

PR 一开，Runner 里依次发生的事是：装 CLI →ocr config set写配置 → 区间模式跑ocr review→ 解析 JSON → 调 GitHub Pull Request Review API 回贴。官方 action.yml 里，评审产出被写到/tmp/ocr-result.json（工作流产物可下载），其结构对应--format json的标准输出：

{ "status": "success", "llm": { "provider": "anthropic", "model": "claude-opus-4-6" }, "summary": { "files_reviewed": 9, "comments": 1, "total_tokens": 21344, "input_tokens": 18012, "output_tokens": 3332, "elapsed": "1m12s" }, "comments": [ { "path": "src/foo.go", "content": "Concurrent map access without a lock — wrap with sync.RWMutex.", "start_line": 42, "end_line": 47, "existing_code": "m[k] = v", "suggestion_code": "mu.Lock(); defer mu.Unlock(); m[k] = v" } ] }

每条comments[]里的start_line/end_line是行级定位，suggestion_code是可直接照抄的修复建议。张贴脚本（scripts/github-actions/post-review-comments.js）会遍历这些条目：有行信息的走 GitHub 内联评审评论；没有行信息的（文件级发现）合并进 PR 摘要评论；内联批量 API 被拒时逐条重试并回退为普通 issue 评论。摘要评论的格式也很直观，以🔍 OpenCodeReview found N issue(s)开头，逐项列出✅ posted inline、📝 in summary、⏭️ skipped (overlap with history)、❌ failed to post。

值得留意的是每条发现的元数据——模型被要求按 internal/config/toolsconfig/tools.json 中code_comment工具的参数结构输出category（bug / security / performance / maintainability / test / style / documentation / other）和severity（critical / high / medium / low），且二者为必填。这份结构化元数据不是摆设：你可以用route_severity_below（如medium）把中低危问题从内联评论路由到 PR 摘要，route_categories按类别同样路由，实现“高危内联、低危汇总”的降噪策略，一个发现都不会丢（fail-open）。

AI 评审意见的可信度，是这类工具最容易被质疑的点。OCR 应对它的方式是“确定性工程 × Agent 混合”：

• 确定性管线负责不能出错的部分。文件筛选（决定哪些文件该审、哪些该过滤）、相关文件智能分桶（如message_en.properties与message_zh.properties捆绑成一个子任务）、规则匹配，都由工程逻辑而非大模型保证。internal/config/rules/system_rules.json 里path_rule_map按文件类型映射了 50+ 种语言的专项规则——Java 审 NPE 与并发、Go 审 goroutine、TS/JS 审原型链污染、Python 审资源泄漏，默认规则（internal/config/rules/rule_docs/default.md）的审查维度覆盖正确性、边界条件、异常处理、SQL 注入 / XSS、N+1 查询、命名与架构一致性等。
• Agent 负责动态决策的部分。带工具调用（读全文件、代码库搜索、跨文件上下文）的 agent 针对评审场景做提示词与工具集调优，而不是通用 agent 的“广而不精”。

效果如何？README（README.md）给出的 AACR-Bench 基准（50 个热门开源仓库、200 个真实 PR、10 种语言，经 80+ 资深工程师交叉标注 1505 条 ground-truth 问题）显示：与通用 agent 相比，同模型下 Precision 与 F1 显著更高，而 token 消耗只有约 1/9，评审更快——Recall 略低是有意为之的取舍，宁缺毋滥，优先压低误报噪音。

最后两个贴士，帮你把“AI 初审”定位准确：默认并发是 8 个并行子 agent，大 PR 遇到 provider 限流就调低--concurrency；把sticky_summary（默认开启）保持为true，摘要评论会在原地更新而不是每次新增一条，配合incremental只追加不与历史评论重叠的新发现，PR 越改越干净。AI 初审负责“第一遍语义审查 + 定位准确的疑问”，人类评审者接手时看到的是一份已经过滤过噪音、带行号、带修复建议的问题清单——这正是中小团队最缺的评审杠杆。

【免费下载链接】open-code-reviewSecure, fast, efficient, battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review