经常有人跑来问我AI都能写代码了能不能直接让它帮我做一个3D小游戏我的回答一直是——能但前提是你得会写Prompt。注意不是那种“帮我做一个3D游戏”一句话甩过去而是把玩法规则、场景尺寸、摄像机逻辑、碰撞反馈、界面状态全部拆到指令里的写法。我自己用这套思路做了十几个小游戏原型从最初翻车翻到怀疑人生到后来基本一次生成就能跑起来中间沉淀了10多个真正好用的Prompt模板。这篇文章就把它们全部整理出来每个都附上我的设计意图和使用场景适合正在用AI辅助前端开发、想快速验证游戏点子的朋友参考。先说清楚一个观点Prompt生成3D小游戏重点从来不在“生成”两个字而在“拆解”。你拆得越细AI给的结果越接近可运行状态。接下来我会从为什么总翻车讲起再给模板、跑完整案例最后把生成后最常见的坑也一并列出来。1. 为什么“一句话生成3D游戏”总是翻车先说清Prompt的边界很多人第一次试AI生成游戏都是满怀期待地把需求往对话框里一扔比如“做一个3D跑酷游戏”。结果生成出来的东西要么摄像机乱飞要么角色直接穿模掉出地图要么压根没有游戏循环。问题不在于AI笨而在于3D游戏本身的信息量远超一段自然语言能表达的范畴。1.1 3D项目本质上是一套状态机不是单文件脚本一个再简单的3D小游戏背后也至少包含这几层逻辑场景初始化、渲染循环、输入监听、物理碰撞、游戏状态切换开始/进行中/结束、UI更新。这还不算资源加载、音效播放、性能优化。你让AI用一句话去脑补这一整套体系它只能给你一个“看起来像游戏”的空壳。我第一次用AI生成3D游戏时让它生成一个“第三人称收集金币”的Demo。AI确实给出了完整的HTML文件打开一看场景有、金币有、角色也有但按下WASD角色纹丝不动。检查代码才发现它把键盘监听写在了坐标系变换之前输入事件绑定了但对应的位移函数根本没被调用。这种问题在传统开发里一眼就能定位但在AI生成的代码里非常常见因为AI默认你知道它的默认约定而你不知道。1.2 两个最常被忽略的失败原因坐标系和资源路径踩了几次坑之后我总结出两个高频翻车点。第一是坐标系混用。Three.js里世界坐标、局部坐标、屏幕坐标是完全不同的三套东西Prompt里如果不说清楚“角色移动用世界坐标还是局部坐标”AI大概率会随机选一个结果就是角色移动方向跟视角方向完全对不上。第二是资源路径问题。很多AI生成的代码习惯性地用相对路径加载模型或贴图比如./assets/model.glb但实际项目里模型文件根本没放进去或者网络CDN路径失效于是打开页面所有模型都是粉色的警示色。这两个问题看起来是代码问题根源却在Prompt写得不够精确。所以我在后面的所有模板里都会显式声明坐标体系、资源处理方式以及运行环境。这也是我从翻车到稳定的关键转变。2. 动手前要先定的事技术栈和项目骨架Prompt写得再好技术栈没定对后面全是白费。3D小游戏开发现在主要就是三条路线我分别都试过直接说结论。2.1 三个主流方案怎么选Three.js、R3F还是Babylon.js为了方便对比我先列个表方案适合场景上手门槛AI生成成功率我的评价原生Three.js单页小游戏、演示Demo、无需UI框架的项目中等较高最通用Prompt结果最容易预测React Three Fiber已在用React、需要组件化开发的中大型项目中高中等适合工程化但AI容易生成React版本混乱的代码Babylon.js需要内置物理引擎、复杂碰撞、VR场景高中低功能全但API复杂AI生成质量不稳定我个人做小游戏原型90%的情况选原生Three.js而且要求AI把整个游戏写在一个HTML文件里通过CDN引入Three.js。原因很简单AI生成单文件代码的成功率远高于多文件工程因为不需要处理模块导入、构建配置、资源引用这些容易出错的部分。你拿一个HTML文件随便找个浏览器就能打开验证想法够用了。如果你追求更细腻的光影和画面效果Babylon.js确实更强但代价是Prompt要写得极其精细连粒子系统的参数都要指定。对大多数人来说用Three.js先把玩法跑通比纠结渲染效果更重要。2.2 我给AI准备的“项目上下文”长什么样很多人在技术栈定了之后就直接开始写功能Prompt了。我的习惯是先给AI一段固定的“项目上下文”让它知道你手头项目的边界条件。这一段不是可有可无的客套话而是后面所有Prompt都依赖的基准线。我常用的项目上下文是这样的项目约束 - 使用Three.jsCDN版本0.160.0及以上通过script标签全局引入 - 所有代码组织在单个HTML文件中不得拆分JS文件不得使用npm包 - 场景单位1单位1米Y轴向上X轴向右Z轴朝向屏幕外 - 摄像机默认使用PerspectiveCamera视野角60度 - 角色、障碍物、道具全部使用内置几何体BoxGeometry、SphereGeometry等拼装禁止使用外部模型文件 - 交互输入支持键盘和鼠标键盘使用WASD空格不使用方向键 - UI使用HTML叠加层不使用Three.js的CSS2DRenderer或画布文字 - 代码中所有对象必须命名清晰关键参数使用常量便于修改 - 每次给出修改时只输出完整HTML文件同时说明改了哪些API把这段丢给AI后面的对话质量会明显提升。它不再需要猜测“单位是米还是厘米”“摄像机用哪种”“UI怎么渲染”直接把精力放在游戏逻辑上。如果你的项目有特殊要求比如必须支持触屏手势那就修改对应约束即可但一定要在上下文里写明白。3. 10个可以直接抄的3D小游戏Prompt附设计意图下面就是重点了。这些Prompt是我这几个月反复调出来的版本覆盖了3D小游戏开发里最常见的几个模块场景搭建、角色控制、玩法逻辑、UI状态、音效反馈、性能优化。每个你都可以直接复制到AI对话框里用也可以按需改参数。3.1 场景与角色类PromptPrompt 1基础场景搭建在Three.js中创建一个3D小游戏的初始场景要求 - 使用半球光和环境光组合保证场景整体明亮柔和阴影清晰但不生硬 - 地面使用圆形或方形平面颜色为草绿色接收阴影 - 天空使用渐变色处理从顶部浅蓝色过渡到地平线白色 - 在场景边缘放置6到8棵树每棵树由圆柱树干和两个大小渐变的圆锥树冠组成树冠颜色为深绿随机旋转角度朝向 - 场景中央留出10x10米的空旷区域不放置任何物体 - 提供一段35度的环绕摄像机角度从上方俯瞰空地 - 所有代码放在一个HTML文件中直接打开就能看到场景这个Prompt的设计逻辑是“先给舞台再谈玩法”。为什么我连树冠圆锥的数量和颜色都要写因为AI默认的直觉是“放一棵树就行”而游戏场景需要的是边界感和空间尺度感。你把这些细节写清楚AI生成的场景才不会像白板一样空。Prompt 2第三人称角色控制器在已有场景基础上添加一个玩家角色要求 - 角色由立方体身体和球形头部组成身体颜色为橙色头部颜色为肤色浅黄色 - 使用WASD控制角色移动W前进、S后退、A左移、D右移移动速度每秒4米 - 空格键跳跃跳跃高度2米落地后可以再次跳跃不考虑二段跳 - 摄像机跟随角色位置固定在角色后方3米、上方2米处始终注视角色头部 - 角色移动时面向移动方向按下W面向正前方按下S面向后方A和D对应左右转身 - 角色不能穿过场景中的树木碰撞检测使用AABB包围盒碰撞后停止移动但不反弹 - 输出完整HTML可直接使用这里最容易被忽略的是“碰撞后停止但不反弹”这个要求。如果你不写AI生成的碰撞逻辑往往是“检测到碰撞就反向位移”角色会像撞了弹簧一样疯狂抖动。我实际测试时遇到过角色卡在树冠里出不来的情况就是因为少了这句约束。3.2 玩法与交互类PromptPrompt 3可收集道具与计分逻辑在场景中放置12个金色小球作为收集道具要求 - 每个小球半径0.3米使用MeshStandardMaterial材质金属度高、粗糙度低让表面有反光效果 - 小球随机分布在场景空地内相互间距不小于1.5米高度统一在地面上方0.5米处 - 小球以自身Y轴为中心缓慢旋转每秒旋转60度 - 玩家角色碰到小球后小球播放0.3秒缩小动画后消失分数增加10分 - 在页面左上角用HTML元素显示当前分数字体大小24像素黑色加粗 - 所有小球收集完毕后在屏幕中央显示“恭喜通关”文字 - 输出完整HTML文件可以直接运行写这个Prompt时我特别强调了“旋转”和“缩小动画”因为道具若是完全静止的玩家在移动视角时很难注意到它们的存在而有了旋转动画场景会立刻生动起来。这里还有个通用技巧道具的碰撞不需要精确到球体表面用AABB包围盒判断即可玩家体验上几乎无感但代码量少很多AI也不容易写出bug。Prompt 4敌人AI追踪在场景中添加2个红色敌人角色要求 - 敌人使用锥体身体和半球头部颜色为深红色体型比玩家小30% - 敌人在地面巡逻巡逻路径为矩形四角到达一个角后停留2秒再走向下一个角 - 当玩家距离敌人小于5米时敌人切换为追击模式以每秒3米的速度跟踪玩家 - 追击时敌人会持续注视玩家方向头部朝向玩家 - 如果敌人触碰到玩家身体游戏结束显示“游戏结束”画面并停止渲染循环 - 敌人不穿越树木与树木碰撞后绕过或停下等待 - 输出完整HTML可直接运行这里的核心是“巡逻/追击两种模式切换”这是基础游戏AI最常见的设计。很多AI生成的敌人只会傻站在一个点或者直接穿过树木冲向玩家就是因为Prompt里没写状态切换条件和碰撞处理。我加上了距离阈值和停留时间AI生成的行为就自然多了。3.3 状态与体验类PromptPrompt 5倒计时与游戏循环为游戏添加完整的生命周期管理要求 - 游戏分为三个状态READY等待开始、PLAYING进行中、ENDED已结束 - 页面加载后首先显示封面标题为“收集金币大作战”下方显示“按Enter开始” - 按下Enter后进入PLAYING状态开始60秒倒计时倒计时显示在屏幕正上方使用等宽字体 - 倒计时归零后进入ENDED状态停止玩家运动停止敌人追踪显示最终得分 - ENDED状态下按R键重新开始所有道具恢复分数归零重新进入READY状态 - 开始/结束切换时画面不能出现闪烁或残留 - 输出完整HTML可直接运行游戏制作者最怕的一件事就是“游戏没有开始和结束”。很多AI一次生成的东西页面打开就自动开始跑玩家死了之后完全不知道该怎么办。所以我现在要求AI必须是清晰的三态状态机而且用按键而不是点击来触发切换。键盘事件比鼠标点击在AI生成里更容易控制也不容易和UI层产生冲突。Prompt 6音效与反馈系统为游戏添加音效反馈要求 - 使用Web Audio API生成音效不加载外部音频文件 - 收集道具时播放短促上行音阶频率从523Hz升到784Hz时长0.2秒 - 跳跃时播放上升滑动音效频率从200Hz升到600Hz - 敌人追击时播放低沉持续音调频率110Hz音量随距离减小距离超过5米时静音 - 游戏结束时播放下行三音阶频率从440Hz降到220Hz - 所有音效音量统一限制在0.3以下避免刺耳 - 每个音效函数单独定义便于修改 - 输出完整HTML可直接运行不要小看音效这个环节它直接影响玩家对游戏手感的第一印象。我要求用Web Audio API合成音效而不是加载音频文件是因为AI生成代码时如果让你放一个MP3路径你做Demo还得去网上找素材纯纯浪费时间。用API合成虽然音质粗糙但游戏逻辑完整后续替换成真实音效也容易。3.4 进阶优化类PromptPrompt 7移动端触屏适配为游戏增加手机触屏支持要求 - 左侧1/3屏幕区域为虚拟摇杆摇杆中心显示半透明圆形拖动控制角色移动方向 - 右侧屏幕区域点击触发跳跃 - 触屏模式下摄像机跟随逻辑不变但默认拉远至角色后方4.5米处 - 屏蔽触屏默认的页面滚动行为避免拖动时页面跟着滚动 - 屏幕宽度小于768像素时自动启用触屏模式同时隐藏键盘操作提示 - 所有触屏按钮用HTML绝对定位实现不遮挡分数显示 - 输出完整HTML可直接运行移动端适配是Prompt里最容易出bug的一类需求因为触控事件和键盘事件的坐标系不一样AI经常把touchmove的坐标直接当世界坐标用。所以我加上了“虚拟摇杆半透明”“屏蔽页面滚动”这些边界条件生成结果基本不会跑飞。Prompt 8性能优化对游戏进行性能优化要求 - 所有几何体在初始化时合并不重复创建相同形状的对象 - 静态物体树木、地面设置castShadow为false只有角色和道具接收阴影 - 使用renderer.setPixelRatio(Math.min(window.devicePixelRatio, 2))限制像素比 - 渲染循环中不创建任何新对象所有临时向量在初始化时定义复用 - 场景中粒子和光照数量保持在10个以内不使用后处理特效 - 在渲染循环中每帧计算FPS当FPS低于30时自动降低shadowMap.type至BasicShadowMap - 输出完整HTML可直接运行写性能类Prompt的关键是“给AI一个明确的量化标准”。你写“尽量优化”它只会给你一个requestAnimationFrame写“合并几何体、限制pixelRatio、降低阴影精度”这些具体操作它才会真的去改底层代码。Prompt 9双人同屏模式将游戏改为双人同屏模式要求 - 玩家1使用WASD控制颜色为橙色玩家2使用方向键控制颜色为蓝色 - 摄像机改为固定侧视角从侧面俯视整个场景保证两个玩家都在画面内 - 两个玩家各自有独立分数显示分列屏幕左右上角 - 游戏目标改为比对方先收集满5个道具 - 两个玩家之间不能互相穿过碰撞后各自弹开0.5米 - 敌人不会锁定任何玩家只沿固定路径巡逻 - 输出完整HTML可直接运行双人模式会让你对场景布局的理解完全改变。单人模式下摄像机可以一直跟着主角转双人就必须用固定视角或者动态拉远Prompt里必须把视角策略直接定死否则AI会生出一个两人各玩各的分屏那体验比单人还差。Prompt 10关卡扩展与存档为游戏增加关卡系统要求 - 共设计3个关卡每关的地图大小和障碍物数量不同 - 第一关10x10米2棵树5个道具第二关15x15米5棵树8个道具第三关20x20米8棵树12个道具 - 每关通关后显示“进入下一关”按钮点击后重置场景并加载下一关配置 - 玩家每关的生命数为3碰到敌人扣1条命命归零则本关重新开始 - 关卡数据使用JavaScript对象数组定义结构为mapSize、treeCount、itemCount、enemySpeed - 当前进度存在localStorage中刷新页面后可从最后一关继续 - 输出完整HTML可直接运行多关卡是“从Demo到完整游戏”最关键的一步但也是最容易让AI生成崩溃的需求。如果你让AI直接写三个不同的场景它往往会复制粘贴大段代码最后整个文件上千行。我的做法是让AI把地图配置抽象成数据对象这样后续加关卡就是加一行JSON的事。Prompt 11头顶血条与状态显示进阶为角色添加头顶血条要求 - 血条使用HTML的div实现通过屏幕坐标投影到角色头部上方 - 血条宽度80像素高度8像素背景为半透明黑色内部填充为绿色 - 角色受到伤害时血条颜色变为红色血量为0时角色消失并触发游戏结束 - 血条每一帧跟随角色移动但只在角色距离摄像机小于15米时显示 - 不做任何文字标签仅显示血条本身 - 输出完整HTML可直接运行这种“把UI绑到3D物体上”的需求很常见但也是Prompt生成的重灾区因为AI天然地会把血条放到固定位置或者用Three.js的Sprite画一个贴图。我要求用屏幕坐标投影代码路径最直接也不会混入其他渲染层。4. 完整案例从零Prompt到可玩的躲避收集小游戏前面那些模板拆开看容易理解但怎么组合成一个完整可玩的游戏才是真正的难点。我用一个具体案例带大家走一遍全流程看看我是怎么把前面这些模块拼起来的。4.1 拼接流程和一个具体Prompt我要做的游戏叫“森林收集战”核心玩法是在树木环绕的空地上控制角色收集金币同时躲避两个巡逻的敌人60秒内尽可能多得分。目标平台是桌面浏览器。我不会把整个游戏需求一次性扔给AI而是分三步走第一步用项目上下文加上Prompt 1生成基础场景。 第二步在场景已经能正常显示后追加Prompt 2把角色控制加进去。 第三步依次追加Prompt 3、Prompt 4、Prompt 5把道具、敌人、倒计时的逻辑串起来。每次追加时我都会在对话里附上一句“在上一版代码的基础上修改只输出改动后的完整HTML”。这里我要重点说一句**分步生成比一次性生成功率高一倍不止。**AI对话模型对长文本上下文的依赖很强你在一轮里堆太多需求它到后面就会把前面的约束忘掉。分步走每一轮专注一个模块生成结果稳定很多。4.2 生成后要做的手工修正即便Prompt已经写得比较细生成后的代码也大概率需要小修。以我“森林收集战”为例生成后的第一版里角色踩到金币时金币直接消失了但是分数没变——原因很简单AI把碰撞检测写在了道具旋转的那一帧旋转结束后碰撞检测就不再执行。我在生成代码里找到了类似if (intersects) { scene.remove(item) }这样的片段但没有调用score 10和更新UI的逻辑。补上之后就没问题了。如果你不想手工找这种bug还有一个办法在Prompt里多加一句“道具消失前必须调用内部回调函数ScoreManager.addScore()”。给AI一个明确的函数名和职责边界它会比从一个匿名逻辑块里推断行为可靠得多。**这套流程我实际跑下来平均一个可玩Demo的调试时间在30到60分钟。**如果你直接让AI一口气生成光是定位bug就可能超过两小时。时间花在哪里自己一算就明白。5. 生成代码最常见的6类问题以及我怎么修光给Prompt不告诉你会遇到什么坑等于只给地图不给加油站。下面这些问题是生成代码里出现频率最高的我把定位思路和修法一起列出来。5.1 摄像机视角飞出地图症状打开页面后画面里什么都没有或者只能看到地面纹理的一角。原因通常是摄像机初始位置的坐标超出了场景边界。比如场景是10x10米摄像机却摆在了100, 50, 100。定位方法在渲染循环里加一句console.log(camera.position)运行后直接看坐标数值。修复把Prompt里的“摄像机初始位置”显式写出来比如camera.position.set(0, 8, 12)并加上“位置必须在场景边界内”的约束。大部分情况下这一步就够了。5.2 角色移动方向跟视角方向不一致症状你按下W角色往屏幕的右前方跑而不是正前方。这是世界坐标和摄像机坐标混用导致的。定位方法检查键盘监听回调函数里角色速度向量的计算方式。如果直接用vector.set(1, 0, 0)那就说明根本没考虑摄像机朝向。修复在Prompt里写死“角色移动方向必须基于摄像机朝向计算摄像机的正向即屏幕正前方”。如果AI生成的代码结构太乱直接在回调里改用camera.getWorldDirection()做基准向量。5.3 角色被夹在物体之间不停抖动症状角色靠近树木或墙壁后身体不停抖动还会慢慢穿进物体。定位方法看碰撞解决逻辑。通常AI写的是“检测到碰撞后沿X轴推回0.5米”之类的硬编码位移没有考虑速度方向。修复在Prompt里加一句“碰撞后角色应停在碰撞表面速度清零然后沿碰撞法线方向滑动”。如果还不行最简单的办法是把角色碰撞体半径缩小一点让角色模型看起来像擦着物体边缘过去。5.4 物体加载后全是粉红色症状场景里的模型或地面显示为粉红色/紫色。这几乎一定是材质和光照问题要么是模型用了MeshPhongMaterial但没有加光照要么是纹理图片加载失败。定位方法打开浏览器控制台看有没有Failed to load resource或者Texture loaded警告。同时检查场景里是否添加了DirectionalLight或AmbientLight。修复要求AI“所有材质使用MeshStandardMaterial或MeshLambertMaterial场景至少包含一束环境光和一束方向光”。如果纹理加载失败就把纹理换成纯色材质先保证Demo能跑。5.5 渲染循环占用大量CPU风扇狂转症状一个简单的收集金币游戏浏览器标签页就能吃掉40%以上的CPU。定位方法看渲染循环里有没有每帧创建新对象比如每帧new THREE.Vector3()或new THREE.Raycaster()。Three.js官方文档都强调过循环里反复创建对象会导致GC频繁触发表现为帧率波动和CPU飙升。修复在Prompt里加上“渲染循环中不得创建任何新对象所有临时变量在初始化时定义并复用”。如果已经有代码就把声明挪到循环外循环内只做赋值和运算。5.6 游戏重新开始后残留旧对象症状按R重开后上一局被收集的道具又出现了但分数已经清零——也就是世界状态和UI状态对不上。定位方法看重置逻辑是怎么写的。大多数AI是直接从场景中删除道具但没把道具引用从数组里清空下一次“重新生成道具”时数组里还留着旧对象。修复Prompt里写“重置时必须清空所有动态对象的引用数组再重新生成不得保留上一局的物体引用”。修代码的话直接找道具数组的赋值语句确认重置时执行了items.length 0。这6类问题覆盖了我用AI生成3D小游戏时遇到的绝大多数崩溃场景。前两类最基础后四类在复杂度高一点的项目里才会出现。建议你把这些症状和修法存一份真遇到了直接对照排查比从头看代码快得多。6. 让Prompt效果更稳的几个使用习惯最后一个部分不讲技术参数讲我在反复实践中总结出来的几个使用习惯。它们比任何一个单独Prompt都更能提升整体成功率。第一一次只解决一个需求。你不要在同一个Prompt里既要求改移动手感又要求加血条还要求优化性能。AI模型在处理多任务时容易“顾此失彼”尤其是前一版代码里的bug它可能都还没修完。我现在的习惯是每个需求单独开一轮对话每轮只改一个模块。虽然对话轮次变多了但每一轮的结果都稳定可用。第二用“输出完整HTML”而不是“输出修改后的代码片段”。这个习惯可能有点反直觉因为完整HTML文件会导致对话里出现大段重复代码看起来效率低。但这恰恰是AI生成最稳定的方式——它每次都在完整上下文中重新生成不会出现“只改了函数A但函数B还在引用老的变量名”这类前后不一致问题。你省下的复制粘贴时间远比修复这种隐性bug的时间少。第三给AI一个明确的“错误边界”。写Prompt时主动告诉它“如果某种情况发生应该怎样处理”。比如“如果玩家碰到树木停在原地不要移动”“如果倒计时归零停止所有动画循环”“如果生命值为0显示重新开始按钮”。AI在没有边界情况下生成的代码行为往往不可预测有了边界它就会在那些关键的if分支里写上实际逻辑。第四善用常量配置区。我在Prompt里总会加一句“所有可调参数移动速度、跳跃高度、道具数量、倒计时时长集中在代码开头的CONFIG对象中”。这样生成出来的代码天然有个“旋钮面板”之后调整游戏手感不用翻遍几百行代码找硬编码数字。这个习惯是我觉得最值回票价的。第五先在AI里跑通再谈优化。很多人习惯一上来就让AI生成一个“很完美”的游戏结果Prompt写了500多字AI犯迷糊生成的代码要么语法错误一堆要么压根没法看。我的做法是先跑通最基础的版本——角色能动、道具能捡、碰到敌人会结束——然后再一轮一轮地把音效、血条、触屏、阴影效果加进去。每一轮改动都建立在已验证的基础上出问题了也知道是最后一轮引入的。我用这套方法在不到两周的时间里做了十多个可运行的小游戏原型躲避障碍的、收集金币的、双人对战的、带简单追捕AI的。每一个都经历了从Prompt到代码、从跑通到调优的完整循环。这个过程最大的心得就是AI生成代码的能力已经足够强大真正决定效果上限的是你给它提供的上下文质量和需求拆解粒度。