Claude Code 做 3D 游戏：10 个开源工具与一套可复用的原型工作流

本文整理自爆裂队长 NEXT（@thinkszyg）在 X 发布的《想让 Claude Code 帮你做 3D 游戏，别让它从零手写物理和粒子特效》。原帖把 10 个开源项目分成三组：让 AI 操作游戏引擎、生成或准备素材、为网页 3D 游戏提供现成能力。本文保留这套分类，并根据各项目公开仓库的 README 与许可证信息补充使用边界。项目版本、引擎兼容性和安装方式会变化，实际接入前应重新检查仓库文档。

先看结论：让 Agent 组装成熟能力

用 Claude Code 或其他编程 Agent 做 3D 原型时，最容易浪费上下文和 Token 的地方，是让模型从零实现物理、粒子、相机控制、寻路或联机协议。这些问题已经有成熟库可用，更有效的分工是：

人定义玩法和验收标准
        ↓
Agent 读取项目与工具文档
        ↓
复用成熟库搭出最小可玩原型
        ↓
运行、截图、看日志、修复问题
        ↓
再补资产、特效、性能和联机能力

这套方法不等于“装完 10 个库就能自动生成完整游戏”。每个项目解决的是一个明确问题，仍然需要处理引擎版本、运行环境、资产许可、性能预算和游戏设计本身。

10 个项目如何分组

组别	项目	主要解决的问题
Agent 操作引擎	Gamedev Agent Skills	根据引擎和任务加载相应开发技能
Agent 操作引擎	MCP Unity	让 Agent 与 Unity 编辑器交互
Agent 操作引擎	Godot MCP	让 Agent 启动 Godot、运行项目并读取调试输出
素材	TripoSR	从单张图片重建 3D 物体，适合早期道具原型
网页 3D 组件	Drei	为 React Three Fiber 提供相机、环境、模型等辅助组件
网页 3D 组件	React Three Rapier	为 React Three Fiber 接入刚体和碰撞物理
网页 3D 组件	Yuka	提供 NPC 寻路、感知和状态机等游戏 AI 能力
网页 3D 组件	three.quarks	为 three.js 提供粒子和视觉特效系统
网页 3D 组件	React Postprocessing	为 React Three Fiber 增加泛光、景深等后处理效果
网页 3D 组件	Colyseus	提供 Node.js 多人游戏的房间、状态同步和重连基础

第一组：让 Agent 直接操作游戏引擎

1. Gamedev Agent Skills：先让 Agent 认识项目

Gamedev Agent Skills 是一组面向游戏开发的 Agent Skills。原帖提到它包含 74 个技能，并覆盖 Godot、Unity、Unreal、Phaser、PixiJS、three.js、Bevy、pygame、LÖVE 和 Roblox 等生态。它的核心价值是把“当前项目用什么引擎、正在做什么任务、应该遵循哪些步骤”整理成 Agent 可以读取的技能文件。

适合用在这些场景：

• 新建项目后，让 Agent 先识别引擎和目录结构；
• 让 Agent 按引擎惯用方式创建场景、脚本和资源；
• 在修复问题时，给 Agent 提供项目约定和检查清单；
• 把团队自己的导入、测试和打包规则沉淀为 Skill。

原帖给出的安装入口是 npx skills add gamedev-skills/awesome-gamedev-agent-skills。安装后不要立刻让 Agent 生成完整游戏，先让它回答三个问题：识别到的引擎是什么、将调用哪些技能、预计会修改哪些文件。这样可以提前发现目录识别错误和不必要的全局改动。

2. MCP Unity：把编辑器动作接给 Agent

MCP Unity 用 MCP 把 Unity 编辑器暴露给支持 MCP 的客户端。原帖强调的能力包括在编辑器里搭建场景、修改物体、配置材质和查看控制台错误；项目 README 将其定位为连接 Unity Editor 的 MCP 插件。

它适合缩短“改代码 → 回到编辑器 → 运行 → 看报错”的循环，但前提是本机已有可用的 Unity 项目和编辑器。使用时需要确认：

• Unity 版本与项目版本匹配，原帖按 Unity 6 及以上描述；
• Agent 连接的是目标项目，而不是另一个打开的编辑器实例；
• 场景、资源和脚本的修改范围可审查；
• 运行和构建命令不会触及项目外的敏感目录。

3. Godot MCP：让 Agent 运行、观察和调试 Godot

Godot MCP 面向 Godot，提供创建场景、添加节点、启动项目和读取调试输出等交互。它解决的是“Agent 能写脚本，但看不到引擎运行结果”的问题。

一个可靠的使用循环是：

1. 让 Agent 读取项目设置和主场景，先不要修改；
2. 让它创建一个只有玩家、地面和摄像机的最小场景；
3. 启动项目并读取调试输出；
4. 让 Agent 根据错误信息做一次小范围修复；
5. 由人检查运行画面和输入手感，再进入下一步。

Unity MCP 和 Godot MCP 的共同点是“操作引擎”，不是替代引擎本身。它们不能自动解决玩法设计、资产质量、帧率和发布配置等问题。

第二组：用单图快速准备 3D 素材

4. TripoSR：先得到可用的道具原型

TripoSR 是从单张图片进行快速 3D 物体重建的项目。它适合把概念图、产品图或临时参考图转成早期道具模型，用于摆放比例、测试碰撞和验证镜头。

它不应被理解为“单图直接得到可上线资产”。单视角输入会造成背面、底部和遮挡区域信息缺失，生成结果通常还需要：

• 清理网格和法线；
• 检查拓扑、材质和纹理；
• 重新设置碰撞体；
• 根据目标平台降低面数；
• 核对输入图片和生成结果的使用权。

原帖提到大约 6GB 显存的英伟达 GPU。这个数字是作者的运行经验，实际显存需求还会受到模型版本、输入尺寸和推理设置影响。没有合适 GPU 时，可以把它放在资产预处理阶段运行，不必让每次 Agent 对话都触发模型推理。

第三组：网页 3D 游戏的现成能力

下面 7 个项目主要服务于 three.js 或 React Three Fiber。它们不是同一个层级的替代品：Drei 负责常用场景组件，Rapier 负责物理，Yuka 负责游戏 AI，three.quarks 和 Postprocessing 负责画面表现，Colyseus 负责多人状态同步。

5. Drei：减少基础场景代码

Drei 是 React Three Fiber 的辅助组件集合，常见能力包括相机控制、天空和环境、阴影、模型加载以及其他场景工具。它的价值在于把重复的 three.js 配置封装成可组合的 React 组件。

适合先用 Drei 搭出“能看、能走、能加载模型”的场景，再决定哪些部分需要自定义。Agent 生成组件时仍要检查资源路径、加载失败状态和销毁逻辑，避免只在静态截图里看起来正常。

6. React Three Rapier：把物理交给成熟引擎

React Three Rapier 将 Rapier 物理引擎接入 React Three Fiber，覆盖刚体、碰撞器和关节等基础能力。原帖建议用它替代手写物理，原因是碰撞、重力和约束很容易在自制代码里产生大量边界 bug。

接入时要先定义物理世界的边界：哪些物体参与碰撞、哪些只用于触发事件、玩家和摄像机分别由谁控制。不要把渲染网格直接当成精确碰撞体，也不要让 Agent 在没有验收场景的情况下随意增加刚体数量。

7. Yuka：补上 NPC 的决策层

Yuka 是用于游戏 AI 的 JavaScript 库，面向寻路、感知、行为和状态机等问题。它适合为 NPC 增加巡逻、追踪、避让或状态切换，让角色不再只能沿固定路径移动。

Yuka 解决的是行为逻辑，不负责替你设计 NPC 的目标、动画和叙事。实现时可以先做一个有限状态机：巡逻 → 发现玩家 → 追踪 → 丢失目标 → 返回，然后用可观测的状态日志验证切换条件。

8. three.quarks：使用现成粒子特效

three.quarks 是面向 three.js 的通用粒子和视觉特效引擎，可用于火花、烟雾、魔法拖尾等效果。粒子系统通常涉及发射率、生命周期、速度场、材质和透明度，完全让 Agent 临时拼装容易出现效果不稳定或性能失控。

建议先为每种特效规定预算：最大粒子数、持续时间、纹理尺寸和移动端降级方案。原型阶段优先验证“触发时机和可读性”，再调整颜色、混合模式和细节。

9. React Postprocessing：用后处理增强画面层次

React Postprocessing 为 React Three Fiber 提供后处理效果，例如泛光、景深和其他屏幕空间效果。它能快速提升画面的层次感，但效果越多不代表画面越好。

使用时应按顺序验收：先保证基础光照、材质和色彩正确，再逐个开启效果并比较帧率。泛光和景深尤其容易掩盖材质、边缘或 UI 的问题，移动端还需要准备关闭或降低质量的配置。

10. Colyseus：为多人原型提供房间和同步基础

Colyseus 是 Node.js 多人游戏框架，提供房间、匹配、状态同步和断线重连等基础设施。它适合在单机原型验证后，再快速搭建多人房间和共享状态。

多人游戏的难点不只是“把位置同步过去”。需要明确服务端权威、客户端预测、状态广播频率、作弊边界和重连后的状态恢复。建议先同步一个低频、可验证的状态，例如房间内玩家列表和准备状态，再逐步增加移动、交互和战斗数据。

一套更稳的安装与开发顺序

不要一次把 10 个项目全部接入。可以按下面的顺序建立最小闭环：

阶段一：先让 Agent 看懂项目

安装 Gamedev Agent Skills，或者先写一份项目级开发说明。让 Agent 输出引擎、入口场景、运行命令、资产目录和测试方式。此时不引入物理、粒子和联机。

阶段二：只做一个可运行场景

选择 Unity、Godot 或网页 3D 其中一个目标。Unity/Godot 项目可以接入对应 MCP；网页项目则用 Drei 创建场景、相机、灯光和一个可加载模型。验收标准是能启动、能操作、能看到错误日志。

阶段三：补一个基础交互

网页 3D 项目可先加入 React Three Rapier，实现地面、玩家刚体和一个碰撞体。引擎项目则使用引擎自身的物理组件。先确认重力、碰撞层和输入映射，再继续扩展。

阶段四：补表现和 AI

用 Yuka 增加一个 NPC 状态机，用 three.quarks 增加一种可触发粒子效果，再用 React Postprocessing 增加一种后处理。每次只加一个系统，记录帧率和错误，方便定位回归。

阶段五：最后处理素材和多人

用 TripoSR 生成或整理临时道具，替换占位模型；当单机循环稳定后，再用 Colyseus 加入房间和状态同步。多人系统应放在玩法已经可验证之后，否则网络问题会掩盖玩法问题。

给 Claude Code 的任务模板

可以把下面的结构作为一次 Agent 任务的起点：

你正在一个 [引擎/框架] 项目中工作。

目标：创建一个最小可玩 3D 原型，包含 [玩家动作]、[场景目标] 和 [验收画面]。

现有能力：
- 场景入口：[文件或场景]
- 运行命令：[命令]
- 已安装库：[库名]
- 资产目录：[路径]

约束：
- 先读取项目结构，不要覆盖现有场景；
- 优先复用现有库，不要手写物理、粒子或联机协议；
- 每次只修改一个可回滚的小范围；
- 不新增账号、密钥或项目外文件。

完成标准：
- 项目可以启动；
- 玩家可以完成 [动作]；
- 碰撞/特效/NPC 行为满足 [具体条件]；
- 运行日志没有新增错误；
- 列出修改文件、运行命令和仍待人工检查的事项。

这个模板把“调用什么工具”和“怎么判断完成”写出来，能减少 Agent 在错误方向上持续生成代码的时间。

许可证、费用和兼容性边界

原帖将这 10 个项目概括为免费开源，并称无需额外 API key。根据公开 GitHub 仓库元数据，截至本文整理时，列出的项目许可证主要为 MIT 或 Apache-2.0；但“代码仓库有开源许可证”不等于所有模型权重、示例资产、第三方依赖和生成内容都可以任意商用。

还需要区分三类成本：

• 软件许可证成本：项目本身的 MIT/Apache-2.0 许可义务；
• 本地计算成本：TripoSR 等模型运行所需的 GPU、显存和时间；
• Agent 使用成本：Claude、Codex 或其他服务的订阅、额度和请求费用。

因此，是否“免费”应按自己的完整链路核算，不能只看 GitHub 页面上的许可证。引擎版本、Node.js 版本、React Three Fiber 版本、浏览器 WebGL/WebGPU 支持和 GPU 驱动也需要在开始前锁定。

最终验收清单

• Agent 能正确识别引擎、入口场景和运行命令。
• 项目可以从干净环境启动，不依赖个人目录中的隐式文件。
• 物理碰撞在至少三个边界场景下符合预期。
• 粒子和后处理在目标设备上有明确质量档位。
• NPC 状态切换有可观察日志或调试显示。
• 资产来源、模型权重和纹理许可已经记录。
• 多人原型定义了服务端权威、断线重连和状态恢复策略。
• Agent 输出了修改文件、运行命令、测试结果和剩余风险。

来源与编辑边界

• 原始 X 帖子：爆裂队长 NEXT（@thinkszyg），发布于 2026-10-21。
• 本文保留了原帖列出的 10 个项目和三组分类。
• 项目用途和许可证信息根据对应 GitHub 仓库公开元数据交叉核对；版本兼容性、性能和商业使用限制没有在本文中作统一保证。
• 原帖关于“原型时间能砍掉一大截”的表述属于作者经验，实际收益取决于项目规模、团队能力、引擎和验收标准。