近年来，AI 辅助编程从「写代码」延伸到「审代码」。在 GitHub 上引发关注的 Juror 就是这一方向的新工具：它把自己定位为一款「比 Greptile 更便宜也更好的开源替代品」，直接跑在用户自己的 GitHub Actions 上，而不是依赖第三方托管的 SaaS 服务。

多模型并行评审，重复结论自动合并

Juror 的工作方式并不复杂：当一个拉取请求（Pull Request）触发评审时，多个前沿大模型会各自通过原生的智能体框架并行审查同一份代码差异（diff）。不同模型给出的发现会经过五道「无损合并」流程——先按行锚定、再按文件与代码窗口分组、完全相同的报告直接归并，随后用加权相似度加「裁判」模型判断是否重复，最后做覆盖审计，确保每一条原始发现都归属于唯一的最终结论。

设计上，Juror 明确声明自己「不是自动修复机器人，不是代码检查器（linter），也不是聊天界面」。它只做一件事：审阅 diff 并贴出发现。项目方强调，使用它不需要安装应用、不需要注册账号，也不需要先为代码仓库建立索引。

基准测试：声称优于 Greptile

Juror 最具争议也最吸引眼球的是它的基准数据。项目方称，在自带的「生产环境拉取请求」种子样本上，Juror Fast 找到了 4 个 P0–P2 级别缺陷中的 4 个（召回率 66.7%，精度 100%）；而 Greptile 只找到 1 个（召回率 16.7%，精度 50%）。按项目方说法，Juror Fast 发现的「经裁决确认的 P0–P2 缺陷」是 Greptile 的 4 倍。

需要说明的是，这一对比来自 Juror 项目方自己的基准，并非独立第三方评测。Greptile 作为商业产品，其评审策略、默认模型和触发条件与 Juror 并不相同，单纯比较两个工具在同一份样本上的命中数量，未必能完整反映真实工程场景中的表现。

支持哪些模型与预设

Juror 通过不同的「harness」接入各类模型：Claude Code 可调用任意 Anthropic 模型，Codex 可调用任意 OpenAI 模型，opencode 能接入 models.dev 上的 Fireworks、Groq、OpenRouter 等，Grok Build 调用 Grok 系列，Kimi Code 调用 Fireworks 上的 Kimi K3，此外还支持通用的 OpenAI 兼容接口。

为了平衡成本与效果，Juror 内置了多档预设（preset）：默认的 fast 档用 Codex 上的 GPT-5.6 Luna 与 opencode 上的 DeepSeek V4 Flash；balanced 档加入 Grok 4.5 与 Kimi K3；high 档再叠加 Opus 5；ultra 档则把七款模型全部拉满。用户也可以自己写配置，把 DeepSeek V4 Flash 等模型按需接入。

成本透明，采用 MIT 许可

Juror 的一大特点是「每轮评审都打印自己的收据」。一份示例收据显示，一次评审调用 3 个模型、耗时 2 分 14 秒，成本为 0.91 美元。配置文件中还能设定每轮拉取请求的目标预算（默认 5 美元），超出时按「可负担子集」或跳过处理，而不是悄悄超限。

该项目以 MIT 许可证开源，代码托管在 GitHub 的 Juror-AI/juror 仓库，最近一次提交时间为 2026 年 8 月 11 日。接入方式也贴合开发者习惯：一条 npx juror-ai review --pr 1234 --repo owner/name 即可在终端查看评审结果，加上 --post 参数便会把结论作为一条置顶总结评论加若干行内评论贴回拉取请求。

对于希望把 AI 代码审查留在自己基础设施内的团队来说，Juror 提供了一条不依赖外部 SaaS 的路径。不过，它的基准优势仍需在更多真实项目中验证，工具是否真能长期替代商业方案，还要看后续社区的独立评测与持续维护情况。

来源：Hacker News / GitHub（Juror-AI/juror）