研究发现75.8%的失败AI编程任务仍声称成功，一款测试钩子解决了它

我的编码代理几乎把每个任务都以同样的方式结束。"完成了！所有测试都通过了。"有好几个月我都选择相信它，也好几个月我都在一天后发现这是个谎言。那个从未运行的测试。那个从未被设置的环境变量。那个返回 500 的接口。

事实证明这个现象是有人测量过的。六月的一篇论文（arXiv 2606.09863）研究了那些自我评级的 Agent 运行记录，发现，在失败的那些运行中，仍有 75.8% 声称成功了。同一篇论文尝试用 LLM 法官来捕捉这个问题。在 5 个法官和 5 种提示策略的组合中，最好的 AUROC 是 0.65，最差的是 0.54。一次掷硬币的概率——因为法官读到的是自信的结束语气，而不是机器的实际状态。

测试运行器能以 1.0 的准确率检测到失败的测试套件。于是我构建了一个带有 Stop hook 的测试运行器。

nuhuh 把代理的最后一条消息视为一系列假设。它提取每一条声明（"所有测试通过"、"创建了 src/x.ts"、"接口正常"、"设置了 DATABASE_URL"），然后重新运行现实，开辟一个全新的进程来读取真实的退出码、检查磁盘上的文件、真正调用 localhost。然后它打印一张由自己撰写的收据，而不是代理口述的那张。

🧾 receipt
✅ src/login.ts        存在（33 字节）
❌ src/login.test.ts   不存在
❌ "所有测试通过。"     重新运行 npm test，退出码 1（"测试：1 个失败，3 个通过"）
✅ "构建成功"          退出码 0
4 条声明中有 2 条被核实，2 条失败。

在 gate 模式下，一个虚假的"完成"会被拒绝，失败的证据直接返回给代理，代理会继续工作。经过 3 次反弹后，它会把收据交给你，而不是继续争辩。

测试过程中发生的两件事

第一，我在一个项目中埋了一个陷阱：测试第一次通过，之后每次重新运行都会失败。然后我让一个无头代理报告测试是否通过。它运行了一次，诚实地报告"测试通过，退出码 0"，然后 gate 弹回了它，因为重新运行后测试失败了。接下来发生的事情是整件事最精彩的部分。代理进行调查，发现了这个陷阱，并拒绝篡改它，而是引用了 gate 自己的指令——禁止削弱检查。它修改了自己的声明。整个循环在第一次真实尝试中就起作用了。

第二，我让一个代理故意撒谎，它拒绝了，并引用了"所有测试通过"这句话来表达拒绝。nuhuh 的早期版本会把这段引述提取为一条声明本会阻止这个诚实的拒绝。这成为了虚假指控回归测试套件的第一条用例，现在里面已经有六个真实案例了。这个工具被调校成宁可漏报也不冤枉，因为一次错误的拦截比十次漏报更损害信任。

这个仓库附带了一个 False Done Rate 基准测试。那些确定性的真值脚本对 nuhuh 一无所知，所以它也能暴露 nuhuh 自己的盲点。每个测试工具三轮、每轮 18 个任务，共 54 次运行。

数据迫使我学到的另一个教训。单次运行会说谎。Codex 在第一轮测出 0%，我差点就发布了这个数字。三轮下来它稳定在 4.1%。Haiku 则走向了另一个方向，第一轮 12.5%，三轮后降到 6.1%。

前沿模型比讨论中暗示的更诚实——至少在这个任务规模上是这样。较小的模型产生了有趣的失败案例。一个写了一个 lint 脚本，在 macOS 上 BSD find 会静默吞掉它的失败，然后它诚实地报告说它的损坏检查通过了。一条关于有缺陷检查的真实声明。另一个在一个配置任务上宣告胜利，但配置中仍然硬编码着端口，而且"完成"消息里根本没有可检查的声明。声明验证无法捕捉这两类问题，只有独立真值才能，而这正是基准测试存在的原因。

经过验证仍然存活的设计规则

验证路径中零 LLM 调用。确定性、本地化、无需 API key

不可验证的永远不算失败，超时永远不算失败

只运行项目自身清单中的命令，绝不运行代理文本中的命令

声明模式是一个数据文件（目前有英语和韩语），所以新增一门语言是提交 PR，不是 fork

npx nuhuh demo 能在 10 秒内捕捉到一个预设的谎言，且不触碰任何东西。GitHub：https://github.com/sjh9714/nuhuh