Unfix 推出验证工具：专查 AI 修复 C/C++ 与固件代码是否真修好

AI 编写的 C/C++ 与固件代码的第二把钥匙 你的 AI agent 说已经修好了。Unfix 不写代码——它复现 bug，应用修复，重新运行证据，然后把修复撤出来，确认 bug 是否回归。最后给出一个确定性结论：VERIFIED、REJECTED 或 NOT VERIFIABLE（当证据无法判定时）。 1 分 46 秒 · 开启声音 · 以工作名 cplus 录制 Unfix 构建固件，烧录 NUCLEO 板并运行测试。3 次全部失败：计数器应为 42，实际为 41。 这个“修复”把 unity_fail 变成了 unity_pass。CI 会转绿。Unfix 判定 REJECTED，并指出具体行。 板上执行了八项独立检查——修复前有 bug，修复后 3 次全部通过，其他一切正常，回退后 bug 重现。VERIFIED。 内存错误、竞态和偶发失败，正是 AI 编程 agent——以及疲惫的人类——最爱走捷径的地方。Agent 报告成功；bug 却随产品发布。 Sanitizer 被关闭 崩溃消失了，是因为 ASan 或 TSan 不再运行——而不是因为内存错误被修好了。 测试被削弱 断言被放松，或失败用例被跳过，于是测试套件在 bug 周围变绿了。 用延迟代替修复 一个 sleep 让竞态在某台机器上更难触发。但在现场、在真实板子上，它依然会失败。 在干净的沙箱中构建，并确认 bug 在基础版本上失败——每一次运行都要失败，而不是只跑一次。 从 PR 或 agent 处获取补丁，开启 sanitizer 重新运行参考测试。 移除修复，确认失败重新出现。如果没有回来，说明这个测试从未证明过任何东西。 在 diff 中标记被禁用的 sanitizer、被削弱的断言和新增的延迟。 一个基于 STM32 NUCLEO-F401RE 的固件项目。终端应用的未编辑截图。 在运行任何东西之前，会先检查项目类型、连接的板子、ST-Link 探针和沙箱。一键启动。 固件在容器中为 ARM 构建，并烧录到板子上。bug 必须在每次运行中都失败——否则就没有可证明的东西。 测试未被削弱。bug 修复前存在，修复后消失。其他一切仍然通过。撤出修复后 bug 重新出现。 应用到你的文件夹，创建分支，或导出 HTML 报告。如果修复作弊了，你会看到 REJECTED——就像本页顶部那样。 GitHub Action（演示） 在我们演示仓库的 pull request 上 在我们的演示仓库中，GitHub 检查会把结论和证据直接发布在 PR 里，让审查者在合并前就能看到修复是否真实。 该 PR 检查目前在我们的演示仓库中运行；合作伙伴集成正在准备中。 来自我们演示仓库的真实评论（以工作名 cplus 发布）。 查看真实 pull request：#1（VERIFIED），#2（REJECTED）。 在你的 AI agent 中 面向 Claude Code、Codex 及其他 agent 的 MCP 工具。Agent 负责修复；Unfix 判定是否完成。 在终端中 一个简单的命令流应用，包含 /bug、/fix 和 /check——用于环境搭建、调查和演示。 在真实板子上 在你的硬件台架上烧录、运行和检查——面向在板子上而非主机上测试的团队。 我们从知名开源 C/C++ 项目中选取真实 bug，让 code CLI 修复它们，再由 Unfix 依据维护者自己的参考测试来评判每个修复——这些测试对 agent 隐藏。选取这些测试的规则在 agent 运行前就已固定（有一个已记录的例外，fmt-4960），并用反作弊测试防止钻空子。 4 VERIFIED 6 REJECTED 0 UNRESOLVED 覆盖的 bug 类型：ASan 下的内存错误、TSan 下的并发 flush 竞态、边界情况和逻辑错误——包括一个接近固件代码的纯 C 案例。 大多数嵌入式团队在硬件上测试。Unfix 在真实台架上驱动你现有的烧录和测试工具，并把通常混在一起的结果区分开。 目前通过 ST-Link 在 STM32 NUCLEO 板上运行。 对于单个 bug 修复，/fix 给出一个结论：VERIFIED、REJECTED 或 NOT VERIFIABLE。 结论来自构建、测试和 sanitizer——没有语言模型参与判定。确定性规则，结论中无 LLM。偶发和竞态 bug 通过重复运行来判定，而非单次通过。 每次运行都会留下报告：复现了什么、运行了什么、改动了什么。适用于 IEC 62304 风格的变更记录。 为封闭网络而构建。无云、无 LLM——Unfix 完全在你的机器上运行。一次性设置完成后，构建和测试可在断网状态下运行。 Unfix 是面向 C、C++ 和固件 bug 修复的独立验证器。它不写代码。它检查一个修复——由开发者或 AI 编程 agent 编写——是否真正消除了 bug，并返回 VERIFIED、REJECTED 或 NOT VERIFIABLE（当证据无法判定时）。 它在基础版本上复现 bug（每次运行都必须失败），应用修复并在开启 sanitizer 的情况下重新运行测试，检查其他测试仍然通过，然后移除修复并确认 bug 重新出现。它还会扫描 diff 以发现掩盖行为：被禁用的 sanitizer、被削弱或删除的测试、新增的延迟。 因为证明修复有效的最有力方式，就是把它再撤出来：如果移除修复后 bug 没有回来，那么这个测试从未证明过任何东西。 不。结论来自构建、测试、sanitizer 和硬件运行。确定性规则，结论中无 LLM。偶发和竞态 bug 通过重复运行来判定，而非单次通过。 可以。Unfix 能构建固件、烧录真实板子（目前是通过 ST-Link 的 STM32 NUCLEO）并在硬件上运行测试。/check 在你的台架上给出逐测试结论：FIXED（变更前失败，现在通过）、BROKEN（变更前通过，变更后失败）、FLAKY ON THE BENCH（无变更时也不稳定；在信任任何结果前先修好台架）以及 FLAKY, WORSE（变更前偶发，变更后明显更糟）。对于单个 bug 修复，/fix 给出一个结论：VERIFIED、REJECTED 或 NOT VERIFIABLE。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）