同一份PR重跑三次，AI评审每次都发现新问题：这是能力增强，还是结果不稳定？

同一份PR重跑三次，AI评审每次都发现新问题：这是能力增强，还是结果不稳定？

摘要：新版Copilot Review会展示后续才发现的Previously missed问题。本文给出重复运行、变形补丁和问题级召回的稳定性评测方法。

第一次AI评审找到空指针，第二次找到权限问题，第三次又指出并发覆盖。代码一行没变，问题清单却越跑越长。

这既可能是模型多次采样带来的额外价值，也可能说明单次评审不可靠。GitHub新版Copilot Review专门增加Previously missed分组，让后续才发现的旧问题显式出现。

测试团队需要把“惊喜”变成数据。

用问题级召回，不用评论条数

先人工标注一小批PR：每个真实问题有稳定ID、严重级别和证据。对同一补丁运行5次，统计每个问题被发现几次。

runs = [
    {"NPE", "AUTH"},
    {"NPE"},
    {"NPE", "AUTH", "RACE"},
    {"NPE", "AUTH"},
    {"NPE", "RACE"},
]

def recall(issue):
    return sum(issue in run for run in runs) / len(runs)

assert recall("NPE") == 1.0
assert recall("AUTH") == 0.6

高危AUTH只有60%稳定召回，就不能拿一次成功截图证明系统可靠。

再做一次“无语义变化”变形

给补丁加注释、改变量名、移动无关函数、调整文件顺序。业务缺陷没有变化，结果不应大幅漂移。如果漂移，说明评审可能依赖表面线索或上下文位置。

门禁可以分层：高危问题要求稳定召回；普通可维护性建议允许更多探索性差异；新增发现要经过确定性测试或人工证据确认，不能因为模型说得自信就直接阻断合并。

Previously missed要进入质量报表

建议每周看三个数：高危稳定召回率、误报关闭率、Previously missed占全部有效问题的比例。后者持续升高，说明一次评审不足以覆盖风险，可能需要缩小PR、增加针对性规则或调整上下文。

一次评审、三次评审，成本怎么选

并不是所有PR都值得跑五遍。可以按风险分层：文档和低风险重构只跑一次；涉及鉴权、支付、数据迁移的变更跑三次，并对结果取并集；发布前再用确定性安全测试过滤误报。

这样做的关键是不能把三次模型意见简单投票。一个高危问题只出现一次，也应该进入人工复核；三次都出现的低级样式建议，则不应该阻断发布。严重度和证据强度要一起参与裁决。

质量报告可以记录每个问题的found_runs/total_runs、人工结论、是否有测试证据和最后处置。时间久了，团队会知道哪些类型模型稳定擅长，哪些类型必须交给规则扫描或人工Review。

什么时候说明PR本身需要拆小

如果Previously missed集中出现在超大PR、跨多个业务域的PR，解决方案可能不是再跑十次模型，而是控制变更规模。把一个大补丁拆成有顺序的小提交，既让人容易审，也让模型有足够上下文预算关注关键行为。

这时测试团队可以把“评审不稳定”反向变成工程指标：超过某个文件数或Token预算时，提示拆分；高风险文件被上下文截断时直接拒绝自动评审结论。

AI评审的价值不在每次都说同一句话，而在重要问题不能靠运气出现。测试工程化的任务，就是把“这次看见了”升级为“关键问题稳定看得见”。