大概再补 3 个 prompt，就在 640×480 下跑到了 35fps，每帧还得动用 8 个 CPU 核心

一句话看懂：Garry Tan 称用 Opus 5.5 快速模式，仅靠追加约 3 条 prompt，就把一个跑在 Bel LISP 上的 Doom 实现优化到 640×480 分辨率下 35fps。这件事的看点不在帧率本身，而在于 AI 已经能在极短时间内完成过去需要资深工程师数天才能调优的系统级工作。

事件核心：发生了什么

根据 Garry Tan 在 X 上的描述，他此前在一次晚餐中，用 Opus 5.5 的 fast 模式，把约 3.2 万行 C++ 的 Doom 源码转译成不到 2000 行的 Bel 代码（Bel 是 Paul Graham 设计的 LISP 方言），同时用 JavaScript 写了一个完整的 Bel 解释器，整个过程约 20 分钟。随后他又补充说，大概再追加 3 条 prompt，程序在 640×480 分辨率下跑到了 35fps，每帧要占用 8 个 CPU 核心。

需要说明的是，这是开发者本人在社交平台上的自述，目前公开信息显示，尚未看到完整代码、可复现脚本或性能剖析数据对外披露。

为什么重要

第一，它显示了模型从”写代码”向”调性能”延伸。转译代码只是第一步，真正的工程难点在于让一个 LISP 解释器上运行的 Doom 达到可交互帧率。用 prompt 迭代性能，意味着大模型开始介入性能瓶颈定位这类高门槛工作。

第二，Bel 和 LISP 属于解释型、抽象层级极高的语言，在这个基础上跑实时渲染，本身就是对 AI 生成代码质量的压力测试。它不能直接说明 LISP 比 C++ 更好，但能说明模型有能力在极端约束下做工程取舍。

第三，它进一步模糊了”写代码”和”调系统”之间的边界。对于依赖推理成本与算力预算的团队来说，这类案例会直接影响他们评估 AI 在遗留系统改造、跨语言迁移上的可行性。

对用户/开发者/创作者的影响

对开发者而言，值得关注的是这类工作流的可复制性：把大模型当作性能调优的对话对象，而不是只用来生成新代码。对创作者和小团队来说，这意味着原型验证的门槛可能继续下降，一个人加几次 prompt 就能完成过去需要多人协作的移植任务。但也要注意，35fps 依赖 8 个 CPU 核心，属于用算力换开发时间的典型取舍，目前公开信息显示，还没有能效比或成本对比数据，实际生产环境未必划算。