先看证据
一项技术同时打开两扇门
2026年10月14日，Simon Willison 的博客转述了独立游戏开发者 Popcar 对 AI 辅助游戏反编译的讨论。Popcar 描述的这波尝试，一边让人把旧游戏改造成混搭、模组或新平台版本，一边也让人担心：同样的能力可能被用来拆解仍在销售的软件，并以未经授权的方式复用代码。这里讨论的不是一款新游戏，而是重建既有软件的工作方式正在变化。
这项变化值得技术负责人留意，不是因为 AI 已经能自动还原任何游戏，而是因为它改变了工作分工。传统反编译通常依赖熟悉机器码的个人或社区长期推进，编程代理则可以承担一部分重复的函数分析和代码重建。门槛下降带来的结果并不单向：保存项目更容易启动，未经许可复制软件也更容易尝试。
提速来自拆分任务，而非一键理解
Maurice Heumann 公开描述过一个射击游戏反编译项目。他没有公开游戏名称，称项目持续约三个月。代理借助 IDA 的 ida-mcp 读取程序分析结果，再协助把函数重建为 C++；人负责组织工作、安排任务并检查进度。项目通过 GitHub issue 按翻译单元分工，并利用 Discord 和持续集成系统反馈错误。
因此，“AI反编译游戏”容易让人误解成模型看一眼游戏，就能吐出完整源码。实际机制更像一条由人管理的并行流水线：把程序拆成较小的函数级工作，逐项重建，再把结果送回编译和检查环节。Heumann 的博文标题称使用超过5000亿 tokens，之后他又估算总量约为6000亿至7000亿 tokens。这些是项目参与者给出的不同口径估计，并非经独立审计的用量统计。
比重建更关键的是证明重建正确
在 Heumann 描述的项目里，验证不是最后才做的验收步骤，而是让并行重建能够继续推进的基础。团队使用原游戏所用的编译器生成目标文件，再将重建函数与原二进制逐字节比对。涉及重定位的引用则另行检查目标符号和偏移，匹配结果还可以进入 CI，避免后续改动破坏已经验证的部分。
这种方法给出了比“看起来能玩”更严格的证据，但并非所有游戏都能照搬。Heumann 指出，编译器设置、寄存器分配、内联和调用约定都会影响结果。即使两段代码语义相同，指令顺序不同也可能无法通过逐字节匹配。换言之，代理可以加快生成候选代码，正确性仍要依赖适合具体二进制和构建环境的验证方法。
保存旧游戏，不等于开放整款游戏
“反编译”“重编译”和“移植”也不能当作同一件事。反编译是从编译后的程序重建源代码；重编译项目可以把原游戏逻辑翻译成新代码，再编译运行；另一些移植工具则尝试让原程序在新平台工作。Popcar 把这些做法放在同一波保存浪潮里讨论，但不同项目的技术路线并不相同，不能因为都借助 AI，就推断它们都还原了同一套内容。
《以撒的结合》相关项目提供了一个重要的边界例子。其 README 描述的是将原游戏代码翻译成 C++，运行在新写的原生引擎上，并要求玩家自行提供 Steam 游戏文件；README 也注明开发过程使用了 AI 辅助。这说明代码重建或新引擎并不自动包含原游戏素材，更不意味着用户不再需要原版文件。对保存工作来说，能运行只是链条中的一环，文件依赖和分发方式同样决定了谁能实际访问游戏。
把可运行、可验证和可分发分开评估
浏览器运行是降低访问门槛的一条路径。Popcar 提到，旧游戏有时可以借助 WebAssembly 在浏览器中运行，这让旧平台停服或硬件不再常见时，多了一种继续访问的可能。但材料没有说明所有案例都采用这条路线，也没有证明浏览器运行能够解决游戏素材、网络服务或授权问题。WebAssembly改变的是运行环境，不会自动替代保存项目对原始文件和其他依赖的处理。
对技术负责人而言，评估这类项目时应把三个问题分开：代码能否重建并通过足够严格的验证，运行是否依赖用户自行提供的原版文件，以及项目计划如何处理代码与素材的获取和分发。AI代理确实能让更多函数级工作并行展开，但它不会消除编译差异，也不会替项目做出授权判断。把验证和文件来源纳入架构与成本评估，才不会把“可以跑”误当成“可以完整保存并自由交付”。