测试全绿后，再检查 AI 改动覆盖率

AI 写完代码，测试全绿，项目总覆盖率也没怎么变，新加的逻辑却可能一次都没执行过。开源工具 diff-cover 把覆盖率报告与 Git 差异交叉比对，找出当前改动中没有被测试执行的代码行，给合入前的检查多一个具体依据。

目前能确认什么

diff-cover 读取 Cobertura、Clover、JaCoCo 或 LCov 格式的覆盖率报告，再筛出 Git 改动涉及的行。它回答的是「这次改动有哪些行没跑过」，因此能暴露项目总覆盖率容易掩盖的小范围缺口。

文章给出了 Vitest 和 coverage.py 的接入示例，并用 --fail-under 设置门槛，覆盖率不足时返回失败退出码，方便接入自动检查。

但有两个容易漏掉的地方：

• 默认包含已暂存和未暂存的改动；未跟踪的新文件需要加 --include-untracked。
• 如果文件根本没出现在覆盖率报告里，diff-cover 不会把它记成未覆盖。上游覆盖率工具必须配置为包含未执行的源文件。

报告没有列出缺口，不一定代表新增代码都被测到了。

我的判断

对使用 AI 编程的团队，这项检查适合放在测试通过之后：把未覆盖的改动行反馈给 Agent，要求补上对应场景，比笼统地要求「再加几个测试」更具体。

但行覆盖率只证明代码执行过，不能证明断言有效，也不能保证条件的不同分支都被验证。退款接口里的状态判断即使被执行过，仍要检查非支付状态是否真的被拒绝。

节选后半段的检查脚本没有展示完整，不能据此认定它已经堵住所有绕过路径。尤其是新增未跟踪文件中的覆盖率忽略注释，前面的 git diff 检查并未覆盖。接入时要分别检查文件是否进入差异、是否进入覆盖率报告，以及断言是否验证了预期行为。