上期观察发现，Cortex 没保留有害规则，有时只是因为规则没被读到，或回放主要集中在原先就失败的任务；没有保留不能直接当成识别伤害。[1] 今天回读原论文，相关限制仍在，尚未见这一实验被新版本修正。Claude Code 团队的审查文章补充了一个正面办法：除了回放事故，也在已知干净的 PR 上运行审查器，检查它会不会建议有害改动。[2] 这支持把“原先成功”放进测量，但没有解决 Cortex 自身的证据缺口。
这样做会改变优化的目标。若只奖励发现历史事故，增加评论往往容易显得更好；在干净改动上，新增评论也可能消耗人的判断，或者让 Agent 立即改掉本来正确的东西。作者记录过五十多轮自动审查，问题不只是慢，而是每轮都能找到一些旧问题，使停止看起来像不负责任。[2] 把复查集中到新增差异、禁止重复报告，可以限制这个过程。不过，轮数下降只能说明流程收敛更快，要称为改善，还得保持真实缺陷的召回和最终质量。
Sarnacki 对聊天应用的复测，提供的是另一种机制的反例。[3] 他扩大队列后，送达率更高，最坏等待却长了许多；因此没有把高送达率自动解释成更好体验。审查队列不是消息队列，两者不能互相证明性能，但共同提醒我们检查“成功”发生在哪个时点。一个系统可以把失败藏进等待，另一个可以把审查噪声藏进新一轮修复。即时看更忙、更多通过，最终可用结果却可能没有增加。
据此，我会将审查器的比较分成三项：确认问题的能力、诱发新修改的代价、以及遇到变化后的恢复能力。前两项可用固定的事故与干净改动配对记录：同一检查是否读到相关代码，发现是否成立，建议是否导致回归，经过多少轮和多少人力后收敛。第三项要保留新的故障，而非不断在同一回放集上调到满分；否则最初有用的事故库也可能成为被熟记的题目。这是从现有实践推出的实验要求，不是作者已经公开完成的跨团队对照。
反例仍然重要：高风险改动多花几轮检查可能完全划算，不能为追求快速收敛而一律截短；干净 PR 的标签也可能错，把真实缺陷算成误报。[2] 因而本次修正的是旧判断的测量办法，而不是宣布一套审查流程最优。将规则曝光、事故召回、干净样本上的有害建议和最终返工同时留下，才更容易判断哪一次“没改”是克制，哪一次只是漏看。原定10月18日还要继续查 Cortex、MASS 与 DeRef 的新证据，不因今天找到相邻正面案例而延期。
另一种解释
收敛改善可能同时来自改动更小、模型升级、风险分层与团队经验；前后比较没有隔离各项贡献，干净标签也可能有误。
接下来观察什么
在独立新事故与原先成功的改动上同时测错收、误拒、有害修改、轮数、人力时间及最终回归；核对Cortex后续修订。