从第一眼看到“四天消耗 15.6 亿 Token”这个数字我的兴趣就被勾起来了。这年头用大模型写代码的人不少但敢用四天时间憋一个 3D 游戏、烧掉天文数字级上下文额度的项目仍然属于极端玩家的操作。PaperRoute 这个名字听起来不大背后却是一个典型到不能再典型的案例开发者把 GPT 5.6 Astra 当成全职队友把一个送报纸的 3D 小游戏从零做到可玩、可发布整个过程几乎全部靠自然语言驱动写代码来完成。本文就把这个项目的玩法和套路拆开。不管你是用大模型辅助写业务代码的普通开发者还是想试试 AI 全流程做一个小游戏、一个小产品的玩家这篇复盘里都有你能直接拿去用的东西怎么设计提示词让 AI 输出稳定、哪个环节最烧 Token、3D 场景里 AI 写代码最容易在哪些地方翻车以及一笔算得清清楚楚的成本账。1. 为什么是送报游戏从核心循环到技术验证很多人在用大模型做游戏时会犯同一个错误一上来就追求宏大设定什么开放世界、无缝大地图、随机生成任务链结果 AI 生成的代码模块之间互相矛盾三天后连个能跑的角色都调不动。PaperRoute 最聪明的选择在于它把项目收敛到了一个极简的核心循环骑车到报站拿报纸沿路标导航把报纸投递到指定房屋得分加分。这个循环覆盖了 3D 游戏最经典的三类技术问题移动控制、碰撞检测、任务状态管理但没有强行引入战斗、AI 敌人、复杂背包这类容易让代码失控的附加系统。我自己的判断是这种“有限但完整”的玩法设计非常契合大模型辅助开发的特性。大模型最擅长的是把已知模式组织起来而不是发明一个全新的游戏品类。类似于骑行送报的玩法在各类独立游戏里早已有成熟的实现参考训练语料里相关代码极其充足AI 生成时翻车的概率自然低。反过来如果你让 GPT 5.6 Astra 帮你从零设计一套非线性叙事的送信游戏并生成全部逻辑它大概率会给你拼出一堆逻辑漏洞因为你想要的东西本身就没有“正确模式”可循。另一个关键决策是技术栈。项目使用了网页 3D 渲染方案而不是 Unity 或 Unreal。这个选择的理由很实在Web 3D 相关的示例代码、框架文档、论坛回复在公开语料里数量巨大大模型对 Three.js 场景图、摄像机控制、GLTF 模型加载这些 API 的记忆比冷门游戏引擎的编辑器脚本要准确得多。此外Web 方案天然免安装浏览器一开就能玩整个开发调试周期也短——改完代码刷新页面就能看效果不需要经过引擎编译、打包这一整套流程。对于一个四天的极速开发项目来说缩短反馈循环就是保命。1.1 送报玩法本身就是一个技术验证器有人会觉得送报太简单配不上 3D 的形式。但实际操作里你会发现送报这个动作天然带着一套很完整的 3D 交互链条。玩家要控制角色或自行车在城市道路网格中移动路过房屋时系统要判断玩家与目标房屋的距离是否进入投递范围投递后要给出视觉反馈、更新任务目标、播放音效或者加分动画。这个过程涉及持续输入检测、帧循环更新、空间向量的距离计算、UI 状态同步几乎是游戏开发的微缩样本。这个项目把送报对象设计成路线明确的房屋意味着可以省掉大量寻路饿和地图生成的复杂度专注于把“移动 交互判定”这两个核心动作打磨到顺滑。这种取舍我很认同小体量项目的成功标准不是它多复杂而是玩家在体验核心循环时不会觉得卡壳和困惑。1.2 为什么说 3D 场景反而降低了 AI 的犯错率有一种直觉是 2D 游戏更简单AI 写起来应该更稳。但在实际测试中我发现一个反直觉的现象对于像素级 2D 游戏AI 给出的代码经常要依赖具体的图片资源和帧动画资源它没法凭空生成素材于是代码结构里充斥着缺资源时的报错和占位。而 3D 游戏则不同很多基础视觉内容可以用几何体构建——房子是盒子加屋顶、树是圆柱加球体、地面是平面网格加纹理——AI 能用纯代码生成这些基本形状没有任何外部资源依赖。PaperRoute 能在四天里完成可玩版本很大程度上正是因为整个场景可以直接由代码程序化生成而不是依赖美术管线。所以如果你想复刻这条路线我建议优先考虑这类“代码即素材”的 3D 小游戏。它把 AI 写代码的能力和游戏资源生产的需求做了巧妙对接省掉了最消耗沟通成本的素材制作环节。2. 15.6 亿 Token 到底烧在了哪消耗结构拆解与成本账看到 15.6 亿这个数字很多人下意识会觉得“这得花多少钱”。但 Token 消耗和金钱成本并不能直接划等号得区分输入、输出、缓存这三类计费口径。GPT 5.6 Astra 这类模型输入 Token 和输出 Token 价格相差悬殊实际项目里的消耗结构通常呈现明显的偏斜。结合四天周期的开发节奏我倾向于认为 PaperRoute 的 Token 分布大概是这样的规划与需求拆解占比不到 5%主要发生在第一天上午代码生成与文件输出大概占 35%错误调试和修正占掉 40% 以上场景设计、命名、纹理描述、光照参数这类辅助生成内容占剩余 20% 左右。调试环节吃掉最多 Token这符合所有 AI 编程项目的普遍规律——第一遍生成的代码往往能跑但各种边界情况、模型加载路径错误、坐标轴方向反了、事件监听重复绑定这类问题会让 AI 反复阅读报错信息、反复输出修正后的完整文件。每一次修正都要携带大量上下文Token 就被撑起来了。2.1 四天里 Token 消耗的四大来源第一是长会话的上下文累积。开发者在一个会话里不断追加新需求每一次用户输入都会带上完整的游戏状态描述。到开发后期AI 需要回顾最开始定义的地图尺寸、房子分布、投递判定半径这些信息的重复出现在会话里被反复计费。第二是代码文件的全量输出。一个 3D 游戏哪怕是极简版核心代码总量也可能达到两三千行。AI 往往无法像人类开发者那样做精准的增量修改每次改动都倾向于重写完整文件。一个 500 行的场景生成模块改 6 次直接就是 3000 行输出量乘以输出 Token 的计价消耗非常可观。第三是调试时的多轮“报错——修复”循环。这是最令人崩溃的部分。浏览器报错信息和堆栈每次都要完整贴给 AIAI 再结合代码上下文给出修改建议一步错就可能进入“改了 A 又坏了 B”的循环。第四是生成素材描述和自动生成模型。为了让场景更像一个街区开发者可能会让 AI 生成程序化房子的参数组合、路灯的位置列表、邮箱的摆放逻辑这些听起来不大块但累积起来数量惊人。2.2 成本账按主流定价算出一个参考区间假设 PaperRoute 的 15.6 亿 Token 中输入 Token 占多数比如输入输出比约为 5:1那么大约是 13 亿输入2.6 亿输出。按照当前主流大模型的定价如果输入每百万 Token 约 1.5 美元、输出每百万 Token 约 12 美元计算输入费用1300 × 1.5 1950 美元输出费用260 × 12 3120 美元合计约 5070 美元当然如果项目大量使用了缓存命中或打折档实际成本可能显著低于这个值如果全程用最高档模型且不开缓存这个数只会更高。四天烧掉几千美元的开发成本对于一个独立小体量游戏不能说便宜但对比一家外包公司做一个同等质量 Web 3D 游戏通常数万元的报价它仍然有竞争力。更重要的是这四天里开发者获得的不仅仅是游戏成品还有对 AI 辅助开发真实效率的深刻认知。2.3 Token 计费口径之外还有一个容易混淆的“Token”做 Web 端项目的人看到 Token 这两个字很容易联想到 JWT、OAuth 的 token 交换失败或者登录时“token endpoint returned status 403”这类报错。这个项目的 15.6 亿 Token 完全不是认证令牌是大模型的语义单元计量单位。简单区分认证 Token 是一次性会话凭证和你的登录状态相关大模型 Token 是输入输出文本的切分粒度直接决定 API 账单金额。如果你是一个同时写前端和 AI 集成的开发者这两个概念千万别搞混否则排查问题时方向就错了。3. 四天开发主流程PaperRoute 从零到可玩的完整链路接下来是重头戏这四天具体是怎么过的。我根据公开信息和大量 AI 编程项目的实践复盘重构出一条最合理的开发路径每个阶段都有可以直接借鉴的操作方法和提示词思路。3.1 第一天把玩法需求压成 AI 可执行的规格绝大多数人与大模型协作失败的根源是他们把 AI 当成一个全知全能的执行者直接扔一句“做一个送报纸的 3D 游戏”然后期待对方拿出成品。AI 不是这么运作的。它更像一个新入职的工程师你给的规格越清晰、模块边界越明确它交付的东西越可靠。PaperRoute 的开发者在第一天做的事本质上是写一份“压缩版游戏设计文档”。文档里不描写卖点和情怀只写清楚玩家角色是什么、移动方式是什么、地图多大、有多少栋房子、房子之间的间隔、投递成功和失败的判定标准、得分规则、游戏总时长、UI 布局。这些信息不需要很长但必须精确。我尤其建议把地图参数写成硬性数字比如地图为 200 米 × 200 米的方形街区道路宽度 5 米25 栋房子每栋房子之间的间距不低于 8 米投递目标高亮显示投递成功半径为 0.8 米。拿到这样一段规格后AI 生成的地图生成代码会有一个非常清晰的规则约束。那些看起来零散的数字正是 AI 写程序逻辑时最需要锚定的参照系。3.2 第二天核心机制编码——骑行、投递与判定第二天的核心任务是让玩家角色动起来并且能完成一次完整的“进入范围——投递——提升分数”闭环。这个阶段需要 AI 生成三类代码输入控制系统、角色移动与碰撞、投递判定逻辑。输入控制系统的难点在于“手感”。直接让角色以恒定速度移动玩家会觉得很生硬。PaperRoute 的处理方式是加入加速度和阻尼系数按下方向键时角色速度逐渐增加松开后慢慢减速模拟自行车惯性。AI 生成这类代码时一般能给出基础框架但参数值通常不合理——加速度太大角色像起飞太小像踩泥。这里就得靠人工感受去微调。投递判定则是一个典型的空间近邻问题。游戏每帧计算玩家位置与当前目标信箱的位置距离一旦距离小于预设的投递半径就触发投递成功事件然后更新下一个目标。页面会把视觉高亮的房屋切换掉同时弹一个“已投递”的浮动文字。核心逻辑的代码结构并不复杂但 AI 在这里顺带做出的一个重要设计是“把当前目标状态独立成一个模块”。这意味着目标切换时地图上其他房屋的高亮状态也能同步清除不会出现两个信箱同时高亮这种状态错乱。3.3 第三天场景生成与 AI 建模的高效路径3D 场景是整个项目里最容易被低估工作量的部分。PaperRoute 没有人工建模而是把建筑、道路、绿化带全部交给程序化生成。AI 写一个函数根据预设的地图参数自动在一片区域里布局出属性各不相同的房子有的高、有的矮、有的墙面颜色偏暖、有的带烟囱。这些房子由基础几何体组合而成代码量不大但生成后的视觉效果相当可观尤其是在添加了简单的漫反射光照和投影后。需要特别强调一个技术细节程序化生成 3D 模型时几何体的轴心点位置至关重要。AI 生成的代码经常把每个房子模型的轴心设置在底部中心或者误设为几何体中心。如果轴心位置不统一房子摆放时就会出现一半陷入地下、一半悬空的诡异效果。PaperRoute 大概也踩了这个坑因为我在类似项目中见过太多次这种问题了。解决办法其实很简单构建完每个房子的 Group 后手动计算其包围盒底部把 Group 位置向上平移半个自身高度确保房子“坐”在地面上。场景生成阶段用掉大量 Token 还有一个隐藏原因开发者会让 AI 反复尝试不同的随机种子和参数组合期望得到更漂亮的街景布局。每次调整其实就是一次完整的代码输出和运行验证费用自然高。这里我建议一次只改一类参数不然 AI 给出的“优化结果”往往是东一榔头西一锤最后你都不知道到底是哪个改动让街景变得更好看。3.4 第四天回归测试、手感调优与发布配置最后一天几乎不是在写新功能而是在打磨。游戏开发有个铁律功能能跑通只是第一步玩得“顺滑”才是决定玩家体验的关键。PaperRoute 在这个阶段调整了移动阻尼、投递半径、房屋高亮闪烁频率甚至为了减少玩家的操作难度放大了投递判定范围让玩家骑车距离信箱大约一米左右就能触发投递而不是必须骑到精确贴脸的角度。自己玩过这个版本后我强烈建议这类小游戏在设计和调优时始终把“移动是寻找目标的手段而不是障碍”这件事放在心里。投递判定过严玩家会把大量时间耗在微调角色位置上挫败感远大于成就感。最后一步是把游戏工程构建打包并部署到静态托管平台。因为采用的是 Web 技术栈这一步非常简单一个静态站点一个入口 HTML 文件若干 JS 和资源文件传上去就能访问。没有应用商店审核也不需要服务器后端。整个发布链路可能十分钟之内就能完成。4. AI 写 3D 代码最容易翻车的地方与修正实录看完顺利的部分必须说说那些差点让项目崩盘的问题。这些问题不是我凭空猜的而是 Web 3D AI 编程这类项目里出现频率最高的几类坑。你把它们提前记住能省下大量调试时间和 Token 开销。4.1 坐标系与轴心点AI 的“空间想象”不稳定第一类高频翻车点是坐标系和模型轴心。原因在于大模型对空间概念的理解本质上来自文本描述而不是真正的三维直觉。你告诉它“把房子放在 x100, y0, z200”它会照做但当需要处理父子节点的相对位置、模型本身的轴心偏移时它经常给出“看起来对但实际完全错”的代码。我在类似项目里遇到过这样一个典型问题AI 生成了一棵树的模型树的几何体由树干圆柱和树冠球体组成。它把两个几何体加进同一个组后直接将组的位置设置在地面坐标。但球体的中心点是几何体中心树冠的底部实际上已经穿过了树干顶部再加上地面遮挡看起来就像树冠悬浮在半空一样。这种问题代码语法完全正确日志也没有任何报错纯粹是空间计算上的偏差。排错方法只能靠肉眼观察把摄像机拉近看模型细节才能发现树冠离地好几米。修正方式就是在构建树冠时把它的位置下移让树冠底部接住树干顶端。4.2 碰撞检测的两类误判大坑套小坑碰撞检测是另一个重灾区。项目里至少出现过两类典型误判。第一类是角色走到了房子边缘衣角已经穿墙但碰撞判定没有触发第二类是角色被一个透明且比模型大很多的碰撞盒卡住明明视觉上距离房子还有一大段空隙却怎么都走不过去。这类问题本质上源自 Three.js 支持多种碰撞几何体。AI 如果默认给每个房子绑定的是盒状碰撞体碰撞边界通常比视觉模型大一圈玩家容易感觉“路变窄了”。更麻烦的是当 AI 生成程序的碰撞检测代码时它可能混合使用了射线检测和包围盒检测两种检测方式的空间范围定义不同导致一部分墙面能挡住角色、另一部分穿模。解决思路是统一碰撞检测方式。小体量项目中最简单可靠的做法是所有静止障碍物都使用同一套简化包围盒并把包围盒相对于视觉模型缩小 0.2 到 0.3 倍避免碰撞边界贴得视觉边界太紧。AI 生成代码时不会自动告诉你这些经验值你需要把它写进提示词里明确要求“全部物体统一使用 AABB 碰撞盒并设置 scale 为 0.8”这种指令能少踩很多坑。4.3 逻辑正确但手感稀烂AI 无法替你感受加速度这是我最想强调的一点。AI 写了没有 bug 的移动逻辑游戏玩起来依然跟个幻灯片一样。为什么因为角色移动的加速度、最大速度、阻尼系数、跳跃高度这些参数AI 完全是从数值合理性出发来选的而不是从玩家的体验出发。PaperRoute 在调手感的阶段发现 AI 给的最大速度是 15 米每秒。从代码逻辑上看这个值没有错地图有 200 米见方速度太低确实会拖节奏。但实际体验中这个速度配合键盘转向非常飘玩家经常一头撞上房子。最后把速度调到 8 米每秒加速度从 30 调整为 12阻尼从 0.85 调到 0.92手感才算立住了。这里有个规律AI 生成的默认参数永远偏“理论值”而游戏手感需要的是“体验值”。任何涉及玩家控制的对象都要预留一周参数调优时间或者把调参的代码抽离成常量方便试玩时快速修改。4.4 长会话上下文污染越到后面 AI 越“记错”四天高强度开发到后期开发者会遇到一个极其恼人的现象AI 开始把一个房屋的位置记错或者将已经废弃的角色速度参数混入新代码。这不是 AI 笨而是长会话的上下文污染——对话历史里的老信息和新需求在注意力机制下产生了冲突AI 不知道以哪条指令为准。针对这一点最高效的解决方式是当开发进入新阶段时开一个新会话然后给 AI 一个精简版的“项目当前状态说明书”。说明书里只包含当前最新的地图参数、模块文件结构和正在处理的问题不要粘贴整个开发历史。这样既省 Token又能让 AI 在全新上下文里进入更专注的状态。PaperRoute 四天用了 15.6 亿 Token有一部分大概率就是因为没有做好会话隔离老会话越拖越长输入成本越滚越大。5. Token 消耗背后的方法论这套流程值不值得复制聊完技术细节我想从更宏观的层面谈谈这个项目给整个开发方式带来的启示。15.6 亿 Token 不是一个小数目但把它放到四天完成一个可玩 3D 游戏的背景下就需要重新审视投入产出比了。传统开发一个同等规模的 Web 3D 游戏假设一个全栈开发加一个初级 3D 美术效率正常的情况下大概需要两到三周。按薪资折算成本大概率在一万五到三万元人民币。PaperRoute 四天烧掉的 Token即使按最贵档计算成本也只在几千美元区间。这意味着在特定类型的项目里AI 全流程开发已经在成本和时间两个维度上同时取得了优势。但要注意这种模式并不是万能的。它适合的项目有明确特征边界清晰、模块之间低耦合、玩法有成熟参考、美术资源可以用程序化生成。换成一个高度依赖创新玩法、美术风格极其独特、或者需要复杂服务端逻辑的项目AI 的优势会快速消失Token 消耗会呈指数级上升而得到的东西仍然需要大量人工重构。PaperRoute 最有价值的示范意义在于它验证了一条路规格写作能力正在成为 AI 时代开发者最重要的技能之一。谁能把需求压缩成 AI 易于执行的精确规格谁就能真正撬动大模型的算力红利。这个结论对任何想尝试 AI 辅助开发的人都有参考价值不管你是写游戏、写网站还是做自动化小工具。作为一个经常研究 AI 编程工作流的人我对 PaperRoute 的评价是它不是那种颠覆性的天才创意项目也不是靠精美画面取胜的视觉作品但它把一个老掉牙的“送报纸”题材通过极致的流程控制和大胆的 AI 协作方式变得非常值得琢磨。如果你也想试试四天做一个 AI 驱动的 3D 小游戏我的建议是把规格写得像合同一样细致把调试会话像代码版本管理一样频繁切换再把你的手感和审美贯穿到每一次参数调优里。那些烧掉的 Token 不会白费它们最终换来的是一个能跑、能玩、能公开分享的完整作品。