审查循环失控：当三个 Reviewer 产出超过修复能力

审查越严格，发现的问题越多。发现的问题越多，修复压力越大。修复越多，越容易引入新问题。新问题又触发新一轮审查。

问题#

三方交叉审查解决了单人审查放水的问题。但它带来了一个新问题：产出与消化的速度不匹配。

一次实际案例（4/8–4/12 全审查工作流）：

视觉审查经历了 4 轮迭代（V1→V4），评分从 3/5 逐步提升到 4.2/5：

轮次	审查者	评分	发现的问题
V1	可乐	3/5	5 个高优（配色+聊天页+对话列表）
V2	可乐	3.5/5	3 个高优（composer+CTA+头部）
V3	可乐	4/5	3 个低优（截断+按钮+头像）
V4	可乐	4.2/5	通过 ✅

加上 API E2E 测试（5 轮）和全审查（三路并行 + 多轮修复），整个工作流 4 天才收敛。

三个因素叠加：

PM 看到的产品问题、设计师看到的视觉问题、QA 看到的功能问题——这三组问题几乎不重叠。所以总量是三者之和，不是三者的交集。

改一个 CSS 修视觉，可能影响另一个页面的布局。改一个接口修功能，可能影响产品逻辑。每一轮修复都有概率引入新问题。

第一轮审查时，reviewer 对代码不熟悉，只能发现明显问题。到第三轮、第四轮，reviewer 对代码已经很熟了，开始发现更细微的问题。标准在迭代中自然提高。

工作流引擎设置 max_iterations: 10。达到上限仍未收口时，自动升级给人类决策。

这不是一个好的解决方案——它只是一个安全网。真正的解决方案在下面。

三方审查后，架构师（芋泥）做合并：

合并后的问题数会因去重而减少——同一个根因可能被三个 reviewer 从不同角度报告。

不是所有问题都必须在本轮修复：

这让每一轮修复的工作量可控——只修 Blocker + High，Medium 和 Low 推后。

从实际经验看，收敛的信号是：审查评分持续上升且不再发现 Blocker。V1 到 V4 的评分轨迹（3→3.5→4→4.2）就是一个典型的收敛曲线。

同一类型的审查，随着积累会越来越快：

视觉审查	日期	轮次	单轮耗时
V1→V4	4/9 09:08–12:46	4 轮	agent 编码 47min（4/9 09:08–12:46）
V7	4/14	1 轮	25 分钟

从 4 轮 3h38m 到 1 轮 15 分钟——因为前 4 轮积累了经验，问题密度大幅下降。