你的 AI 代码审查员没有人可以反驳

让 AI 审查你的代码，你得到的只是一个模型的观点。一次对差异的检查。无论它首先关注什么。

有时这样就可以了。有时它确实能发现问题。

但如果你曾经在一个有强大审查文化的团队中工作过，你就知道最好的审查并不是这样工作的。最好的审查发生在具有不同关注点的人查看相同的代码，然后就他们发现的问题进行争论时。

安全人员标记了某个问题。架构师说："实际上这没问题，因为我们是这样构建 X 的。" 质量工程师注意到他们两人都忽略了一个连接这两个发现的错误处理漏洞。这种对话揭示了任何单个审查员都无法单独发现的问题。

这种来回交流才是真正的信号所在。而我试过的每个 AI 代码审查工具都完全跳过了这一点。

单次检查只是带有更好营销的抛硬币

让我对当前这一批 AI 审查工具感到困扰的是：

它们都在做本质上相同的事情：获取一个差异，将其扔给一个模型，然后漂亮地格式化输出。有些添加了项目上下文。有些并行运行多个检查。但归根结底，你得到的是单一的、未经争议的观点，没有人质疑这些发现是否真实。

你知道从未经争议的审查中能得到什么吗？误报。幻觉般的发现。表面级别的挑剔被包装成关键问题。偶尔，在噪音中埋藏着真正有用的反馈。

听起来熟悉吗？应该是的。这也是为什么单个人类审查员对于重要代码来说是不够的。几十年前我们就用多人审查的概念解决了这个问题。只是我们花了一段时间才将同样的逻辑应用到 AI 版本上。

如果审查员们真的互相交流呢？

这就是促使我开发 Open Code Review 的问题。

我最初将其作为内部工具为我们团队构建，因为我们对上述问题感到沮丧。想法非常简单：如果我们像高性能工程团队实际做的那样来构建 AI 代码审查会怎样？

所以它是这样工作的：

• 你配置一个具有特定角色的审查员团队。架构、安全、代码质量、测试，任何对你的代码库有意义的自定义角色。
• 每个审查员独立进行他们的检查。不同的关注点，不同的重点领域，不同的发现。
• 然后是真正重要的部分：一个结构化的讨论步骤，让他们互相辩论各自的发现。同意、挑战、连接相关问题、揭示新问题。
• 只有在这之后，最终的综合才会产生你实际看到的审查。

可定制到极致（或者直接使用默认设置）

你的代码库不是通用的，你的审查团队也不应该是通用的。

它了解你的需求，而不仅仅是"最佳实践"

这是让我对大多数审查工具感到恼火的另一件事。它们根据通用的最佳实践评估你的代码，而对你实际想要构建的东西没有任何概念。

OCR 允许你传入规范、提案、工单中的验收标准，或者其他任何内容。

每个审查员都会根据他们的专业知识和你声明的需求来评估代码。最终的综合包括需求验证，显示哪些已满足，哪些存在差距，哪些是模糊的。

如果你正在进行任何形式的规范驱动开发，这一点就真的很重要了。

无缝集成，不干扰工作流

我无法足够强调这一点对现有工作流的干扰有多小。这是一个核心设计目标。

那么它真的更好吗？

我们的团队再也没有回到其他任何工具。审查质量根本不在一个水平线上。

我认为这归结为一件非常简单的事情：有争议的观点比无争议的观点更有价值。无论模型有多聪明，如果在到达你之前没有任何东西对其发现提出质疑，你就会花时间过滤噪音，而不是处理真正的问题。

让审查员先争论。在成为你的问题之前先把噪音去掉。