史诗级突破：用 GLM-5 完整复刻 GBA 模拟器（附：长任务 Prompt 设计思路）

这是 GLM-5 连续工作 24 小时后，交付的工程项目：一个完整的 GBA 模拟器

太牛逼了，太牛逼了！

这个玩意儿，是我朋友老栾干的，这两天，他专门围绕「长任务」能力，对着 GLM-5 做了点实验。这个 GBA 模拟器就是产物：能加载 ROM，能玩《口袋妖怪》，整个东西嵌在一个 3D 场景里渲染...

项目是基于 JavaScript 从零写的，单 Agent，无并行，全程 700+ 次工具调用，800 次上下文切换

大家可能觉得 AI 搞个小工具、写个网页没什么稀奇。但 GBA 模拟器这种级别的工程，之前没人敢想。看到成品能跑的那一刻，第一反应就是：妈的，我操！太牛逼了！

这到底是个什么东西

给不太熟悉的朋友说一下

GBA 模拟器干的事情，是在你的电脑上，用软件把一整台 Game Boy Advance 重新造出来

处理器要造，GBA 用的 ARM7TDMI 支持两套指令集，总共几百条指令，每一条都得精确复现，模拟器能不能跑全看这个

内存系统要造，GBA 的内存分了好几个区域，不同区域读写规则不同，搞错一个地址整个程序就崩

图形引擎要造，背景层、精灵、窗口、特效，还有极严格的时序，差一帧画面就花掉

音频要造，这些东西全部跑起来之后，还得嵌进一个 3D 前端场景里渲染出来

AI 写个函数、修个 Bug，这种事早不新鲜了。但像 GBA 模拟器这种横跨多个子系统的完整工程，需要的能力完全不同：得调研，得做架构设计，得分阶段实现，得持续测试，遇到问题得调整方向，还得把每一步的决策记下来，以便后续衔接

一个 Coding Task 几分钟就搞完了，这种工程任务要跑几天

中间差的那个能力，叫「长任务」

接下来，具体聊聊这个项目是怎么架构的

让 AI 连续跑 24 小时

核心思路：把 Prompt 当程序写

传统的 Prompt 是一问一答。给一个问题，等一个回答，结束。长任务的 Prompt 完全不一样，它是一段循环程序，模型在里面反复执行

工作 → 测试 → 记录 → 推进

这个 Prompt 叫 Meta-Prompt，里面定义了几个关键的东西

首先是目标拆解。整个 GBA 模拟器被拆成若干阶段，每个阶段有明确的完成标准。处理器核心到什么程度、内存系统过哪些测试、图形渲染到什么状态才能往下走。模型不需要一口气吞掉整个项目，它只需要知道当前这一步做什么，怎么算做完

然后是笔记协议。这可能是整个思路里最关键的部分。模型的上下文会被清空，但写进文件里的东西不会丢。所以每个 Session 结束的时候，必须记下来：做了什么、下一步该做什么、卡在哪里。这份笔记是交接给下一个「自己」的唯一通道

还有循环跳出条件。每次重试都记到文件里，带上计数。连续失败 3 次就换思路，一个问题超过 20 分钟就记录、跳过、或者喊人。这条规则专门防 AI 钻牛角尖，后面会讲到，真的会钻

最后是恢复流程。每个新 Session 开始的第一件事：读 progress，读 decisions，读 blockers，检查最近改过的文件，然后从下一个待办项继续

底层逻辑的话，可以一句话讲清楚

上下文是短期记忆，文件是长期记忆，Meta-Prompt 是工作方法

过去两年行业花了大量精力扩展上下文窗口。4K，32K，128K，1M。但这个项目里，上下文在 800 次切换中被反复清空，项目从未停滞。关键信息都在文件里，架构决策被持久化，工作状态跨 Session 衔接

上下文窗口装得下一个项目的全部代码，但装不下持续数天的工作过程。文件可以

这套思路说起来简单。但能不能跑通，完全取决于 Meta-Prompt 写得好不好。目标拆得太粗，模型不知道当前该干什么。拆得太细，又会丧失自主判断的空间。笔记协议写得不够具体，下一个 Session 就没法准确恢复上下文。跳出条件定得不好，模型要么太早放弃，要么死磕到天荒地老

写 Meta-Prompt 本质上是在对 AI 做逻辑编程。你得理解工程是怎么运作的，才能把工程的逻辑编进 Prompt 里。同样的模型，不同人写出来的 Meta-Prompt 质量天差地别

两个版本

这个项目，是跑了两个版本：有参考的&无参考的，验证不同条件下的效果

有参考版本，提供了一份开源 GBA 模拟器 gbajs 的源码作参考。

GLM5 读了它的架构，理解了设计思路，然后按照自己的模块规划重新实现。它不是照搬原有代码，而是消化了整体设计之后，自己决定模块怎么拆、接口怎么定、先做哪个后做哪个。结果：GBA 模拟器核心功能完成，可加载并运行 ROM，3D 场景渲染完成。就是你们在开头看到的那个

零参考版本，则不给任何参考代码，关掉网络搜索，纯靠训练知识和一份硬件文档，从零探索实现。没有任何现成的架构可以参考，每一个模块的设计决策都由模型自己做。结果：持续运行超过 24 小时，处理器指令集核心模块完成，模型仍在往前推

同样的任务在上一代模型上也跑过。上一代跑着跑着就开始遗忘，陷入循环，逐渐偏离目标，工具调用出错直接卡住

在 800 次上下文切换之后，Meta-Prompt 里定义的架构规范、编码约定、测试流程，仍然被严格遵守。什么时候该测试、什么信息该记录、什么时候该换策略，这些工程判断的质量从头到尾一致

只能说...GLM-5 这个模型还是有点东西的，不会因为跑久了就开始偷工减料

探索还是曲折的

长任务不是设好了 Prompt 就能放手。过程中踩到了两个坑，做长任务都会遇到

坑一：AI 会钻牛角尖

Debug Boot 阶段遇到了一个 Stub Bios 的错误。模型开始反复尝试修复。一个 Session 修不好，下一个 Session 接着修，再下一个还在修。这个循环跨越了好几个 Session

从单个 Session 的输出看，每次都像在正常工作。有分析，有尝试，有记录。但退后一步看连续几个 Session 的日志，才发现它在同一个地方转了好几圈，每次用的方法还差不多

跟人一样，在难题上死磕，越陷越深，自己意识不到

这里做了一次介入，给了更好的参考文档，帮它跳出了循环

坑二：AI 不会喊人

搜索 3D 资产失败了好多次之后，GLM5 开始从零生成一个 GBA 主机的 3D 模型。它打算自己建模。这件事它干不了，测过其他一线模型也干不了。但它就是不停下来说一句「这个我搞不定，需要帮忙」。它会一直尝试，一直失败，一直尝试

模型天生带着一个设定：我要自己把问题解决掉。短任务里这没毛病，长任务里会造成巨大的浪费。人碰到这种情况，早就去找设计师要资源了。但模型没有这个「我干不了就找人」的本能

如果提前在 Prompt 里定义好工作范围和场外求助的触发条件，这段弯路完全可以省掉

人的角色变了

这两个坑给了一个很直接的经验：长任务里，Agent 持续运行，人变成巡视者
大部分时间在观察，偶尔在关键时刻推一把。帮它校正方向，帮它跳出死循环，帮它判断什么时候该喊人

整个 24 小时里，人只介入了两三次

剩下的时间，是 Agent 在自己读笔记、做判断、往前推。每一个新 Session 启动的时候，它读取上一个 Session 留下的记录，恢复工作状态，接着干。人不在场，它也在跑

往后想一步。一个人同时开着好几个这样的长任务 Agent，各自推进不同的项目。在它们之间巡视，在对的时刻给对的方向。但前提是，你得有能力写出足够好的 Meta-Prompt，让每一个 Agent 都能自主运转下去

工具都是现成的，GLM5 或者其他一致性够强的模型，加上 Claude Code、OpenCode、Cline 这类 Agent 环境。但 GBA 模拟器这件事证明了一个东西：把工具用起来不难，让 Agent 连续跑 24 小时交付一个完整的工程项目，这中间差的是对工程的理解，是 Meta-Prompt 的设计能力

这也是我为什么说这件事是个突破。过去大家讨论 AI 写代码，关注的是单次生成的质量。现在这个维度变了。当 AI 可以自主运行一整天，自己读自己写的笔记，自己决定下一步干什么，自己在多个工程角色之间切换，「写代码」和「做工程」之间那道坎，开始被跨过去了

GBA 模拟器发生在代码领域，但长任务的逻辑不限于代码。任何需要持续推进、多阶段协调的工作都适用

当一个「任务」的时间跨度从几分钟拉到几天，它就越来越接近「工作」本身

体验链接（记得点一下 HD，切换高清模式）：
https://e01.ai/gba