用Claude Opus 5.5独立开发并上线3D网页游戏全流程

一位独立开发者用 AI 从零打造并上线了一款3D「高压水枪清洁」网页游戏，上线后吸引近千名玩家，平均游玩时长约两分钟。整个游戏——从游戏逻辑、角色模型、环境美术到各项系统——几乎全部由 Anthropic 最新发布的 Claude Opus 5.5 完成。这篇文章拆解他的完整工作流，看看 AI 辅助游戏开发到底能走多远。

一个人、六个半小时、一款可玩的游戏

这款游戏的玩法并不复杂：在限定时间内清理完整个关卡的脏污，但不能踩坏植物或喷到屋主的宠物，否则游戏失败。做得好就能通关并解锁更多升级。看似简单的休闲游戏，背后却是一套相当成熟的 AI 协作流程。

开发者坦言自己并不刻意记录成本，因为他使用的是 Claude Max 订阅（最近从 5x 升级到 20x 套餐）。但他让 Opus 5.5 自行估算：整个项目耗时约六个半小时，上线时按 API 定价约合 233 美元，加上后续持续加内容和修 Bug，总成本大约翻倍。关键在于，这六小时并非全程盯着屏幕——他把一批提示词丢给 AI 后便让其在后台运行，隔段时间回来检查进度。

值得关注的一个细节是「子代理（sub-agents）」的使用方式。虽然日志里出现了多达 21 个子代理，但并非同时运行。他的做法是：任何给定任务通常只有一个主代理，若任务可并行化，再派生一两个子代理协助；同时在后台跑一批子代理专门负责捕获提示词、提交代码和截图，自动生成一份记录页面，方便他后续做视频复盘。主建游戏任务用 Opus 5.5，琐碎的提交与截图则交给更轻量的 Sonnet 5。

为什么选择 WebAssembly + WebGPU 而非游戏引擎

这款游戏没有使用任何传统游戏引擎，而是基于 Rust、WebAssembly 和 WebGPU 直接运行在浏览器中。玩家无需安装，桌面和手机浏览器都能直接打开游玩，分发极其便利。他把游戏托管在 Wavedash 平台上，任何人点开链接即可游玩。

他提到这个选择受到一位开发者关于 WASM 与 WebGPU 的帖子启发，核心逻辑是：既然现在大多数人已经不再逐行阅读代码，像 Three.js 这样提供人类可读 API 的抽象层，对 LLM 来说可能已不再必要——模型足够强大，能直接处理更底层的实现。对这位开发者而言，这套管线带来的好处是浏览器端效果出色、移动端兼容性好，且迭代速度极快。

WebAssembly（WASM）是一种可在现代浏览器中以接近原生速度运行的二进制指令格式。开发者用 Rust 编写游戏逻辑后，通过工具链编译为 WASM 字节码，浏览器的沙箱虚拟机直接执行，无需插件或安装包。WebGPU 则是 W3C 标准化的新一代浏览器图形 API，它暴露了现代 GPU 的底层能力（计算着色器、显式内存管理等），性能和表达力远超此前的 WebGL，已在 Chrome、Safari 等主流浏览器中逐步落地。两者结合意味着：游戏逻辑跑在高效的 WASM 运行时，渲染调用直达 GPU，整条管线绕开了 JavaScript 的性能瓶颈，同时仍保留「打开链接即玩」的零安装优势。对 AI 辅助开发而言，这套技术栈还有一个隐性好处：Rust 的类型系统和编译期检查能在一定程度上过滤掉 AI 生成代码中的低级错误，让输出更可预期。

从头脑风暴到灰盒原型的关键步骤

开发者反复强调一个核心观点：不要「一键生成」游戏（stop one-shotting games）。他认为那些跑上 12、13 甚至两天的一键生成项目，确实能展示模型能力，是不错的技术演示，但你对结果几乎没有创意掌控权。真正想做出属于自己的游戏，必须在细节上与 AI 持续对齐。

他的流程第一步永远是生成多版美术 Mockup。这次他用 Gemini（Gremity）2.5 图像模型生成了多种美术风格的草图，并明确要求同时适配移动端和桌面端，先对齐视觉方向，再让 AI 动手构建。

在工作流设置上，他坚持将角色、环境、道具分别放在独立的 Blender 文件中制作，而不是直接在游戏里建模。角色模型可以单独绑骨骼和做动画，环境则作为更偏静态的道具单独处理。这种分离让他能并行推进多条产线。

接着他开启了三线并行：一边用子代理生成角色模型（通过制作 turnaround 转面图，再用 Tripo 这类图生3D工具生成模型，最后在 Blender 中绑定骨骼），一边生成环境道具（树木、汽车等），同时让第三个代理构建一个「灰盒关卡（gray box）」用占位美术测试高压水枪的核心机制。

他特别强调要先把核心玩法「做对、做爽」——夸张的动作反馈、水流物理手感是重点。灰盒阶段就能开始试玩调手感，而美术资产在后台同步产出。他形容这就像拥有了一支完整团队：角色美术、环境美术各司其职，而现在这些角色都由 AI 并行扮演。

「灰盒（gray box）」是游戏开发中的原型技术，指用无纹理的简单几何体（立方体、平面、胶囊体）搭建关卡布局，目的是在投入任何美术资源之前验证核心机制的可玩性和手感。这一方法源于关卡设计领域，核心思路是把「设计是否成立」和「画面是否好看」拆成两个独立问题分阶段解决。在 AI 辅助工作流中，灰盒原型的价值被进一步放大：AI 可以并行生成正式美术资产，而开发者同时在灰盒版本中调整参数、测试反馈循环，两条线互不阻塞。等美术资产就绪，替换占位几何体即可，不需要推倒重来。这也是为什么作者强调「先把核心玩法做对、做爽」——没有灰盒阶段就直接堆美术，一旦机制需要修改，已有的精致资产往往会成为阻力。

Opus 5.5 的进步：绑骨与权重一次做对

一个让开发者印象深刻的提升是绑骨（rigging）与权重绘制（weight painting）。几周前他尝试做动画时，还需要手动修正权重、挪动骨骼；而这次 Opus 5.5 几乎开箱即对，第一次就把绑骨和权重做对，他基本没有手动干预。

更精彩的是水枪喷嘴与角色手部的连接处理。最终游戏里，角色不喷水时只是握着喷枪，一旦开始喷射，喷嘴会与手部骨骼正确绑定——这个效果他原本没指望能一次做对，但得益于预先搭建的测试场景，AI 完成得相当到位。

他还做了一件有意思的事：让 Opus 5.5 生成一份解释「喷射瞄准如何实现」的说明页。由于全部跑在 Rust 和 WebAssembly 上，计算可以在 120Hz（每秒 120 次）下进行，从而实时计算模型转向、让水流自动朝光标方向喷射。AI 不仅给出代码片段，还用通俗方式解释：喷嘴本质上就是一个「弹簧」，它不断尝试从一点摆向光标所在位置，这种弹性正好模拟出水流的视觉效果。

他借此提出一个值得玩味的观点：虽然如今「没人看代码」，但 AI 不该只是把脑中想法盲目实现后就丢在一边——它也是绝佳的学习工具。换作自己从零手写，他得花大量时间搜索研究；而 AI 帮你拿到结果后，还能回过头来像老师一样讲解它是怎么算的。

绑骨（rigging）是3D动画流程中将骨架系统附加到网格模型的过程，骨骼的运动会带动周围顶点一起变形，从而产生角色动作。权重绘制（weight painting）则是指定每个顶点「听从」哪根骨骼、以何种比例跟随移动的精细化步骤——权重分布不合理会导致关节处出现穿插、塌陷或不自然的扭曲，通常需要美术师反复手动调整。这两项工作在传统管线中属于技术美术的专业领域，既需要空间想象力，也依赖大量经验积累，历来是 AI 自动化最难突破的环节之一。作者特别指出此次 Opus 5.5 「几乎开箱即对」，对比几周前同类任务仍需大量手动干预的状况，说明模型在理解三维骨骼拓扑与蒙皮逻辑方面有了可感知的代际跃升，这对于希望用 AI 完成完整3D角色制作流程的独立开发者而言是重要的参考信号。

从原型到可上线：打磨与首次体验设计

从灰盒原型到成品，剩下的工作主要是打磨。他分享了几个实用技巧：

• 加天空盒（skybox）：之前灰蒙蒙的背景让游戏显得单薄，用图像生成工具做一张包裹场景的天空盒图片，瞬间提升氛围和精致感。
• 填满街区：原本角色像站在一块随机草地上，他让 AI「填满整个社区」，生成了完整的邻里环境，也为后续做不同街区留下空间。

上线前他重点打磨了「首次用户体验（FTUE）」。他设计了循序渐进的教学：第一关学习扇形喷头清理落叶并学会避开障碍物，之后遇到需要高压射流模式才能清除的油污，第三关才引入计时压力。通过关卡逐步教会玩家全部机制，而非让玩家自己读说明文字。

最终，这款游戏已具备任务系统、关卡进度和升级机制——从一个灰盒原型成长为一个完整的「垂直切片」。开发者表示 AI 大约花了六小时跑出游戏主体，其余时间用于打磨。鉴于反响不错，他计划继续加内容：更多街区、更多喷射类型、更多游戏模式。

对独立开发者意味着什么

这个案例最大的价值不在于「AI 能写游戏」这件事本身，而在于它展示了一条从创意到上线、再到分发触达真实玩家的完整闭环。借助可并行的子代理工作流、分离式美术管线和浏览器原生的 WASM/WebGPU 技术栈，一名单人开发者能在数小时内把脑中的想法变成一款真正可玩、可托管、可被近千人游玩的游戏。

对于那些一直梦想独立做游戏的人来说，门槛正在被显著拉低。但开发者反复提醒：AI 擅长执行，创意方向与细节把控仍需人来掌舵——先对齐、再构建，拒绝一键生成，才是做出属于自己游戏的正确姿势。