说真的看到这个标题我第一反应是不信。“一句话让顶级模型写出能玩的 QQ 飞车”这种说法听起来就像营销号在吹牛。但等我真把手头能用的最强模型打开用一套打磨过的提示词跑完整个流程从一句需求描述到浏览器里能开、能漂、能超车、能跑满三圈的竞速小游戏前后顶多五十分钟。这篇文章不聊玄学我只把我完整的提示词、每一轮迭代指令、踩过的坑全部摊开。想用 AI 做小游戏原型、做一页跑起来就能演示的 demo或者对提示词工程感兴趣的人都可以直接照抄。1. 项目全景一句话生成可玩赛车游戏的思路拆解1.1 这不是“魔法”是需求工程很多人看到“顶级模型一句话生成游戏”会觉得是模型突然开窍了其实完全不是。QQ 飞车在这里只是一个需求锚点它代表了竞速、漂移、氮气、AI 对手这类成熟玩法而真实的任务是让模型在单个 HTML 文件里把这些玩法的核心版本实现出来。关键难点不在“生成代码”而在“说清楚到底要什么”。我自己把“能玩”拆成三条硬标准可操作有明确的输入方式键盘或者触屏能控制方向和速度不会出现按了没反应、松手还在跑的情况。有反馈视觉、物理、UI 对每一次操作都有即时响应。撞墙要有减速感漂移要有痕迹超车要有紧张感。有目标存在终点线、圈数、单圈时间、排名这类东西玩家清楚自己是在赢还是在输。这三条标准听起来朴素但模型生成的代码如果真的逐条跑一遍绝大多数“看起来很酷”的版本都会挂掉。正因为很多人只拿一句话丢给模型不看这三条才会觉得 AI 生成游戏是玩具。1.2 顶级模型和普通模型的分水岭在哪我不卖关子直接说结论这种“从一句话到完整可玩游戏”的任务普通模型是干不了的。你让一个入门级模型写一个赛车游戏它可能给你一个方框在直线上来回移动或者给你一堆互相冲突的代码打开控制台全是红色的报错。顶级模型在这类任务上的优势具体体现在三件事上长上下文整合能力整个游戏在单个 HTML 文件里有几百行代码互相耦合。顶级模型能整体理解渲染、输入、物理、AI 之间的依赖关系改一处不会把另一处带崩。代码重构能力我做迭代时要求它“只改车辆移动和碰撞相关的函数不要动 UI”它真的能精准定位把影响面控制得很小。普通模型很容易把整个程序推倒重来。视觉常识顶级模型能画出赛道弯道、树木阴影、路肩条纹这种人眼看着顺眼的东西。普通模型画出来的东西就是纯几何图形谈不上“能玩”。我给三种档位的模型做过快速对比效果差异非常直观。模型档位代码可运行率迭代修复能力视觉还原度上下文利用入门模型很低经常缺依赖不敢改一改全崩几何图形级别只能理解单文件片段主流模型中等简单 demo 可以能修简单问题有基础造型能理解 300 行左右顶级模型高基本可运行能精准局部修改接近美术出图能维持整文件一致性所以这个项目的第一个“成功要素”其实是选型。别拿入门模型硬刚那不是提示词能弥补的。1.3 “一句话”其实是“一段结构化话术”加“N 轮迭代”标题里说“一句话”这句话很容易误导人。实际上真正送到我模型里的提示词是一段带有明确需求分层的结构化文本而且生成之后我还要跟它对话四五轮不断发现问题、反馈、让它修。整个过程可以概括成一句大实话模型负责写代码人类负责当产品经理和测试员。“提示词工程”碰到的第一个认知误区就在这里。很多人以为找一句神奇的“魔法咒语”模型就能给你交付成品。这纯属玄学。确切地说提示词承载的是“需求文档的语义压缩”它决定了模型第一版输出的下限而后续迭代决定的是最终成品能不能玩。2. 提示词设计这才是项目真正的核心资产2.1 我的主提示词模板可直接复制这是我最想分享的部分。整个项目能不能成八成靠这一段提示词。我直接把我在实际测试里用得最顺手的版本贴出来请用纯 HTML CSS JavaScript全部放在一个 .html 文件里不需要任何外部依赖和素材图片做一个 2D 俯视视角的竞速赛车小游戏类 QQ 飞车玩法。 需求 1. 玩法玩家控制一辆赛车在环形赛道上跑圈赛道上有 3 台 AI 赛车同时比赛。完成 3 圈后比赛结束显示总用时和最终排名。每过一圈屏幕上方显示圈数和当前单圈时间。 2. 操作方向键或 WASD 控制转向和油门空格键使用氮气加速。氮气有能量条能量条可以通过漂移和经过赛道上的道具点积攒。支持漂移在急转弯时按住方向键会进入侧滑状态侧滑时轮胎留下拖痕特效。 3. 物理车辆要有速度和角速度模型带适当摩擦力和惯性。撞墙时减速并沿墙滑动不能穿墙也不能卡死在墙里。速度越快转向效率越低手感要接近街机赛车而不是冰面滑行。 4. 视觉赛车、赛道、路肩、树木、指示牌全部用 Canvas 或 CSS 绘制不要外部图片。配色鲜艳偏卡通风格。右上角显示速度表、圈数、排名、氮气能量条的 UI。 5. 约束全部代码本地运行不需要服务器。代码结构清晰变量命名规范关键逻辑写中文注释。如果某个功能特别难实现优先保证游戏能跑起来再补充功能。为什么这段能好用因为它不是一个需求而是五个层面的需求组合。玩法层、操作层、物理层、视觉层、约束层各占一块模型读了之后能快速建立起一个完整的项目结构而不是只想着“画一辆车动起来”。2.2 提示词里的三个隐藏细节逐条讲讲我写这段提示词时的心机。第一强调“单文件、无外部依赖”这一步直接决定了整轮开发的效率。单个 HTML 文件最大的好处是双击就能跑连本地服务器都不用开。模型只要生成一个 index.html我存下来在浏览器里一打开就能立刻验证效果。没有构建工具、没有 npm install、没有路径配置整个迭代闭环被压缩到 10 秒以内。别小看这个细节很多 AI 项目死在“代码写出来了但跑不起来”这一步多数是因为外部依赖版本冲突。第二关于物理手感我在提示词里明确写了“有速度和角速度模型”“速度越快转向效率越低”。这些术语对模型来说不是装饰而是精确的算法指示。如果我只说“手感好一点”模型完全不知道从哪里下手。但我说出角速度、摩擦系数、转向效率衰减这些词它就能自然生成一整套街机手感的物理模型。第三约束层里最重要的其实是那句“如果某个功能特别难实现优先保证游戏能跑起来”。这是给模型留的后路。大模型有时候会为了追求功能完整性生成一个 2000 行的怪物里面一堆未定义的变量。我在这个项目里吃过一次亏后续所有提示词都强制加上这句话。模型在这种“保底指令”下会优先保证核心流程跑通之后你再让它逐项补全高级功能。2.3 “不做什么”的重要性比你想象中大很多人写提示词喜欢写“我要这个、我要那个”但很少写“不要什么”。测试下来这是个很大的坑。我做过一次对比同一款模型的 A 版本没写负面约束B 版本加了“不要做地图选择、不要做商城、不要做存档、不要做多人联机”四个排除项。结果 A 版本生成出来一个带三张地图选择页、带有商店和金币系统的半成品页面本身都跑不动。B 版本则老老实实生成了一个单赛道竞速游戏稳定运行。原理在于模型会试图满足你对某个品类的所有联想。你提“QQ 飞车”模型自动脑补了端游里的商城、角色、道具赛、排位系统。它不知道你是要做个两小时能跑完的 MVP 原型。所以负面约束的本质是给模型的“脑补”划定边界让它不要把资源浪费在不必要的系统上。这个思路适用于所有提示词场景。不管你是写代码、写文案还是做角色设定第二步就写“不要包含哪些内容”整体输出的稳定性会提升一大截。3. 实操复盘从第一版到“能玩”的完整迭代过程3.1 第一轮生成能跑但没“手感”用上面那段提示词第一版输出出来大概花了一分钟。我打开浏览器页面成功加载UI 和赛道都在用方向键可以控制一辆彩色小赛车在环形赛道上跑。但我上手玩了不到十秒问题全暴露了。手感受问题最明显。这辆车开起来像在冰面上滑行速度快了以后点一下转向车身会以极不自然的方式甩出去。撞墙的判定只在水平方向生效斜着撞上去会直接穿墙。三台 AI 赛车更是拉胯只会沿着预设直线匀速前进走到弯道就撞墙然后原地抽搐。我分析了一下第一版代码的结构模型给车辆的物理模型基本就是“加速度加限速”的二维简化缺少两个关键部分转向角速度和摩擦系数。我大概还原了它的核心逻辑写出来给大家感受一下// 第一版核心逻辑简化示意 car.ax throttle * force; car.ax * friction; car.ay steer * turnRate; // 这里直接把转向变成了横向速度 car.x car.ax; car.y car.ay;看出来问题了吧a 向量直接跟横向移动绑定转向变成了“瞬间获得一个横向速度”没有角速度概念速度越快转起来越像甩尾。这就是冰面手感的来源。3.2 第二轮迭代修物理与碰撞才是手感来源发现问题之后我追加了第二轮提示词。这里有一个非常重要的操作习惯不要笼统说“手感不好”而要指出具体模块和期望表现。我当时写的是现在车辆手感太滑。请把车辆模型改成接近赛车游戏的经典街机手感车辆有前进方向与横向速度两个维度增加路面摩擦和侧向摩擦系数速度越高时转向角速度越低实现转向效率随速度衰减。撞墙时先用矩形碰撞粗判如果车头碰到墙把速度分解为平行墙面和垂直墙面两个分量垂直分量归零保留平行分量实现沿墙滑动。只改车辆移动和碰撞相关代码不要动 UI 和 AI 车逻辑。这一轮模型改掉了核心 update 函数。我看了一下改动逻辑上已经完全不一样了// 第二轮改造后的核心逻辑示意 let speed car.forwardSpeed; let heading car.heading; if (throttle) { car.forwardSpeed accel * dt; } car.forwardSpeed * friction; // 路面阻力 let steerFactor steer * turnRate * (1 - speed / maxSpeed); // 速度越高转向越低效率 car.heading steerFactor * dt; // 碰撞后的滑移处理 let vx forwardSpeed * Math.cos(heading); let vy forwardSpeed * Math.sin(heading); // 把速度向量分别沿墙面法向和切向分解 let normalSpeed vx * wall.nx vy * wall.ny; vx - normalSpeed * wall.nx; vy - normalSpeed * wall.ny;这套东西其实就是经典街机赛车物理。运行之后效果立竿见影转弯能感觉到明显的离心力但不会像冰面那样失控撞墙也不会卡死而是沿着墙面滑一段然后停下来。这一轮改完之后游戏已经能“玩”了但还谈不上“爽”。3.3 第三轮迭代加入赛车游戏的核心乐趣物理手感对了以后我开始要求模型补玩法层面的内容。我给它追加了三项指令。第一是把漂移做成一个显性机制而不是偶然的侧滑。第二是把氮气能量条和漂移/道具点关联起来。第三是重写 AI 对手的逻辑让它们沿着路径点行驶而不是直线乱跑。漂移这一块的实现要求比较细我给的追加提示词是给车辆加入一个漂移状态机。当玩家速度大于阈值、正在按住转向键、且油门松开时进入漂移状态。漂移时车辆转弯半径更小、摩擦系数更低并在车尾生成拖痕粒子。漂移持续超过 0.3 秒后松开转向键时向前追加一段短时间加速。氮气能量条改为每漂移 1 秒增加 15 点每经过一个地面道具点增加 30 点。这个状态机的关键点是“漂移状态机”这个抽象概念。模型能理解状态机的状态转换然后自然地在 update 循环里增加判断分支。我实测下来效果很好漂移入弯、拖痕粒子、出弯喷一小段火这套手感和 QQ 飞车那种“漂一下喷一管气”的爽感已经非常接近了。AI 对手的逻辑我要求走路径点插值// AI 对手的路径点追踪逻辑 ai.waypointIndex (ai.waypointIndex 1) % waypoints.length; let target waypoints[ai.waypointIndex]; let desiredAngle Math.atan2(target.y - ai.y, target.x - ai.x); let angleDiff normalizeAngle(desiredAngle - ai.heading); ai.heading angleDiff * ai.turnSpeed; ai.forwardSpeed ai.accel * dt;这样 AI 车不再是直线撞墙而会沿着赛道路径有模有样地过弯。我还特意让模型把 AI 的极限速度调得比玩家略低一点保证玩家只要正常操作就能赢但如果不小心失误AI 真的会超到前面去。这种“有竞争但不太凶”的调校是最适合展示 demo 的难度设置。3.4 时间线复盘七轮对话四十八分钟我把整个迭代过程的时间和关键产出整理成一个表格方便大家感受一下真实的节奏。轮次追加指令重点产出状态耗时1初始提示词能跑冰面手感AI 撞墙1 分钟生成2物理模型改造手感及格能正常跑圈8 分钟3漂移状态机 氮气玩起来有爽感了12 分钟4AI 路径点系统有竞争性赛道活了10 分钟5特效和 UI 优化界面完整观感好7 分钟6修小 bug稳定运行5 分钟7难度调校手感接近目标5 分钟从第二轮开始每一步的改动范围都很小这是我能保持快速迭代的核心原因。整个项目跑下来四十八分钟其中我花在思考和写提示词上的时间大约是二十多分钟剩下的都是模型生成和等待时间。4. 提示词工程的实战方法论把 AI 当成远程开发者4.1 把需求翻译成模型听得懂的语言核心心法就是一句话把 AI 当成一个远程开发的新程序员你会怎么给他说需求你就知道提示词该怎么写。你不会直接丢一句“做个飞车”给一个刚入职的同事至少会告诉他这是什么类型、用什么技术栈、现在要跑通哪个核心流程、先不要碰哪些模块。提示词也是一样的只是面向模型的表述要更结构化。我给大家总结了一张映射表方便日常写提示词参考需求维度提示词里的写法为什么重要技术栈“纯 HTML CSS JS单文件无依赖”限定边界让模型不走偏核心玩法“完成 3 圈后结束显示总用时和排名”定义成败标准交互反馈“速度越高转向效率越低”输入性能描述让手感的定义可执行视觉要求“Canvas 绘制不需要外部图片”避免素材依赖负面约束“不要做地图选择、商城、存档”控制范围防止系统爆炸兜底机制“如果太难优先保证能跑”防止生成不可运行的大怪物这套映射表是有通用价值的。你写一个“AI 帮做 PPT”的提示词也可以先定义内容结构、视觉风格、演示场景、负面排除再写兜底。底层逻辑是相通的。4.2 迭代反馈的四个原则效率翻倍光有好的第一轮提示词不够后续迭代如果做得乱整个项目照样烂尾。我基于多次实操总结出四个反馈原则按这四个原则写追加提示词模型修复的成功率会高非常非常多。第一个原则一次只改一个系统。我这里说的“系统”指物理、AI、UI、音频、关卡这类的独立模块。我见过很多人一上来就让模型“把画面调好看点再加一个道具系统顺便修复撞墙 bug”这种多目标指令必然导致模型混乱。正确做法是物理手感一轮AI 逻辑一轮视觉效果再一轮。第二个原则给模型指路别让它满文件找问题。每当我知道问题出在哪个函数我会直接在提示词里说“问题出在 updateVehicle 里的碰撞检测分支”模型就能精准定位不会误伤其他逻辑。这就像你找医生直接说“我右侧肋骨下方疼”比“我肚子不舒服”要有效得多。第三个原则小步验证。每一轮改完立刻刷新浏览器跑一圈赛道确认改动没有引入新问题。不要等到攒了一堆改动再一次性测试否则模型改崩了你都不知道是哪个指令引起的。第四个原则把报错原文原样贴给模型同时告诉它触发条件。只贴报错不描述怎么触发的往往不够。正确的姿势是“按下空格键后立即报错 Uncaught TypeError: Cannot read properties of undefined期望行为是触发氮气加速”。模型拿到触发上下文之后修复精准度会高一个台阶。4.3 怎么判断模型输出质量预览、报错、边界测试很多新手拿到模型生成的代码打开浏览器看到画面很酷就觉得完工了。这是大错觉。判断模型写出来的游戏能不能用我有三个固定检查通道。第一步是直接跑起来预览。这不仅为了看好不好看还要验证页面有没有崩溃。第二步是打开浏览器开发者工具切到 Console 面板看有没有红色报错。第三步是边界测试故意做一些极端操作比如高速状态下连续左右转向、贴着墙加速、撞到赛道最外沿、死按氮气不松手看看会不会出现卡死、穿墙、数值爆炸。边界测试里最容易暴露两类问题。一类是数值未定义某些变量在特定分支下没有初始化一触发就直接崩了。另一类是物理数值失控比如漂移叠加了无限加速速度狂涨到画面抖动。这两类问题在 Console 面板里通常都有红色警告线索直接复制给模型修就可以了。补充一个非常实用的技巧如果模型给出的代码改动在你贴回原文件之后反而跑不起来了优先怀疑它“只贴了改动片段漏掉了上下文依赖”。这时候不要慌直接跟它说“请在回复里包含完整的
