最近打开社交平台又被一个演示刷了屏某个顶级模型只凭一句提示词生成了一版能玩、能漂移、能撞车的“QQ飞车”式竞速小游戏。评论区一半人在喊“AI要取代程序员”另一半人觉得“不过是个demo”。作为一个常年拿大模型当结对编程搭子、也踩过无数生成式代码坑的人我更在意的是另一件事那句提示词到底是怎么写的模型究竟听懂了什么又是靠什么能力把“一句话”撑成了一个完整可玩的游戏这篇复盘不是标题党复述而是我基于自己反复实验的经验把这次“一句话生成QQ飞车”背后的提示词构造逻辑、游戏代码生成的真实难点、以及从单轮生成走向多轮协作的技术路径完整拆一遍。无论你只是好奇AI能不能写游戏还是想在自己的项目里复刻这种能力这篇对你都应该有实际参考价值。1. 为什么“一句话生成游戏”是检验AI编码实力的标杆老读者应该知道我平时不怎么追“AI一觉醒来又学会了XXX”这类热梗。但“顶级模型一句话写出能玩的QQ飞车”这个case我确实认认真真看了几遍。原因很简单游戏生成尤其是竞速类小游戏是AI编码能力里一块非常难啃的试金石比生成一个待办事项列表或者登录页要硬核得多。1.1 为什么偏偏是游戏而不是CRUD很多AI编程演示选的都是“管理后台”“电商页面”这类模板化场景。这类代码对模型来说太“熟”了训练语料一抓一大把拼凑痕迹明显跑通了也说明不了太多。但游戏不一样尤其是赛车游戏它至少同时踩中四个难点物理逻辑车的速度、加速度、转向、摩擦、漂移、碰撞后的反弹这些不是简单if-else能糊弄的需要基本的运动学计算。状态管理与渲染循环requestAnimationFrame怎么驱动画面刷新、游戏状态怎么在不同阶段准备、疾驰、过线之间切换。输入响应键盘事件绑定的准确性、按键延迟与帧率匹配度、组合键比如方向氮气的处理。可玩性设计跑道不会太宽也不会太窄、对手车AI不会一头撞墙、道具点位置合理这些是“能跑”和“能玩”的分水岭。所以当模型能仅凭一句话把上述要素全部串起来至少说明了两点第一它对游戏开发的标准范式理解很深第二它的指令跟随能力已经能把一句高度压缩的意图展开成上千行彼此依赖的代码而不至于在中间某个环节自相矛盾。这两点正好就是提示词工程最关心的核心能力。1.2 一次生成背后的“假象”与“真相”很多人听完“一句话生成游戏”会觉得模型像开挂一样脑子里面已经装了一整套游戏引擎。真相没那么玄乎。模型靠的是大规模代码语料训练出来的“条件概率补全”本质上是在拟合“类似的提示词通常对应什么样的代码结构”。但拟合不等于理解。我实测过很多类似场景结论是顶级模型一次性生成代码的成功率确实比普通模型高出几个量级但这个“成功”建立在一个前提上——提示词描述得足够精确。提示词里哪怕一个关键信息缺位比如“跑道要有边界”没写明模型就可能生成一辆能穿墙的赛车再比如“按R键重置车辆”没说明玩家跑出赛道后就只能刷新页面重来。这就是为什么我要把这次“一句话生成QQ飞车”拆开看。表面上是模型厉害实际上是提示词工程把模型的潜力榨干了。接下来我直接结合实际提示词逐块讲清楚它是怎么被设计出来的。2. 拆解那句“一句话”背后模型到底听懂了什么网上流传的原始提示词我无法百分百考证但根据复现效果和我自己的调优经验可以相当确定地重构出它的核心结构。大致是这样一句话“请用纯HTML/CSS/JavaScript在单个HTML文件里实现一个类似QQ飞车的俯视角竞速小游戏包含赛车、赛道、弯道、对手车、氮气加速、漂移手感、碰撞检测、键盘方向键控制画面简洁但完整刷新后可重新开始。”看似只是一句话其实里面塞了五层信息。我把它们拆开逐一分析。2.1 载体约束从技术栈到交付形态“纯HTML/CSS/JavaScript”“单个HTML文件”这看起来像是随口说出的限制实际上是对整个生成过程的硬约束。它帮模型锁死了四条路不允许想到用Python游戏引擎不许引入需要构建步骤的框架。不许生成服务端代码单文件意味着所有游戏逻辑必须跑在浏览器端。不许依赖外部图片资源车和赛道都要用Canvas或DOM绘制这直接影响了美术实现方式。交付形态被钉死为“拿到手就能双击打开跑”省去了环境配置这一步。我自己的经验是如果提示词里不写“单个HTML文件”模型会倾向于拆成index.html、style.css、game.js三个文件。倒不是说三个文件不行但对验证类demo来说单文件极大减少了调试噪音。这种约束词在提示词工程里叫“交付物限定”它体现的不是技术偏见而是对验证成本的清醒认识。2.2 玩法对象清单让模型知道“需要造哪些东西”接下来是“赛车、赛道、弯道、对手车、氮气加速、漂移手感、碰撞检测、键盘方向键控制”。这串名词看着朴实但它其实是对象清单。模型生成代码时会以此为依据建立类或者模块划分。注意这里的高明之处它没有说“实现一个赛车游戏该有的功能”而是用具体名词把需要生成的实体挨个点了名。这就好比你去餐厅点菜与其说“来点好吃的”不如说“一份宫保鸡丁、一份米饭、一碗紫菜蛋花汤”。名词越具体模型对要生成的代码结构越明确。在实际复现中我发现对手车很容易被模型做成静止不动的装饰物。原因很简单让NPC车移动涉及自动寻路、速度控制和碰撞避让比生成一辆玩家控制的车复杂得多。所以提示词里“对手车”三个字就成了一根保险丝凡是听话的模型都会主动给它安排移动逻辑区别只在移动得笨还是聪明。2.3 手感词是“可玩性”的最大变量“漂移手感”这四个字是整个提示词里最微妙的部分。它不是功能而是体验指标。模型没有标准答案来对应“手感好”到底是什么只能靠训练时见过的无数游戏代码去猜测可能需要给赛车加一个摩擦系数、一个转向角增量、一个侧滑偏量、一个速度损失曲线。我实测过不带“漂移手感”和带“漂移手感”两种版本。不带这个词时车辆转向像坦克转弯几乎原地掉头毫无惯性可言带上之后模型会主动加入类似“速度越快漂移时横向偏移越大”的属性方向键回中后再慢慢恢复抓地力。这就是提示词工程里常说的“质量属性显式化”——你想要什么体验最好在提示词里说出来否则模型只会给你一个功能正确但体验平庸的东西。2.4 验收标准可运行、可重启、可重来最后那句“画面简洁但完整刷新后可重新开始”也同样关键。没有这句话模型往往会生成一个“只能跑一圈冲线之后页面卡死”的游戏。因为你没告诉它冲线之后该干什么。“刷新后可重新开始”本质上是把重置逻辑写进了需求。懂游戏开发的都知道一个可玩小游戏必须包含状态重置碰撞飞出赛道后要能回位比赛结束后要能重新发车。这句话逼着模型在游戏循环里加入初始化函数而不是把所有变量一股脑塞在顶层脚本里。底层变量一旦封装不到位刷新也救不了刷新本身就是最原始的重置方式。2.5 关键要素的权重排序我根据复现经验把提示词里的要素按“缺少后破坏性程度”做了一个排序提示词元素缺失后果破坏等级单HTML文件交付物分散验证成本高中碰撞检测穿墙、串车游戏逻辑崩坏高对手车赛道冷冷清清失去竞速感中漂移手感手感僵硬可玩性打折高刷新重置无法重复游玩中键盘控制游戏没法操作极高这也印证了那句老话提示词不是越长越好而是关键约束一个都不能少。顶级模型之所以能用“一句话”写出好游戏不是因为它读心而是因为那句话恰好把决定成败的约束点全部打中了。3. 从“能跑”到“能玩”赛车游戏最容易翻车的六个地方提示词再精准第一次生成的代码也几乎不可能完美。我反复跑过类似项目每次都要经历一遍“能打开、能操作、但哪里不对劲”的阶段。这一节我聊聊竞速游戏生成里最容易翻车的地方以及我实际遇到后是怎么修回来的。3.1 碰撞检测最常见的“穿模事故”很多新手以为碰撞检测是高端物理引擎才有的东西其实一个俯视角赛车游戏需要的碰撞检测非常朴素判断车和赛道边界是否有交集。生成代码最常见的方案有两种一种是基于坐标比较的矩形碰撞一种是基于距离判定的圆形碰撞。最容易翻车的是赛道不是矩形而是带有弯道的封闭曲线。如果模型偷懒把整个画布四边当成赛道边界玩家车就会在跑道内侧草地上如入无人之境。要解决这个问题我通常会在提示词里追加一句“赛道由路径坐标数组定义车辆必须限制在路径宽度范围内”。这一句就够了模型会立刻切换到多边形碰撞检测方案。3.2 物理参数不协调要么飞天要么蜗牛第二类高频翻车点是油门、摩擦、转向这几组参数互相不匹配。典型的例子最大速度设了800摩擦力却只有0.01结果油门一按车子直接飞出去或者转向角增量写得太陡速度一快就原地陀螺。我习惯的修法是把参数集中到一个配置对象里手动调。这里分享一组我调得比较顺的初始参数适合俯视角小赛车const physics { maxSpeed: 6, acceleration: 0.15, friction: 0.92, turnSpeed: 0.045, driftFriction: 0.85, collisionBounce: 0.6 };friction不是减法的绝对值而是乘系数这样速度接近0时会自然收敛不会出现倒溜。turnSpeed是小数值乘到方向输入上避免键盘按下瞬间角度跳变。这套参数不是模型凭空想的是我在浏览器console里一帧一帧试出来的生成代码里如果能直接带上这三个数值手感基本不会太垮。3.3 键盘事件忘了阻止默认行为俯视角赛车游戏通常用上下左右方向键控制。方向键在浏览器里是有默认行为的——滚动页面。如果代码里只监听了keydown却忘了e.preventDefault()就会出现一边开车一边往下滚页面的诡异场面。这个问题我在多个模型生成的代码里都遇见过修法不复杂window.addEventListener(keydown, (e) { e.preventDefault(); keys[e.key] true; });但这里有个细节容易被忽略如果页面里还有其他表单元素全局阻止默认行为会影响它们的键输入。对单页游戏来说问题不大可养成“只在游戏区域监听键盘事件”的习惯总归是更稳的。3.4 帧率分离游戏速度不该依赖设备性能很多AI生成的赛车游戏逻辑直接在requestAnimationFrame循环里跑每帧固定位移。这个写法的隐患是高刷新率显示器上每秒跑120帧游戏速度快一倍低帧率设备上则卡成慢动作。正确做法是引入时间差deltaTime。模型初代代码很少主动这么做而我一般会在测试时用一条补丁提示词把它改过来“所有位置增量必须乘以deltaTimedeltaTime由两帧间隔计算并限制在0.05以内防止异常。”这一条补丁能显著提升跨设备的一致性也让生成游戏从“在我的电脑上能玩”升级为“换了电脑也能玩”。3.5 AI对手车不会超车不会避让对手车逻辑是“能玩”和“好玩”的分界线。模型生成的NPC车最高频做法是沿固定路径匀速直线行驶弯道也不减速。于是玩家看到的画面就是几辆车排队走位你轻轻松松从弯道内侧超过去。要让对手车有点竞速感我通常会在提示词里补充一个简单规则“对手车沿路径点行驶在弯道前按路径曲率降低速度玩家车距其小于50像素时向侧面偏移避让。”后者尤为重要它让NPC车具备了“看见玩家”的反馈能力。虽然仍然谈不上智能但至少不会像个纸片一样跟玩家穿模重叠。3.6 画面节奏缺少动态反馈最后一个大翻车点是画面缺乏反馈感。模型默认生成的画面常常是车在动、背景静的像贴图。没有速度线、没有轮胎印、没有氮气火焰。玩起来总觉得没劲。如果你想让生成的游戏更像“QQ飞车”最有效的其实是视觉反馈。我推荐在提示词里要求两类元素一是轮迹车在漂移或高速转向时留下渐隐的轮胎印二是速度与氮气状态条直接在Canvas顶部绘制。这两种反馈实现成本不高但对可玩性的提升是决定性的。模型完全有能力生成这类视觉逻辑关键是你要在提示词里提醒它“用户需要感知速度”。4. 单条提示词的天花板为什么要向多轮协作与Agent演进“顶级模型一句话写出能玩的QQ飞车”确实是让人手心发热的时刻。但如果就此认为提示词工程就该停留在“一句定乾坤”那就把路走窄了。以我自己的实践来看单条提示词的上限非常明显它能生成一个骨肉完整的demo但很难生成一个经过调优、结构清晰、可以长期迭代的项目。4.1 为什么单轮生成注定有瓶颈单轮生成的本质是一次性翻译模型把整段需求翻译成整段代码。这种模式下有三个天然缺陷上下文长度有限。想表达的需求越多单轮提示词就越长而超长提示词会让模型在生成后半段时注意力涣散开始回头重复或者胡乱拼接。无法自我验证。模型只会生成不会对代码跑一遍单测再修改自己。所以单轮生成出来的代码质量高度依赖训练数据的匹配程度。知识隔离。你无法在单轮里同时融入“物理参数调优经验”“浏览器兼容处理”“美术资源替换”这些跨领域知识只能靠模型自己猜。这就是为什么我在真实项目里几乎不会用“一句话生成整个项目”的方式而是把工作拆成多个阶段先让模型生成骨架再逐模块喂需求和修正意见。4.2 从“一句话”到“多轮对话”的节奏控制多轮协作的关键不是提示词更复杂而是每一轮只干一件事。我实际操作时会划分成这样的节奏第一轮让模型生成完整可玩的单文件demo目标只有一个——能跑起来。第二轮提交具体缺陷清单让模型逐条修复。比如“碰撞穿模”“对手车不动”“漂移无痕”。第三轮优化手感给出物理参数区间甚至直接递给模型一组我自己调好的数字。第四轮重构代码结构把单文件拆分模块、补充注释、抽出配置项。这里有两个多轮协作的重要技巧。第一每轮修改意见要当作一条独立的提示词不要一条提示词里装五个请求。经验是模型对连续多个指令的处理准确率会急剧下降尤其是当这些指令涉及不同代码区域时。第二每轮对话开始前把上轮生成的完整代码重新粘贴一次。不要只发“你继续改”就完事模型没有记忆上下文一旦翻滚它会忘了之前的代码长什么样。4.3 Agent化让模型自己跑测试、自己修Bug多轮对话仍然要靠人来发现问题、组织语言、推动进程。更进阶的玩法是把工具使用能力交给模型也就是Agent化。简单说让模型不只是写代码还能在沙箱环境里执行代码、观察报错、自己迭代。我在2025年上半年实验过一条Agent化工作流拿来做AI写游戏刚刚好步骤一设定主Agent的角色和任务输入需求文档。步骤二让它生成代码文件并保存到工作目录。步骤三调用浏览器无头工具打开HTML页面截图存证。步骤四把截图回传给Agent附带指令“检查游戏画面圈出视觉问题”。这套流程跑起来的体验非常有趣。Agent会自行发现“赛道位置偏移了”“车的贴图被裁切”“碰撞后状态没有重置”。它甚至能在控制台里捕获JavaScript报错并根据报错信息退回去改代码。相比纯单轮生成Agent化把人类的“反馈-修改”循环自动化了。当然Agent化不是万能的。它需要把每个环节拆成可被脚本化的步骤需求本身如果模糊Agent也会疯狂跑偏。我见过一个测试让Agent生成“类似QQ飞车”的游戏由于没限定俯视角它直接生成了一款3D第一人称赛车物理效果惨不忍睹。所以即便是Agent提示词工程的基本功依然决定上限——Agent只是把你的每一条提示词放大执行并不能凭空修正错误的需求表达。4.4 多模型协作为什么要让“写代码”和“审代码”分开最后一个值得展开的点是“多模型协作”。我在实际项目中越来越倾向于不让同一个模型既写代码又审查代码。原因很简单模型在审查自己生成的代码时会带上“我觉得这没问题”的惯性很难发现那些它自己埋下的逻辑漏洞。正确姿势是引入“审议者”角色用模型A生成代码用模型B审查代码。审查指令可以是“逐行分析这段游戏代码找出可能导致崩溃、穿模、性能卡顿的问题按严重程度排序输出”。把B给出的问题清单再扔回给A让A针对清单逐项修改。这种双模型协作在游戏生成场景里很有用。因为游戏代码的bug往往在运行期才暴露审查模型可以通过阅读对预期行为进行推演而生成模型通过针对性的修单提升成功率。我自己落地时的体会是看似多花了一轮成本实际省掉了大量手动调试时间。5. 实操体会我给提示词工程定的几条规矩写了这么多我重复一句老观点AI写游戏这件事拼的从来不是模型的“智力”而是你提示词工程的基本功。下面这些规矩是我从无数次生成、调试、翻车、返工里总结出来的不一定全对但很值得你用在自己的AI编程工作流里。5.1 永远给项目一个“最小验收标准”很多人在提示词里喜欢写“做一个炫酷的赛车游戏”这句话的问题在于“炫酷”没有验收标准。我倡导的做法是先定义最小验收标准再谈扩展。比如这一个竞速小游戏的最小验收标准可以定义成玩家能用键盘控制赛车移动赛车不穿模有至少一个对手车在跑能冲线并重新开始。只要这五条达标游戏就算“能玩”。后续所有优化锦上添花。提示词里写清楚验收标准模型才知道哪些功能是“必须实现”哪些是“可以省略”生成时不会为了一些无关紧要的装饰浪费代码能力。5.2 物理参数单独提不要混在玩法描述里我发现把物理参数和玩法描述放在同一个句子里模型生成逻辑容易混乱。比如“汽车很快但转弯不漂移”这种模糊修饰模型会根据训练数据自由发挥结果往往不尽如人意。更好的做法是把物理数值直接写到提示词里就像是给一个不懂车的同事一张参数表。数值哪怕不是最优也会给模型一个精确的锚点。好模型对数值型约束的服从度通常很高你给了maxSpeed: 6它就不会生成一个速度变量设置为600的怪物。5.3 默认怀疑“第一版能玩”的代码生成结果看起来能玩这只说明“无崩溃”不说明“无bug”。我的经验是立刻做三件套检查故意开进草地上看碰撞是否生效故意长时间按住方向键看车辆是否会滑出屏幕刷新页面三次确认状态重置稳定。这三个动作能排查掉八成的基础逻辑漏洞。5.4 不要急着把代码“模块化”单文件demo阶段我强烈建议让所有代码留在单文件里。先打通逻辑再谈工程化。这不是说模块化不好而是对AI生成代码来说单文件便于整体读取和全局修改一旦拆成多文件模型在跨文件修改时容易陷入“不知道其他文件内容”的窘境。等项目功能稳定了再让AI逐步抽取公共模块。5.5 在提示词里加入“禁止项”除了正向描述需求我还喜欢在提示词里加入少量禁止项。比如“不要使用外部图片库”“不要引入不必要的框架”“不要生成登录注册页面”。这类负面约束能有效避免模型脑补一些超出范围的模块。注意禁止项不宜过多超过三个会让模型变得过度保守反而影响生成质量。5.6 利用“模拟对话”来提升提示词效果最后分享一个相对小众但非常好用的技巧与其直接写一段功能描述不如模拟一段“产品经理与游戏开发者的对话”放进提示词里。比如“产品经理说我要一个俯视角赛车游戏赛道是一个环形的车要能加速和漂移。游戏开发者回应……”。模型对这种对话体提示词的指令跟随效果常常优于指令体因为角色扮演能激活它的上下文推理能力让模型从“照着做”变成“站在开发者角度思考该怎么做”。这个技巧我在调试手感时屡试不爽。当模型以“资深游戏开发者”身份回答时生成的代码细节明显更多更接近有经验的工程实践而不仅仅是满足表面功能。最后再多说一句回到“顶级模型一句话AI写出了能玩的QQ飞车”这个标题。模型确实很强但真正让这个项目成立的是那句看似不经意的提示词背后创作者对游戏逻辑的理解、对模型生成规律的把握、对验收标准的清醒认知。我强烈建议看到演示的朋友不要停留在“AI好厉害”的感叹上而是自己动手试一次从一条最简单的提示词开始生成一个能跑的赛车游戏然后亲手去把它从“能跑”调成“能玩”。这个过程中你学的不是怎么向AI许愿而是怎么把一个模糊的项目想法拆解成一个它能精确执行的指令。等你学会了这套拆解功夫AI写游戏也好写工具也好都只是同一件事的不同变体罢了。