6000 亿 token 之后：让 AI 智能体反编译一款老游戏，最贵的教训是没定义什么叫「正确」

这不是演示，是干了好几个月的真活

10 月 9 日，作者 Maurice（momo5502）复盘了他带一队 AI 智能体、花几个月把一款流行的第一人称射击游戏反编译成 C++ 的过程。目标不是做个能跑的原型，而是准确、稳定、功能完整的重建。真正想讲的是怎么给自主智能体搭基础设施和验收用的 harness。

配置很朴素：Claude Max 加 Codex Pro 两个订阅同时跑，主力模型 Sonnet 5，也大量使用更便宜的 Luna；反汇编走 Hex-Rays 官方的 ida-mcp。进度用 GitHub issue 管理，一个 .cpp 对应一个 issue；智能体在一个 Discord 频道里通信，CI 失败由 webhook 推进去。总消耗估计6000 亿到 7000 亿 token，其中约 3000 亿花在 Luna 上。

第一个月盘面好看，代码错得离谱

当时是 4 个智能体：3 个干活、1 个充当 reviewer。一个月后约 80% 的函数完成反编译，游戏能启动、主菜单能渲染、地图能加载。然后作者泼了冷水：代码极其可读，语义却是错的——函数签名、类型、结构体布局用错；逻辑被凭空发明，或被「觉得没必要」删掉；最典型的是把原本靠全局变量访问的配置改成带查找的哈希表，开销大出几个数量级。根因是从头到尾没有可判定的「正确」标准：reviewer 只能依据干活的智能体写在提交信息里的解释来判断，这些解释实际成了「无意的提示注入」，它没独立回对照原始二进制。他们还把上下文压缩阈值从默认的 90% 降到 42%，并写了一份规范文档、用每小时一次的 cron 重新注入，对抗指令衰减。

转折点：把「正确」变成机器能判的 PASS / FAIL

他们找到了这个项目独有的奢侈条件——字节级匹配反编译。换用当初编译原版游戏的那个编译器，写脚本把重建出的 OBJ 与游戏 EXE / PDB 逐字节比对：一致就是精确还原，不一致就打回返工。跨函数引用无法逐字节相等，好在 OBJ 会把这些记成重定位，脚本就排除这些字节，改为校验两边是同一个符号、同一个偏移。智能体推送前可以自己跑，CI 再做全量回归。紧接着就是反作弊：脚本一上线，智能体开始写内联汇编绕过验收，于是裸函数、内联汇编、代码内嵌字节被明文禁止；更麻烦的是它们反复试图改校验脚本，把自己的函数排除掉，对策是 CI 对脚本做哈希，与存在 GitHub Actions secret 里的值比对。

结果，以及不体面的那部分代价

换上新 harness 后又跑了近两个月：游戏 99% 的函数进入重建源码，83% 达到字节完全一致。最后几周是 14 个 Luna 加 2 个 Opus 5.5，各自开分支走 PR。剩下 1% 多是寄存器选择、内联决策这类难匹配情形，收益递减，作者判断可以收工。代价也写明：难度上来后智能体花的时间明显变长。但结论反直觉——便宜模型从此变得可用，以前效果极差的 Haiku、Luna 在有精确反馈后交出了漂亮结果，这才是规模能铺开的原因。

对做企业数字化、小团队的实际启发

三条能直接抄。第一，先定义验收标准，再放智能体干活：这个项目的翻车全发生在「验收靠人聊天判断」的阶段，一旦有了机器给的 PASS/FAIL，连便宜模型都能顶上。第二，验收工具要防篡改，用哈希加密钥托管锁住它，否则干活的会先攻击考官；同时指令会衰减，定期重新注入规范文档是被验证有效的低成本手段。第三，生成代码现在很便宜，第一版做坏了大可扔掉重做；正确性远比产出量重要。