我最近把一个很“标题党”的想法真的落地了向顶级模型要了一句话让它直接写出一款能玩的类QQ飞车赛车游戏。最后的成品是一个独立的 HTML 文件在浏览器里双击就能跑方向键控制赛车能加速能刹车弯道里可以漂移有 AI 对手在赛道上竞速跑完一圈会显示成绩。整个过程我没有手写过一行游戏逻辑所有代码全部由AI生成我做的只是拆需求、喂提示词、跑测试、再把报错信息丢回去让它自己修。这个实验能成但不代表AI已经能凭空变出3A大作。恰恰相反越是玩到后面越会发现简单的一句话背后少说了很多默认前提赛道画成什么样才不算玩具车子的转向和漂移手感怎么才算“像飞车”碰撞检测用圆形还是矩形竞速计时以什么为基准这些问题都有无数种答案AI猜错了游戏就会变成“能打开但不能玩”的半成品。所以我这篇东西重点不是吹“AI多牛”而是想复盘“我怎么把一句话拆成十几个小问题再让AI逐个解决”的完整过程。适合看这篇的朋友我觉得主要是三类想用AI快速做游戏原型验证玩法的人做活动页、外包Demo时想省掉从零手写时间的人以及单纯对“大模型生成代码”能力边界好奇的人。你能从这里拿到的不是某一段可以直接抄走的代码而是一套方法怎么在一句话的约束下把需求表达得足够精确让AI产出一个可运行、可迭代、可交付的东西。1. 项目概述把“一句话生成赛车游戏”当真了1.1 那句话到底是怎么写的我给模型的那句话原话差不多是这样的“帮我写一个网页版赛车小游戏玩法参考QQ飞车用Canvas渲染玩家用上下左右方向键控制赛车赛车能加速、刹车、左右转向和漂移漂移有轮印特效赛道是俯视角有直道、弯道、路肩和发卡弯再加两辆AI对手车一起竞速游戏里要有倒计时和单圈计时界面要简洁带开始按钮和成绩结算所有代码整理成一个HTML文件打开浏览器就能运行。”这确实是一句话但信息量并不少。它能成功不是因为模型懂“QQ飞车”这个牌子而是因为它把技术栈、视角、核心交互、竞速规则、交付形式这五类信息都包含进去了。我后来仔细拆过这句话发现里面其实藏着至少十几个默认要求画面每帧要重绘赛车有速度、方向、位置三个状态漂移本质上是转向与速度的耦合AI对手需要有路径计时从按开始键触发结算页面要显示成绩。如果一个普通开发者拿同样的话去问模型得到的代码大概率也能跑但细节会非常不一样。所以“一句话”是营销式说法准确地说应该是“语义密度很高的一句话”。真正厉害的不是模型会写代码而是它能在这么短的输入里推断出足够完整的实现方案。这背后靠的是大模型在大量游戏代码和网页Demo上学到的先验知识而不是什么神奇的“游戏生成引擎”。1.2 为什么选赛车游戏当试金石我选赛车游戏是因为它正好踩在大模型代码生成的舒适区和盲区交叠处。一方面赛车Demo在开源社区里太常见了模型肯定见过大量相似样本不至于生成一堆毫无章法的代码。另一方面赛车游戏又比待办清单、计算器这类“CRUD应用”复杂得多它需要实时更新、物理模拟、碰撞检测、玩家输入、动画渲染和状态管理同时跑通。任何一环出问题游戏就会立刻拉胯很难用“反正逻辑是对的”来糊弄。具体来说一个能玩的赛车游戏要处理的事情包括读取键盘事件并忽略默认行为维护一辆车的世界坐标和朝向用三角函数把速度和方向分解到x、y轴在每一帧用 requestAnimationFrame 更新画面绘制赛道背景、路肩、车辆和漂移轨迹检测车辆与赛道边界的碰撞处理AI对手的路径跟踪在计时和圈数上做状态切换。这里面有数学、有图形学、有时序控制还有看似不起眼但极其影响体验的“帧率稳定性”。选择一个足够复杂的项目来测试AI还能看出模型在“局部修改”和“全局重构”之间的平衡能力。第一版代码生成后我不可能只用一句话让它全推翻重来更多时候是让它加功能、修Bug、调参数。每一次修改都可能导致另一处功能静默损坏这种问题正好能检验模型对代码上下文的记忆能力。我在实验里用这招测出了不少有意思的现象后面会详细说。1.3 “能玩”的三个验收红线为了避免“AI写完了跑起来了但根本没有游戏性”这种表面成功我一开始就给自己设定了三条验收红线。第一打开HTML后用户要在三秒内进入可操作状态不能在黑屏和加载动画里卡半天。第二赛车必须有明确的加速感、减速感和转向惯性不能一按方向键就瞬移也不能松开键盘立刻停下来。第三漂移不能只是一个贴图或粒子特效它要改变赛车的过弯轨迹至少在视觉上呈现出“车尾甩出去再拉回来”的过程。这三条红线看起来简单实际执行时要靠“手感”来判断。说出来有点玄但玩游戏的人都懂车子转起来灵不灵活、过弯时有没有侧滑、碰墙后是立刻弹开还是陷在边界里这些都比一行行代码更诚实。我后来甚至让模型连续迭代了四次才勉强到了“我拿去给朋友试玩对方不会在第一分钟就关掉”的程度。2. 技术选型让顶级模型一次生成整个游戏的关键2.1 模型能力评估我不只需要“会写代码”的AI很多人以为只要把需求发给AI剩下的就是等结果。实际上模型选型直接影响最终产出是不是“能玩”。我在实验前评估了手边能用到的几个模型发现这类任务最关键的不是参数规模而是三点上下文窗口够不够长、代码生成稳定性高不高、以及在代码出错后能否根据报错信息进行自我修正。上下文窗口太小的模型很容易写到后面忘了前面的变量名。最常见的表现是前面用 car.x 和 car.y后面突然改成 playerX 和 playerY结果游戏一跑就黑屏。我自己在实验里遇到过这个问题后来只能一遍遍提醒“保持一致不要乱改变量名”。而能力更强的模型通常能一边生成代码一边保持命名一致性这种能力比“会写复杂算法”更值钱。我用的“顶级模型”并不神秘就是目前综合能力排在头部的大语言模型Claude、GPT、Gemini 这一档都可以。区别主要体现在细节处理上有的模型对美工描述的理解更好生成的界面更精致有的模型对物理反馈更敏感调出来的漂移参数更接近真实赛车游戏。所以如果你也想复现这个实验不用纠结于“必须用某一个”手头哪个强就用哪个重点是把需求说清楚。2.2 生成前先定技术栈Canvas还是DOM很多人会让AI“随便用什么技术”这是最容易翻车的点。AI一旦自由发挥可能给你生成三个分离的HTML、CSS、JS文件或者用DOM节点做赛车每帧操作一堆元素最后卡到没法玩。所以我从一开始就锁死了技术栈单HTML文件、Canvas渲染游戏画面、DOM用于开始界面和结算界面、JavaScript负责全部逻辑。为什么选Canvas而不是DOM因为赛车游戏的主场景是动态画面每一帧都要重绘赛车、赛道、漂移痕迹和AI对手。DOM节点天然就不适合这种高频更新当你每秒钟移动几十个元素浏览器的重排和重绘会直接把帧率拖垮。Canvas虽然上手门槛高一点但它作为“位图画布”就是为实时绘制而生的。大模型对Canvas绘图的样本积累也很足生成时犯低级错误的概率反而比用复杂框架更低。另外一个决策是“不用游戏引擎”。很多人会下意识想用 Cocos 或 Phaser但用这些框架就需要引入外部库、构建工具和资源加载流程和“单HTML文件”的目标冲突。No框架、单文件、浏览器原生API这套组合对AI来说训练样本最多生成结果最稳定。我的体会是AI生成代码的任务技术路线越接近“教科书里最常见的写法”成功率越高。2.3 Prompt结构一句话里藏着哪些必须信息开头那句话看上去就是一整段但我在心里把它分成了五个信息层。第一层是“做什么”指网页赛车游戏第二层是“用什么做”指定Canvas和单HTML文件第三层是“核心玩法”包括方向键控制、漂移、氮气、AI对手第四层是“表现要求”比如俯视角、路肩、漂移轮印第五层是“交付验收”意思是打开浏览器就能直接跑。如果你把五层信息全塞进一句话模型把握不住重点。我自己习惯用一段话而不是纯碎词先告诉它项目性质再给玩法细节最后写清楚“不要用什么”和“必须达到什么”。例如我会额外加一句“不要做登录系统不要引入任何外部库不要使用前端框架代码尽量控制在600行以内”。这些负面约束看起来像废话却能避免AI自作聪明地写出一堆过度设计。还有一个细节如果AI对某处理解有偏差不要只在聊天里说“不对”而是要说“玩家现在按左键时车子直接切向左边我希望它有一个渐进转向过程约0.2秒内完成”。给具体时间、具体数值、具体预期效果它才能生成能用的参数。我后来甚至把“转向平滑系数”“漂移摩擦力衰减”这些术语直接放进PromptAI立即就写出了更像样的代码。3. 实操全流程从Prompt到可运行游戏的踩坑实录3.1 第一版引擎AI给出的赛车模型长什么样第一代代码生成后我打开浏览器试玩发现AI给了一个所有内容都跑通的版本赛道是用Canvas画出来的灰色椭圆环带中央有白色虚线汽车是一个旋转方向随角度变化的矩形方向盘输入是简单的“左右键改角度上下键改速度”。车速被限制在固定的几个档位最高速和最低速之间切换非常生硬。但至少车会动画面上能看到一辆车沿着赛道转。我检查了核心代码发现AI用的是最经典的运动学模型用一个 angle 保存车的朝向speed 保存当前速度然后每帧计算车的位置变化。对应代码大概是这样的car.x Math.cos(car.angle) * car.speed * dt; car.y Math.sin(car.angle) * car.speed * dt;这个模型虽然简单但胜在稳定所有赛车Demo的基础都是从这行公式长出来的。AI没有选择“真实物理引擎”式的模型而是选择先跑通循环这说明它知道“第一版最重要的是让人能玩起来而不是让物理足够真实”。这一步的教训是别指望AI第一版就给你完美手感先让它把框架搭起来然后靠后续迭代调优。3.2 迭代一从“能跑”到“能漂移”第一版最能跑但没有速度感。我按一下加速键车速立刻到顶松开就掉到零完全不像赛车。于是我给AI提出第一个修改需求“加入平滑加速和刹车车速不是瞬间切换而是用加速度逐渐改变刹车时减速要更快并且松开方向键不会立刻停车而是靠滚动阻力慢慢降速。”AI很快把逻辑改成了这样除 speed 外新增 accelPower 和 brakePower 两个变量用 if 判断按键状态后把加速度累加到speed上。这样车子终于有了“油门踩下去慢慢提速”的感觉。不过另一个问题出现了转弯手感还是像“转盘子”车头能瞬间转到一个角度车身没有任何滑动。我意识到要真正有QQ飞车的触感必须引入“漂移”。我为这个需求给AI的描述是“增加漂移机制按住空格键或者Shift键时车子的转向幅度变大但车辆会失去一部分抓地力开始向原前进方向侧滑同时在地面留下轮胎痕迹几秒后渐渐淡出。” AI给出的方案是在漂移状态下引入 driftDriftFactor车速的方向不再严格等于车头方向而是车头方向与当前速度方向的插值同时在Canvas里绘制半透明的弧线当成轮印。从代码上看这就是在原来的运动学模型之上加了一个“速度方向”和“车头方向”分离的概念。实际效果比我想象中好弯道里按住漂移键车尾真的会甩出一个弧线出弯时松开按键方向会逐渐回正。那一刻我能明确感受到这不只是一个视觉特效而是一个真的会影响车辆轨迹的状态机。3.3 迭代二加入障碍、计时和AI对手有了单辆车能跑下一步就是让游戏变得像竞速游戏。我先让AI加入两辆AI对手车要求它们“沿着赛道中心线行驶速度比玩家慢一点但不会主动避让玩家碰撞后玩家会减速”。这里最麻烦的是生成“AI路径”。AI走的是曲线如果直接用椭圆方程算路径车辆过弯时会特别死板所以AI采用更简单的方式预置一个包含多个坐标点的数组AI车按顺序朝下一个点移动到达阈值距离后切换到下一个点。碰撞检测这里我踩了个大坑。AI最初用的是车辆矩形中心点之间的距离做碰撞判断导致两辆车明明重叠了也不算碰撞或者跑得非常近时突然被弹开。我让AI改用“圆形与矩形碰撞”的简化模型把每辆车近似为一个半径稍大的圆形赛道边界则用线段和车的圆心距离来判断是否越界。改完后碰撞手感至少不会让人觉得荒谬了。计时和圈数反而简单。AI在赛道某处放了一个看不见的“终点检测线”每次车辆穿过这条线圈数加一并记录当前时间。这里有个小问题如果车辆穿透检测线时速度太快可能一帧里从线前冲到线后导致一次跨线被计算成两次甚至多次。解决方法也很经典——不检查“是否穿过线”而是检查“上一帧到这一帧之间是否跨越这条线段”用两个位置的坐标差来判断。模型在这个问题上给出了一个可用的实现虽然代码不短但逻辑清晰。3.4 迭代三性能卡顿与移动端适配性能问题是紧接着出现的。因为每一帧要绘制赛道、路肩、赛道上的白线、四辆车、漂移轮印、起点线标记再加上开始和结算界面的DOM低帧率很快暴露出来。我让AI用Chrome的性能分析思路自查它给出的建议是把赛道背景等静态元素放到一个离屏Canvas上只重绘动态的车辆和轮印每帧用 drawImage 把静态层贴到主Canvas上。这个优化效果好得惊人帧率从明显的卡顿提升到了稳定60帧左右。另一个小优化是“控制粒子和轮印数量”AI给漂移轮印设置了最大数量旧轮印在超过20条后会自动移除防止内存越堆越高。这些优化看起来都是常规手段但如果没有模型主动提出我自己也不会在第一步就想到。移动端适配也被我列到了需求里。原来的代码只监听 keydown 和 keyup手机浏览器上根本无法控制。我让AI在画面左下角和右下角绘制两组触摸按钮一组是方向键一组是漂移键。为了让按钮不影响游戏画面AI用了“触摸事件阻止冒泡”和“基于坐标命中测试”的实现。虽然手机上的手感远不如键盘但至少能跑了。3.5 最终交付一个文件的游戏长什么样经过四轮迭代后最终交付物就是一个单HTML文件大小约38KB里面嵌入了内联CSS和所有JavaScript。打开文件后点击开始按钮进入游戏顶部有一条横排信息栏显示圈数、当前单圈时间和总时间赛车使用键盘上下左右控制空格或Shift激活漂移按住R键可以复位车辆到赛道中央走了三圈后触发结算界面显示总用时点击再来一局后重新初始化。这个文件不需要服务器、不需要安装依赖、不需要联网任何现代浏览器打开都能直接跑。我把它发给了几个朋友他们在手机上也能点开玩这已经算达到了“能玩”的标准。当然它不是《QQ飞车》但作为一个AI基于一句话生成的竞速游戏原型完成度已经超出我的预期。4. 高频问题与排查技巧4.1 每次改需求都会弄坏某个功能这是AI写代码时最典型的问题。你让它加一个“氮气条”它把原本控制漂移逻辑的一个变量名改了回头发现漂移特效没了。这种问题几乎每次都出现因为模型为了满足新需求会重构相关代码段但重构过程中偶尔漏掉其他位置对这个变量的引用。我总结出来的对策有三个第一每次提新需求前先明确告诉AI“不要改动与本次需求无关的函数”第二如果代码变复杂了要求AI在每次修改后用一句话说明它动了哪些函数方便我检查第三在聊天里保留任务上下文不要动不动就开新对话上下文一旦丢失模型就很容易出现变量名漂移。多次试下来这三点能显著降低“越改越坏了”。4.2 物理碰撞“看起来对但手感不对”有一种Bug最让人抓狂碰撞检测明明生效但玩家总觉得“被弹开的方式不合理”。比如车碰到墙后直接以高速反向弹开又比如碰撞到AI车时自己被震到原地打转。问题根源在于AI把碰撞响应简单写成“撞到就反弹到之前的位置”而不是“只抵消撞墙方向的速度分量”。我让AI改成“把速度投影到碰墙法线方向只保留法线方向的速度再施加减速系数”。听起来复杂其实就是一句话撞上边界后只让车停止在边界内部并减少沿墙方向的速度保留一定横向滑动这样玩家会感觉像“贴着墙滑过去”而不是“被弹飞”。如果你也遇到过类似手感问题优先检查碰撞响应代码而不是碰撞检测本身。4.3 页面白屏和“只有一个画面不动”的原因AI生成初期最让人崩溃的就是白屏而白屏的原因往往非常基础Canvas元素的宽高没有设置或者JavaScript的初始化函数写在页面结构之前。模型经常生成一段在底部执行的代码但开发者检查时忽略了脚本加载顺序。另一个常见情况是游戏画面停留在第一帧说明 requestAnimationFrame 循环没有正确启动或者初始化时出现了运行时错误导致循环中断。排查白屏有一个固定套路打开浏览器控制台F12看红色报错信息。AI代码里的错误信息通常很直白比如“Cannot read properties of undefined (reading getContext)”一看就知道是 canvas 变量没拿到对象。接下来检查是不是把获取 canvas 的代码放在了 HTML 渲染之前。如果是就把初始化逻辑挪到 window.onload 或 DOMContentLoaded 事件里问题基本消失。4.4 专家级避坑清单我最后归纳了一份更通用的自检清单装进脑子里之后再做类似AI生成项目时能省很多时间给AI定死“单文件、原生JS、无外部依赖”的交付要求。每一轮迭代只提一个核心改动不要一次性塞进五个新需求。每次修改之后都实际打开页面跑一遍别相信AI说的“应该没影响”。如果AI开始频繁改变量名立刻在Prompt里强调“保持上一版已有的命名一致”。在每轮修改后花两分钟扫一眼代码找到“这次新增了哪个函数”再去试玩。按照这个清单我后面做的几个AI生成Demo都顺利了很多不再是一边跑一边救火。5. 这次实验留给我的三点认知5.1 AI真正擅长的是“把框架补成成品”“从零写一个游戏”和“给出完整框架然后让AI填充”是两种完全不同的体验。这次实验里我并没有真正从零给AI下达需求而是用几句话暗示了一个非常标准的框架车子有坐标、速度、朝向赛道是Canvas绘制的闭合路径对手车存在一个路径点列表。这些听起来很基础但模型一旦接收到这些碎片就会主动补全为一个完整可运行的游戏。后来我意识到这个所谓的“顶级模型”真正厉害的地方不在于它能无中生有而在于它能把“半成品线索”迅速扩展成高质量的完整实现。换句话讲它像个特别熟悉传统赛车Demo写法的资深外包你给它几个关键词它就能照着以前的经验把整个骨架填满。这对我来说最有用的启示是想让AI写更复杂的项目我的职责不是写代码而是给出足够多的“框架性提示词”。5.2 Prompt写得好不如验收标准定义得好这句话是我这次实验最深的感受。你可以把Prompt写得很华丽比如“请生成一个具有真实物理引擎和动态光影的赛车游戏”但代码一跑你会发现它做不到甚至连一个稳定开放的页面都做不到。与其写一堆漂亮的形容词不如定义一条可以去验证的验收标准能不能用方向键控制能不能漂移出轮印能不能显示单圈计时能不能在手机浏览器里操作。这些标准一旦可验证AI就有方向感。所以我后来给AI提需求的句式改成了“请加入漂移功能。条件按住Shift时转向幅度变为1.6倍车速衰减速度变为原来的0.4倍并在地面留下轮印松开Shift后轮印在3秒内淡出”。这不是文学描述而是验收标准。模型接受这类“带条件的指令”时生成结果明显更稳定因为它的评测目标非常清楚只要满足这些条件就算做对了。5.3 人仍然需要学会读代码但不再是手写整个项目里我确实没有手打过一行游戏逻辑但如果我真的完全不会读代码这个项目做到第二步就会卡死。因为AI生成的碰撞检测是不是合理的漂移代码是不是真的会改变车辆方向性能优化的离屏Canvas方案是不是用了正确API这些都需要有人打开代码看一遍才能判断。读代码的价值没有消失反而变成了更核心的技能。这次实验也让我重新理解了“程序员被AI替代”这个话题。至少从我的经验看AI提高了生成效率但它需要人类去做需求拆分、验收定义、Bug定位和方向修正。不会读代码的人面对AI生成的几千行代码就像面对一个黑盒模型说“没问题”你就只能相信。而能读代码的人即使不自己写也能精准地告诉AI“错在第几行的第几个变量”。我认为这种“AI生成人类审查”的模式会越来越成为常态但这反而意味着基础的编程素养更值钱了。如果你也想试试这类玩法我的建议很简单先找一个你最熟悉的经典小游戏用一句话喂给模型然后按我上面的思路去拆需求、提修改、看代码。真把这一套跑下来你会对“AI能做什么”有一个比看任何演示视频都准确的判断。