31.7 亿 tokens，4974 美元 API 账单，24 个日历日。一个人指挥一个长期会话与 147 个子 agent。整个工程把经典赛车《F-Zero X》从任天堂 64 移植到了 3DS 掌机。新机型 New 3DS 跑满原生 60 帧立体 3D，主频仅 268MHz 的老款 Old 3DS 也获得适配。
在复古社区，逆向移植整台主机游戏通常耗费数年。这需要多名志愿开发者长期投入。G-Diffuser on 3DS 项目把交付周期压缩到了两周多。自动化生成大幅削减了前期体力劳动，却也迅速把真正的工程挑战逼到了聚光灯下。
代码编写环节在自动化流水线介入后迅速退居次席。真正的工程断层暴露在高负荷下的硬件性能归因阶段。只有利用真机性能计数器锁定指令缓存的物理边界，系统才完成了从 10 帧到 60 帧的关键跃迁。
一个人调动 147 个 agent，24 天把黑屏推到 60 帧
整个工程始于 2026 年 8 月 11 日。开发者基于社区完成的 F-Zero X 反编译代码库，搭建起一套单人主导的 agent 流水线。上游核心逻辑保持完整，移植工作主要集中在 3DS 专属的硬件抽象层。
第一阶段的开发持续了 24 个日历日，其中实际活跃日仅有 15 天。期间因为耗尽模型服务商的每周用量配额，项目被迫暂停了三次。即便包含这些中断，代码库依然在 9 月 3 日完成了从开机黑屏到 New 3DS 原生 60 帧的跨越。
调度体系由一个全局编排会话和 147 个专项子 agent 组成，子任务被切细后并发执行。这种调度方式大幅压缩了前期的体力劳动，让单兵作战具备了小型团队的产出效率。
图：v1.0.0 真机（New 3DS）比赛中的画面：下屏是 DASH 仪表盘，显示能量、名次、单圈时间与赛道图。来源：G-Diffuser on 3DS 项目复盘
合规设计在立项初期便被严格执行。最终交付的固件不包含任何受版权保护的游戏 ROM 或磁盘镜像。系统统一从 SD 卡加载用户自行准备的资源包，规避了潜在的法律争议。
31 亿 token 换来万行代码，但模拟器调优在真机失效
第一阶段消耗的 31.7 亿 tokens，按公开列表价折算约为 4974 美元；同期产出是移植目录下 15039 行原生代码与 48 个增量补丁。
代码跑通并不等同于游戏可用。8 月 14 日模拟器首次跑通比赛场景时，画面帧率仅在 12 到 20 帧之间徘徊。8 月 21 日首次烧录进真机运行，帧率虽然爬升到 48 至 50 帧，但离平稳 60 帧的目标仍有明显差距。
工程师随后开启了密集的渐进式调优。9 月 2 日的主线基线测试中，硬件实测中位数帧率为 51.3 帧，p10 帧率低至 39.2 帧，仅有 9% 的时间能稳定在 60 帧上限。此时模拟器中的性能曲线已经趋于平稳，无法反映真实芯片的时延瓶颈。
团队接连推行了五轮系统改造。引入高速桥接缓存后，中位数帧率提升至 57.2 帧；随后优化 HUD 纹理图集、三角面记录与音频混合，p10 帧率拉升至 48.0 帧。把渲染线程搬到第三个核心、启用前方模式（Ahead）并自动调节对手细节之后，真机中位数帧率在 9 月 3 日收官时达到 59.6 帧。
图：v1.0.0 真机（New 3DS）Expansion Kit 的 Select Mode（COURSE EDIT、CREATE MACHINE），下屏为 DASH 空闲界面。来源：G-Diffuser on 3DS 项目复盘
真机跑出 10 帧：瓶颈在 16KB 指令缓存而非指令数
进入第二阶段后，团队把目光投向了规格受限的老款 Old 3DS。这款硬件仅有 268MHz 的 CPU 主频和 64MB 应用内存，曾被社区普遍判定无法承载 60 帧的高速 3D 竞速。开发任务从主线分叉，由并行 agent 展开内存压榨。
9 月 29 日的首次真机测试给团队浇了一盆冷水。针对 New 3DS 编译的固件直接崩溃死机，而专为老机器削减内存的构建虽然勉强进入比赛，却只跑出惨淡的 10 帧。这让原本在模拟器中看似合理的性能推演全面失灵。
常规优化很快触及天花板。工程师将音频互斥锁的作用域收窄，为每一帧省出了约 20 毫秒的等待时间。随后引入的跳帧机制消除了意外慢动作，但真机上的基础渲染时间依然居高不下。
关键转折发生在 9 月 30 日至 10 月 1 日之间。开发者启用了真机性能计数器做精确采样，才看清真实症结所在：卡住系统的是 ARM 核心上 16KB 一级指令缓存的海量未命中，指令总数反而不是问题。
面对这一棘手阻碍，agent 团队曾迅速准备了一套姿态重放的降级方案。该方案牺牲部分实时性以维持帧率，在技术上已经就绪。人类主管在评审时否决了这个妥协方案。他坚持要求探索真机原生 60 帧的可能性。
重写渲染流水线，两代掌机硬件全部跑满全速
诊断明确之后，优化路线发生了根本转向。工程师停止微调指令条数。重构工作全面转向利用指令缓存的局部性。10 月 1 日，一套定制化的自研渲染解释器开始投入构建。
传统移植框架沿用原版 N64 的显示列表逐帧遍历机制，代码体积庞大且跳转频繁。自研渲染器直接跳过了复杂的几何遍历，为赛车、赛道等每一类实体提炼出微型渲染循环。每个渲染热点小循环的代码体积均被严格压制在 16KB 指令缓存之内。
图：Select Machine 界面的 Blue Falcon，从 Homebrew Launcher（.3dsx）启动。来源：G-Diffuser on 3DS 项目复盘
这一重构带来了立竿见影的效率飞跃。Old 3DS 上 2D 模式的 Grand Prix 单帧时间降到 16.5 毫秒（中位数）。原本看似不可逾越的硬件鸿沟，在紧凑代码与指令缓存契合后被迅速抹平。
在随后的两周内，团队补齐了逐眼立体渲染与自适应垂直同步调度。除了最繁重的两条极限赛道可能触发平稳 30 帧保护外，绝大多数赛道在老款硬件上均能维持 59 至 60 帧全速运转。同一套统一代码库最终成功输出了适配两代硬件的三份发布级固件。
自动化生成时代，工程归因能力成为真正分水岭
G-Diffuser 项目提供了一个评估现代自动化研发的绝佳范本。AI 智能体展现出了惊人的模块拼装与原型产出效率，大幅降低了大型逆向工程的启动成本。但在缺乏准确硬件反馈时，agent 往往会沿着局部最优的错误方向持续空转。
模拟器中的顺利通过往往掩盖了物理芯片上的缓存颠簸与总线争用。当团队在真机上遭遇 10 帧困境时，现成的提示词工程无法自动推导出硬件计数器的采样结果。从几十万行指令中锁定 16KB 缓存边界，依赖的是人类工程师对体系结构的深刻理解。
这场历时 43 天的深度攻坚清晰界定了人机协作的价值边界。高效的 agent 舰队可以快速搬运砖石、铺设脚手架，甚至承担繁琐的补丁试错。决定工程成败的决定性力量，依然是那几次基于第一性原理的系统归因与架构重构。
参考链接：
- G-Diffuser on 3DS 项目复盘
- Hacker News 讨论
