最近我有一个挺具体的烦恼。

代码生成的速度上去了，代码审查的速度没跟上。

我现在的开发方式，通常是把一个需求拆成几个小模块，再交给 Coding Agent 一个模块一个 PR 地实现。Agent 干活很快，一天下来开 15～20 个 PR，已经不是什么稀奇事。

问题是，PR 提得起飞，我审得不飞。

以前我的办法是：复制 PR 链接，贴给另一个Qoder Work，让它帮我看一遍；看完以后，再把 AI 的评论贴回 PR，让 Coding Agent 照着修改。这个流程能用，但一周之后我就开始烦了：

  • 每个 PR 都要手动复制链接、发消息；
  • 同一个 PR 交给不同的 AI，结论经常不一样；
  • 有的 AI 特别爱挑格式问题，真正重要的 bug 反而被埋在一堆废话里。

于是我想做一件很朴素的事：

PR 一提交，就自动请几个 AI 各看一遍，再请一个“组长”把意见整理好，直接评论在 PR 下面。

这就是 guanlili/ai-pr-review 的起点。

先说明一下：这篇文章不展开 Action 的参数、Prompt、JSON 结构和实现代码。那些内容都放在 GitHub 仓库的 README 里。这里更想讲清楚一件小白也能看懂的事：我为什么要请四个 AI，它们到底怎么配合，以及这件事能帮我省掉什么麻烦。

01. 先把几个名词翻译成人话

如果你平时不写代码，第一次看到 PR、GitHub Actions、LLM，可能会觉得像在读一份外星菜单。

其实可以把它们想象成公司的工作流：

  • PR（Pull Request）：一张“我改完了，请你看看”的任务单；
  • GitHub Actions：仓库里的自动化机器人，满足条件就自己干活；
  • Reviewer AI：几个负责找问题的评审同事；
  • Judge：最后负责汇总意见、过滤重复问题的技术负责人。

所以这不是四个 AI 在 PR 下面互相吵架，而是：三个评审各自看材料，最后由一个 Judge 整理成一份报告。

02. 我做的事情，其实就是请了四个同事

先看完整流程：

ai-code-review-pipeline-editorial-zh

以前是我一个人拿着任务单，到处找同事帮忙看；现在是任务单一出现，机器人自动把它分发给几位评审。

我目前使用的是豆包、DeepSeek、GLM 三种不同风格的模型做评审，最后再让豆包的 Seed-Evolving 当 Judge 做汇总。它们全部通过火山方舟调用，所以目标仓库只需要配置一个 ARK_API_KEY。

这里的重点不是“模型越多越厉害”，而是让不同模型提供几个独立的参考意见。一个模型可能漏掉边界条件，另一个模型可能更敏感于安全问题，第三个模型也许会发现前两个没注意到的地方。

它们不一定谁对谁错，但放在一起看，通常比只听一个声音更容易发现盲区。

GitHub Actions 中该 PR 评审工作流的运行记录

03. 为什么不只用一个 AI？

这和找人做 code review 很像。

你让一个特别擅长写业务代码的同事来审，他可能很快发现逻辑 bug；但涉及权限、异常处理或者边界条件时，他未必最敏感。

你再找一个偏架构的同事，他关注的可能是模块之间怎么耦合、未来会不会难以维护；安全同事则会条件反射一样检查密钥、注入和权限问题。

不同的人有不同的盲区，不同的模型也一样。

所以我没有让同一个模型连续审三遍，而是让三个模型各自独立完成第一轮评审。它们互相看不到对方的答案，也就不会因为“前面的人这么说了”而跟着附和。

最后的 Judge 负责做三件事：

  1. 把描述同一个问题的多条意见合并起来；
  2. 判断哪些问题比较重要，哪些只是建议；
  3. 把有争议的意见标出来，留给人来决定。

这里要特别说明：多模型不是正确答案制造机。 它只能增加一个问题被发现的机会，也能帮助我过滤一部分明显的误报；最终的业务判断，仍然不能完全交给 AI。

04. 为什么 Judge 用的是 Seed-Evolving

三位 reviewer 我刻意挑了三家不同厂商的模型；Judge 只有一个，得选个能扛事儿的，我定的是豆包的 Seed-Evolving。

Judge 这个活儿其实挺重：它要一次性把三份 reviewer 的原始意见、整份 PR 的代码变更，还有项目的 AGENTS.md 都读进来，再接着做去重、排优先级、过滤误报，最后生成一份能直接贴到 PR 的报告。这是一件典型的”长上下文 + 多步推理 + 吃 token”的事。

翻了一圈方舟上的模型，Seed-Evolving 三点刚好对上：

  • 上下文够长，仓库级的大 PR 整份代码塞进去都不用截断；
  • 长程推理稳，多步融合的时候不容易读到一半开始”编”；
  • token 用得省，同样一份报告，比同档模型大概省两成。

但说实话，最打动我的不是这三点，而是它一个很特别的设计：Model ID 固定成 doubao-seed-evolving，字节每次升级基座，会自动把这个名字指过去。 也就是说我这边什么都不用改，就能一直用到最新版本。

这件事听起来小，但对一个要装到好几个仓库、长期跑的工具来说特别值。以前用别的模型，每隔几个月就得手动改一次版本号、重新测一遍兼容；现在”跟进模型迭代”从一个需要我操心的负担，变成了一个我白捡的红利——基座每升级一次，这套 PR review 就自动变强一点，一行代码都不用动。

05. Judge 是怎么做决定的？

可以把它理解成一次评审会。

如果三位同事都指出同一个问题，比如“这里没有校验用户权限”，那它大概率值得优先看；如果只有一个人提到，而且内容比较像个人偏好，Judge 就会把它降级成普通建议，甚至直接过滤掉。

大致规则是这样的：

多人都指出同一个问题       → 高置信度，优先处理
只有一人指出，但涉及安全   → 保留，提醒人工确认
只有一人指出普通问题       → 降级，并标注“仅一位 AI 提出”
只是格式或个人偏好         → 尽量过滤
意见互相冲突               → 标记为争议，交给人判断

这不是数学意义上的“投票决定真相”，更像是几位同事先各自发表意见，技术负责人再结合原始代码做一次复核。

Judge 不只看三份评论，也会重新读取 PR 的代码变更和项目里的 AGENTS.md。后者可以理解成项目的“员工手册”：

  • 哪些目录不能随便改；
  • 哪些用户输入必须先过安全检查；
  • 哪些接口必须补测试；
  • 项目里有哪些容易踩的历史坑。

没有 AGENTS.md 也能运行，但有了它，AI 的评审就不再只是“通用代码检查”，而更像一个熟悉项目背景的老同事。

一份多模型融合后的 PR 评审报告：每条问题标注置信度级别与提出人数

上面这份报告里，每条问题都会说明：有几位 reviewer 提到、属于什么优先级、Judge 为什么保留或合并。这样我不用读三份重复的原始报告，先看最终清单就够了。

06. 用起来需要做什么？

目标仓库只需要准备两件东西：

  1. 一个 GitHub Actions workflow，用来告诉 GitHub“什么时候启动评审”；
  2. 一个名为 ARK_API_KEY 的 Secret，用来调用模型。

具体的安装文件、模型配置和参数说明，我都放在 ai-pr-review 的 README 里了。照着 README 配好以后，新的 PR 打开或更新时，评审就会自动开始。

如果你不想一开始就让它审所有 PR，也可以先只在自己的测试仓库里试跑，看看它提出的问题是不是符合你的项目习惯。

有一点也要提前说清楚：Action 负责审查和评论，不负责替你直接修改代码。 我后面让 Coding Agent 读取评论、提交修改，是我自己的组合工作流；如果你没有 Coding Agent，它依然可以单独作为一个自动 code review 机器人使用。

07. 我现在的开发闭环

装好以后，我现在每天的流程大概是这样：

  1. 把需求拆成几个小模块；
  2. 交给 Coding Agent 实现；
  3. Agent 提交代码并创建 PR；
  4. GitHub Actions 自动请三个 AI 评审，再由 Judge 汇总；
  5. 评审结果评论到 PR；
  6. Coding Agent 读取评论，修改后再次提交；
  7. 我最后看一眼真正需要业务判断的问题，再决定是否合并。

以前我需要在“复制链接、找 AI、整理评论”这些事情上来回切换。现在这些机械步骤被串起来了，我的注意力可以集中在更重要的问题上：这个方案是不是合理，这个字段是不是应该允许为空，这个业务规则是不是符合产品预期。

当然，我不会因为报告里写着“没有 blocking 问题”就闭着眼睛合并。AI 评审更适合做第一道筛选和提醒，不能替代对业务负责的人。

08. 这套东西适合什么，不适合什么？

它比较适合处理这些重复工作：

  • 有没有把异常吞掉；
  • 有没有硬编码密钥；
  • 有没有遗漏权限校验；
  • 这次改动有没有明显的边界问题；
  • 相关测试是不是一起更新了。

但下面这些事情，仍然需要人来拍板：

  • 业务规则到底应该是什么；
  • 这个接口设计是否符合长期规划；
  • 某个“看起来不优雅”的实现是否是为了兼容旧系统；
  • 一个问题的修复成本是否值得。

还有一个现实问题：模型会变化，评审结果也会变化。即使模型名称不变，升级后的模型也可能换一种判断方式。所以这套工具更像一个持续进步、但偶尔会有新脾气的助手，而不是一台每次都输出完全相同答案的测试机器。

写在最后

做完这个 Action，我最大的感受不是“我又造了一个 AI 工具”，而是：AI Coding 真正带来的变化，不只是让一个人写代码更快，也让原来的协作流程开始出现新的瓶颈。

代码可以一口气生成很多，但每一份代码都值得被认真看一遍。把重复的初筛交给 AI，把需要经验和责任的判断留给人，可能是现在比较舒服的分工。

多模型融合也不是某种神奇的“AI 博弈”。说到底，它只是一个很朴素的工程办法：多听几个意见，再由一个人或一个 Judge 把意见整理好。

这件事目前还不完美，误报、漏报和模型升级带来的波动都会存在。但至少从“每个 PR 都要手动复制给 AI”走到“PR 自己带着评审报告回来”，已经让我的开发节奏轻松了不少。

如果你也想试试，代码在 guanlili/ai-pr-review，具体配置和实现细节都放在 README 里。欢迎拿自己的仓库跑一跑，也欢迎把它评审错的地方提回来——这也是它继续变好的方式。