一封关于”AI 垃圾代码”的来信

当地时间 9 月 10 日，切尔尼在 X 平台上公开了一封开发者写给他的邮件，标题直白地写着”怎么处理 AI 垃圾代码？”。他透露，自己几乎每天都会收到类似来信，并尽量多作回复。

这位匿名开发者把 AI 编程带来的”摩擦”归纳为两种截然不同的做法，请切尔尼判断哪一种更合理。第一种相对克制：仍像从前一样写代码，只是用 AI 加速，未必逐行审查，但代码必须经得起审查，提交者要能解释自己提交了什么，且代码对人类维护者而言至少不比以前更难。第二种则更放任，也就是当下流行的”氛围编程”（vibe coding）思路：把代码当黑箱，不关心内部实现，只看最终输出。

来信者也坦言，不少人其实做不到第一种，却又担心因此失去工作，”很多人只是在硬着头皮用 AI”。

原型可黑箱，生产代码标准更高

切尔尼完整公开了自己的回复，并指出两种做法并非只能二选一，各自都有合适场景。对于”只管结果、不管代码”的做法，他认为原型和一次性代码完全可以当成黑箱——反正最终会被丢弃，只要出问题的影响范围不大，就没必要追求完美。

真正进入生产环境的代码则完全不同。切尔尼写道，Claude 写出的生产代码，标准应当比人类写的更高。他在文中列举了 Anthropic 内部设置的多道防护机制：大量代码规范检查规则与测试、Claude 驱动的端到端测试、每天运行的模糊测试工具，以及自动代码审查、安全审查和自动代码重构。他提醒，缺少这些措施，代码库很容易逐渐变成难以维护的烂摊子；好消息是模型能力越强，把这些日常流程跑顺也越容易，例如每天固定跑几套流程，或使用 Claude Code Review。

开发者的新角色：mini CEO

切尔尼的核心观点是，开发者的真正职责在于”守住代码质量标准”。AI 行业有人把这种新角色称为”mini CEO”——开发者更像一名管理者，需要判断什么代码能进入系统，什么代码应当当场拦下。

如果上述办法仍解决不了问题，切尔尼还给了三条退路：更直接地介入 Claude 的工作过程、让它重写整个代码库，或者干脆”等下一个模型”。在 AI 接管大量编码工作的趋势下，如何为代码质量设下闸门，正成为工程师价值所在的新焦点。

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

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）