变更行门控差异测试覆盖率

解决的问题

在持续集成里，全量覆盖率往往是个很迟钝的信号。一次只改了十几行的 PR，报告却显示整体覆盖率从 82% 掉到 81%，或者从 79% 涨到 80%。这个数字对 reviewer 几乎没有决策价值，它混合了历史遗留的未覆盖行、被删除代码的影响，以及本次真正新增的逻辑。结果就是覆盖率门禁变成走过场：要么永远通过，要么为了凑数字去补一堆跟本次改动无关的测试。

真正的风险在于新增代码。一行刚写出来的业务分支如果没有测试，它就是下一次线上事故的候选。而传统门禁恰恰看不到这一点。

技能如何工作

这个技能的思路是把覆盖率检查缩小到变更行上，在合并前做一次聚焦的门控判断。它的核心流程：

• 获取当前分支相对于合并基线的 git diff，得到本次实际改动的行集合。
• 读取受支持的覆盖率报告格式，通常是 XML 或 LCov，这些是 coverage.py 生态下的常见产物。
• 把覆盖率数据与差异行做交集，计算出变更行中被测试命中的比例。
• 输出一份差异覆盖率结果，标记出本次新写入但仍未被测试覆盖的行。

下游的 Agent 拿到这份结果后可以有明确的行动：要么补一个能命中这些行的测试，要么在 PR 里直接说明为什么这几行不需要测试。门禁的判定依据不再是模糊的整体百分比，而是「本次改动有没有被测试守住」这个具体问题。

它依托 diff-cover 这一类工具的能力来完成 diff 与覆盖率报告的比对，poetry 在 Python 项目里负责虚拟环境和依赖组织。

适用边界与注意点

几个实际使用中需要留意的地方：

• 前提是存在覆盖率产物。如果项目根本没有生成 XML 或 LCov 报告，技能无法凭空计算差异覆盖率。
• 只对行级变更有意义。报告关注的是行粒度，纯注释改动、格式化改动也会算进 diff，可能产生噪音，实践中需要结合 diff 过滤。
• 依赖 Python 生态工具链。diff-cover 的能力边界决定了它能处理的报告格式，其他语言的报告需要先转换或确认兼容性。
• 环境准备需要前置。Git 仓库、覆盖率生成流程、Python 环境这三样缺一不可，缺失任何一个环节都无法跑通完整链路。