FixProof 用修复前后测试核验 AI 补丁

AI 写完补丁，再跑出一个绿色测试，就能证明 bug 修好了吗？FixProof 追问的是：这个回归测试在修复前，究竟有没有失败过。它把验证拆成「修复前失败、修复后通过、检查测试完整性警告、给出结论」这条证据链。

这个 MIT 开源工具已发布 v1.0.0。它值得关注的地方，是把「测试通过」和「测试足以证明这次修复」分开。不过，原文没有真实项目的验证数据，工具能检查到什么程度，也需要继续观察。

为什么修复后的绿灯还不够

假设 AI 修改了业务代码，又补了一条测试，最后测试通过。这里仍有一个缺口：如果这条测试放到修复前的代码上也能通过，它就没有证明自己能抓住原来的 bug。

修复后通过，只能说明当前代码满足这条测试，不能单独证明这条测试覆盖了原始问题。

FixProof 会针对选定的回归测试，分别在修复前和修复后的已提交代码上运行。理想结果是前者失败、后者通过，让补丁与测试结果之间建立可检查的联系。

但这一组结果也不是终点。作者还把断言被修改、断言可能变弱，以及测试证据不完整或含糊等情况纳入警告。比如，测试通过可能来自业务逻辑修正，也可能来自检查条件被放宽，两种情况需要区分。

原文没有解释这些警告的具体检测规则，因此不能据此认定它能识别所有测试取巧行为。

四种结果，比一句「修好了」更有用

FixProof 不会把所有结果都压成通过或失败，而是给出四种判定：

• verified：修复前复现了失败，修复后通过，且没有测试完整性警告。
• failed：最终测试仍然失败。
• inconclusive：缺少足够可靠的证据，无法证明修复成立。
• needs-review：已有修复前失败、修复后通过的证据，但完整性警告需要人工审查。

这里最有用的区分是：证据不足，不等于已经证明补丁错误；测试先失败后通过，也不等于可以跳过人工检查。

作者对 verified 的边界说得很明确：它只回答选定测试在特定范围、特定环境中，是否可靠地展示了这一次修复。它不承诺整个应用没有 bug。

接入前，先确认项目命令怎么配置

原文称 FixProof v1.0 支持「显式配置的可信项目命令」，并提供 GitHub Actions 集成和浏览器报告查看器。它没有列出 Jest、Vitest 等测试运行器的适配情况，也没有展示可信命令的配置方式。

下面这条命令用于选择仓库、修复前后两个提交，以及要验证的回归测试：

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

要特别看 --base HEAD~1 和 --head HEAD 两行：它们指定比较哪两个提交。实际使用时，需要确认它们确实分别代表修复前与修复后，而不是照搬相邻提交的写法。

运行后，FixProof 会生成报告，记录变更前后的执行情况与完整性警告，再通过浏览器查看器打开。原文没有交代依赖安装、环境差异，以及测试文件如何在两个版本间安排，这些都是评估实际接入成本时需要核实的地方。

我的判断

我赞同它强调的验证顺序。与只在补丁完成后跑一次测试相比，「先证明测试能抓住问题，再证明补丁让它通过」提供了更完整的修复证据。

但这套方法也可以通过人工切换提交、执行测试来完成。FixProof 的实际价值，要看它能否稳定地组织执行、解释证据，并把值得审查的测试改动呈现出来。作者没有提供与人工流程或现有 CI 的对照数据，暂时不能判断它能节省多少时间、减少多少误判。

它还有一个前提：选定的回归测试本身足够贴近问题。一个覆盖范围很窄的测试，即使获得 verified，也只能支持同样有限的结论。

作者目前正在征集真实 bug 修复的反馈，尤其关注证据为何无法判定、哪些项目配置难以支持，以及报告是否清楚。因此，更适合把它当作待验证的审查辅助工具，而不是直接替代代码评审的质量门禁。

能拿来做什么

• 让 AI 修复前端或 Node 项目的 bug 时，先要求它补出能复现问题的回归测试，并确认测试在修复前确实失败。
• 试用 FixProof 时，选一处容易复现的修复，明确 --base、--head 和 --test，检查报告是否准确呈现了已知事实。
• 审查补丁时同时查看断言变更；遇到 needs-review 要读警告，遇到 inconclusive 要补证据，不能把它们当作通过。
• 评估 GitHub Actions 集成时，先核实项目命令与运行环境的配置方式，再决定是否纳入团队流程。