用可信覆盖率约束智能体代码补丁

CI 变绿，可能只是失败的测试被移出了执行范围。dev.to 的一篇文章提出，在总覆盖率之外增加「可信覆盖率」：只计算当前代码树上实际运行、且未被冻结的测试产生的覆盖，并用它的变化约束代码智能体提交的补丁，识别通过隔离测试换取通过的修改。

目前能确认什么

这是一套基于 pytest、coverage.py、YAML 登记表和 CI 的工作流。作者在节选中举例：总覆盖率为 84%，排除冻结登记表中的 11 个测试后，可信覆盖率降到 71%。这是文中的示例，不能当作普遍差距。

覆盖率衡量代码是否被执行，不能直接证明断言有效或业务行为正确。「可信」在这里也有明确边界：它指测试参与执行且未被冻结，并不保证测试质量。

方案把冻结决定放进版本管理中的登记表，记录负责人、原因、到期时间，以及测试应验证的性质。CI 据此生成排除列表；冻结过期后，测试重新参与运行，同时触发到期检查。

计算时，完整运行和可信运行共用固定的代码行集合，避免隔离测试后，部分文件从统计分母中消失，造成覆盖率虚涨。补丁还要与基准分支在相同统计范围内比较。

我的判断

它最有价值的地方，是让「修好代码」和「移走失败测试」在 CI 中留下不同信号。

对允许智能体修改测试或 CI 配置的团队，这比只看绿灯更有针对性。冻结有负责人和期限，也让临时绕过的问题有机会重新暴露。

但这道门禁有边界：如果被冻结测试执行的代码仍被其他测试覆盖，可信覆盖率可能不变，丢掉的关键断言仍然无法体现。

节选在 CI 接线部分被截断，基准数据如何生成、两次运行的数据文件如何隔离，还没有完整说明。已有脚本也主要围绕登记表生成排除参数，能否识别补丁另加的 skip、xfail 或 CI 排除项，尚不能确认。可信覆盖率可以补充审查信号，不能代替对测试改动本身的审查。