审查结果先截断再过滤，可能漏掉真实缺陷

AI 审查给 PR 打了绿色对勾，不一定代表模型没发现问题。DevReview 在检查自身实现时发现：模型返回的发现，可能先被评论数量上限截掉，再因文件路径无效被过滤，最后页面却显示「没有值得关注的问题」。

这次修复值得读，原因不在于模型又犯了什么错，而在于应用如何处理模型输出。排序、过滤、计数这些普通业务逻辑，也能把「发现无法发布」变成「审查通过」。不过，作者尚未确认这个问题是否在生产环境发生过。

八条评论的上限，怎么把有效发现挤掉了

DevReview 是一个审查 GitHub PR 的 GitHub App。为了让审查结果容易阅读，每次最多发布八条评论，并按严重程度挑选。

这个限制有合理目的：让读者先看重要发现，避免 PR 被大量评论淹没。但旧实现的执行顺序有问题：

1. 把模型返回的发现按严重程度排序，只保留前八条。
2. 删除文件路径不属于当前 PR 的发现，因为这些评论无法发布到对应文件。
3. 如果没有剩余评论，就显示绿色对勾，并写上「No issues worth your attention」。

作者给出的例子很直接：模型返回十条发现，前八条都引用了不属于当前 PR 的路径，第九、第十条的路径有效。

第一步截掉后两条，第二步删除前八条，第三步便宣布没有问题。两条原本能发布的发现，连进入路径校验的机会都没有。

这里还有一层限制：模型报告了 bug，不代表 bug 已被人工证实。这个例子能说明的是，系统丢失了模型返回的有效定位结果，并给出了不应有的通过信号。

「没有可发布的评论」不能直接推导出「没有发现问题」。

修复顺序之外，还要修复结果的含义

他们团队做的第一项修改，是把路径检查移到数量限制之前。只有能够发布的发现，才参与八个名额的竞争。这样，无效路径就不会挤占有效发现的位置。

但只调整顺序还不够。如果模型返回的发现全部无法发布，最终仍可能剩下零条评论。因此，作者又补了三类结果说明。

首先，统计并披露丢弃数量。文件路径不匹配、格式不符合要求，都不能再悄悄消失。审查会显示：

「N findings could not be posted because they did not match this PR's files or the expected format.」

其次，收紧绿色对勾的条件：只有模型返回零条发现时才显示。哪怕只有一条发现被丢弃，也要去掉对勾。

最后，把数量上限造成的压缩单独说明。例如：

「2 remarks suppressed to keep this review focused: 1 NIT, 1 PRAISE.」

这里的 NIT 指细节建议，PRAISE 指表扬。它们与路径或格式错误导致的丢弃，是不同原因，应该分开计数。

作者还删掉了提示里的「lower-priority」。因为超过八条时，被截掉的也可能是 bug，不能让读者误以为省略的都是无关紧要的内容。

他们也修改了营销文案。之前宣称没有内容会被静默隐藏，但格式错误的发现确实曾被直接丢弃，且没有数量记录。产品说明需要服从代码实际做到的事。

测试证明修复有效，但生产链路还没验完

作者先写测试，确认旧行为会失败，再修改实现。审查函数现在使用伪造的模型响应和 GitHub 响应做端到端测试。

前面的十条发现用例已经覆盖：八条虚构路径加两条有效发现，现在会发布两条有效结果，同时披露另外八条无法发布。格式错误的计数也有验证，移除这段计数逻辑就会导致测试失败。

这些测试支持的是特定输入下的程序行为。作者没有观察到真实生产审查中的同类事件，也没有完成真实 GitHub 与 Anthropic 交互的验证，后者仍是下一步检查。

还有几个缺口没有解决：

• 仪表盘仍可能显示「completed, 0 comments」，即使所有发现都被丢弃，看起来依然像通过。
• 丢弃数量目前只出现在 PR 评论和日志中，尚未存入数据库；仪表盘展示需要新增一列。
• PR 中有些文件完全没有被审查时，系统仍可能显示绿色对勾。
• 评论内部出现代码围栏，可能导致整次审查失败。

因此，这次修复改善了发现结果的处理和披露，还没有让绿色对勾成为完整审查覆盖的保证。

我的判断

我赞同作者把问题落在结果语义上。读者看到绿色对勾，会据此决定是否继续检查代码。系统既然丢弃过发现，就不能把这段信息损失包装成确定的通过结论。

先校验、再限制数量，对这条处理链也有明确价值：既然无效路径注定无法发布，就不该让它占用发布名额。针对构造输入的测试，已经验证了这项修复。

不过，八条是否是合适上限，原文没有给对照数据。它是产品取舍，不能据此认定八条比其他数量更有效。与展示全部发现相比，限制评论能减少阅读负担，但必须让读者知道省略了什么。

我还会把「模型返回零条发现」与「审查完整通过」分开看。作者已经承认存在文件未审查的问题。即便没有丢弃任何发现，覆盖不完整时，绿色对勾仍可能让用户高估结果。

能拿来做什么

• 给 Node 中处理 AI 输出的流水线检查执行顺序：如果后续校验会淘汰结果，就确认提前排序和截断是否会挤掉可用内容。
• 为 AI 编程或审查工具分别记录模型返回数、校验丢弃数、上限截断数和最终发布数，让零条输出有可以解释的原因。
• 给结果页补一个明确的异常状态。当模型有发现但全部无法展示时，显示丢弃原因和数量，避免让用户把空列表当作通过。
• 为审查链路加入「八条无效路径加两条有效发现」这样的回归用例，并把真实 GitHub 与模型服务的交互验证作为后续检查。