撤销修复再跑测试，检查AI补丁是否被覆盖

AI 生成的补丁通过测试，能证明它修好了问题吗？dev.to 的一篇文章提出反向检查：撤销修复，再跑测试，看看测试是否会失败。这个办法能帮助识别「测试全绿，却没覆盖修复行为」的情况。不过，节选中的示例脚本有执行目录问题，直接照用可能得出错误结论。

目前能确认什么

作者提出的核心问题是：拿掉这次修复，测试能否察觉？

示例脚本创建独立的 Git worktree，在其中反向应用指定提交。worktree 可以让同一个仓库拥有独立的工作目录，适合执行这类临时检查。脚本还用退出码区分三种结果：测试发现变化、撤销后仍然通过，以及检查无法执行。

但这段脚本没有切换到临时 worktree 再运行测试。

代码里的 Git 操作通过 git -C "$WT" 指定了目录，最后的 $TESTCMD 却仍在调用脚本的目录执行。按默认的 npm test 用法，它可能测试的是原工作目录，而非撤销修复后的代码。

节选还提出另外三个审查方向：评测集是否包含触发修复的案例、补丁新增了哪些能力，以及判断输出的测试与评测框架是否可靠。

我的判断

这个方法适合给 bug 修复补一道验证：先确认修复后的测试通过，再只撤销实现，保留对应的回归测试，观察目标断言是否失败。

撤销后变红，也不能直接证明测试有效。

依赖缺失、环境异常、编译失败，都可能让命令返回失败；示例脚本会把这些情况一起算作「检测到变化」。如果提交同时包含实现和测试，整体反向应用还可能把新增测试一起删掉，影响判断。

对程序员而言，值得采用的是这套反向验证思路。至于脚本能否用于 PR 检查，还需要核对测试目录、撤销范围和失败原因。当前节选没有交代完整文章是否补齐了这些处理，不能把它当作已经可靠的审查工具。