四天15.6亿Token做完一款能跑的3D送报游戏。这组数字是我最近一次用GPT 5.6 Astra做PaperRoute时留下的真实账单。你可能觉得15.6亿这个量级很夸张但拆开看这里面有3D场景代码的反复生成、多模态素材的迭代、还有Astra自带的推理过程消耗其实每一笔都花得有迹可循。PaperRoute的核心玩法很简单玩家骑着一辆自行车在规定时间内把当天的报纸投递到街区每一户门口的邮箱里。听起来像是个小体量的休闲游戏但一旦决定用3D呈现事情就变得复杂了——场景里的房屋、路网、邮箱、树木再到光照、碰撞检测、移动端适配每个环节都在烧Token。这篇文章就把我四天的完整开发过程、Token消耗分布、以及踩过的坑都摊开讲给想用大模型做小游戏的人一个真实参考。1. 项目思路为什么做送报游戏又为什么选3D1.1 创意来源与核心玩法设计送报这个题材其实是从生活场景里挖出来的。前阵子我在楼下看到投递员骑电动车挨家挨户送报纸和快递忽然觉得这种路线规划限时送达的玩法天然适合游戏化。玩家的目标不是战斗而是在压力下做决策先送哪条街、哪户的报纸容易漏、遇到死胡同怎么掉头。这种轻度策略玩法搭配复古的美式街区风格画面感和氛围感都很容易出来。玩法规则我定了三条第一每局限时三分钟超时未送达的订单会扣分第二所有房子必须经过门口邮箱时按住交互键才能投递第三街道路口会有车流玩家需要判断穿越时机。这三条规则足够简单但也足够撑起一个完整的游戏循环。最关键的是这样的玩法对3D场景的要求很明确不需要复杂的物理模拟和战斗AI属于看着唬人、实现不难的类型。1.2 技术选型为什么用Web 3D而不是Unity很多朋友问我为什么不用Unity或者Godot反而选了Three.js做网页版。我的答案很直接因为这次开发的主角是GPT 5.6 Astra我希望整个流程都能在一个浏览器环境里跑通方便随时把中间产物给模型看、让模型直接改代码。Web 3D的好处有三个。其一是零安装任何人拿到链接就能玩不用装客户端这对做作品分享和快速验证非常友好。其二是迭代链路短ASTRA生成HTML、CSS、JavaScript代码后我刷新页面就能看到效果这个反馈周期是以秒计的比传统引擎的编译流程快太多。其三是社区资源丰富Three.js的文档质量高模型生成工具的导出格式GLB/GLTF和Web端配合得非常好几乎没有转换成本。当然Web 3D也有短板最明显的是性能上限不如原生引擎。但对于PaperRoute这种体量的小游戏来说Three.js完全能撑住六十帧运行而且移动端适配也有成熟方案。这个选型在成本和收益之间取得了很好的平衡。1.3 整体架构与模块划分整个项目按模块拆分成五块这样划分有两个目的一是让Astra在生成代码时目标更聚焦二是当我需要修改某个模块时不会把整段上下文都拖进来消耗Token。第一块是场景渲染层负责3D世界的构建、光照、相机控制和渲染循环这一部分主要使用Three.js。第二块是数据结构层管理游戏内所有实体的状态包括报纸订单、房屋坐标、玩家位置和投递进度。第三块是交互控制层处理键盘和触摸输入比如骑行速度控制、视角旋转、投递动作触发。第四块是游戏逻辑层实现计分规则、限时倒计时、任务生成和关卡难度曲线。第五块是UI表现层负责HUD显示、倒计时条、得分动画和游戏结束界面的渲染。每个模块我给Astra设定了明确的输入输出边界比如交互层只需要接收一个方向向量和一个动作指令完全不关心底层渲染怎么实现。这种接口先行的方式让Astra在写代码时不会把边界搞混也让我后续排查问题时能快速定位是哪个模块出了偏差。2. Token消耗实录15.6亿烧在了哪些环节2.1 四天消耗的整体分布拿到账单的时候我第一反应是是不是哪里出了问题但对照开发日志一算发现每个阶段的消耗其实都有合理的去处。我把15.6亿Token大致分成了四份分别对应四个开发日的主任务开发阶段主要任务Token消耗占比第一天需求拆解、场景原型搭建、基础代码生成3.1亿19.9%第二天3D资源生成、街区布局、建筑模型调优4.8亿30.8%第三天交互细节、UI界面、多轮联调修复4.0亿25.6%第四天性能优化、移动端适配、打包发布3.7亿23.7%这里有个很反直觉的点第一天看似只是搭个场景原型消耗却接近3.1亿。原因是初始代码生成时Astra会把整个游戏框架、函数定义和注释一次性输出动辄几千行代码。而三万多字的代码生成光是输出Token就是一大笔消耗。后面几天的消耗更集中在多轮调试上——每次报错Astra不仅仅会给出修复代码还会把上下文重新梳理一遍这个过程会反复消耗输入和输出Token。2.2 为什么消耗量会这么大很多人对15.6亿Token没有概念我换个说法如果把1个Token大约等价于0.75个英文单词那么15.6亿Token大约是11.7亿个英文单词相当于把整套《大英百科全书》来回读了二十多遍。为什么一个小游戏会消耗这么多首先要说的是多模态生成的隐性成本。PaperRoute里的房屋、邮箱、树木等3D素材有一部分是通过图片生成接口产出概念图再由模型转成3D资源。每一次图片生成系统不仅计算生成结果还要把参考图、描述文本、生成参数全部计入Token消耗。我第一天为了定下美式街区的视觉风格反复测试了十几种设计方案每种方案都要生成4到6张概念图单是视觉定调这一环节就消耗了大量Token。其次是Astra的推理过程本身。GPT 5.6 Astra在回答复杂问题时会先内部推演一段思考内容再输出答案这个过程同样计费。我在第三天调交互逻辑时一个为什么报纸投递碰撞检测不生效的问题触发它进行了好几轮自我推理前后消耗的Token超出实际代码修复本身好几倍。这个成本我不能说冤枉毕竟是这些推理让Astra能直接定位到问题症结但对于预算敏感的个人开发者来说确实要做好心理准备。2.3 单次会话的Token峰值记录四天里我记录到的最夸张的一次单会话消耗出现在第二天下午。当时我在让Astra把整个街区的房屋排列方式从手动放置改成程序化生成这个改动牵扯到场景初始化、碰撞体生成、路径寻路三个模块Astra在生成新代码的同时还必须保留对已有代码结构的一致性理解。那次会话我保持了将近四个小时不中断累计消耗接近90万Token。Astra的上下文窗口差点被撑满到后半段它的响应速度明显变慢而且开始出现前面改过的代码记不准的情况。最后我不得不手动新建会话把关键的文件结构、数据结构、改动目标重新粘贴进去才算把这个问题解决。那90万Token里至少有三分之一花在了重新理解上下文上这是一笔完全可以避免的开销后面我也会讲到对应的省Token方案。3. 3D资产与场景实现不用建模软件也能做出能看的3D游戏3.1 模型来源文生3D与程序化生成的组合拳最开始我也考虑过用Blender手搓模型但PaperRoute里涉及房屋、邮箱、报纸、自行车、行道树、路灯这么多物件手工建模的画不划算而且Blender的文件格式和Three.js的实时渲染之间还隔着一层转换。我更倾向于用Astra的多模态能力配合文生3D工具来快速出资产。实际操作里我把TripoAI当作主要模型来源。它的优点是对文本描述的还原度高能直接导出GLB格式而且按次计费的价格相对可控。我给每个物件写的提示词都有固定模板比如生成房屋时是low poly american suburban house, cream walls, blue roof, with front porch, 3D model、生成邮箱是rustic metal mailbox on wooden post, red flag up, stylized low poly 3D model。每批生成四到六个变体然后从中挑出风格最统一的那个。但这批模型只能说轮廓正确细节精度不足以直接进游戏。我的处理办法是让Astra写一个资源后处理脚本通过程序化参数修正模型的比例、材质粗糙度和颜色偏差再用代码把不同模型统一缩放到同一个尺寸体系里。这里有个很实用的技巧在Three.js中直接修改模型的scale和material既省资产生成费用又不会额外消耗构图Token因为走的是本地代码逻辑。3.2 Three.js场景搭建步骤与核心代码场景搭建我拆成了四个步骤初始化渲染器、搭建灯光系统、生成街区网格、放置建筑与道具。下面这段代码是PaperRoute场景初始化的核心部分我直接贴出来供你参考import * as THREE from three; import { GLTFLoader } from three/examples/jsm/loaders/GLTFLoader.js; const scene new THREE.Scene(); scene.background new THREE.Color(0x87CEEB); const camera new THREE.PerspectiveCamera(60, window.innerWidth / window.innerHeight, 0.1, 200); camera.position.set(0, 12, 18); camera.lookAt(0, 0, 0); const renderer new THREE.WebGLRenderer({ antialias: true }); renderer.setSize(window.innerWidth, window.innerHeight); renderer.shadowMap.enabled true; renderer.shadowMap.type THREE.PCFSoftShadowMap; document.body.appendChild(renderer.domElement); // 灯光系统 const sunLight new THREE.DirectionalLight(0xfff5e6, 1.2); sunLight.position.set(10, 20, 5); sunLight.castShadow true; sunLight.shadow.mapSize.width 1024; sunLight.shadow.mapSize.height 1024; scene.add(sunLight); const ambientLight new THREE.AmbientLight(0xffffff, 0.35); scene.add(ambientLight); // 街区网格铺设程序化生成 const blockSize 3.6; const rows 8; const cols 8; const roadGroup new THREE.Group(); for (let i 0; i rows; i) { for (let j 0; j cols; j) { const isRoad (i % 2 0) || (j % 2 0); const tileMaterial isRoad ? new THREE.MeshStandardMaterial({ color: 0x555555 }) : new THREE.MeshStandardMaterial({ color: 0x6d9e4a }); const tile new THREE.Mesh( new THREE.BoxGeometry(blockSize, 0.2, blockSize), tileMaterial ); tile.position.set( (j - cols / 2) * blockSize, 0, (i - rows / 2) * blockSize ); roadGroup.add(tile); } } scene.add(roadGroup);这个街区网格的逻辑不复杂关键是偶数行偶数列铺道路、其他区域种草皮的布尔运算它保证了街区之间有基本的道路骨架。房屋和邮箱的放置逻辑更简单就是遍历所有非道路瓦片在每个瓦片中心随机放置一个房子或一棵树然后通过射线检测确认没有和已有建筑重叠。这些工作全交给Astra写循环逻辑我只负责调整间距参数和随机种子。3.3 3D性能优化移动端也能跑满60帧游戏做完后我在桌面端跑得非常流畅但一放到手机浏览器上就露馅了——帧率掉到二十多帧转动视角时画面卡顿严重。排查后发现三个元凶每个建筑单独的材质导致draw call过多、阴影贴图分辨率过高、还有模型面数在移动端GPU上压力太大。针对这三个问题我做了三个优化。第一是把同材质的建筑合并成一个大几何体能用InstancedMesh的地方全部改成实例化绘制把整个街区的draw call从两千多次降到四百次以内。第二是降低阴影贴图分辨率到512同时把阴影相机的范围裁剪到玩家周围二十米内超出范围的阴影直接关闭。第三是给模型做了LOD分级——远距离的房屋只显示外轮廓盒子中距离显示简化模型近距离才加载完整模型。这里我想特别说一句很多人觉得性能优化是最后才做的事情但如果你一开始就用的是程序化生成和文生3D资产应该在写生成逻辑时就考虑性能预算。Astra生成代码时如果你不主动指定它不会自动给你加性能优化逻辑。我第二次重构街区生成代码时就是在需求描述里明确写了所有建筑材质尽量复用避免每栋楼新建材质对象后续生成的代码性能表现明显好了一个档次。4. 让Astra真正帮手干活提示词与协作方式的复盘4.1 从写代码到给方案的思维转换四天用下来我最大的感受是GPT 5.6 Astra的强项不在于替你机械地输出整段代码而在于它能从大方向上理解一个复杂需求并给出结构化的实现路径。前提是你得把Prompt写得像给一个思路清晰的同事交代任务而不是像给搜索引擎输入关键词。我的核心做法是先方案后代码。在让Astra写任何一个模块之前我会先让它输出该模块的技术方案包括数据流、函数接口、渲染流程、异常处理策略。比如第二天做投递检测时我没有一上来就说写一段投递检测的代码而是给出了问题定义玩家自行车位置为坐标点邮箱也有坐标点需要检测玩家在移动中是否与邮箱有碰撞碰撞后触发投递动作同时播放一个报纸飞出动画。Astra先给出一套方案建议用射线检测加距离阈值的方式实现还提出了几种优化思路。等方案确认后我再要求它按方案生成完整代码。这样做的好处是方案讨论环节占了总Token的20%但能避免它生成大量方向错误的代码从而节省后80%的返工成本。这个投入产出比非常划算。4.2 用多模态能力辅助UI与视觉调试热词里有人问GPT-6 Astra可以画电路原理图吗这个我之前还专门试过。坦白说它的图表生成能力还达不到专业设计软件的水准但在UI草图和视觉参考这个级别上已经够用了。我在做PaperRoute的HUD界面时让Astra生成了一张复古报纸风格的倒计时UI草图它在十分钟内给了三个不同版式我从里面挑了一个最顺眼的然后把这张图直接粘回对话里让它生成对应的HTML/CSS代码。这个流程在传统开发模式下几乎不可能实现因为你至少需要一个设计师或者一套组件库来起底。但在Astra这里从视觉参考到实现代码的链路缩短到了一个会话里。整个过程消耗了不少Token图片生成代码补全但从产出看完全值得——最终的游戏界面风格非常统一和我最初想要的复古报纸感完全一致。4.3 报错调试的黄金工作流第四个实战经验是报错调试的交互方式。很多人在代码报错时直接把红色日志一股脑扔给大模型然后期待它直接给修复代码。我的做法是先让Astra解释错误产生的可能原因再给出修复方案最后才让它输出代码。看起来多了一步实际上大幅减少了修完这个错又冒出那个错的循环因为有些报错只是表层现象底层的逻辑错误没有解决反复打补丁只会消耗更多Token。我第一次做报纸投递检测时Console里持续报Uncaught TypeError: Cannot read properties of undefined我直接把这个错误和代码片段一起贴给Astra它定位到是碰撞检测时引用了尚未初始化的邮箱数组。这个修复只花了五百Token。但如果我不先让它解释原因而是把整段代码重新生成一遍那又是几万Token的消耗。所以我的调试原则是小错直接修大错先出方案再动手绝不重复生成完整代码。5. Token续签与会话保持那些登录报错的真实排查过程5.1 token失效与刷新机制的那些报错开发到第三天下午我遇到了一个所有重度用户都会遇到的麻烦——登录突然失效页面弹出your access token could not be refreshed. please log out and sign in again。我还录到过AUTH003和token exchange failed: token endpoint returned status 403这类报错。如果你没接触过OAuth 2.0的机制看到这些提示可能一头雾水但只要理解token的短令牌长令牌模式就明白了。这里的核心是两种Token的配合工作access token是短期票据通常半小时到一小时过期API在每次请求时校验它refresh token是长期票据存在本地或后端当access token过期时客户端用refresh token去授权服务器换一张新的access token。当你看到token exchange failed说明refresh token去换新令牌时被服务器拒绝了这时候系统为了安全起见只能让你重新登录。我在本地排查了很久发现这次403的原因很可能是服务器判定刷新令牌的使用环境存在变化。解决办法倒是很朴素退掉所有页面、清掉浏览器内的旧缓存和本地存储、重新走一遍登录流程。如果使用多个标签页同时操作一定要全部关掉再重新登录避免多个页面互相覆盖刷新令牌。此外检查设备时间是否准确也很重要因为JWT这类令牌的签发和校验依赖时间戳如果系统时间和服务器时间偏差超过一两分钟令牌请求就会因为时间窗口不合法直接失败。5.2 免费Token额度与用量控制的心得热词里搜免费token的人很多说明这块需求量不小。我对免费额度的态度是用来做技术验证和原型验证非常好但如果你真的想靠它完成一个完整项目预算很容易失控。四天15.6亿Token如果放在付费档位按每百万Token几美元的常见价格换算这已经是一笔客观的开支。所以聪明做法是免费额度做小步实验付费额度做关键冲刺。具体的省Token技巧我可以分享几个实测有效的每个会话只专注一个任务不把多个需求混在一起避免每次提问都要重新载入超长上下文。实测下来一个专注的短会话比一个大杂烩长会话能节省三成左右的Token。需要参考旧代码时不要直接把整个文件贴进对话而是让Astra读取文件结构或者只贴关键函数片段。我用一个脚本把项目代码的关键函数自动抽成摘要需要时只把摘要喂给模型。调整难度和细节的时候尽量用增量描述而非全量重写。比如把房屋间距从3.2改成4.0就比重新描述一遍所有街区参数省很多。开启仅输出修改代码模式。我明确告诉Astra只有在必要时才输出完整文件否则只输出需要修改的代码片段这一步让后续对话的输出Token显著减少。5.3 会话崩溃后的恢复方案即便做了这么多防护我还是在一次大会话中把上下文窗口撑爆了。当时页面直接失去响应刷新后之前的对话记录只剩一半等于之前投进去的十几万Token全打了水漂。后来我学乖了每完成一个里程碑就新建会话并且在这个新会话里创建一个项目状态备忘文档内容包含当前文件结构、已完成功能清单、遗留问题列表和关键代码片段的索引。之后不管我怎么折腾哪怕某个会话中途崩溃我只要把这份备忘粘给新会话的Astra它就能在很短时间内恢复工作记忆。这比单纯依赖Astra的上下文回溯要可靠得多也不容易让Token在重复理解中白烧。这也是我用四天时间做完整个游戏的关键基础设施。6. 常见问题速查与复盘体会6.1 四天开发中的高频问题速查把这几天遇到的高频问题整理成一张表希望对打算做Web 3D小游戏的朋友有帮助问题现象可能原因我的解决方式3D模型加载后黑屏灯光未添加或模型面法线方向错误检查场景内是否有光源用MeshStandardMaterial.side THREE.DoubleSide临时验证手机端帧率暴跌draw call过多、阴影分辨率过高合并几何体、使用InstancedMesh、降低阴影贴图分辨率、启用LOD网页刷新后进度丢失本地存储未写入使用localStorage保存关卡进度和最高分投递检测时灵时不灵碰撞体与可视模型未对齐用Box3.setFromObject为模型生成包围盒再扩大1.1倍作检测范围Astra输出代码重复上下文在同一个会话内持续堆积新任务新建会话并粘贴项目状态备忘让模型只关注当前任务登录token报错刷新令牌异常或时间偏差关闭所有页面、清理站点数据、校对系统时间、重新登录6.2 我对用大模型做游戏这件事的体会四天做完一个3D小游戏如果放在五年前简直是天方夜谭。但这不代表大模型能替你做所有事——它更像一个极其聪明但需要你不断校准方向的高级程序员。你可以把模糊的想法给它它能快速给一个实现路径但这个路径靠不靠谱最终还是需要你自己判断。我在PaperRoute里至少有三次让Astra重构核心逻辑都是因为它生成的代码虽然在语法上完全正确但架构设计不是最优解后续扩展很别扭。Token开销的管理也是一个核心课题。15.6亿Token消耗看着吓人但拆到每一天也就四个多亿如果合理规划、善用短会话和增量提示同样的工作量其实可以压缩到十二亿以内。反过来如果你陷入不断重新生成全量代码的循环二十亿都未必够用。这个差距完全取决于使用者的工作习惯而不是模型本身。6.3 给同样想动手的人三个实用建议首先不要一开始就追求完整方案。第一天只需要跑通一个可以骑行的场景哪怕只有马路和一辆自行车都行先把游戏循环跑起来后面再逐步加料。其次一定要做Token用量日志每次修改都记录大概消耗和产出这样你能在项目中期就发现问题而不是等到账单出来才心痛。最后把Astra当作结对编程的伙伴而不是执行工具多和它讨论设计取舍、多让它解释方案选择的理由这样它生成的代码才是最贴合你需求的——这个过程虽然会多花一点Input Token但会省下大量的Output Token和返工时间。如果你也想用类似的工作流做一个小游戏或者想复刻PaperRoute这样的送报玩法欢迎参考这篇文章里的思路。15.6亿Token换来的不仅是一款能玩的游戏更是一套用大模型构建完整数字产品的方法论。下一次我会试试动作性更强的玩法到时候再来分享新的踩坑记录。