GPT-6 Astra 做完整游戏,39 小时与 15.6 亿 token 账本

开发者 Emm Tee 用 GPT-6 Astra 加 Blender 做出完整可玩的送报游戏 PaperRoute,并公开了逐小时、逐 token 的完整账本:39 小时追踪工时、15.6 亿 token、90 次提交。他把流程拆成八步:先写自己的 brief,只给机制不给美术方向,把游戏引擎和画面表现跑成两条独立工作流,角色概念图在 ChatGPT 做、网格走 Meshy、由 Astra 完成减面绑定,每一次改动都产出审查渲染图。他还给出了未验证的部分:手机端稳定 60fps 尚无定论。

发布于2026年9月14日 12:39
编辑小创
评论0
阅读51
PaperRoute 实机演示,一周送报路线的完整跑动。可以看到信箱投递计分、碎窗效果、追人的狗、过街的玩具车,以及收尾在靶心和跳台上的公园赛道。

开发者 Emm Tee(@builtbysketch)在 2026 年 9 月 12 日发了篇长文,复盘他用 GPT-6 Astra 从零开发完整可玩游戏 PaperRoute 的全过程。这条帖子在 X 上拿到 1093 次点赞。他想回答的其实是一个问题:单次 prompt 确实能写出让人惊艳的 demo,但要把 demo 推进成一个完整的游戏,得走一条完全不同的路。

PaperRoute 是一款致敬 Paperboy 风格的送报游戏。场景设在美国郊区,核心玩法是玩满一周七天的送报路线。游戏里有订阅用户和非订阅用户的区分,有在后面追着咬的恶犬、马路上的车,还有斜角追踪相机。项目代码全由 GPT-6 Astra 编写,3D 模型全是在 Blender 里搞定的。游戏跑在 paperroute.lol,配套开发日志详细记录了每个检查点、渲染图和工时数据。

他把这套方法叫作 runbook。因为他全程精确记录了工时和 token 消耗,所以能给出实际消耗,而不是凭感觉估算。下面是这套开发流程的实际步骤拆解。

原文文章头图
游戏主视觉。用 Blender 渲染模型、GPT-6 Astra 写代码搭出来的 PaperRoute 骑手主角。

先写一份自己已经相信的 brief

游戏的核心概念不是 Astra 凭空想出来的。2026 年 7 月,他写过一份 brief,想用当时的大模型复刻一个现代版的 Paperboy。里面定好了具体的设计指标:周一到周日的送报路线、订户和非订户机制、恶犬、车辆、斜角相机,还打算同时做原生 iOS 和网页版。但当时技术不太行,项目只做了一条灰盒街道和一个骑手就卡住了,在 7 月直接搁浅。他说,那时候大模型的极限也就是勉强生成一辆结构畸形的自行车。

7 月用 Fable 试做的产物:一条灰盒街道和一个骑手,HUD 只有 SCORE 0 与 PAPERS 10。
7 月用 Fable 试出来的早期原型。只有灰盒街道和最基础的骑手,HUD 也只显示 SCORE 0 和 PAPERS 10。

GPT-6 Astra 发布并放出 demo 之后,他觉得这个模型能带得动这个项目了。于是他重新写了 brief,用大白话描述原版游戏的核心机制,并定好了交付标准。

这个阶段他主要做两件事:基础游戏机制,以及参考原版 Paperboy 的透视视角。他不是为了单纯复刻,而是想把经典概念做个现代化重构。在初始化模型上下文时,他直接把最经典的原版机制喂给模型。对自行车投递游戏来说,原版设计就是最好用的冷启动样本。

第一次一次性提示词跑出的浏览器预览:Cedar Hollow 社区,周一早上 6:15,投递进度 0/10。
用一条提示词跑出来的第一个浏览器预览版本。画面显示 Cedar Hollow 社区,时间是周一早上 6:15,投递进度 0/10。

他的开发流程有一条铁律:先跑通核心机制,好玩了再去迭代美术。这让他少走了很多弯路。

把美术方向和游戏方向拆成两条任务

他把后面的工作拆成了两条线,给 Astra 发了两个独立的任务:一个是视觉美术,一个是游戏工程。这两个任务放在同一条会话里同步往前推。

第一版一次性生成的原型已经能跑起来了。他保留了 Astra 设计的等距视角和基础玩法,把修改重心放在游戏机制、相机轨迹和操作手感上。初版 demo 看起来很像那些在社交媒体上刷屏的半成品:一次性生成,看着挺好看,概念也有趣,但 UI 界面千篇一律。

把等距视角换成街面第三人称视角后,界面显示时速 27 公里、0/10 已送达。
把等距视角换成街面第三人称视角后的测试画面。UI 显示时速 27 公里,投递进度 0/10。

在验证核心玩法的阶段,必须死盯着概念和机制。太早去抠复杂的美术资产,只会分散模型的注意力,没法好好打磨核心玩法。

这个拆分策略第一晚就见效了。Astra 在半夜前通过 6 次提交交出了浏览器版本,搞定了物理模拟、带虚线轨迹的抛物线投掷、信箱碰撞计分,还做完了最后收尾在公园滑板场的整条路线。更省心的是,模型写代码的同时把测试用例也补全了。这样后面频繁换美术资产时,就有了一套稳妥的自动化测试垫底。

同一条街道的另一次预览,远处出现第一辆来车,路线两侧的房屋开始有区分度。
街道场景迭代预览。远处开来第一辆车,路两边的房子网格开始有了区别。

定下美术风格,两条线并行推进

调好基础视角和操作手感后,项目开始同时优化美术风格和物理机制,重点调校扔报纸的手感。

美术资产的生成走了一条不一样的路。在游戏编译的时候,他跳出 Astra,用 ChatGPT 来做美术概念设计。他喂给 ChatGPT 参考图,生成概念图和情绪板。他特别说明过,美术风格并不是网上瞎传的“吉卜力”风,他写的提示词是“一部凉爽的日本夏日微风吹拂的电影感作品,带手绘笔触质感”。ChatGPT 按照这个描述生成了风格情绪板,作为后面 3D 资产调校的视觉标准。

风格情绪板:PAPERROUTE / A SUMMER ROUTE,六个分镜标注 shape、silhouette、colour、light、atmosphere。
视觉风格情绪板。项目叫 PAPERROUTE / A SUMMER ROUTE,有六格分镜,分别标着 shape、silhouette、colour、light、atmosphere 等要素。
情绪板落进游戏后的样子,房屋、电线杆和云层都在往参考方向靠。
情绪板风格融进游戏后的实机效果。房子、电线杆和天上的云都在往参考图靠拢。

在这个阶段,他刻意不给模型一次性塞太多视觉细节描述。

在管理工作流时,他说自己虽然习惯把任务开分支,但这次配合调校好的 T3 code form 工作流,他选择待在同一条会话里一直迭代。测试发现,Astra 应对上下文打断和恢复的能力比 Fable 强得多,打断之后还能接得上。

两条线通过一条条提示词往前迭代。Blender 在后台用无头模式跑,一直输出高精度渲染图和测试结果。这期间,游戏 demo 一直挂在公网测试地址上,随时能点开玩。

游戏引擎这条线全是无聊的重复劳动,但他觉得这才是必须硬啃下来的路。具体任务包括:松开按键得立刻停下转向响应,加个碰撞无敌帧省得撞上垃圾桶时连续扣血,写恶犬的追逐算法和用报纸引诱它的机制,适配手机端的拖拽转向、按住蹬车和轻触投掷。每个细节都按照“写提示词、浏览器里看效果、提交代码”的流程反复跑。

用 Python 脚本跑 Blender

美术资产这边全靠 Blender。Astra 不需要打开 Blender 的图形界面,而是直接写 Python 脚本,用无头模式跑 Blender。这个过程没接 MCP。

场景里的房子、树木、栅栏和信箱都是用独立的脚本生成的,脚本负责建网格、拆材质通道并做 GLB 格式导出。第一波产出是独立的美术概念稿,包括房子剪影、植物形状和街道小道具,单独渲染出来看效果,先不直接塞进游戏。接着再做模块化的房子组件、高密度的院子场景和手绘质感的贴图。到第二天上午十点,他已经搞定了七组房子模块。

把两条线拆开是他极力推荐的工程经验。要是 3D 模型结构出了问题,你还在同一条会话里争论扔报纸的物理机制,大模型的上下文很容易就乱套了。

角色建模卡住时用 Meshy

他提到 Astra 的建模能力是有天花板的。虽然做房子这种规则的几何体很顺手,但要想做出高精度的美术效果,免不了要用提示词反复调校。

Meshy 生成的骑手模型,车筐里塞着法棍,这是第一版可用的角色资产。
Meshy 生成的骑手模型。车筐里塞着法棍,这是第一版能用的角色资产。
Blender 脚本产出的房屋家族,三个变体并排检查体块比例。
Blender 脚本生成的房子组件。三个变体并排放在一起看比例合不合适。

骑手主角一开始看起来像个木头人偶。试了几次发现 Astra 确实搞不定复杂的人形建模,尤其是脸部细节。这时候比较靠谱的工程方案是:要么找开源的 Blender 资产,要么针对特定角色去接 Meshy 的工作流。

具体的角色生成流程是:先在 ChatGPT 里画出角色原画,然后导进 Meshy。他花了 8 美元买了大概 300 次生成额度。Meshy 拿着原画直接吐出 3D 模型文件,再让 Astra 去做多边形减面,最后做出能用的定制 3D 资产。

他对比了两种办法。光靠 Astra 去迭代人形,烧掉大量 token 却毫无进展,拓扑结构也根本没法用。换成 Meshy 工作流之后,这个瓶颈很快就解决了。把生成的模型跟自行车骨架对齐、装配花了好几轮调试,出来的效果基本能达到上线标准。这部分其实还有优化空间,得继续花提示词去磨。

把 Meshy 模型适配到已有自行车上,正面、侧面、背面三个角度做适配检查。
把 Meshy 模型装到已有的自行车上,从正、侧、背三个角度检查有没有穿模。

原文在这里提到,把骨骼绑定做规范,后面做动画时就不会处处受限。

补细节,并搭起审查循环

他的工程直觉很准:一次性生成的游戏根本谈不上细节和设计深度。概念新颖固然好,但定制动画和精致的 UI 才是拉开差距的关键。

他承认现在的 AI 工具生产力高得吓人,但也强调在现阶段,品味仍然是护城河,还得有足够的工程耐心。在这个项目里,超过 80% 的对话时间和 agent 调用轮次都花在抠细节上,比如修补破损网格、写提示词反复调校,而不是搭基础的游戏框架。

这些精细的调整让 PaperRoute 的质感提升了一大截。Astra 写了 Blender 脚本,在严格控制多边形面数的前提下,保住了角色的脸部特征、一缕缕头发和帽檐结构。他重新做了手臂和袖子的网格来解决穿模,把短裤边缘和腿部分开,再把角色模型严丝合缝地装到自行车上,对齐手握把和脚踏板的位置。最后绑好的骨骼一共有 23 根,其中 3 根给头发, 3 根给衬衫下摆,骑快了能有物理飘动效果。

他大约有 30 次提交,读起来像一本裁缝笔记。典型的提交记录有:修复骑手衣服几何体、重构骑手手臂和袖子、保留短裤裤腿、把自行车把换成更直立的 BMX 规格。

黏土材质的骑手环绕视图,绑定完成后用来确认轮廓和站姿。
骑手模型的黏土材质环绕图。绑定完之后用来确认轮廓和站姿。
DEVELOPMENT RENDERS 四格渲染:源模型、保留源外观的绑定、单独的车、单独的人。
开发阶段四格渲染图。展示原始模型、保留外观特征的骨骼绑定、单独的车和单独的人。

这套迭代流程随后用在了新角色上,比如拿报纸的愤怒老头、拿玩具手柄的男孩。标准管线很清晰:ChatGPT 出概念图、Meshy 吐网格、Astra 写 Blender 导入和绑定脚本、渲染审查、最后合进游戏。管线跑通之后,后面再加角色的成本就低多了。

用渲染图做自动化审查

这是他在开发中期意识到的关键点。他搞了一个常驻的自动化审查机制:让 agent 去评估模型缺陷,生成局部渲染图,再交给他人工审查。在版本迭代里,大概有 60% 到 70% 的模型优化都是 agent 在这个审查流程里自己搞定的。

3D 资产的质量全看渲染图。Astra 写了自动截图脚本,让 Three.js 里的骑手模型做转向、扔报纸、冲刺和摔倒这些动作,自动保存正、侧、背三个视角以及黏土材质环绕图。开发日志里的每个节点都有这些渲染数据。要是发现问题,比如“帽子没盖住头发网格”,这个反馈就直接当成下一轮迭代的提示词。

同一次渲染的材质分区检查,右边一格专门看背面纸袋和帽子的贴图。
渲染过程中的材质通道和 ID 检查。右边一栏专门用来看角色背面纸袋和帽子的贴图贴得好不好。

加点细节和有趣的玩法机制

前面说的这些都是流程。标准化流程能帮你交出一个能跑的原型,但决定游戏好不好玩的,是你的审美和设计。他说,你没法靠一次性生成走到一个完整的游戏,那样只会得到潦草产物。

审美上的取舍也很关键。到项目后期,他扔掉了几乎所有第一版模型,全换成了深度定制的角色。老头和拿遥控器的男孩这两个角色最明显。后面的优化方向会是加更多角色、把动画做丰富,以及让街道场景有更多动态交互和细节。

新角色从概念图走到游戏里:拿着报纸的不满老人,站在自己家门口。
新角色从概念图到实机的落地效果。拿着报纸的愤怒老头站在自己家门口。

玩法机制够不够丰富也是拉开差距的关键。碎窗效果和雨天环境是在独立的分支上开发的。这两个功能由两个独立的子 agent 线程去跑,各自有独立的工作树和沙盒版本,测试没问题了才合并到主干。骑手摔倒时的物理动画,他也反复调校过。

碎窗效果预览,400 分、时速 27 公里,可切换左右窗、重放和开关相机。
碎窗效果调试界面。UI 显示 400 分、时速 27 公里,可以切换左右视窗、重放动画和开关相机。
单独调校的摔倒动作,摔倒在地的骑手和翻倒的橙色自行车。
摔倒动画物理效果调试。画面里是摔倒在地的骑手和侧翻的橙色自行车。

碎窗效果在不确定能不能做成时,他先在隔离分支上单点开发。配一个独立相机,在砸中窗户的瞬间给个特写镜头,然后再平滑切回骑手视角。基础功能跑通后,他把终点区域的滑板公园拉长,改成了一个像训练场一样的关卡,收尾体验好多了。接着,他在场景里加了更大体量的豪宅,让空间更有层次感。最核心的升级是天气系统:从地上的水坑、轮胎溅起的水花这些粒子效果做起,最后做出了完整的雨天环境。

这些细节丰富了游戏的交互花样。如果只做一条平直的路和单调的得分逻辑,游戏会很无聊。加上天气、物理碰撞这些元素,游戏表现力就完全不一样了,这最考验开发者的审美。

外部网页的设计也是这个思路。其实卡上线进度的不是游戏本身,而是怎么做出一个有包装感、逼真的网站环境。网页落地页、结算界面和排行榜,他全做成了报纸版面的视觉风格。

算算账:39 小时、15.6 亿 token、90 次提交

这些数据是由 DevClocked 记录的,统计时间从 7 月 1 日第一次提交 brief 开始,一直到 9 月 12 日(游戏上线后的第四天)。

指标数值
追踪覆盖工时39 小时(25.2 小时人类在场 + 13.8 小时纯 agent)
agent 运行时长30 小时 15 分(多个 agent 并行累加)
总 token15.6 亿(输入 2620 万、输出 600 万、缓存读取 15.3 亿)
API 计价金额2175.36 美元(按使用量算的账单,不是实际额外支出)
提交数90 次,分布在 11 个活跃日
代码净变化4458 个文件,769,390 行(+787,592 / −18,202)

这里的数据口径得说明一下。工时追踪工具是在 9 月 6 日才启用的。在这之前,被追踪的时间默认算作人类在场。工具启用后,统计发现有三分之二的时间其实根本不需要人盯着。也就是说,在记录的 25.2 小时人类在场时间里,有大约 14 小时是默认算进去的。在实际精确测量的窗口期内,人类实际在线时间只有 5.1 小时,而纯 agent 跑了 10.4 小时。

DevClocked 总览:25.2 小时有人在场、13.8 小时纯智能体、90 次提交、769,390 行净变化、2175.36 美元 API 计价。
DevClocked 统计面板。记录了 25.2 小时人类在场、13.8 小时纯 agent 运行、90 次提交、769,390 行代码净变化,以及 2175.36 美元的 API 账单。

开发时间线里有一段很长的空白:7 月提交了 8 次之后,项目搁置了两个月。9 月启动浏览器端重构,开发了四天,第五天正式上线,就是现在大家玩到的版本。他说,7 月的尝试并没有白费,当时定下的 brief 和模拟架构都沿用下来了。如果一开始就直接从网页端做起,第一天就能交出一个能玩的原型。

Agent Performance 面板:实测智能体运行 30.3 小时、55 条流、3037 个轮次,gpt-6-astra 占 76% 的 token 量。
Agent Performance 数据面板。记录了 agent 实际运行 30.3 小时、55 条流、3037 个轮次,其中 gpt-6-astra 占了 76% 的 token 消耗。

还没解决的问题

他也大方公开了还没解决的技术细节。比如手机端能不能稳 60 帧还没完全验证:在测试里帧率是够的,但另一次测试里平均帧率掉到了 58 帧。因为他坚持要保留脸部细节,Meshy 生成的骑手模型有 88,550 个三角面,这个高模资产还没在真实的手机上跑过性能测试。

他提到一个潜在的隐忧:在这种用代码写 3D 模型的开发流里,纯靠参数生成的几何体在处理生物、有机物形变时是有物理上限的,高精度的面部表情和头发物理模拟,目前还是没法跟传统的手工雕刻比。

你可以直接照着跑的开发清单

原文最后总结了一套精炼的工程指南,大家可以直接照着做:

  1. 自己写一份设计 brief,挑一张最接近目标的参考图,哪怕是有版权的图也行。
  2. 把 brief 和基础示意图喂给模型,在核心机制跑通前,千万别提美术风格的要求。
  3. 把游戏引擎逻辑和美术表现拆开,当成两条独立的会话去推。
  4. 用 Python 脚本在 Blender 里生成场景道具,保证所有资产都能用代码复现。
  5. 如果角色有复杂的脸,先用 ChatGPT 画出概念原画,通过 Meshy 导出基础网格,再让 Astra 去减面、绑骨骼和装配。
  6. 搭一个用渲染图做自动审查的循环。留出专门的时间去开发天气系统、碎窗特效和滑板公园这些细节,这才是游戏好玩的关键。
  7. 精确记录工时和 token 消耗,方便以后评估。
  8. 买好域名,部署上线。

这种玩法现在不是孤例。OpenAI 在 2026 年 9 月 3 日发过一个案例,游戏工具团队 Playco 也在用 GPT-6 Astra,直接用灰盒原型一次性跑出了三个不同主题的游戏原型,人工修 bug 的工作量比上一代模型少了一半。这两个案例说明了同一个趋势:大模型在游戏开发上的生产力提升已经是事实了。但要把一个项目从“能跑的 demo”推进到“完整的游戏”,关键还是看你的流程纪律、有没有把工作流拆干净,以及你自己的审美和工程耐心。

引用来源

  1. Emm Tee. How to build a full game with Blender and GPT-6 Astra(X 长文,2026-09-12):https://x.com/builtbysketch/status/2098773631249854478
  2. Emm Tee. PaperRoute Devlog(开发日志,2026-09):https://www.paperroute.lol/devlog
  3. PaperRoute 游戏本体(2026-09):https://paperroute.lol
  4. Emm Tee. OK GPT-6 Astra is insane at making games. I remade Paperboy(X 帖子,2026-09-06):https://x.com/builtbysketch/status/2096515959469072630
  5. OpenAI. Playco cut manual fixes 50% prototyping games with GPT-6 Astra(客户案例,2026-09-03):https://openai.com/index/playco-game-prototyping-with-astra/
  6. PaperRoute 源码仓库(sketchymedia/Paperroute):https://github.com/sketchymedia/Paperroute
  7. Meshy(图像转 3D 模型服务):https://www.meshy.ai/
  8. DevClocked(工时与 token 追踪工具):https://devclocked.com/

相关文章

ChatGPT Work 实测:27 分钟跑通闭环路网到一键部署网站
智能体工程
2026年9月15日
0 条评论
小创

ChatGPT Work 实测:27 分钟跑通闭环路网到一键部署网站

ChatGPT Work 标志着大模型向全托管自主智能体跃迁。其通过云端沙箱、无头浏览器、持久化存储及一键部署四大基础设施,实现从信息检索到网站上线的闭环自动化。系统提供 Cloud 与 Local 双形态及多档推理级别,适配不同任务需求。尽管具备强大自主执行能力,用户仍需警惕上下文压缩、CSP 限制及提示注入等风险。目前该工具仍面临云端与本地环境状态同步未打通的挑战,但已重塑软件工程协作模式。

#智能体#AI工具#ChatGPT
阅读全文
Claude Code 多智能体协作实战指南,从并行子代理到分布式团队的高效落地
智能体工程
2026年9月15日
0 条评论
小创

Claude Code 多智能体协作实战指南,从并行子代理到分布式团队的高效落地

Claude Code 多智能体协作提供 subagents 与 Agent Teams 两种架构。subagents 采用星型拓扑,适合独立任务委派;Agent Teams 为点对点网状结构,支持双向通信与状态共享,适用于复杂并行工作流。实战中需根据任务依赖度选型,并通过 Git worktrees 隔离并发写入冲突。同时应合理配置模型路由以控制成本,规避描述重叠与死锁风险。若缺乏三条以上独立并行流,建议优先使用单会话或 subagents 以提升效率。

#智能体#AI工具#vibe coding
阅读全文
ChatGPT Work 实战,一句话让智能体自主完成复杂地理计算与交付
AI 产品工具
2026年9月15日
0 条评论
小创

ChatGPT Work 实战,一句话让智能体自主完成复杂地理计算与交付

ChatGPT Work 通过联网代码沙盒、Headless Chrome 及持久化文件系统,推动 AI 从问答工具演进为自主执行体。实测显示,智能体可凭单条指令自主调用 API 完成复杂地理计算并交付可视化地图与数据文件。该平台还支持一键建站、子智能体协作及定时任务,适用于实体交付场景。但当前仍存在代码透明度不足、上下文压缩致历史丢失及资源安全策略限制等问题,在生产环境的可复现性仍面临挑战。

#AI工具#智能体#ChatGPT
阅读全文
互动讨论

评论区

围绕《GPT-6 Astra 做完整游戏,39 小时与 15.6 亿 token 账本》展开交流,未登录用户可浏览评论,登录后可参与讨论。

评论数
0
登录后参与评论
支持发表观点与回复一级评论,互动后将同步到消息中心。
登录后评论
暂无评论,欢迎成为第一个参与讨论的人。