GPT-6 Astra怎么做Three.js游戏？从想法到四驱车网页游戏完整工作流

GPT-6 Astra发布以后，网上已经出现了大量“一句话生成游戏”的演示。

但真正值得普通开发者研究的，并不是最后那几十秒的成品视频。

而是：

这些效果不错的AI游戏，到底是怎么一步一步做出来的？

开发者BubuAi最近公布了一个非常有参考价值的案例。

他把小时候喜欢的《爆走兄弟 Let’s & Go!!》四驱车题材重新做成了一款浏览器3D游戏：

STORM RACE。

整个项目主要采用Three.js开发。

更值得关注的是，作者随后把自己的GPT-6 Astra工作流程完整公开了。

并不是反复几十轮：

“这里改一下。”

“那里再优化一点。”

而是采用了一套非常清晰的方法：

想法 → 概念图 → Astra Build Prompt → 浏览器首版 → 一次修正 → Work/Codex本地精修。

作者甚至表示，第一次通过GPT-6 Astra生成的浏览器版本，视觉效果已经达到最终版本的大约70%。

这套方法对于想用ChatGPT制作：

• Three.js游戏
• 3D网页
• 互动产品Demo
• 可视化项目
• Vibe Coding项目

的人，都很值得参考。

GPT-6 Astra做出的STORM RACE是什么？

STORM RACE是一款以迷你四驱车为主题的浏览器3D赛车游戏。

从目前公开版本可以看到，它并不是简单做一个模型然后让车辆沿赛道移动。

游戏已经加入了多个完整的视觉和游戏系统。

包括：

• 3D迷你四驱车
• 赛车和赛道
• 加速Boost
• 车辆零件展示
• 车库拆解视图
• 晴天赛道
• 雨天效果
• 暴风雨环境

整个项目运行在桌面浏览器中。

从最终观感来看，它已经明显超过过去常见的“几个几何体组成的AI网页小游戏”。

但真正有意思的地方，还不是成品。

而是作者如何让Astra把一个童年想法逐渐变成可以玩的游戏。

第一步不是写代码，而是先把想法说清楚

BubuAi公开的工作流程中，第一步并没有立即进入Codex写代码。

他首先在Chat中使用GPT-6 Astra进行：

Idea Pitch，也就是创意讨论。

这一点很重要。

很多人使用AI做游戏的第一句话就是：

帮我写一个3D赛车游戏。

这样当然也可能生成结果。

但问题是模型并不知道：

• 你想做真实赛车还是街机赛车
• 视觉风格应该是什么
• 游戏重点是速度还是改装
• 镜头应该怎么表现
• 玩家真正应该感受到什么

所以更加有效的流程应该先讨论：

这个游戏到底为什么值得做？

以及：

玩家打开以后第一眼应该感受到什么？

第二步：先生成概念图锁定方向

确定基本想法以后，BubuAi并没有马上要求Astra完成整个项目。

他先使用模型生成概念图。

目的不是为了最终直接把图片放进游戏。

而是确定三个东西：

• 视觉方向
• Gameplay Feel游戏感觉
• 最终画面目标

这一步非常像传统游戏开发中的Concept Art。

例如只是说：

“做一个有童年感的四驱车游戏。”

每个人脑中的画面都可能完全不同。

但如果先生成一张参考图，那么：

用户和AI终于开始看着同一个目标。

这会明显减少后续开发过程中：

“我想要的不是这个感觉。”

这种问题。

为什么AI开发项目最好先有视觉目标？

文字非常擅长描述功能。

例如：

“点击按钮以后打开菜单。”

非常明确。

但文字并不擅长精确描述审美。

例如：

“页面应该有速度感、童年动画感，同时看起来现代一点。”

这里存在大量主观空间。

一张概念图却能同时传递：

• 色彩
• 构图
• 光照
• 材质
• 车辆比例
• 摄像机角度
• UI氛围

所以对于：

• 游戏
• 网站
• 3D项目
• App

来说，一个非常值得尝试的Astra工作方式就是：

先用图片确定目标，再写代码。

第三步：不要直接开发，让Astra先写一份Build Prompt

这是整个案例里最值得学习的一步之一。

BubuAi在确认概念以后，没有继续在原来的聊天里直接让Astra不断生成代码。

而是要求Astra：

根据前面的讨论和概念图，重新整理成一份详细的Build Prompt。

Build Prompt可以理解成：

真正交给Coding Agent执行的项目需求文档。

它应该包含：

• 项目目标
• 技术栈
• 游戏机制
• 视觉方向
• 控制方式
• UI
• 场景
• 性能要求
• 最终交付标准

这样可以把前面大量零散讨论压缩成一份结构更加清晰的任务。

为什么Build Prompt比几十轮聊天更有效？

长对话存在一个问题。

随着内容越来越多，里面会逐渐混入：

• 被放弃的方案
• 旧的需求
• 临时修改
• 互相冲突的规则
• 不再重要的信息

最终模型必须自己判断：

“到底哪个要求才是最新的？”

而Build Prompt相当于在正式开发之前进行一次：

需求清洗。

把真正确定下来的方案重新整理一次。

对于复杂的Agent任务，这往往比不断追加Prompt更加有效。

第四步：新开一个Chat，从零生成第一版

BubuAi接下来的做法也很有意思。

拿到完整Build Prompt以后：

他新开了一个Chat。

然后让GPT-6 Astra从头构建第一版项目。

这相当于让执行模型获得一个更加干净的上下文。

它不会再看到前面各种：

• 脑暴
• 废弃方案
• 讨论过程
• 临时想法

只需要面对最终Build Prompt。

这个思路非常适合复杂项目。

可以把两个对话分成：

对话A：产品经理

负责：

• 讨论想法
• 确定方向
• 生成概念图
• 整理需求

对话B：执行工程师

负责：

• 读取最终需求
• 写代码
• 完成项目

这种分离方式比所有事情一直堆在同一个Chat中更加干净。

第一版真的能达到最终效果70%吗？

根据BubuAi后续回答，第一次使用网页端GPT-6 Astra生成的版本，已经达到：

最终视觉效果大约70%。

这是开发者本人对项目完成度的主观估计，并不是官方Benchmark。

但这个数字仍然值得关注。

因为如果一个AI Agent第一次构建就能完成70%左右，那么开发流程已经发生明显变化。

传统开发是：

从0%开始一点点做到100%。

新的工作流开始变成：

AI先做0% → 70%，人和AI再共同完成最后30%。

最后30%往往恰恰是：

• 游戏手感
• 细节
• 平衡
• UI体验
• 控制优化

这些非常依赖设计判断的内容。

第五步：浏览器阶段最多只修一轮

BubuAi后续给出的另一个经验是：

不要在Chat里面过度迭代。

第一版生成以后，他通常最多再进行一次修正。

例如处理：

• 明显Bug
• 缺失功能
• 完全偏离目标的地方

然后就停止在网页Chat中继续反复修改。

为什么？

因为项目真正进入细节阶段以后：

本地开发环境比纯聊天更加合适。

第六步：把项目拉到本地Work/Codex

完成网页端初版以后，BubuAi把代码拉到本地。

然后继续使用：

• ChatGPT Work
• Codex
• GPT-6 Astra Medium / High

完成最后阶段的精修。

这个阶段重点已经不再是：

“把游戏做出来。”

而是：

“让游戏真正好玩。”

本地阶段主要修改什么？

作者列出的重点包括：

• Gameplay tuning
• UI/UX polish
• Game feel
• Balancing
• Controls
• Small visual tweaks

翻成更直白的话就是：

游戏玩法调优、界面优化、手感、数值平衡、操作和最后的视觉细节。

这也揭示了一个很现实的问题。

AI可以快速完成：

• 页面
• 逻辑
• 3D场景
• 功能

但“好不好玩”仍然需要不断体验。

什么是Game Feel？为什么AI不容易一次做对？

Game Feel很难直接翻译成一个词。

它大概可以理解成：

玩家操作以后，游戏给人的整体反馈和手感。

例如四驱车加速时：

• 镜头要不要震动
• 速度感应该多强
• 车辆加速需要多快
• Boost应该持续多久
• 音效什么时候出现
• 画面模糊应该多强

这些东西没有唯一正确答案。

它们依赖玩家实际体验。

BubuAi也提到，项目最后一段很大程度依赖自己多年玩游戏形成的：

玩家直觉。

这说明即使Astra能力已经很强：

人类经验仍然是最后20%到30%品质的重要来源。

STORM RACE使用Blender了吗？

没有必要把这个项目描述成Astra + Blender案例。

BubuAi后续专门回答了这个问题。

第一版是直接要求GPT-6 Astra使用：

Three.js

来制作。

作者表示，他认为网页端首版并没有使用Blender。

这意味着我们看到的很多3D效果，本质上是直接在Web 3D环境中实现。

这和前面那些：

Astra → Blender → 导出模型 → Web

的路线并不相同。

Three.js是什么？

Three.js是一个非常流行的JavaScript 3D图形库。

它基于WebGL，让开发者可以直接在浏览器中创建：

• 3D场景
• 模型
• 材质
• 灯光
• 摄像机
• 动画
• 粒子
• 交互

过去Three.js有一定学习门槛。

因为开发者不仅要懂JavaScript，还需要理解：

• 3D坐标
• 向量
• 光照
• 材质
• 相机
• 性能优化

而Coding Agent的出现正在降低这种门槛。

开发者可以更多描述：

“我想看到什么效果。”

而不是亲自逐行处理每一个3D API。

为什么Three.js特别适合AI生成游戏？

浏览器游戏有一个天然优势：

生成以后马上就能看。

AI写完代码以后，可以立即：

• 运行
• 打开浏览器
• 检查画面
• 发现Bug
• 继续修改

形成一个非常短的反馈循环。

而最终成果也非常方便分享。

部署到Vercel以后，一个链接就可以让其他人直接试玩。

不需要下载安装包。

这个项目完全没有使用外部资产吗？

BubuAi在后续评论中表示：

项目资产由Astra完成，没有使用外部资产。

这一说法来自创作者本人，目前没有必要把它扩展成“所有素材都经过第三方独立验证”。

但从工作流角度看，它展示了一种很重要的新趋势：

AI Coding项目越来越不只是：

“写代码。”

还开始同时承担：

• 视觉设计
• 资产制作
• 界面
• 玩法
• 最终部署

STORM RACE有哪些游戏内容？

社区目前收录的公开版本显示，STORM RACE包含几个比较有意思的系统。

四驱车竞速

核心仍然是迷你四驱车赛车玩法。

零件拆解车库

游戏提供车辆零件的Exploded View，也就是拆解式展示。

玩家可以从更立体的方式观察四驱车结构。

Boost加速

比赛过程中存在加速机制，增强赛车游戏需要的速度反馈。

天气变化

赛道包含：

• 干燥天气
• 雨天
• 暴风雨

不同天气不仅改变视觉，也让整个项目更接近一款完整小游戏，而不是单纯Three.js技术展示。

为什么“第一版70%”比“一句话生成游戏”更值得关注？

网络上的AI演示特别喜欢使用：

“One Prompt。”

“One Shot。”

“一句话生成。”

这些表达。

但真正开发过产品的人会知道：

第一版出来只是开始。

真正决定一个作品质量的，通常是后面的：

• 测试
• 反馈
• 细节
• 调整
• 取舍

所以STORM RACE真正有参考价值的地方不是：

“Astra有没有一次把100%全部完成。”

而是：

它能不能把第一个可用版本的起点，从10%提高到70%。

这对于开发效率的影响可能更加实际。

为什么作者不推荐在Chat里疯狂迭代？

这个经验尤其值得Vibe Coding用户注意。

很多人在项目开始以后会不断写：

“再优化。”

“再高级一点。”

“这个不好看，再改一下。”

“继续完善。”

几十轮以后，上下文越来越复杂。

模型开始同时面对：

• 旧代码
• 新代码
• 已经废弃的需求
• 最新需求
• 越来越多补丁

项目反而容易越来越乱。

BubuAi的方法则是：

前期确定方向 → 生成干净Build Prompt → 一次构建 → 最多一次大修 → 本地精修。

这比无限循环“再改一下”更接近真正的软件开发流程。

GPT-6 Pro适合做什么阶段？

从BubuAi自己的体验来看，他特别喜欢把更高能力的模型用于：

前期创意和第一版构建。

因为这个阶段需要模型同时处理：

• 模糊需求
• 设计
• 规划
• 视觉
• 完整架构

模型越能够一次理解大目标，第一版质量越高。

如果第一版基础方向就错了，后续修改成本会非常高。

为什么后期反而可以使用Medium或High？

到了本地精修阶段，问题已经更加具体。

例如：

“Boost时间缩短0.5秒。”

“这个菜单在1080p屏幕下太大。”

“雨天车辆控制应该更滑一点。”

这时候任务边界已经清晰。

使用Medium或者High就可以持续进行针对性修改。

因此整个项目并不需要：

从头到尾永远使用最高推理档。

这也是控制模型额度和成本的一种方法。

创作者称整个项目用了多少Astra额度？

BubuAi在后续回复中表示：

第一版通过网页端完成，之后进入Codex使用Medium/High继续精修。

按照他的个人账号观察：

这一阶段大约消耗了5%到8%的相应用量。

需要注意，这只是该创作者在特定账号、特定任务和当时额度规则下的个人记录。

不能直接换算成：

“所有用户做同样游戏只需要5%额度。”

实际消耗会受到：

• 项目大小
• 推理档位
• 对话长度
• 修改次数
• 工具调用

影响。

普通人能不能照这个方法做游戏？

可以参考这套流程。

真正值得复制的不是四驱车题材。

而是开发方法。

你可以把它应用到：

• 赛车游戏
• 塔防
• 射击游戏
• 跑酷
• 3D产品展示
• 互动地图
• 数据可视化

题材可以完全改变。

流程仍然适用。

可以直接参考的GPT-6 Astra游戏开发流程

阶段一：Idea

先和模型讨论：

• 做什么
• 为什么好玩
• 核心玩法
• 目标用户

阶段二：Concept

生成概念图，锁定：

• 画风
• UI
• 摄像机
• 视觉目标

阶段三：Build Prompt

让Astra把讨论重新整理成一份最终项目需求。

阶段四：Fresh Chat

新开对话，只提供最终Build Prompt，让模型从干净上下文开始。

阶段五：Browser Build

先生成能够真正运行的V1。

阶段六：One Iteration

只修复明显缺失和严重问题，避免无限聊天迭代。

阶段七：Local Work / Codex

下载项目到本地，进行：

• 玩法
• UI
• 平衡
• 控制
• 视觉

精修。

可以直接使用的GPT-6 Astra Build Prompt结构

你需要从零开发一个可直接在桌面浏览器运行的Three.js 3D游戏。

项目目标：

制作一款强调速度感和车辆个性的迷你赛车游戏。玩家进入以后应该能够在很短时间内理解操作并开始比赛。

视觉目标：

以我提供的概念图作为视觉参考，包括车辆比例、赛道气氛、摄像机角度、UI层级和整体色彩。不要只完成基础功能，需要尽量接近概念图表现。

核心功能：

• 车辆选择
• 3D赛道
• 完整竞速流程
• Boost
• 速度反馈
• 天气变化
• 赛车相关UI

技术要求：

• 使用Three.js
• 桌面浏览器可直接运行
• 项目结构清晰
• 优先保证流畅度
• 避免没有必要的复杂依赖

工作方式：

不要只生成代码片段。请完成整个可以运行的项目，并自行检查明显错误。完成后确保用户打开页面即可开始体验核心玩法。

为什么这套方法也适合做网站？

其实把“游戏”换成“网站”，方法几乎完全一样。

例如：

想法 → 网站参考图 → 最终需求Prompt → 新Chat开发首页 → 浏览器检查 → 本地Codex精修。

相比直接说：

“给我做个科技感官网。”

先把参考视觉和Build Prompt确定下来，最终结果通常更稳定。

GPT-6 Astra做Three.js游戏有哪些问题？

这个案例效果很好，但并不代表AI网页游戏已经没有限制。

性能仍然是问题

Three.js最终运行在浏览器。

复杂的：

• 模型
• 阴影
• 粒子
• 后期效果

都会增加GPU压力。

AI很容易出现：

“为了好看不断往里面加效果。”

因此性能仍然需要人工检查。

手机适配不能默认存在

社区目前验证的是桌面浏览器。

不能因为桌面版能够运行，就直接认为：

• 手机触控已经做好
• 移动GPU性能足够
• 所有屏幕比例正常

移动端需要单独测试。

游戏好玩和代码正确不是一回事

Astra可以完成所有功能。

但赛车：

• 太快
• 太慢
• Boost过强
• 控制太灵敏

都会影响最终体验。

因此Game Feel仍然需要真实玩家测试。

模仿动漫做AI游戏需要注意版权吗？

如果只是个人学习和技术实验，可以把熟悉的动画或游戏作为灵感来源。

但如果准备：

• 商业发布
• 收费
• 投放广告
• 大量公开传播

就应该特别注意：

• 角色版权
• 商标
• 车辆造型
• 音乐
• 原作名称

最稳妥的方法是：

学习玩法和情绪体验，但重新设计原创世界观、名称、角色和视觉资产。

GPT-6 Astra做游戏常见问题

STORM RACE是谁制作的？

STORM RACE由BubuAi制作，作者表示项目主要使用GPT-6 Astra完成。

STORM RACE使用什么技术？

主要技术栈是Three.js，并以浏览器游戏形式发布。

这个项目使用Blender了吗？

作者表示第一版是在网页端直接要求Astra使用Three.js构建，他认为该阶段没有使用Blender，因此不应该把这个案例描述成典型的Blender项目。

GPT-6 Astra第一版完成度有多高？

按照作者自己的估计，第一次网页端生成结果已经达到最终视觉效果的大约70%。这是个人项目评价，不是标准Benchmark。

第一版以后是怎么继续开发的？

作者把项目拉到本地Work/Codex，然后使用Astra Medium/High继续调整玩法、UI、游戏手感、数值平衡、控制以及视觉细节。

是不是不停和ChatGPT对话就能把游戏越改越好？

作者反而建议不要在网页Chat中过度迭代。他的做法是第一版之后最多进行一次主要修正，再进入本地开发环境完成精修。

Astra生成游戏需要先写超长Prompt吗？

不一定。更有效的方法是先和模型讨论想法和概念图，再让模型根据已经确定的需求自动整理出一份详细Build Prompt。

GPT-6 Astra可以完全不使用外部资产做游戏吗？

BubuAi表示STORM RACE中的项目资产由Astra完成，没有使用外部资产。不过这是创作者对自己项目的说明，并不代表所有Three.js游戏都适合采用同样方式。

Three.js适合AI做游戏吗？

很适合快速原型，因为代码修改后可以立即通过浏览器运行和检查，而且最终项目也很容易部署分享。但大型3D项目仍需考虑性能问题。

总结：真正值得复制的不是游戏，而是这套Astra工作流

看到STORM RACE以后，最容易产生的第一反应可能是：

“GPT-6 Astra现在已经可以直接做出这么漂亮的3D游戏了。”

但真正值得学习的并不是成品本身。

而是BubuAi后来公开的工作方法。

它可以浓缩成七步：

Idea → Concept → Build Prompt → Fresh Chat → First Build → One Iteration → Local Fine-tune。

这里面有几个很重要的经验。

第一：

先确定方向，再开始写代码。

第二：

复杂项目最好先让AI把讨论整理成一份干净的最终Prompt。

第三：

第一版完成以后，不要陷入几十轮聊天式补丁。

第四：

网页端适合从0到70，本地Work/Codex更适合从70到100。

第五：

最后决定游戏质量的仍然不是“有没有功能”，而是玩法、UI和Game Feel。

这也说明GPT-6 Astra正在改变Vibe Coding的重点。

以前大家比的是：

“谁能用一句Prompt写出最多代码？”

现在更有价值的问题正在变成：

“怎样组织AI工作流，才能用最少的迭代得到最高质量的成品？”

STORM RACE提供的答案并不是无限Prompt。

恰恰相反。

它是一套更接近真正产品开发的流程：

先想清楚，再一次性构建，最后针对体验精修。

对于想用GPT-6 Astra开发网页、Three.js、游戏甚至完整产品的人来说，这套方法可能比直接复制任何一条“神级Prompt”更加有价值。