单轮审查 13+ 文件：43% 检出率。多轮：86%。

单轮审查中的注意力稀释导致质量下降，程度与文件数量成正比。一次审查中的文件数越多，模型找 bug 的能力越差。

两轮架构

第一轮：单文件审查。 每个文件在自己的 API 调用中独立审查。消除注意力稀释——每个文件获得全部注意力。这些可以并行运行。

第二轮：跨文件集成审查。 单文件审查完成后，一个单独的轮次检查接口、文件间的数据流、依赖一致性和 API 契约对齐。捕获只在文件边界上才显现的问题。

多轮在 13+ 文件上的检出率：86%——单轮的两倍。

什么时候触发多轮

数据驱动的阈值：4+ 文件时触发多轮，此时单轮从 95% 降到约 82%。4 文件以下，单轮就够了。

并行加速

并行的单文件审查 + 集成轮次在约 3 分钟内完成。串行处理需要 10+ 分钟。每个单文件审查是独立的——它们之间没有依赖，可以同时运行。

共识投票是错的

同一个审查跑 3 遍，只保留 3 次中出现 2 次的发现，会压制罕见的真实 bug。一个只在 3 次中被捕获 1 次的微妙问题，恰恰是最重要的那种发现。共识投票杀死的是召回率。

更大的上下文窗口修不了这个

注意力稀释不是容量问题。更大的上下文窗口能装更多文件，但注意力仍然被稀释到所有文件上。修复是架构层面的（单文件隔离），不是容量层面的（更大窗口）。

不要强制拆分 PR

要求开发者拆分大 PR 来适配审查系统，是把负担放错了地方。修的应该是审查架构来处理大 PR——并行执行的单文件轮次解决了问题，不需要改变开发者的工作流。

一句话总结： 并行独立审查每个文件（单文件轮次），然后检查跨文件交互（集成轮次）——这在大 PR 上把检出率从 43% 翻倍到 86%，并且能在 3 分钟的 CI 预算内完成。