一款1998年的N64滑雪游戏，被一支小团队用84天做出了字节级完全一致的反编译——编译出的机器码和原版ROM逐字节对齐。作为对照，它的续作《Snowboard Kids 2》用了596天才走完同样的路，速度差了近7倍。开发者Chris Lewis把这归因于AI辅助加上团队经验积累，但报告里藏着一个更值得盘问的数字：批量跑在1830个未匹配函数上的自动化翻译工具m2c，成功率只有0.93%。
这提醒我们别急着把84天读成"AI又干成一件事"。反编译不是让游戏能跑起来就算数，而是要求逆向出的C代码经编译后，产生和原版ROM完全相同的机器码——这个门槛比"看起来对"高得多，也正是这类项目里AI真正的边界所在。
一个停产的编译器，比AI更难对付
《Snowboard Kids》用的是SGI的IDO 5.3编译器，续作用的是开源GCC 2.7.2。这个差异才是项目难度的核心变量。GCC至今仍在维护，行为可预测，社区经验丰富；IDO早已随SGI工作站停产，源码不公开，优化和代码生成拆成好几道内部传递，一处C代码的微小改动就可能让寄存器分配整个改写。开发者的原话是：LLM和他自己都不太擅长复现IDO的输出。
一个已经停产多年、没有官方文档的闭源编译器，恰恰是permuter、m2c这类自动化工具最吃力的场景——你可以让工具反复排列组合去凑一个字节匹配，但如果C代码的结构本身就写错了，排列组合永远凑不出正确答案。
那个被算糊了的4.8%
报告里另一个数字更值得追问：作者自称仅4.8%的匹配commit涉及专家人工介入，暗示AI和自动化工具包办了剩下九成五以上的工作。但这个数字目前找不到独立来源佐证，统计口径也没说清是按commit数、函数数还是耗时算的。
- 风险.4.8%这类低比例数字容易掩盖"关键节点上极少数人做了不成比例的工作"——作者自己的脚注也承认，没有几位核心贡献者的IDO专业知识，项目很可能卡在89%到90%就再也推不动。
同一批1830个未匹配函数，m2c批量翻译只精确命中17个，成功率0.93%。这两个数字放在一起看，比"AI贡献了多少百分比"的自我总结更诚实：AI能扫掉标准库代码这类低垂的果实，libultra、libmus之类的现成函数一抓一个准；但真正决定项目能不能封顶的长尾部分，还是要靠人对编译器怪癖的直觉。
速度纪录，还是workflow的复利
真正拉快速度的，更像是workflow层面的积累，而不是模型本身突然变强了。团队把IDO的编译器怪癖写进了一份共享文档，一个agent踩过的坑能立刻变成另一个agent的经验；四个Git worktree并行工作时，一处新匹配的函数可以跨分支即时被其他agent引用，不用等合并到主干。这些都是流程优化，跟GPT或Claude本身的代码生成能力关系不大。
一个侧面证据是《Pilotwings 64》的反编译只用了74天——虽然它的函数数量比《Snowboard Kids》少一些，编译后代码量却更大，两者不能完全类比，但足以说明：经验丰富的人类团队配上对的工具，本来就能达到类似速度，未必非要归功于AI的跃升。
对速通玩家和modding创作者来说，这份完整源码的实际用处，比"84天"这个数字更值得关注。源码能解释CPU寻路和玩家速度背后的具体机制，帮速通社区把路线和道具操作打磨得更精确；对modding者而言，团队已经在尝试把初代的关卡内容移植进续作的引擎里，这条路径此前只能靠猜。但100%匹配反编译不等于代码已经被读懂——大量变量和结构体现在还是自动生成的占位名字，清理、命名、静态重编译，都是接下来要单独啃的活。