Abacus AI 超级计算机与自主编码环境搭建
本次测试的核心在于利用 Abacus AI 提供的云端超级计算机实例，该环境为 GPT-5.6 Soul 和 Fable 5 模型提供了 完整的 root（根）访问权限。这种底层系统控制权是执行复杂任务的关键，因为模型需要独立处理环境配置、后端服务部署以及前端物理引擎的集成。视频演示了一种“氛围编码”（Vibe Coding）的高级形态，即 AI 工程师自主解决安装或执行过程中出现的错误，通过读取终端日志自行修复问题，而无需人类干预。这种自动化能力使得模型能够在一个无头服务器环境中，独立完成从代码编写到服务部署的全流程。测试者特别指出，这种设置允许模型利用云算力运行本地资源密集型任务，为后续部署轻量级大语言模型（LLM）奠定了基础。
游戏架构设计：本地化 LLM 与后端逻辑
在技术栈选择上，项目要求构建一个全栈浏览器端 3D 物理游戏，后端采用 Python。为了赋予 NPC（非玩家角色）对话能力，模型被指示拉取并部署一个 0.5 billion parameter（5 亿参数） 的 Qwen 2.5 模型。选择该特定版本的原因在于其 不具备思维链（thinking）功能，这使得它在生成快速、简单的游戏内对话时更加高效且响应迅速。后端需要创建一个 API 端点，接收文本输入和角色 ID，并返回由本地 Qwen 2.5 生成的响应。这种架构不仅实现了游戏逻辑，还展示了 AI 驱动的智能 NPC 在游戏开发中的实际应用潜力。通过本地部署小参数模型，避免了对外部 API 的依赖，确保了游戏在离线或低延迟环境下的稳定性。测试者强调，这种 AI 赋能的 NPC 将成为未来游戏开发的重要趋势。
前端交互与核心玩法机制：Yeet 物理引擎
游戏的前端基于 3.js 和如 Cannon.js 或 Ammo.js 等物理引擎，构建了一个细节丰富的 3D 城市街区环境。玩家以第一人称视角控制角色，屏幕上显示一只巨大的拳头。场景中填充了可互动物理道具（如垃圾桶、箱子）以及至少三个具有独特人设的 NPC 模型。核心玩法机制围绕 NPC 对话与物理打击 展开：当玩家点击 NPC 时，会弹出聊天界面；NPC 根据预设的幽默系统提示（如“暴躁的热狗摊贩”、“偏执的科技新贵”或“禅意喂鸽人”）进行动态回复。对话结束后，玩家需输入关键词来决定结局：若输入 "neet"，和平结束；若输入 "yeet"（意为猛投/击飞），巨大的拳头将对 NPC 施加一个巨大的物理冲量，使其飞出城市。此外，游戏还引入了 随机数机制 来增加趣味性：NPC 会在玩家进行一定次数（1-10次之间的随机数）的 "yeet" 后发起反击，将玩家角色击飞并重置游戏页面。
Max Mode 执行与部署验证
为了启动这一复杂任务，测试者在 Abacus AI 界面中启用了 Max Mode，明确指定使用 Fable 5 和 GPT-5.6 作为处理最困难任务的日常 LLM。模型被赋予“自主 AI 工程师”的角色，要求其在遇到错误时自行读取日志并修复。在发送指令后，界面切换至聊天风格窗口以监控进度，同时保留超级计算机视图以便观察底层操作。模型成功完成了环境设置、后端 LLM 托管以及前端静态文件的serve服务，并最终提供了 本地端口和公共 URL。这一过程验证了当前顶级大模型在无需人类代码辅助的情况下，能够独立构建包含复杂逻辑、物理交互和本地 AI 推理的全栈 Web 应用。测试者通过这一案例展示了 云端算力与先进大模型结合 在降低开发门槛和提升创作效率方面的巨大潜力。
"I need you to act as an autonomous AI engineer and game developer. You have root access to this machine... Your task is to build and deploy a full-stack browser-based 3D physics game called Street Eat."
"The reason I'm choosing that model specifically is Qwen 2.5 doesn't have thinking, so it just makes it easier when we want quick and fast, simple dialogue systems for NPCs in games."
"If yeet, the chat closes, the player's giant fist punches the NPC, applying a massive physics impulse that sends the NPC flying a hilariously long distance across the city."
云端沙箱环境与本地 AI NPC 配置
Abacus AI 的核心工作流始于在超级计算机云端沙箱中构建独立实例，代理拥有该环境的 root 访问权限以完成所有设置。这一过程完全隔离于用户本地系统，无需任何敏感数据暴露或权限转移。所有代码编写、环境配置及模型下载均在虚拟云中完成，最终仅输出一个可访问的实时链接供用户游玩。这种架构极大简化了复杂应用的部署流程，实现了真正的“氛围编码”（Vibe Coding）。
在环境初始化阶段，系统重点配置了本地小型聊天 AI 参数。为了增加角色互动的多样性，开发者设定了三个特定 NPC：Vinnie（暴躁热狗摊贩）、Blake 和 Maureen。每个角色拥有独立的提示词，避免对话同质化。聊天 AI 的参数设置为最大生成 token 数 120，温度值（Temperature）设为 0.8。这一设置旨在平衡生成的创造性与稳定性。虽然温度值可设为一以上以产生更离奇的对话，但 0.8 已足以满足当前游戏场景的需求。代理通过编写代码将这些参数应用到项目中，确保本地 AI 能够稳定运行。
代理自主工作流与模型优化迭代
整个开发过程展示了完整的智能体（Agent）自主工作流。代理不仅负责代码生成，还持续监控并执行待办事项列表（To-Do List）。在开发初期，代理专注于创建 Vinnie 角色及其旁边的热狗推车模型。随着任务推进，待办事项列表实时更新，例如从第一步进展到第二步时，代理开始设置项目环境并下载所需的模型权重。值得注意的是，所使用的模型体积较小，因此无需担心本地硬件的资源占用或设置复杂性。代理自动处理了从依赖安装到模型加载的所有后端工作，用户只需关注最终的游戏体验。
在测试阶段，代理发现尽管小型 AI 响应迅速且能在 CPU 上高效运行，但角色一致性（Character Adherence）较弱。代理报告指出：“the character adherence is weak because of the tiny model. Let me strengthen it with few shot examples.” 为了解决这一问题，代理利用前沿模型（如 GPT-5.6 和 Fable 5）的能力，对仅有半十亿参数（half a billion parameter）的 Quantum 2.5 小型模型进行微调。通过提供少样本示例（few-shot examples），代理在云端超级计算机上自主测试并优化了小型模型的表现，使其能够更连贯地保持角色设定。这一过程体现了前沿大模型对小型特定任务模型的优化能力，无需用户干预即可自动完成性能提升。
游戏机制验证与自动化测试反馈
随着开发进入后期，代理开始进行自动化游戏测试。界面采用分屏显示：左侧为代理的计算机操作动作，右侧则在云端 Chrome 浏览器中实时展示游戏运行效果。测试初期，代理展示了基本的场景元素：街道、玩家移动特效以及 Vinnie 角色。游戏的核心机制涉及互动选择，玩家需要先与 NPC 对话，然后决定是否执行“yeet”（投掷）动作。若玩家输入特定指令如 “neat”，系统会在聊天框中显示和平互动的反馈信息。代理在测试过程中自动验证了这些机制，并确认“all mechanics have been verified”。
尽管代理在测试中偶尔会出现操作失误（如意外控制角色导致画面异常），但其自主纠错和继续测试的能力确保了开发流程的连续性。代理能够识别并修复这些临时性问题，无需用户手动介入调试。这种端到端的自动化测试不仅验证了游戏逻辑的正确性，还确保了图形渲染和交互反馈符合预期。虽然当前的图形保真度可能仍处于早期阶段，但核心玩法循环已完整建立。代理通过持续的迭代和优化，逐步将概念转化为可玩的应用程序，展示了 AI 在复杂应用开发中的巨大潜力。
模型配置与初始部署策略
在启动游戏开发项目时，系统首先完成了提交检查点并记录了部署状态。为了托管一个仅有 半十亿参数（half a billion parameter） 的微型模型，技术团队特意选择了仅使用 CPU 运行的 PyTorch、Transformers 和 Accelerate 库。这种配置旨在降低资源消耗，但同时也带来了 提示词遵循能力不足（prompt adherence） 的挑战。为了解决这一问题，模型在构建过程中自主决定采用 单样本角色示例（one shot in character examples） 来强化人设一致性，并将最大生成长度限制为 120个新令牌（Max new tokens 120），以确保对话简洁且符合角色设定。最终生成的游戏被命名为 "Street Yeet" 并部署在 Abacus AI 的超级计算机上，同时提供了完整的文件列表及 GitHub 连接选项。
初步测试与负面反馈循环
游戏上线后，开发者立即进行了首次交互测试。在 Chrome 浏览器中打开 "Street Yeet" 后，开发者发现虽然角色动画（如出拳）存在，但 缺乏音效 且初始状态下无法通过 WASD 或方向键移动角色。针对这些缺陷，开发者给出了严厉的反馈："Absolutely, I'll address the feedback and make a substantial improvement pass."（绝对会，我会处理反馈并进行实质性改进）。值得注意的是，开发者在测试中特意确认了模型未包含之前 Opus 5 版本中出现的不当内容（如狗或宠物），并保留了 "Counter Yeet"（反击投掷）机制以增加游戏策略性而非单纯的上帝模式。随后，开发者尝试在移动端访问该网页应用，发现虽然屏幕较小且可见度有限，但点击屏幕仍能触发出拳动画，证明了跨平台的基础兼容性。
迭代优化后的游戏体验与细节验证
经过一轮实质性改进后，刷新页面展示了显著变化：场景中新增了 移动体积云（moving volumetric clouds）、车辆以及背景音乐。开发者与 NPC "Hot Dog Vinnie" 互动时，尽管受限于模型参数量（半十亿参数模型），对话智能度有限，但角色回应了 "I'm Vinnie always hot dogging it up. Yeet." 等符合人设的台词。物理交互方面，开发者成功投掷了车辆，并注意到不同物体的 重量感（weight） 设定相对真实。此外，NPC "Maureen"（喂鸽子女士）和 "Blake"（技术 guy）的对话也展现了剧情分支，例如 Blake 拒绝透露机密信息以换取种子轮投资。开发者还测试了投掷消防栓、热狗车等物体，并确认模型成功阻止了对鸽子的攻击（"No, good. And we don't want to."），体现了安全约束的有效性。尽管仍有改进空间，如希望增强投掷力度和覆盖更多物体，但整体体验已符合预期。
后续改进需求与总结
在第二次版本测试后，开发者列出了进一步的优化清单。核心诉求包括：能够投掷所有物体（如消防栓、热狗车、鸽子等），并解决当前车辆投掷 压缩力度过大（far too compressed） 的问题。开发者强调，虽然目前的版本已经实现了基本的移动、对话和物理交互，但在 投掷手感 和 物体覆盖范围 上仍需调整。整个开发过程展示了 AI 模型从代码生成、部署到基于用户反馈快速迭代的能力，特别是通过 单样本示例 解决小模型人设漂移问题，以及利用云端算力实现即时部署和测试的流程。开发者对模型的进步表示满意，但也指出了在物理引擎细节（如投掷力度反馈）上仍有提升空间。
强化卡通风格与NPC交互机制
开发团队对游戏进行了显著的“过度”和“夸张化”调整，旨在增强整体的卡通感和荒诞感。核心改动包括增加非智能NPC的数量，即使这些随机生成的角色不具备高级AI逻辑，也必须具备反击玩家“Yeet”（投掷）动作的能力，以此提升游戏的趣味性和挑战性。同时，引入了“Power Yeet”（强力投掷）道具，拾取后能显著增强玩家的攻击力度。在视觉反馈上，当鸽子被投掷时，会伴随“squawk”音效以及名为“Cartoon juice impact text”的夸张文字特效，进一步强化卡通化的打击感。
"I just want more extreme overall... make it more over the top and cartoonish along with these features."
测试过程中，玩家观察到NPC群体行为的变化。虽然部分NPC（如Randy和Gary）表现出进入建筑物的简单逻辑，但整体 crowd 行为符合“dumb NPC”的设定。此外，场景中的可交互物体范围扩大，路灯杆和热狗车均成为可投掷对象。虽然尚未找到关键的“Golden Fist”（金拳头）道具，但新增的“Counter Heat”机制允许刷新状态，为游戏增添了更多策略维度。这些改动共同构建了一个更加混乱、滑稽且充满互动性的开放世界环境。
移动端控制适配与UI优化
在桌面端测试完成后，开发重点转向移动端的全面支持。这包括实现手机触屏控制以及将道具名称从“Golden Fist”改为更具卡通风格的“Golden Knuckle Sandwich”。系统自动在设置面板中添加了切换开关，并自主测试了触屏功能。开发者注意到屏幕右侧出现了虚拟按钮（如蓝色跳跃键），且聊天功能的射线检测逻辑也得到了修复，解决了之前触屏无法打开聊天的问题。这一阶段的关键在于验证移动端触控操作的可行性与流畅度，确保核心交互（移动、攻击、跳跃）在触屏设备上能无缝移植。
"The final task here is basically to implement mobile phone support... rename the golden fist power-up to something a little more cartoonish."
系统自动生成的测试显示，虚拟摇杆和按钮布局合理。开发者特别指出，触屏控制下的UI元素（如文本大小）更符合卡通主题风格。通过硬刷新后，游戏正式支持移动端操作。开发者随即使用手机进行实地测试，将设备调整为横屏模式（Landscape），以模拟最佳游戏体验。这一过程验证了从桌面键鼠到移动触屏的交互范式转换是否成功，重点考察虚拟摇杆的移动精度、视角旋转灵敏度以及按键响应的及时性。
移动端实测体验与最终评估
在手机横屏模式下，开发者对游戏进行了详细的操控测试。左侧的虚拟摇杆不仅支持前后左右移动，还能通过拇指操作实现视角旋转（Pivot），这种设计被评价为“相当不错的移植”。右侧的蓝色箭头按钮负责跳跃，而另一个主要按键则用于拳击/投掷。开发者发现，触屏操作下的游戏节奏依然流畅，导航难度低。尽管“Golden Knuckle Sandwich”道具仅有15秒的持续时间限制，但在这短暂的时间内，玩家能够有效地利用投掷机制对抗NPC。测试中多次出现被“Counter Yeet”击败后重新开始的循环，证明了游戏难度的存在与平衡性。
"This actually looks pretty good in landscape mode... It is definitely a good transposition to mobile controls."
最终评估认为，移动端控制体验令人满意。虚拟摇杆的移动和视角旋转配合良好，跳跃和拳击按键布局合理且响应迅速。开发者特别提到，即使在被NPC反击后重启游戏的过程也显得自然，未破坏游戏体验的连贯性。整个“Vibe Coding”测试项目得益于Abacus AI及其超级计算机功能（使用Max模式结合Fable 5和GPT-5.6 Soul），成功实现了从概念到多平台可玩原型的快速迭代。此次测试不仅验证了核心玩法的趣味性，更证明了AI辅助开发在跨平台适配上的高效性。
Abacus AI 超算集群支撑底层依赖与模型部署
本次演示的核心在于利用 Abacus AI 的超算基础设施，实现了从环境配置到模型运行的全流程自动化。由于项目涉及 智能 NPC（Intelligent NPCs），系统必须自动下载并运行 Tiny Quan 模型。在传统的开发流程中，依赖设置和 CPU 上的模型推理往往需要繁琐的手动配置，但在此案例中，所有依赖设置及 CPU 模型运行完全由 Abacus AI 超算处理。这种架构不仅解决了本地算力不足的问题，还确保了开发环境的纯净与高效。通过云端托管，开发者无需关心底层硬件细节，只需关注逻辑实现。整个部署过程由 Abacus AI 托管，使得原本复杂的后端配置变得无缝衔接。这种“即插即用”的基础设施支持，是项目能够迅速从代码转化为可运行应用的关键前提。
跨平台无缝访问与项目文件打包机制
Abacus AI 的部署优势不仅限于后台，更体现在前端的访问体验上。项目通过云端托管，实现了从特定系统到移动设备的无缝跨平台访问。开发者只需输入代码，即可生成一个在线可玩的生产级游戏链接。该过程极其流畅，开发者可以将生成的链接分享给任何人，对方无需安装任何客户端即可直接在浏览器中游玩。此外，平台提供了完整的项目文件下载功能。以游戏“Street Eat”为例，用户可以一键下载整个项目文件夹及 agents.md 配置文件。这种打包机制不仅包含游戏代码，还包含了 Quen 2.5 0.5 B 模型的权重文件。尽管包含模型权重，下载体积仍处于合理范围。所有文件的打包与分发均由智能体（Agents）协调处理，确保了数据完整性与传输效率。这种端到端的交付模式，极大地降低了游戏分发和协作的门槛。
多模型协同开发与移动端验证成果
本次视频总结了使用 GPT-5.6 与 Fable 5 协同工作的完整工作流。开发者利用这两个模型共同构建游戏逻辑、设置机器依赖，并最终实现了一个可在手机上直接游玩的游戏。其中，“Street Eat”作为模型测试中的热门案例，其独特之处在于为行人赋予了智能 NPC 行为。通过 Abacus AI 的超算支持，开发者成功解决了模型推理的资源瓶颈。整个开发过程展示了从代码生成到移动端部署的完整闭环。这种协作模式不仅验证了 GPT-5.6 和 Fable 5 在处理复杂游戏逻辑时的有效性，也证明了云端超算在降低 AI 应用开发门槛方面的巨大潜力。最终生成的游戏不仅功能完整，而且具备良好的跨平台兼容性。这一成果标志着 AI 辅助开发在游戏领域的应用已趋于成熟，为未来的独立游戏开发和原型设计提供了新的范式。
结论
本次测试证实，结合 Abacus AI 超算与 GPT-5.6、Fable 5 模型，可实现从代码生成到全栈部署的“氛围编码”闭环。其核心优势在于云端 Root 权限赋予 AI 自主解决环境配置、依赖安装及报错修复的能力，无需人工干预。通过本地部署轻量级 Qwen 2.5 模型并辅以少样本提示，有效解决了小参数 NPC 的角色一致性问题。跨平台适配与自动化测试验证了多模型协同在快速原型开发中的高效性。
然而，当前方案仍存在局限：小参数模型导致对话智能度有限；物理引擎在投掷手感、力度反馈及物体覆盖范围上尚需优化，存在压缩感过重等细节缺陷。此外，初始版本缺乏音效且移动端触控逻辑需额外修复。该流程适用于对图形保真度要求不高、追求快速迭代的游戏原型验证，但尚未达到生产级游戏的精细打磨标准。