同时评审代码和通过标准

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

覆盖门要求至少70%，候选只有68%。补丁却将阈值降到60%并跳过失败测试，随后显示绿色。评审要检查实现，也检查通过标准有没有被偷偷改变。

具体做法

固定分支基线到完整工作树的范围，包括已暂存、未暂存和新文件。比较阈值、测试删除/skip、断言删除、抑制、桩及例外；阅读语义判断合法替换还是削弱。要求实现满足原契约；确需例外时写理由、范围、负责人和到期，并按项目权威裁决。护栏不能运行也应报告未知，不能当干净。

反例

为让覆盖通过，把70%改60%，跳过失败用例，直接报告修复完成。

改进写法

评审完整补丁时对照原70%门槛。将降阈值和skip作为显式变更报告，先修未覆盖行为；若拟用例外，列具体范围、理由与到期供裁决。不能让绿色状态隐藏门槛下降，也不能仅凭文本匹配否定合法测试重写。

为什么这样改

测试同时被作者修改时，绿色可能来自条件放宽。把门槛作为审查对象，能保留成功的原始含义，防止通过标签替代任务行为。

如何验证

教学68%在70%下失败，60%下通过但应触发门槛变更发现。删除冗余测试且等效覆盖仍保留则需语义复核，不自动判削弱。缺基线或护栏错误应标检查未完成。

适用边界

浅层diff扫描可能误报合法重构，也会漏语义削弱；外部工具也有范围和配置。原标准不一定合理，但修订需要明确依据与授权，不用暗改绕过。非确定指标还需可比条件。