舒适内部 | 如何让四个对立的AI实验室争夺我们的代码审查

我在 Comfy 处理大量的代码审查，大部分代码不再由人类编写。一个代理程序编写代码，我进行修改，我所监控的代码数量越来越多，而我个人编写的代码越来越少。一个疲惫的人无法监控如此大量的代码。因此，我放弃了尝试，并开发了一个可以做到这一点的解决方案。

方法是将 PR 差异分发给四个来自不同实验室的模型，每个模型执行两次，然后由一个评判者汇总结果。它在 CI 中运行，月费固定为 200 美元。其基本假设是违反直觉的：来自同一个实验室的多个模型代表一个观点，以不同的声音表达，而不是多种观点。疲惫的审查者的解决方案不是更好的模型，而是实验室的多样性。

我公开发布了它供团队和其他人使用（以下是存储库详细信息）。下面是功能和费用。

问题

对抗性审查是我最不信任自己的专注力的事情。在下午的第三个 PR 时，我比第一个 PR 时更不批判，尽管 bug 持续存在，不论时间。隐藏的错误、静默类型转换和在规模上出现的问题要求一个新鲜、怀疑的读者；到下午晚些时候，我已经疲倦和适应性。

这个过程已经自动化。将差异粘贴到一个模型中，请求攻击代码。将其粘贴到另一个模型中，要求边缘情况。列出后开始我的审查。这是一个等待编写的脚本。我以前没有这样做，因为单个模型的性能不佳。它根据相同的偏见评估代码，这些偏见用于生成它，只是回应我的先入之见。

为了澄清这里的“我的代码”：它评估的是 ComfyUI 的云基础设施，而不是其渲染引擎。实际上，这包括我们的 Go 后端（摄入和推理服务、OAuth 实现、资产管道）、MCP 服务器、CI 和基础架构即代码以及工作流 API 到图形转换器，以及我本地的任何内容。它尚未审查采样节点或 CUDA 路径。检测到的 bug 涉及推理服务中的并发性、身份验证处理、工作流图分析中的原型污染以及上传路径中的资源耗尽。这个范围是故意的，与我们的实际审查量相符。

约束

• 固定成本限制，而不是按PR付费。忙碌的仓库中按使用付费的风险是意想不到的支出。系统必须在一个200美元/月的Cursor Ultra订阅内运行。如果超出预算，总会有人禁用它。

• 在CI中运行，而不是在本地运行。 只有在手动触发时才运行的审查增加了不必要的步骤。

• 对恶意PR操纵免疫。差异由攻击者控制；如果审查者从PR内部读取说明，PR可以自行批准。

• 与CodeRabbit并行运行，而不是取代它。我们已经有效地使用它。我寻求的是一种补充的、不同的视角，而不是替代品。

为什么有四个不同的实验室

机制：来自相同系谱的模型共享训练偏见，从而导致共同的盲点和虚假警报。它们为代码形状标记典型错误，而不是具体缺陷。四个模型的一致性会产生虚假共识，甚至不如一个审查者通过模仿验证来实现。

不同的实验室打破了这种模式。截至2026年中期，该阵容包括OpenAI、Anthropic、Google和Moonshot（Kimi）等顶级模型，每个模型都有其独特的失败方式。一个专注于并发，另一个捕捉API漂移，第三个发现未关闭的资源。当三个模型一致时，表明可靠性；一个离群值发现突出了同系评审员会错过的问题。

例如，一项为两个提供商实现图像编辑的更改中，有两名审阅者各自发现了其他人忽略的错误。 Claude 单独指出一个提供商只接受单个图像，而代码允许多个图像，从而导致深层调用失败，而不是直接拒绝。在同一个差异中，GPT-5 Codex 单独检测到丢失的内容审查设置，如果提高安全过滤，则会默默地恢复为默认设置。来自一个实验室的四个模型均会批准这两项更改。

很明显的反驳：这不就是集成方差吗？多次运行一个强大的模型在不同的温度下捕捉相同的问题？有一些是的。但是温度重新排列相同的分布；它不会引入新的先验来捕捉其他结构忽略的遗漏。盲点来自训练，而不是采样。我没有严格测试四个温度与四个实验室在标记数据上的差异，欢迎这样的分析。我的假设是谱系多样性提供了温度无法覆盖的覆盖范围。

这在代理草拟代码时更为重要。如果克劳德草拟和审查，它是同一个视角两次，作者盲目。

架构

它最初是作为一个本地Cursor CLI命令，向所有四个实验室传播差异。每个模型运行两次：对抗（假设破碎，找到缺陷）和边缘情况（假设正常路径工作，找到有问题的输入）。四个模型，两次通行，八次审查每个PR。

八个原始审查是过度的：嘈杂，冗余，困扰着虚假共识。因此，什么都没有直接发布到PR。输出汇集到一个法官，最新的克劳德奥普斯，指示不要相信审查员。法官读取实际更改的文件（审查员看到差异；法官看到真实的真相），将发现分为已验证，预先存在或假阳性，然后将输出限制为十个最高信号项目。审查员故意过度标记；法官丢弃了大多数。

扇出使用8个单元的GitHub动作矩阵：

策略：快速失败：false矩阵：模型：-gpt-5.3-codex-xhigh-claude-opus-4-7-thinking-xhigh-gemini-3.1-pro-kimi-k2.5审查类型：[对抗，边缘情况]#4个模型×2个审查类型=8个独立审查每个PR

我将其生产化为一个标签触发的GitHub动作。应用一个审阅游标用于触发分发的标签；作为审查员的分配会自动添加它。到目前为止，大约有 110 个 PR 使用了它。它是基于标签的，而不是每个 PR，因为两个原因：对琐碎变化的激进审查会训练用户忽略机器人，并且 CodeRabbit 已经处理了每个 PR。这是一个可选的深度传递；标记相同行的 PR 获得优先权。

三个关键细节：

• HEAD SHA 的幂等。重新标记或重试避免了重复的审查或对未更改的差异进行计费。

• 5,000 行差异上限。更大的差异表明缺乏审查之外的更深层次的问题。

• 提示位于单独的不可达仓库中。从安全角度来看，审查员和法官提示来自工作流程自己的仓库，固定在一个引用上，从不检查 PR。恶意 PR 无法改变评分规则。

我如何使用它，以及它的成本

它在早期运行，而不是在晚期运行。在编写时，我在代理完成后，在提交前在本地执行它。在审查他人的 PR 时，分配标签会自动添加标签，在我查看差异之前完成传递。我先读取机器人的判决，然后读取代码，并在 PR 上保留输出以便审核。

例如：一个涉及分页列表的批准更改有四位审查者跨三个实验室标记了同一行——排序仅在精确的方向拼写下起作用。空白、打字错误或原始参数会默默地将其反转，从而在共享代码中冒险跳过或重复项目。当竞争模型在由人类清除的行上收敛时，它值得立即关注。

此前，我手动在分配的PR上运行。现在：八个对抗性评论加上一个法官在~110个PR上，修复每月200美元，从不超过限制。在~24天和35个提交中构建，主要是与法官辩论“核实”标准。

一个设计选择证明是有价值的：严重程度标签（critical/high/medium/low/nit），格式错误的标签默认为中等。防止重要错误丢失到格式错误中至关重要。

它也变得共享。作为一个共享的操作，任何人都可以为相同的结果应用标签——不需要安装或权限。当另一位工程师为前端存储库请求它时，它从私有工具过渡到团队基础设施。

仍然开放

• 阵容不断演变。每个实验室的顶级模型是流动的；实验室多样性是持久的，而不是阵容，通过共享配置启用更新。

• 法官的十项限制是启发式的。偶尔，PR有十多个真正的问题被截断；十个感觉是经验主义的正确的。

• 法官是一个克劳德模型，和一个审查员一样。LLM法官表现出自我偏好，可能过度权重克劳德发现。访问真实文件可以缓解这一点，但并没有完全解决。

• 没有benchmarking存在。没有标记的bug集、精度/召回度指标或受控比较——只是大约110个PR的真实捕获人类错过的内容。信任的结果超过引用研究；适当的benchmark会让我感兴趣。

架构是贡献，因此提示和工作流程是开放的：

Cursor Review GitHub Workflow →

采用它，应用于您的PR，并批评法官帽子。我们开源工作流程以吸引辩论设计的工程师——如果你是这样的人，请加入我们。