AI编程工具能生成一个修复，然后告诉你bug已经解决了。但有个问题被跳过了：那条回归测试，真的证明了修复有效吗？

一位开发者为此写了FixProof，一个MIT许可的开源工具，专门检查AI生成bug修复背后的证据链。它不负责修bug，只负责回答一件事：这次修复，有没有被测试真正证明过。

一条四步的证明链

FixProof的思路很直接：失败在前 → 通过在后 → 检查测试完整性警告 → 给出结论。

具体做法是，把选定的回归测试分别跑在修复前的提交代码和修复后的提交代码上。修复之后测试通过，本身并不够。FixProof还会盯住几类可疑信号：

  • 测试被删掉了
  • 测试被跳过了
  • 断言被改动，或者可能被削弱了
  • 测试证据不完整、含义模糊

目的只有一个：让那些回归测试从未真正复现原始问题的改动，更难伪装成"已验证"。

四种结论，不留模糊地带

跑完之后，FixProof只会给出四种结果之一：

  • verified（已验证）：修复前复现了回归，修复后通过，且没有任何完整性警告
  • failed（失败）：最终测试仍然不通过
  • inconclusive（无法定论）：没有足够可靠的证据证明修复成立
  • needs-review（需人工复核）：失败在前、通过在后的证据存在，但测试完整性警告需要人来判断

这四种结果里，后两种才是这个工具真正想强调的部分。测试通过不等于证据成立，证据成立也不等于可以自动放行。

支持哪些测试运行器

FixProof v1.0目前支持Node.js的node:test、Jest、Vitest、pytest，以及显式配置的可信项目命令。此外还带GitHub Actions集成和一个基于浏览器的报告查看器。

一次基础验证长这样：

node bin/fixproof.mjs verify \
--repo ../my-project \
--base HEAD~1 \
--head HEAD \
--test tests/regression.test.mjs \
--output fixproof-report.json

运行后会生成一份报告，描述改动前后各自发生了什么，以及发现了哪些完整性警告。报告可以直接在浏览器查看器里打开。

它不声称什么

FixProof明确划了一条边界：verified结果不代表整个应用没有bug。

它验证的是一个窄得多的问题——在受测范围和环境下，选定的回归证据是否可靠地证明了这一处修复。作者认为，把这条边界说清楚很重要，尤其是在AI编程代理参与进来的时候。

项目目前已经到v1.0.0，代码在GitHub上，附一个在线演示，MIT许可开源。

作者现在想找使用AI辅助编程工具的开发者，拿真实的bug修复来试。他更想知道的是：验证在哪些地方会变成无法定论，哪些真实项目配置目前跑起来困难，报告有没有把证据讲清楚，以及加哪些集成会让工具更有用。用他的话说，眼下找出局限，比单纯收集star更有价值。