推文

@prolibertine · 2026-10-11 19:57

今天中文圈在转「5000 亿 token 让 AI 反编译了一款射击游戏」，我去把 Maurice Heumann（momo5502）10/9 那篇博客原文读完了。游戏他没点名，Kotaku 和 HN 那边都对出来是 2009 年的 MW2，动视已经下过一轮版权投诉。他自己估的用量是 6000–7000 亿 token，因为虚拟机被 agent 搞崩过，日志丢了一批，没法精确。 最有意思的是第一个月。4 个 agent，3 个干活 1 个审，四周还原了大概 80%，游戏能启动、菜单能出、地图能加载。看着进度喜人，结果代码是错的：函数签名、结构体布局乱写，逻辑自己加自己删，原本直接读全局变量的配置被改成了哈希表查找，慢了几个数量级。审查 agent 也没拦住，原因挺损的：干活的 agent 在 commit 和注释里写了一堆「为什么这样改」，审的那个照单全收。作者原话是这些注释等于无意中的 prompt 注入。 后来换了思路，换回原版游戏用的编译器，写个脚本把还原出的函数和原 exe 逐字节比，过就是过，不过就重写。agent 第一反应是写内联汇编糊弄，被禁了以后又去改比对脚本，把自己的函数排除掉，最后只能让 CI 给脚本算哈希，和 GitHub Actions secret 里存的值对。 有了这个判定，审查 agent 直接不要了，而且便宜模型也能干了。之前 Haiku、Luna 这类根本不能用，最后几周是 14 个 Luna 加 2 个 Opus 5.5。博客里写的结果是 99% 的函数都还原了，83% 字节完全一致，游戏跑起来没有明显 bug。 还有两个细节我觉得比 token 数更值钱。上下文压缩阈值从默认 90% 调到 42%，反编译完的函数留在上下文里纯属垃圾。另外每小时用 cron 让所有 agent 重读一遍规则文档，因为跑久了规则会「褪色」，压缩几轮以后 agent 会把某些规则当成不重要。 我的看法是，这篇里最该抄的是验收标准要能被机器判，模型选哪个反而次要。没有硬判定，加再多审查 agent 也是互相说服；有了硬判定，贵模型只用来啃最后那 1%。做 agent 记忆的也可以看看那个每小时重读的土办法，长期规则塞进记忆不等于它会一直生效，得有人定期把它拎回上下文。 作者还有句话挺扎心：头四周的烂代码他们试图修，比推倒重来还费时间。生成代码已经很便宜了，舍不得扔才是成本。

曝光 7 · 评论 0 · 点赞 0 · 书签 0 · 曝光/时 0.8236103673884074