那个通过所有测试的bug，比AI写代码本身更值得看

Anthropic最近在Claude Code文档里加了一个叫advisor的工具，允许你让主模型在关键决策点咨询一个更强的模型。有人把它包装成一套完整的成本优化方案：Sonnet 5.5跑主会话写代码，Haiku 5.5并行探索文件和文档，Opus 5.5只当顾问，在三个时刻介入——锁定计划前、同一个错误出现两次后、宣布任务完成前。命令只有一行：claude --model sonnet --advisor opus。

思路很直接：别用Opus跑那些不需要Opus的活。回复里有人算了一笔账，Haiku做上下文映射，Sonnet的上下文窗口能保持干净，不会在拉取引用时被噪音塞满。也有人泼冷水：模型切换靠什么决定？手动还是路由？Opus 5.5照样会犯错，Sonnet和Haiku的错误只会悄悄堆积。

但这些讨论都没碰到真正要命的地方。

NO1ennn在10月14日发了一篇长文，讲REA这个反向工程工具。REA是一个MCP服务器加CLI，让编码代理能读懂没有源码的程序，一直到机器码级别。文章里最值得读的不是安装步骤，也不是“软件已死”的口号，而是TH08项目里一个已经通过的测试。

一个函数已经通过了精确到字节的对比。然后下游的主机移植版报告了一个道具自动收集的bug。重建的代码把玩家火力跟0.0比较，原版用的是128.0，最大火力阈值。一个常量，不同的游戏。

为什么能通过？对比工具在比较指令前会调整地址，因为重建版可能把常量放在别处。但它没有检查那个地址上存储的浮点数值。指令字节匹配，含义没匹配。

修复分两半：改源码，让对比工具检查常量实际字节。然后审计所有通过弱检查的东西——1,548个浮点字面量引用，又揪出十二个错误，分布在五个已经被“验收”的函数里。

NO1ennn引用原作者N0zoM1z0的话，原文是：“Test the oracle too.” 验证器也是软件，也有bug。一个有盲点的验证器不会只放过一个函数，它会安静地批准几百个。

这跟advisor工具的逻辑其实是同一个东西的两面。把任务拆给不同模型，本质上是承认没有任何单一模型在所有环节都可靠。但如果验证环节本身没被验证过，Sonnet写、Haiku查、Opus审，审出来的结果照样可能是错的。

REA自己的案例里，DX-Ball的一个音频左右平衡函数，3,205个测试用例全过，63个编译字节完全重现。这是行为验证器做到的事。Windows计算器的百分比按钮，200+10%=220的规则被交叉验证到微软公开源码的对应分支。这是把解释也当成了验证对象。

反过来，那个浮点数的故事说明：验证器的覆盖范围决定了你能信任什么。字节对比覆盖了指令，没覆盖数据。你的测试跑过了，不等于你的测试测到了。

所以如果要在团队里用Sonnet+Haiku+Opus这套组合，值得先做一件事：给验证器本身加三个故意失败的用例。改一个常量，换一个分支，挪一个边界。如果这三个错误变体都能通过你的检查，那后面的绿色结果一个都不用信。

Advisor工具解决的是决策成本。Oracle问题解决的是真伪成本。前者让你少花Opus的钱，后者让你少花重写整个项目的时间。两个都做，才算把流程闭环。

Anthropic的文档里写得很克制：advisor是实验性功能，行为、定价和可用性都可能变化。NO1ennn的文章结尾也写了：Berman说的“软件已死”只对了一半。结束的是“闭源等于不可知”这个假设。没结束的是阅读和拿走的区别。

而决定这一切是否成立的东西，从来不是模型。是验证器，以及你有没有测试过验证器。