62% 的审查评论是重复的。加了先前上下文降到 4%

开发者推了审查评论的修复，流水线不带先前上下文重新审查，Claude 再次发了同样的发现。它不记得自己已经标记过什么。开发者看到 15 条评论，其中 10 条和第一次审查说的一样，关于已经修了的问题。

三个开发者屏蔽了审查 bot。真正的问题没被处理。

修复：先前发现作为上下文

在下一次审查的上下文中包含前一次审查的发现。指示 Claude 只报告新的或未解决的问题。

所有 PR 中发现的唯一问题总数相同。增量方式消除噪音而不牺牲彻底性。

对开发者参与度的影响：

62% 的评论是重复时，开发者不再读它们。96% 可操作时，开发者会行动。

实施步骤

1. 存储发现 — 把每次审查的发现保存到持久位置（文件、数据库、PR 元数据）
2. 作为上下文传递 — 在下一次审查的 prompt 中包含存储的发现
3. 指示 — “只报告新问题或先前列表中仍未解决的问题”

第一步是存储。没有存储的发现就没东西可以作为上下文传递。

不是只审查 diff

一个同事建议只审查两次推送之间的 diff 来避免重复。这会遗漏未变代码和新变更交互的问题。一个函数的修复可能解决或创建 diff 不包含的另一个函数中的问题。

带先前发现的完整审查维持完整覆盖。先前上下文防止重复；完整范围防止遗漏交互。

管理多次迭代的上下文增长

一个经过 5-6 轮审查迭代的 PR 累积了长长的先前发现列表。到第 5 轮，上下文膨胀了。

方案：按类别总结先前发现而不是逐条列出。“3 个命名规范问题已解决，1 个错误处理问题未解决”保留增量收益同时保持上下文可控。

不要在设定轮数后丢弃先前发现——那会重新引入重复。不要在早期迭代后切到只审查 diff——那丢失交互覆盖。压缩上下文，但保留它。

和会话隔离（K3.6.4）结合

一个开发者说会话隔离（独立审查者无上下文）和增量审查（先前发现在上下文中）矛盾。不矛盾。

会话隔离意味着审查者没有生成阶段上下文——它没有写它正在审查的代码。增量审查意味着审查者有先前审查发现——它知道之前标记了什么。

组合设置：一个独立的 Claude 实例接收先前审查发现作为结构化输入。它没有写过代码所以没有偏见，但它知道之前标记了什么。两个实践同时适用。

一句话总结： 在迭代之间存储审查发现并作为上下文包含——重复从 62% 降到 4%，开发者参与度从 45% 升到 82%，没人屏蔽 bot。