一句话让AI写出可玩赛车游戏：提示词拆解与调校实录

昨晚我干了件以前想都不敢想的事给当前能力最强的那档AI大模型发了一句需求——“用HTML写一个能玩的网页版QQ飞车单文件浏览器直接跑”。发完之后我去接了杯水回来刷新页面屏幕上已经有一辆赛车在滚动赛道里跑起来了。这是我的真实经历不是标题党。AI编程从“补全函数”到“直接交付一个能玩的小游戏”中间那条鸿沟确实被顶级模型抹平了一大截。这篇文章我打算事无巨细地拆一遍那句话到底暗藏了什么结构AI交出的代码是什么骨架我第一次试玩时被哪些坑绊住、又是怎么用两轮对话把它调成“真想玩”的如果你正在研究提示词工程或者想用AI快速做一个小游戏demo这篇应该对你有用。文章里的提示词和代码我都按实测原样保留可以直接复制回去跑。1. 一句话出游戏先拆掉顶级模型的神秘光环1.1 它凭什么把一句需求变成几十个函数先泼盆冷水那句“帮我写一个游戏”能成功不是模型有魔法而是顶级模型在训练阶段看过海量真实项目源码。GitHub仓库、游戏开发教程、技术博客、Canvas小游戏集合这些公开代码构成了它“写代码接龙”的基本功。当你输入“HTML 赛车游戏”时它并不是凭空创造而是在概率上挑选一条最像“完整游戏”的续写路径。和早年那些“根据注释补代码”的工具不一样顶级模型经过指令微调和强化学习后学会了从需求到架构的映射。它知道“能玩”的背后意味着必须要有主循环、输入处理和渲染循环它知道“单文件”意味着所有代码必须塞进同一个HTML里不能用外链依赖。所以它交出来的不是零散片段而是一个互相咬合的小型系统。有一个细节特别能说明问题初版代码里甚至自带了requestAnimationFrame的降级处理——当浏览器标签页被切到后台再切回来时时间戳会发生跳变它用Math.min(delta, 0.05)把每帧最大增量卡死。这种坑很多刚入行的程序员都不一定记得但顶级模型在训练语料里见过太多次直接就写对了。如果你手头的模型现在还停留在“帮你写个冒泡排序”的水平多半不是它不聪明而是上下文管理没到位。把需求讲成“一份带验收标准的开发任务单”它就能从“补全者”变成“开发者”。这个差别文章后半部分会展开讲。1.2 QQ飞车这几个字等价于一张隐式需求清单很多人在这一步会犯一个错觉得把“QQ飞车”四个字丢给AI就是在提需求。其实这四个字对顶级模型来说是一个高度压缩的需求包。模型训练数据里有大量关于这类赛车游戏的玩法描述它听到“QQ飞车”时自动补充的特征大概是这样我脑子里闪现的需求AI自动映射到的功能模块赛车竞速玩家控制的赛车、滚动赛道、障碍物漂移转向时的侧滑轨迹、轮胎痕迹、速度变化氮气加速加速道具或按键触发的最高速度状态竞速感圈数、单圈计时、总里程、结束结算视觉刺激速度线、尾焰、路面纹理滚动不过有一点必须讲清楚AI理解的“QQ飞车”是它训练数据里关于“这个游戏玩法的普遍描述”不是真的把原版资源拆出来搬运。所以我实际让它做的是一个“参考QQ飞车玩法的简化赛车demo”。这正好让版权问题变得简单——你最后跑起来的是一个形似神也似的独立小游戏不含任何商业素材的直接拷贝。这个“隐式需求展开”能力是顶级模型和普通模型的分水岭。普通模型只会执行显式指令你说画车它就画个矩形它会忽略“赛车游戏”里隐含的速度感、碰撞、胜负条件。顶级模型则会自动把“能玩”翻译成“要有游戏循环”把“QQ飞车”翻译成“要有漂移和竞速”。这就是为什么标题说的是“顶级模型”——换一个参数较小的模型同样的提示词大概率跑不出可玩结果。1.3 那条一句话提示词的完整原版和逐句拆解我实际发出的提示词是一句非常长的话整理之后大概长这样用HTML、CSS、原生JavaScript写一个单文件赛车游戏网页玩法参考QQ飞车。要求竖版画面赛道从屏幕顶部向下滚动玩家用方向键或WASD控制赛车左右移动、上下加速/减速赛道上有障碍车流撞上会减速但不直接结束有加速带漂移时显示轮胎痕迹右上角显示单圈计时器、当前圈数和总里程跑完3圈自动弹结算界面。代码写完整不要省略关键函数给我一个可以直接复制保存为HTML文件的输出。这句话看似随意其实每一段都藏着验收标准“单文件”——决定了零依赖、零部署双击就能跑也卡死了AI不要搞外链CDN。“竖版画面、赛道滚动”——这是AI最熟悉的经典游戏范式它可以直接复用训练语料里成熟的结构而不是设计一套复杂的3D地图。“撞上会减速但不直接结束”——明确死亡规则避免AI脑补成“撞一下就Game Over”的传统街机玩法。“有加速带”“漂移时显示轮胎痕迹”——这已经是在给美术和手感提需求了AI会知道要引入“状态标记”和“粒子效果”。“代码写完整不要省略关键函数”——这句话非常重要。很多模型答数学题会跳步骤写代码也会用注释糊弄加这句能强制它把update、render、checkCollision全部实装。如果你用的模型没那么强可以把“一句含多个分句”拆成“一条主指令 五条编号要求”。但顶级模型能直接吃下整段所以我一直保留这个“一句话”的舞台效果。2. 拆AI的第一版作业代码骨架与首次试玩2.1 AI为什么执着于HTMLCanvas这一套我见过很多人让AI写游戏第一反应是“用Python因为我学过Python”。结果AI生成了一段需要安装Pygame、配置虚拟环境、还得手动调窗口的代码光是环境搭建就劝退了。而这一次AI几乎没犹豫就选了HTML CSS 原生JavaScript Canvas我事后想了想这个选择太合理了。技术栈启动门槛AI生成成功率移动端/分享Python Pygame需安装Python和pygame环境坑多中等基本为0Unity / Godot需下载引擎、创建工程、资源管线复杂低一般HTML CSS JS 单文件双击HTML即玩零安装很高手机平板浏览器通吃关键原因是顶级模型的训练语料里“单文件Canvas小游戏”是极常见的模板。从贪吃蛇到飞机大战从打砖块到赛车躲避这类代码结构高度相似AI等于在复制一个它写过无数次的经典范式。所以想让AI产出“能玩”的结果先给它一个“最容易成功”的载体比逼它上重型引擎聪明得多。还有一个现实优势HTML文件不需要网线就能跑发给同事、丢进群里、传到服务器上都是一个哑文件。对快速验证一个游戏点子来说没有比这更低摩擦的发布方式了。2.2 主循环、按键、碰撞三个核心模块的实际代码AI生成的第一版代码虽然谈不上精致但骨架扎实。最核心的三个模块值得单独拿出来看因为它们决定了“能不能玩”。第一个是主循环。所有游戏都有一个“每一帧更新一次世界状态、再重绘一次屏幕”的循环AI用的是requestAnimationFramelet lastTime 0; function gameLoop(timestamp) { const delta Math.min((timestamp - lastTime) / 1000, 0.05); lastTime timestamp; update(delta); render(); requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);这里最妙的就是Math.min那一步。它限制了一帧的最大时间差防止用户把页面切到后台很久再切回来时游戏把“缺失的几秒”一次性补偿掉导致角色瞬移穿墙。这种保护不显眼但没有它后面的穿模问题会提前爆发。第二个是键盘输入。AI没有在keydown事件里直接改坐标而是维护了一张按键状态表const keys {}; window.addEventListener(keydown, e { keys[e.code] true; if ([ArrowUp, ArrowDown, ArrowLeft, ArrowRight, Space].includes(e.code)) { e.preventDefault(); } }); window.addEventListener(keyup, e { keys[e.code] false; });为什么要这样因为如果直接在keydown里移动按住方向键时会有一顿一顿的现象操作系统默认的按键重复会干扰手感。先记录“哪个键被按住了”再在每帧update里读取状态按住和松开都在帧节奏里生效操作才会连续。preventDefault也很关键不然按方向键时浏览器页面会跟着滚动。第三个是碰撞检测AI用的是最经典的矩形包围盒function checkCollision(a, b) { return a.x b.x b.width a.x a.width b.x a.y b.y b.height a.y a.height b.y; }四行代码判断两个矩形的边界是否重叠。它不考虑物体形状不考虑旋转但对一个简化版赛车游戏来说性能好、直觉、够用。2.3 第一版试玩实测能开但没有赛车游戏的魂代码在浏览器里打开的那一刻我是有点激动的——游戏真的能跑。但真正上手玩了30秒激动就变成了“就这”的尴尬。我做了一张试玩检查表问题一目了然测试项第一版结果现象描述启动通过双击HTML直接可玩加载零延迟键盘控制通过方向键/WASD都能响应碰撞减速部分通过低速撞车会减速满速时经常直接穿过去漂移表现未实现没有轮胎印转弯只是整车平移圈数结算未实现右上角只有里程没有圈数和结算手机触屏未支持触摸屏幕没有任何反应“能跑”和“能玩”之间隔着一个大峡谷。我当时心里想的是这个版本如果拿给朋友看对方多半客套一句“不错”然后就不再打开。但换个角度看AI用一条消息就把游戏的原型骨架搭完了剩下的问题全是可以在对话里继续修的。接下来就是两轮调校的过程。3. 两轮调校实录从能跑到真心想玩3.1 穿模事故一场关于数值尺度的排错最影响体验的Bug是穿模。我把车速提到最高对准障碍车头撞过去有时候会直接“透传”就像赛车变成幽灵车一样。一开始我以为是AI写的碰撞逻辑有误但打开代码检查checkCollision四个条件写得清清楚楚没有运算错误。我按排查链路往下走先把车速调低低速时碰撞正常再把障碍物加厚穿模概率明显下降。这时候基本锁定了问题的本质——不是逻辑错而是“数值尺度”错。车速约为300像素每秒如果帧率掉到30帧每一帧车子要移动10像素而障碍物厚度可能只有8像素。碰撞检测只发生在每一帧结束的那一刻如果这一帧结束前车身还在障碍左侧、下一帧开始后车身已经越过障碍右侧那两次检测之间就“跳过”了整个障碍。物理引擎里这叫“隧道效应”。解决办法不是把碰撞盒子做大而是用“子步进”把一次大位移拆成许多小位移function update(delta) { const speed player.speed; const maxStep 2; // 每小步最大位移不超过2像素 const steps Math.max(1, Math.ceil((speed * delta) / maxStep)); const subDelta delta / steps; for (let i 0; i steps; i) { movePlayer(subDelta); checkAllCollisions(); } }把一帧拆成若干小步每一步最大位移控制在2像素以内碰撞检测就不会再“跳过”薄的障碍物。这个思路不仅适用于AI生成的游戏你自己写碰撞检测的时候同样会遇到属于那种“不亲自踩一次就记不住”的坑。3.2 补全圈数结算AI漏掉终点的逻辑第一版代码里没有“圈数”只有累计里程。原因在于竖版无限滚动的赛道没有物理意义上的“终点线”AI默认把游戏做成了“无尽模式”。但这个和我的原始需求“跑完3圈自动结算”矛盾了。我没有直接说“你漏了圈数”而是给了一个明确的实现路径“用总里程模拟赛道周长当里程达到一圈长度时圈数加1并重置单圈计时当圈数超过3时切换到结算界面。”为什么用累计里程而不是画一条终点线因为滚动赛道的“终点”不是一个坐标而是“里程累计到某阈值”这个状态。想清楚这一点需求才真正可编码。AI很快在update里加了这段逻辑const trackLength 2000; // 一圈对应的总里程 player.totalDistance player.speed * delta; if (player.totalDistance trackLength) { player.totalDistance - trackLength; player.lap; resetLapTimer(); if (player.lap 3) { showResultScreen(); } }这个补充看起来简单但它点醒了我一个通用方法对于AI生成的“缺乏终点”的游戏需求不要只说“加个终点”要把“终点某个可测试条件”这件思考一并告诉它。提示词里多给一步“状态的判定条件”AI就能少跑一次偏。3.3 触屏支持把提示词里没说的平台补齐第一版只在键盘上能玩我在电脑上测试没问题但把文件发到手机里一摸屏幕完全没反应。手机浏览器的用户遇到这个游戏第一反应就是用手点屏幕而我提示词里完全没有提触屏AI当然不会主动写。这一轮我给的补充提示也很直接“增加手机触屏支持屏幕左半部分触摸时赛车左转右半部分触摸时右转屏幕上滑加速下滑刹车同时检测触摸开始和触摸结束事件避免手指离开后按键状态残留。”用触摸事件模拟按键状态本质上就是把keys那张表换成触摸版。canvas.addEventListener(touchstart, e { const touch e.touches[0]; const cx touch.clientX; const half window.innerWidth / 2; if (cx half) keys[ArrowLeft] true; else keys[ArrowRight] true; keys[ArrowUp] touch.clientY window.innerHeight / 2; keys[ArrowDown] touch.clientY window.innerHeight / 2; }); canvas.addEventListener(touchend, () { keys[ArrowLeft] keys[ArrowRight] false; keys[ArrowUp] keys[ArrowDown] false; });这个例子说明了一个提示词技巧如果需求里涉及使用场景一定要把“平台”显式写出来。你没说的环境AI默认是它训练数据里最常见的桌面浏览器。我后来写游戏类需求都会在开头加一句“目标平台是桌面浏览器和手机浏览器”就再没为触屏翻过车。3.4 第二轮Prompt当手感被翻译成状态机第一轮修完后游戏已经“能玩”了但离“好玩”还差一大截。问题在于转弯没有漂移感整车就是直愣愣地左右平移和玩计算器上的贪吃蛇差不多。第二轮我给的提示词开始“要手感”了基于现有代码继续改不要推翻重写。增加漂移手感当玩家按住方向键快速转弯时赛车进入漂移状态车头旋转速度变快赛道留下轮胎痕迹漂移中松开方向键赛车会有一段回正滑行车速超过一定值时屏幕边缘出现速度线HUD轻微抖动撞到赛道边缘路肩时减速并伴随闪烁反馈。对比第一轮的提示词这轮的关键在于我把“手感”翻译成了“状态机”。AI对“漂移”这类抽象词容易给出一个看着复杂但跑起来很假的实现但如果你拆解成“快速转弯时进入漂移状态”“松开后回正滑行”它就能用布尔状态和参数去编码。AI实际做了一件很聪明的事它给车加了driftAngle和isDrifting两个状态量用加速度计的转向输入来触发漂移用轮胎痕迹数组保留最近几十个坐标点每帧往Canvas上画一串半透明圆形。整个逻辑不复杂但效果一下就上来了。如果你想让AI一口气实现复杂手感记住一个原则一次只加一个核心系统。我同时让它加漂移和加摄像机抖动它做到了但也把粒子数组写成了从不清理的无限数组——这个埋下的雷下一节会说。3.5 把AI当结对程序员三条通用调校技巧调校过两轮之后我总结出了三条非常实用的对话技巧基本每次都能让AI稳定产出更好的代码。第一给反馈时给参数不要给感受。说“转弯太肉了”不如说“转向灵敏度从0.3调到0.5”。AI对参数是敏感的对形容词是无感的。你在提示词里给出具体数值它连搜索空间都不用做直接改数就完事。第二一次只改一个点。把“加漂移”和“加碰撞优化”放同一句话里AI也能完成但万一出了问题你根本不知道是哪次改动引入的Bug。分开提每次跑一遍验证排错成本指数级下降。第三让AI review自己的代码。把整个文件丢回去说“请检查这版代码找出可能导致碰撞失效、掉帧和内存泄漏的问题指到函数名一级。”这个用法经常被忽略但效果极好。有一次它主动指出漂移粒子的数组没有上限每帧往数组里塞新粒子却从不清理长时间玩下来内存占用会一直涨。我加了一个超过200个就覆盖最老粒子的限制掉帧问题立刻缓解。这三条看起来简单但在真实的工作流里非常能打。很多人觉得AI写代码“不靠谱”其实不是模型不行而是沟通方式不对——把AI当成一个记性很好但不懂人情世故的结对程序员一切就都顺了。4. AI写游戏的边界哪些省了哪些省不了4.1 单文件小游戏是舒适区长线项目会散架测试完调校环节我得说一句公道话AI写游戏这件事有非常明显的边界。它适合“30秒到3分钟玩一轮”的单一循环游戏因为这类游戏的核心逻辑就三件事——输入、更新状态、渲染画面。AI可以在一段代码里同时管理这三件事不会乱。但如果你想要的是一款有十几个关卡、每个关卡有不同机关和敌人、还需要存档和升级系统的“正经游戏”AI生成的那一大坨单文件代码很快就会变成一座捉襟见肘的积木塔。原因在于AI是“一次性全景生成”它没有做接口设计和模块边界。你在代码里想改某一关的出怪逻辑会发现这个逻辑和主角血条、战斗动画、存档初始化全都耦合在一起。我的建议是用AI快速产生原型验证玩法好不好玩一旦验证通过、准备认真做长线产品就该交给人类工程化重写按模块拆分、写测试、做资源管线。AI负责从0到1人类负责从1到100。4.2 美术、音效、性能三件必须人工兜底的事这一版游戏里所有的视觉元素其实都是Canvas几何图形车身是圆角矩形、轮胎印是半透明圆形、云朵是几团白色弧形。这种“几何图形拼出来的画面”当原型没问题但离上线级美术差得很远。想要真正的赛车模型、路面纹理、引擎声浪和撞击音效AI在这一步只能帮你生成素材占位真正要好看的画面还得靠美术或者更专业的AI绘图工具生成素材再手动接入资源管线。性能调优也一样。我试玩过程中当粒子和障碍物数量变大手机浏览器里明显出现掉帧。Canvas游戏的优化三板斧——对象池、限制粒子数量、减少每帧绘制调用次数——AI不会主动帮你做你得自己动手或者明确提示它去优化。比如把粒子上限设为200、将多个静态障碍的绘制合并成离屏Canvas缓存都是很常见的人工介入。这么说吧AI能帮你省掉“从无到有写出一个可玩原型”的时间但“从能玩到精良”的那条路每一步都需要人的判断。手感是不是爽、画面是不是高级、在不同设备上是不是流畅这些没有量化标准的问题AI目前还顶不上去。4.3 这个工作流对真实项目的价值效率、原型和试错既然如此这套工作流到底有什么实际价值我的答案是它把“验证一个点子”的成本降到了几乎为零。以前我想试一个类似QQ飞车的漂移手感至少要规划一晚上写代码、调碰撞、加UI熬到凌晨还不一定跑通。现在整个流程变成我输入一段提示词等两分钟得到一个能跑的游戏花五分钟把穿模修掉再花十分钟调一下手感然后就能发给团队里其他人试玩了。这个过程里省下的不是“写代码的时间”而是“决策前置的时间”——你终于可以在投入大量精力之前先感受到这个游戏“到底好不好玩”。我身边已经有不少同事把这个流程用在黑客松快速原型、内部工具演示、甚至编程教学案例里。我自己现在做小游戏的基本习惯也固定成了三步AI生成初版代码我手动调核心手感和玩法数值再把外围UI、结算页、音效这些“不太需要手感”的部分交还给AI去补。AI不是替你写游戏是替你省掉从零到一那段最枯燥的体力活。这篇文章最后再多说一句实在的如果你要复现我整个过程不用纠结是不是“顶级模型”——能力越强的模型成功率越高但更关键的是你是否像上面这样把需求拆成可验收的清单、把手感翻译成状态机、把排错链路一条条走通。掌握这个方法即使换一个稍微弱一点的模型也能多给它几轮反馈把它调出来。AI写游戏这件事真正值钱的部分从来不是那一句提示词而是你脑子里关于“游戏怎么做才好玩”的判断力。