local-deep-research AI Code Reviewer 部署指南基于 OpenRouter 的自动化 PR 评审工作流【免费下载链接】local-deep-research~95% on SimpleQA (e.g. Qwen3.6-27B on a 3090). Supports all local and cloud LLMs (llama.cpp, Ollama, Google, ...). 10 search engines - arXiv, PubMed, your private documents. Everything Local Encrypted.项目地址: https://gitcode.com/GitHub_Trending/lo/local-deep-research本文以仓库内 docs/AI_Code_Reviewer_Setup.md 为核心骨架结合.github/workflows/ai-code-reviewer.yml、.github/scripts/combine-ai-reviews.sh 与 .github/ai-review-label-policy.json 等源码实现完整讲解如何为 GitHub 仓库搭建打标签即触发的 AI 代码评审系统。读完本文你将掌握 OpenRouter API Key 的接入、仓库 Secrets/Variables 的全部配置项、多模型并行评审、标签建议与 opt-in CI 的安全交接机制以及评审结果如何以单条 sticky 评论的形式沉淀在 PR 上。一、这套系统解决什么问题AI PR 评审概览AI Code Reviewer 是一套运行在 GitHub Actions 上的自动化 PR 评审系统当维护者为 PR 手动添加ai_code_review标签后工作流会把 PR 的 diff 发送给 OpenRouter 上托管的 LLM由模型从四个维度给出综合性评审最终以一条完整评论的形式发布在该 PR 上。评审覆盖的范围包括安全 —— 硬编码密钥secrets、SQL 注入、XSS、认证缺陷、输入校验缺失性能⚡ —— 低效算法、N1 查询、内存问题、阻塞式操作代码质量 —— 可读性、可维护性、错误处理、命名规范最佳实践 —— 编码标准、恰当的设计模式、类型安全、死代码。一个关键设计是评审结果聚合为单条评论而不是逐文件逐行地刷屏保证维护者在 PR 页面上只需读一条结构化反馈即可。从 .github/workflows/ai-code-reviewer.yml 的头部注释可以看到这条工作流的演进史早期的自动触发opened/synchronize/ready_for_review版本会在每次 push 时消耗评审 API 配额而且一旦出现计费故障HTTP 402所有 PR 都会挂上红叉。因此当前版本改为显式 opt-in只有ai_code_review标签才能触发评审评审结束后该标签会被自动移除重新添加即可再次触发。二、工作流架构与触发原理源码视角整个评审链路以 .github/workflows/ai-code-reviewer.yml 为入口核心执行步骤如下触发事件为pull_request_target的labeled类型见该文件第 30-31 行。之所以用pull_request_target而非pull_request是因为 fork 仓库发起的 PR 在pull_request事件下拿不到 secretsOPENROUTER_API_KEY且只有只读 token评审既无法调用模型也无法发评论。使用pull_request_target的前提是两条必须同时成立的安全不变量下文安全设计小节详述。并发控制以 PR 编号为键做 per-PR 并发限制并开启cancel-in-progress——评审进行中再次添加标签会取消过时的运行而不同 PR 之间互不影响。工作流还处理了一个边界情况labeled事件会对每一个新增标签触发但任务级if只在标签是ai_code_review时才继续跳过事件被路由到带run_id后缀的独立并发组从而不会误取消真正在跑的评审。权限最小化顶层permissions: {}为空任务内仅声明contents: read、pull-requests: write、issues: writeruns-on: ubuntu-latest超时timeout-minutes: 30。取 diff通过git fetch origin $BASE_REF refs/pull/$PR_NUMBER/head:refs/remotes/origin/pr-head把 PR head可能是 fork 代码仅作为数据拉取然后git diff origin/$BASE_REF...origin/pr-head --no-color diff.txt。PR head 从不被 checkout、从不执行base 分支才是 checkout 的对象——这是 fork PR 场景下的安全底线。下载评审脚本从 Friendly-AI-Reviewer 仓库的固定 commite7fe618a下载ai-reviewer.sh并用 SHA-256 校验和做完整性验证防止 CDN 篡改。并行评审按AI_REVIEW_MODELS逗号分隔的模型列表为每个模型并行启动一个ai-reviewer.sh进程每个评审者输出到独立的resp_i.json/err_i.log/code_i文件保证 Reviewer N 编号稳定、输出不交错。结果装配调用 .github/scripts/combine-ai-reviews.sh 把所有评审者输出合并为评论正文、标签集合、pass/fail 决策与成功计数。发布与收尾以贴住式sticky单评论形式发布/更新评审结果添加策略允许的标签移除ai_code_review标签最后清理全部中间文件。三、第一步获取 OpenRouter API Key评审调用的是 OpenRouter 上的公开模型因此需要一个 OpenRouter 账号与 API Key打开 OpenRouter 官网并注册或登录进入 API Keys 管理页面创建一个新 API Key复制该 Key以sk-or-v1-...开头。说明原文档对 OpenRouter 的访问入口、模型列表与计费查询给出了官方站点链接本文按仓库内容直接以文字描述操作路径实际使用时请以 OpenRouter 当前控制台为准。四、第二步把 API Key 写入 GitHub Secrets评审脚本通过环境变量读取密钥因此必须在仓库层面配置 Secret进入仓库页面打开Settings → Secrets and variables → Actions点击New repository secret名称填OPENROUTER_API_KEY必须与 .github/workflows/ai-code-reviewer.yml 第 120 行OPENROUTER_API_KEY: ${{ secrets.OPENROUTER_API_KEY }}完全一致粘贴上一步复制的 API Key点击Add secret保存。Secrets 会被 GitHub 加密存储运行时只以环境变量形式注入到工作流进程不会出现在日志中。五、第三步通过仓库 Variables 配置评审行为无需改动工作流工作流已内置合理默认值。与 Secrets 不同以下是仓库变量repository variables用于调整模型与评审参数。配置路径为仓库 →Settings → Secrets and variables → Actions→ 打开Variables标签页 →New repository variable。5.1 核心变量变量默认值作用AI_REVIEW_MODELS未设置时依次回退到AI_MODEL再回退到内置默认moonshotai/kimi-k2-thinking逗号分隔的模型列表。每个模型独立执行一次完整评审所有结果合并到同一条评论中见多评审模型小节AI_MODELmoonshotai/kimi-k2-thinking单个模型名。在AI_REVIEW_MODELS未设置时被评审工作流使用同时被 release-notes 工作流.github/workflows/release.yml 第 1295 行同样回退到moonshotai/kimi-k2-thinking使用因此必须保持是单个模型AI_TEMPERATURE0.1采样随机性控制。默认低温度以保证评审输出的稳定一致AI_MAX_TOKENS64000模型回复的最大 token 数对应评审正文的长度上限MAX_DIFF_SIZE800000约 800KB允许送入评审的 diff 最大字节数超过即报 Diff is too large以上变量在 .github/workflows/ai-code-reviewer.yml 第 126-129 行通过${{ vars.X || 默认值 }}的写法读取即变量未设置则使用默认值。5.2 工作流还支持的更多变量原文档只列举了上表 5 个变量源码中还暴露了另外 4 个可选变量一并列出便于完整调优变量默认值作用EXCLUDE_FILE_PATTERNS*.lock,*.min.js,*.min.css,package-lock.json,yarn.lock从评审中排除的路径/文件模式避免把锁文件、压缩产物送入模型STRUCTURED_OUTPUTtrue是否要求模型以结构化 JSONreview / fail_pass_workflow / labels_added输出DEBUG_MODEfalse设为true时在日志中输出每个评审者的原始响应与 stderr用于排查问题FAIL_ON_REQUESTED_CHANGES未设置关闭设为true时若任意评审者给出 fail 判定工作流最终失败见下文决策聚合逻辑其中FAIL_ON_REQUESTED_CHANGES的聚合语义很关键.github/scripts/combine-ai-reviews.sh 第 312-317 行只要任何一个有效评审者判定fail整体决策即为 fail。这是刻意设计的 any 而非多数表决——一个模型抓到了真实的阻塞性问题不应被其他模型的通过票淹没。同时评审出错而非给出判定的评审者永远不计入 fail它只会在该评审者的小节里显示一条失败说明。该开关默认关闭只有你主动 opt-in 才生效。六、多评审模型让多个模型并行评审同一份 diff把AI_REVIEW_MODELS设为逗号分隔的多个模型即可让多个模型评审同一份 diff。例如minimax/minimax-m3, z-ai/glm-5.2使用时有几条重要约束原文档明确强调源码亦有对应实现必须用逗号分隔逗号两侧的空格会被自动裁剪但用空格分隔会被当作一个整体模型名并导致失败。工作流第 147-156 行用IFS, read -ra拆分再用参数展开逐项去除首尾空白并丢弃空条目若最终模型列表为空则直接报错退出。匿名展示每个模型在评论中显示为Reviewer 1、Reviewer 2、……模型到编号的映射只出现在工作流日志中。这样读者评判的是反馈内容本身而不是因为是某知名模型所以可信。结果合一所有评审汇集到同一条 sticky PR 评论中被批准的标签建议按评审者取并集未知标签与控制类标签被丢弃。并行执行所有模型并发运行任务整体耗时等于最慢的单次评审而非总和第 170-184 行逐个后台启动并wait。但每个模型仍会各自发起一组 GitHub API 调用获取上下文因此模型列表过长会导致并发调用过多两到三个模型完全在限额之内。fail 聚合FAIL_ON_REQUESTED_CHANGES开启时任一评审者判定变更请求即失败出错而非返回判定的评审者不计入失败。七、使用方式触发、重跑与查看结果7.1 触发一次评审评审是 per-PR 的显式操作打开目标 PR 页面点击Labels添加标签ai_code_review。工作流随即自动启动完成后将结果以评论形式发布。触发后ai_code_review标签会被自动移除.github/workflows/ai-code-reviewer.yml 第 298-304 行这个标签在 .github/labels.yml 中被明确标记为 Maintainer-only仅限维护者使用防止任意贡献者消耗评审额度。7.2 重跑评审代码改动后想重新评审移除ai_code_review标签再次添加ai_code_review标签。这会对 PR 的当前状态生成一份全新评审。由于并发控制是 per-PR 的评审运行中重新添加标签会取消过时的运行。7.3 评审结果一条 sticky 评论评审完成后AI 会发布一条覆盖全部关注点的综合评论。这条评论是贴住式的sticky后续每次重新评审时工作流通过隐藏标记!-- ai-code-review:sticky --定位已有评论并原地更新PATCH而不是每条 push 叠加一条新评论第 231-248 行。该标记确保只操作机器人自己的评论绝不触碰人类或其他 bot 的评论评论末尾还会附带_Last reviewed at commit sha7_一行标明当前评论对应的是哪次提交因为 GitHub 对原地编辑只显示模糊的 edited。需要强调的是AI 评审是辅助人类评审者而不是取代他们。7.4 标签建议与 opt-in CISuggested CI评审者可以建议语义化标签但只能建议仓库自有允许清单内的标签。允许清单由 .github/ai-review-label-policy.json 定义apply列表评审者建议后可直接自动添加的标签38 个如security、performance、bugfix、documentation等recommend列表只建议、不自动添加的标签5 个aliases别名归一化映射如bug → bugfix、test:e2e → test:puppeteer、testing → tests。AI 不能创建新标签也不能添加人工专用、生命周期类或工作流控制类标签如ai_code_review、needs-rework、code-ready等见 .github/labels.yml。资源密集型的测试与研究类标签按建议处理它们出现在评审评论的Suggested CI小节中由维护者手动添加/重新添加对应标签来启动工作流test:puppeteer—— 付费 Puppeteer 浏览器 E2Etest:notes—— Notes 模块的定向 Playwright E2E无需仓库 secretstest:ui-full-shards—— 完整分片 UI 矩阵 严格 Docker CIldr_research/ldr_research_static—— PR diff 驱动或固定查询的研究任务。为什么要人工交接原文档与源码给出了一致的理由这些工作流每启动一次都要消耗付费 API 配额与 CI 墙钟时间因此是否花费这笔资源的决策权必须留在维护者手里而不是交给可能被 PR diff 操纵的模型输出同时这也保留了 fork PR 在 GitHub 只读 token 与 secret 限制下的正常工作方式。不要试图用GITHUB_TOKEN代打标签GitHub 不会因为某次工作流用GITHUB_TOKEN创建的标签事件而启动第二个工作流所以test:puppeteer、test:ui-full-shards以及ldr_research系列都是仅labeled触发会直接卡死而test:notes同时还会在synchronize上触发因此用 token 打上它会在下一次 push 时真的跑起来——成本交接而非 token 行为才是这个设计正确性的根本原因.github/scripts/combine-ai-reviews.sh 第 230-235 行有同样的注释。Puppeteer、LDR 研究、严格 UI 包装在工作流在 fork PR 上可能缺少凭据或写权限不要用特权 checkout fork 代码的方式绕过这些保护。八、成本估算成本随模型而异但 OpenRouter 上大多数代码类模型非常便宜原文档给出的经验区间典型小 PR 1000 行约 $0.001 - $0.01大 PR1000-5000 行约 $0.01 - $0.05。具体费用请以 OpenRouter 各模型的实时定价为准。需要留意的是diff 大小上限MAX_DIFF_SIZE默认 800KB约对应 20 万 token 量级这是模型可接受输入的直接成本与质量边界。九、自定义评审重点评审提示词review prompt位于ai-reviewer.sh中但该脚本并不存放在本仓库——工作流在运行时从 Friendly-AI-Reviewer 仓库下载见 .github/workflows/ai-code-reviewer.yml 中 Download AI reviewer script 步骤下载时固定 commit SHA 并校验 SHA-256防止供应链篡改。当前评审关注的四大领域为安全密钥、注入攻击、认证性能算法、查询、内存代码质量可读性、可维护性、错误处理最佳实践标准、模式、类型安全。要调整评审侧重需要修改 Friendly-AI-Reviewer 仓库中的提示词或 fork 该仓库并把工作流下载步骤指向你的 fork 与对应的 commit/SHA-256 校验值。十、故障排查10.1 评审未运行确认ai_code_review标签是本次添加的而不是早已存在只有labeled事件中的这个标签才会触发且标签触发后会自动移除检查OPENROUTER_API_KEYsecret 是否配置正确验证 GitHub Actions 的权限设置是否允许该工作流运行。10.2 API 错误检查 OpenRouter API Key 是否有效确认 OpenRouter 账户余额充足查看 GitHub Actions 日志中的具体报错信息可配合DEBUG_MODEtrue输出原始响应。10.3 Diff 过大Diff Too Large将 PR 拆分为更小、更聚焦的变更或调高MAX_DIFF_SIZE仓库变量默认上限为 800KB约 20 万 token。10.4 评审者失败的判定规则单个评审者失败进程退出码非零、输出为空、非 JSON 或非对象 JSON不会拖垮其他评审者它只会在自己的小节显示一条失败说明见 .github/scripts/combine-ai-reviews.sh 第 160-163 行。只有全部评审者都失败时success_count 0工作流才会以红叉结束——这是有意为之避免静默通过。十一、安全设计解析原文档的安全要点与源码实现一一对应密钥安全API Key 存放在 GitHub Secrets 中仅以环境变量形式注入.github/workflows/ai-code-reviewer.yml 第 120 行persist-credentials: false避免凭据泄漏显式触发评审只在维护者手动添加ai_code_review标签后运行杜绝自动消耗配额加密传输所有 API 调用走 HTTPS数据外发知情权代码 diff 会被发送给 OpenRouter/AI 提供商请审查其数据政策最小权限工作流只有读取 contents、写入 PR 评论的最小权限pull-requests: write、issues: write顶层permissions: {}为空fork PR 双不变量源码注释中要求改此文件时必须同时保留只有ai_code_review标签触发且只有具备 triage 权限的用户能加标签——fork 代码上的每次运行都是维护者的显式动作绝非攻击者发起绝不执行 PR head 的任何内容checkout 的是受信任的 base 分支pull_request_target默认行为combine-ai-reviews.sh从 base 运行PR head 仅作为数据被 fetch 来计算 diff。工作流注释明确警告永远不要添加ref: ${{ github.event.pull_request.head.sha }}否则会在带 secrets 的环境中执行 fork 控制的脚本提示注入缓解diff 文本会进入 LLM 提示词恶意 diff 可能试图操纵评论或标签建议。维护者标签门槛、仓库自有标签允许清单、以及FAIL_ON_REQUESTED_CHANGES默认关闭的 advisory-only 决策共同限制了爆炸半径见工作流头部注释。十二、源码纵深标签策略过滤与单测覆盖装配阶段的核心逻辑全部收敛在 .github/scripts/combine-ai-reviews.sh 中它把每个评审者的 JSON 响应转换为评论正文、标签集、决策与成功计数并且做了大量的健壮性处理策略 fail-closed 校验脚本启动时用 jq 校验 .github/ai-review-label-policy.json 恰好包含一个文档对象、apply/recommend为数组、aliases为对象、列表无重复且互不重叠策略缺失或畸形直接以退出码 2 失败而不是静默放行第 73-91 行。这里特意用--slurpfile读取避免jq -e FILE只取最后一个文档导致的校验通过、应用时放行缺口。模型输出不可信单评审者标签数上限MAX_LABELS_PER_REVIEWER200、字节上限MAX_LABELS_BYTES16384第 109-110 行防止模型输出把累积标签文本撑爆 argv 的 128KB 上限导致整个脚本中止超限评审者只丢弃其标签通道评审正文与判定仍然保留。匿名化与净化评论中评审者一律显示为### Reviewer N原始响应要求恰好一个 JSON 对象拒绝 I refuse to review this 这类顶层字符串或多文档拼接响应正文会剥离每个评审自带的一级## AI Code Review标题与单数版页脚避免重复。标签分流模型建议经别名归一化后分为apply可直接添加、recommend进 Suggested CI与rejected记录到 step summary便于维护者看到模型想加什么。recommend同时包含ldr_research时自动去掉低成本的ldr_research_static第 283-287 行。测试覆盖这套装配逻辑被 tests/ci/test_combine_ai_reviews.py共 787 行以罐装 fixture 全覆盖——评论头/页脚剥离、Reviewer N 匿名装配、标签并集、pass/fail 聚合全部在无网络、无 GitHub API的条件下于 CI 中验证。结语至此从 OpenRouter 密钥、Secrets/Variables 配置、标签触发、多模型并行评审到标签策略过滤、sticky 评论与 opt-in CI 交接一条完整的 AI 代码评审闭环已经清晰。这套系统在 local-deep-research 仓库中的落地形态工作流、装配脚本、标签策略、单元测试都可以在本仓库对应路径下继续研读入口 .github/workflows/ai-code-reviewer.yml、装配 .github/scripts/combine-ai-reviews.sh、策略 .github/ai-review-label-policy.json、标签定义 .github/labels.yml。把它接入你自己的仓库时只需照搬以上四类文件并完成密钥与变量配置即可获得一套低成本、显式触发、安全边界清晰的 AI 代码评审能力。【免费下载链接】local-deep-research~95% on SimpleQA (e.g. Qwen3.6-27B on a 3090). Supports all local and cloud LLMs (llama.cpp, Ollama, Google, ...). 10 search engines - arXiv, PubMed, your private documents. Everything Local Encrypted.项目地址: https://gitcode.com/GitHub_Trending/lo/local-deep-research创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
