开源实验把 NES 处理器模拟写进模型权重

把《超级马里奥》跑进 Qwen，听起来像让聊天模型一边回答、一边玩游戏。Drew Breunig 做的却是另一件事：把 NES 的 6502 CPU 模拟器做进 Qwen3.5-4B 的权重，再让它运行游戏 ROM。Simon Willison 在 2026 年 10 月 30 日的短文里介绍了这个项目 nesformer。

它已经能运行，但非常慢。比猎奇结果更有参考价值的是构建过程：作者让 Opus 5.5 探索方案、推进实现，期间还用上了已有的 CPU 一致性测试。不过，这篇短文提供的证据，也只够支持有限的结论。

游戏跑在权重里，和让模型玩游戏有什么区别

原文描述的目标是模拟硬件执行，而不是让模型根据画面判断下一步按哪个键。

模拟器需要按目标 CPU 的规则执行指令、更新状态。游戏 ROM 提供程序，模拟器负责执行；这里特殊的地方，是作者把 NES 6502 CPU 的模拟能力放进了 Qwen3.5-4B 的权重。原文称，《超级马里奥》等 NES ROM 已经可以在其中运行。

这个项目展示的是模型权重承载计算规则的可能性，不能直接当成模型学会游戏的证据。

项目受 Divyansh Agrawal 的 qwenputer 启发。但这篇短文没有展开权重如何构造，也没有交代是否经过训练、运行时如何表示 CPU 状态，以及 NES 其他硬件部件如何配合。能运行游戏是一个具体成果，距离完整解释系统仍有不少空白。

为什么提示词先问时钟速度，最后却接受慢速

作者公开的两段 Opus 5.5 提示词，透露了需求怎样收敛。

第一段先要求阅读 qwenputer 的文章和相关源码，再探索能否用同一技术模拟 NES 的芯片与 RAM。作者还拿 FPGA 上模拟硬件的做法作参照，并追问：需要多大的模型？更小、更快的模型能否达到标准时钟速度？

第二段则明确开工，并降低了性能要求：只是为了好玩，慢一点也可以。交付物要有权重，以及一个可以指定 ROM 来运行的 CLI。

这两步很关键。前一步探索可行性，后一步给出可验收的结果。「能否达到标准时钟速度」只是最初的问题，原文没有给出肯定答案；最终描述反而明确强调运行非常慢，也没有提供帧率、吞吐量或硬件配置。

实现过程中还有一个具体细节：据文中转述，Opus 找到并使用了 Christopher Pow 在 15 年前发布的 NES CPU 一致性测试。这类测试用于检查模拟出的指令行为是否符合预期，比观察游戏是否出现画面更适合定位 CPU 实现错误。

不过，原文没列测试通过率，也没说覆盖了哪些行为，不能把「使用测试」写成「完整通过验证」。

我的判断

我更看重这个项目把开放式探索收敛成了两个交付物：权重和 CLI。目标具体，已有 ROM 可以作为输入，又有历史测试资源可供检查，这些条件让 AI 编程任务更容易推进。

但它不是模型模拟器优于传统模拟器的证据。原文没有性能对照、资源消耗或实现成本数据，也没证明这种方式适合实际游戏体验。普通团队如果只是想运行 NES 游戏，这篇文章没有给出放弃传统方案的理由。

Opus 5.5 的参与同样需要限定解读。公开提示词能说明作者如何提出任务，却不能还原全部开发过程；作者修正了多少代码、进行了多少轮调试，短文都没说清。把它当成一个有趣的构建案例合适，把它当成自主开发能力的完整评测就过头了。

能拿来做什么

• 给 AI 编程任务写清交付物。可以借鉴作者的要求，明确输入是什么、通过什么入口运行，以及最终需要留下哪些文件。
• 开发解释器、协议解析器或兼容层时，先找已有的一致性测试。让 AI 围绕明确规则实现，比只凭几个演示结果判断正确性更可靠。
• 做探索项目时，把「先运行起来」和「达到性能目标」分开验收。能跑、跑得正确、跑得足够快，分别需要证据，不能用其中一个替代另外两个。