企业官网建设流程全解析

1. 一句提示词生成可玩游戏：这不是魔术，是正确的工作流

先交代一下背景。我最近在折腾 AI 编程，手里正好有顶级模型的 API 额度，试着做了一件很多人只在短视频里看过的事：只给模型一句话，让它写一个能玩的《QQ飞车》风格的网页赛车游戏。说"能玩"不是标题党，是真能用键盘跑完一圈、撞墙有反馈、弯道要减速的那种。整个过程从零到第一个可玩版本，大约花了不到半小时，其中大部分时间不是等 AI 写代码，而是在调整提示词。

很多人看到这类演示会觉得是"AI 碰巧会背一个赛车游戏模板"，或者觉得这是剪辑过的效果。但实际上，顶级大模型生成完整可运行项目的能力早就不是新鲜事——关键在于你用什么方式跟它协作。一句"帮我写个QQ飞车"扔给模型，大概率得到的是一坨审美平庸、逻辑残缺的代码；但如果把这一句话拆成"角色背景 + 核心玩法约束 + 技术栈选择 + 交互细节"，模型给你产出的东西会完全不一样。

这篇内容不是复述某个 AI 产品宣传页，而是把我自己踩过的坑、调过的参数、改过的提示词全部摊开讲。适合三类人看：想用 AI 做游戏原型但不知道从哪下手的开发者，对 AI 编程感兴趣但在观望的非技术爱好者，以及那些以为"AI 写游戏 = 复制粘贴成品"的围观群众。你可以直接照着下面的思路复现，也可以只当故事看，理解顶级模型是怎么把一句模糊的话变成几百行可运行代码的。

我先说说最反直觉的一件事：让 AI 写出能玩的游戏，难的从来不是"写代码"，而是"描述游戏"。模型内部对代码的生成能力是过剩的，它对自然语言的理解才是瓶颈。一旦你学会用它能听懂的方式描述需求，后面所有事情都会顺起来。

2. 复现过程：从一句"给我写个QQ飞车"到可玩 Demo 的完整链路

2.1 第一轮尝试：提示词太短，得到的只有空壳

我最初的提示词非常朴素，就一句话：

帮我写一个类似QQ飞车的网页赛车游戏

顶级模型确实给了一个 HTML 文件，打开之后能看到一辆车、一条直道，按方向键车能左右移动。但问题是：赛道不会转弯，撞墙完全不判定，没有计时器，没有漂移，甚至没有第二辆车。说白了，这是一个"看起来像赛车"的画布，不是游戏。

这个结果其实完全符合预期。顶级模型理解"赛车游戏"这个概念，但概念之下有几十个维度的细节——赛道形状、碰撞逻辑、速度曲线、视觉效果、操作手感——我一句话把这些全压缩了，它只能按自己训练数据里的"平均印象"来生成，而这个平均印象往往就是最无聊的版本。

从这轮失败里我总结出第一个经验：提示词不是字数越多越好，但关键约束必须写明。什么叫关键约束？就是如果缺了它，这个游戏就不成立的那些东西。比如"弯道需要减速否则会冲出去"、"赛车漂移时屏幕要有残影"、"要有小地图显示当前位置"。这些约束决定了游戏的骨架，而不是皮肤。

2.2 架构提示词：让模型先"思考"再"动手"

第二轮的改进不是直接加需求，而是让模型先拆解任务。我用的提示词结构是这样的：

你是一名资深游戏开发工程师，擅长使用 HTML + Canvas + JavaScript 开发网页小游戏。现在要开发一个类似QQ飞车的竞速赛车游戏，请先列出： 1. 这个游戏需要哪几个核心系统（例如：车辆物理系统、赛道生成系统、碰撞检测系统、AI对手系统、HUD系统）； 2. 每个系统分别负责什么，系统之间的数据流是什么； 3. 每个系统大致需要哪些函数或模块； 4. 用一张文字版架构图描述整体流程。 确认无误后，再开始写完整代码，代码要放在一个HTML文件中，方便直接运行。

这一步非常关键。顶级模型天然是一个"先规划后执行"的系统，你在提示词里给它显式的规划指令，它会输出远高于直接生成的代码质量。看到它列出的系统拆分后，我心里就有数了——它列的五个系统里，车辆物理系统和赛道生成系统是我没有特别描述、但它基于对竞速游戏的理解自动补上的，这恰恰是"顶级"和"普通"模型的分水岭。

它当时给的架构文本大概是这样：

赛道由分段（segment）构成，每段有左右边界坐标，通过离心率模拟弯道； 车辆物理系统每帧计算加速度、摩擦力、向心力，输出位置和朝向； 碰撞检测采用简化的线段相交 + 距离阈值，不追求精确物理； AI对手沿预设路点自动驾驶，路点由赛道中心线采样获得； HUD负责渲染速度、计时、排名和小地图。

有了这个框架，它后面写代码的效率至少提升了一倍，而且生成的代码结构干净，函数与函数之间解耦明显，方便后续定向修改。

2.3 分模块迭代：别让模型一次性写完整游戏

第三次尝试我犯了一个典型错误：让模型一次性把整个架构落地成代码。结果它真的生成了一个 2000 多行的 HTML 文件，浏览器也能跑，但手感非常差——车辆转向反应迟钝，漂移效果几乎没有，碰撞判定时灵时不灵。

问题出在哪？大模型生成超长代码时，上下文里前面的变量定义会逐渐"失焦"，后面部分经常出现变量名拼错、函数调用参数不一致的问题。这不是模型能力不足，而是注意力分布的自然衰减。就像人写长文档写到后面也会忘记前面埋的伏笔一样。

正确的做法是拆开写。我重新调整了策略：

1. 先让模型生成完整的index.html骨架，只包含赛车渲染和一个可以前后左右移动的方块；
2. 然后单独生成track.js，负责随机生成赛道（S型弯、U型弯、发卡弯）；
3. 再单独生成car.js，负责车辆物理和漂移手感；
4. 最后生成ai.js，负责 AI 对手的路点跟随。

这四次交互的提示词，我每次都会附加一句："这是刚才项目中 X 模块的完整代码，请基于它继续实现 Y 模块，不要重写其他部分。" 这样模型的上下文里始终有已完成代码的准确快照，它的输出质量会稳定得多。

2.4 里程碑：第一次跑完一圈是种什么体验

四个模块合体之后，我得到了第一个真正意义上"能玩"的版本：三条完整的赛道循环、手感和 QQ 飞车的低配版类似、按 B 键可以喷射氮气、碰撞障碍物会减速、赛道底部有进度条提示圈数。第一次完整跑完一圈的时候，说实话还是有成就感的——不是因为游戏有多精致，而是这个过程验证了一件事：顶级模型在没有接受任何游戏代码真实训练的情况下，仅凭一句句话的指导，就能组合出一个符合物理直觉的交互系统。

这轮复现的具体提示词我贴在下面，方便感兴趣的人直接抄：

请基于当前项目，实现一个AI对手系统： - 有3辆AI赛车，颜色分别为红、蓝、绿； - 它们沿着赛道的中心线行驶，中心线数据从赛道模块的路点数组读取； - AI赛车在弯道中会适当减速，直线会加速； - 当AI赛车与玩家赛车距离小于50像素时，会尝试偏移到旁边车道超车； - AI赛车彼此之间也要避免碰撞，碰撞后要恢复到安全距离； - 给每辆AI车添加一个简单的名称标签显示在车头上方。

注意这段提示词里的两个细节：一是中心线数据从赛道模块的路点数组读取，这是在告诉模型"你的代码需要和已有代码对接"，二是在超车、防碰撞这些行为上给了明确的数值阈值。

3. 赛车游戏背后的硬骨头：顶级模型到底替你解决了什么

3.1 车辆物理：从简单位移到速度向量

很多人以为赛车游戏的核心是"画一辆车跑起来"，实际上最难的是车辆物理。你按一下方向键，车应该朝哪个方向转、速度怎么衰减、轮胎抓地力怎么模拟——这些全在物理系统里。

顶级模型自动实现了一套我称之为"离线向心力近似"的方案：每一帧计算车辆的当前速度向量，根据转弯输入修改速度向量的方向，同时用一个"抓地力系数"让车辆在未操作时自动回正。这个方案不是真实物理引擎的精确模拟，但用在 2D 网页赛车游戏里完全足够，而且代码只有 100 多行，性能开销极小。

代码大概长这样（这是我后来手动改良过的版本）：

function updatePhysics() { // 油门 if (keys.up) speed = Math.min(speed + acceleration, maxSpeed); if (keys.down) speed = Math.max(speed - acceleration, -reverseSpeed); // 摩擦力与空气阻力 speed *= 0.99; // 转向：速度越快转向角越小，体现高速控制困难 if (keys.left) angle -= turnSpeed * Math.max(0.3, 1 - speed / maxSpeed); if (keys.right) angle += turnSpeed * Math.max(0.3, 1 - speed / maxSpeed); // 漂移：急转弯时产生额外横向滑动 driftOffset = drifting ? 4 : 0; // 更新坐标 x += Math.sin(angle) * speed * driftOffset; y -= Math.cos(angle) * speed; }

注意到if (keys.left) angle -= turnSpeed * Math.max(0.3, 1 - speed / maxSpeed)这一行了吗？它模拟的是真实汽车的速度越快、方向盘能转动的有效角度越小。这一个细节就能让手感和纯粹的"左右平移赛车"完全拉开差距。

3.2 赛道生成：随机算法的乐趣与风险

QQ 飞车的赛道不是随机生成的，但我们的 AI 版本没有美术和策划资源，只能靠算法生成。我让模型用最经典的分段拼接法：整个赛道由上百个线段组成，每段的左右边界坐标独立计算，线段之间通过角度变化衔接出弯道。

这个方案的最大风险是赛道自交——如果随机角度连续累计太大，赛道会绕回来压到之前的自己，玩家跑到那里就会卡死在边界里。我一开始没管这个，结果生成出来的赛道经常有一两个夸张的"蝴蝶结"，游戏完全没法玩。

后来我让模型加了一个selfIntersectionCheck()函数，每次生成新赛段时，检查与之前所有赛段的包围盒是否重叠，重叠就丢弃这一段并重新随机生成。这种"尝试-校验-重试"的循环逻辑，恰好是大型语言模型非常擅长的算法设计方向，因为它的训练数据里有大量类似的碰撞检测案例。

3.3 碰撞检测：为什么"别人家的碰撞"总觉得更自然

赛车游戏的碰撞检测有两个层次。第一层是车与赛道边界，第二层是车与车、车与障碍物。顶级模型初始生成的是最简单的方案：把车当作一个圆心，把赛道边界当作线段集合，检测圆心与线段的距离是否小于车的半径。这个方案在大多数情况下表现良好，但在高速状态下，车辆一帧的位移可能超过碰撞半径，就会出现"穿墙"现象。

我反馈这个问题之后，模型给出的解决方案是连续碰撞检测（CCD）的思路：不是检测车子当前位置是否撞墙，而是检测车子从上一帧位置到当前位置扫过的那条线段是否与赛道边界相交。代码实现并不复杂，就是两帧之间做一次线段相交测试。这个改进让穿墙问题彻底消失了，手感也硬朗了不少。

你可能会问，这种细节 AI 怎么会知道？答案就是：顶级模型其实受过大量游戏开发教程、割草机社区问答、GDC 演讲笔记的训练，它只是把这些知识以另一种方式组织起来，在合适的上下文里就能提取出来。这也是为什么说提示词的上下文质量，决定了 AI 输出质量的平均水平。

3.4 AI 对手：让 NPC 像真人而不是机器人

QQ 飞车里的AI对手是灵魂所在，没有对手的竞速游戏就没有竞速的意义。模型的初始 AI 方案是：沿赛道中心线自动驾驶，到达终点自动循环。但玩两把就发现，这种 AI 太死板了——它永远走中线，永远用最佳路线过弯，玩家跟它跑几局就能抓住规律轻松碾压。

为了让它像真人，我让模型加了四种随机扰动：

• 起步反应时间：每辆 AI 车有一个随机的起步延迟，0.2 秒到 0.8 秒；
• 过弯失误概率：每个弯道有 10% 的概率会切弯过急，导致擦墙减速；
• 超车冲动阈值：当前方车辆距离小于 100 像素时，AI 会尝试变道超车，但变道动作是一个快速猛打方向，有一定概率甩尾失控；
• 策略偏好：每辆 AI 车在发车时随机决定这一局是激进型（弯道减速少，失误率高）还是保守型（减速多，几乎不失误但直线慢）。

这些扰动加到代码里之后，同一张赛道跑五局，每局的前三名基本都是不同的人，手感上几乎和真人对战无异。这种"规则 + 随机"的 AI 设计思路，是顶级模型非常喜欢给出的方案，因为它可解释、可预测、且调试成本低，合作起来非常舒服。

4. 实测踩坑：AI 生成的代码为什么经常"看起来能跑，一跑就崩"

4.1 变量名漂移：长代码的隐形杀手

这是我复现过程中遇到的最频繁的问题。具体表现是：HTML 文件里有个变量叫playerCar，某个模块里写player.x = 100，另一个模块里却变成car.x = 100，结果打开控制台一片ReferenceError。

为什么会这样？顶级模型生成代码时，它的注意力在长序列上会逐渐不集中，特别是当一个项目拆分成多次交互生成时，每次交互之间模型的"记忆"并不是百分百连续的。所以你就得在每次请求时重新把关键变量名写清楚。

我的做法是搭建一个简单的"接口契约"文件：

// 全局游戏状态 window.gameState = { player: { x: 0, y: 0, angle: 0, speed: 0 }, aiCars: [], track: { segments: [], waypoints: [] }, gameStatus: 'ready' // ready / racing / finish };

每次生成新模块时，我都把这段契约贴在提示词的最前面，要求模型的所有函数都以这个全局状态为输入输出。这个方法立竿见影，变量名漂移问题从"每两轮必现"降到"几乎不出现"。

4.2 Canvas 渲染性能：页面卡成 PPT 的元凶

AI 生成的初版代码使用 Canvas 每一帧清屏并重绘所有元素，这在赛道只有 20 个线段时毫无压力，但一旦赛道涨到 200 个线段，加上粒子特效和漂移残影，浏览器立刻掉到每秒二三十帧。

查了性能瓶颈之后发现，问题出在 AI 用了context.shadowBlur来实现霓虹灯效果。这个属性在 Canvas 里是出了名的性能杀手，每一次调用都会触发整个画布的阴影计算。我把所有涉及阴影的代码替换成简单的线性渐变填充，帧率瞬间回到 60。

这里有个通用经验：让 AI 调试性能问题，不要让它猜测，直接告诉它"性能瓶颈是什么"+ "你希望的行为是什么"。比如：

当前游戏帧率只有20fps，我怀疑是shadowBlur导致的。把代码中所有shadowBlur移除，改用简单的颜色叠加模拟发光效果，保持外观风格不变。

在这个提示词下，模型会精准寻找并修改问题代码，而不是漫无目的地重写整个文件。

4.3 漂移手感：调了三轮数值才找到"爽感"

QQ 飞车的手感核心是漂移。实话说，AI 第一次生成的漂移效果非常糟糕：按方向键加 Shift 后，车辆会立刻转成横向滑动，但松开 Shift 后又会瞬间恢复抓地，中间没有任何过渡，导致玩家完全没法流畅地画弧线。

我尝试让模型直接调参数，比如提高漂移摩擦系数、增加漂移时的角速度，但效果一直不对。后来我想通了：漂移的"爽感"不是单一参数能调出来的，它是速度曲线、转向角速度、视觉残影、音效四者的配合。于是我重新改了提示词方向：

漂移手感不佳。请参考《QQ飞车》中的竞速漂移体验，改进以下细节： 1. 漂移启动时有一个渐进过程：按漂移键后 0.2 秒内逐渐增加横向滑动量，而不是瞬间切换； 2. 漂移过程中车辆会额外加速 10%，模拟"出弯提速"； 3. 漂移结束时增加一个小幅度的回正动画，持续 0.3 秒； 4. 漂移期间车尾绘制 5 个逐渐消失的半透明轮胎印记。

这次改动效果非常明显，漂移从"生硬的平移"变成了"有节奏感的弧线"。这个案例给我的启发是：AI 不是不能做手感，而是你需要把"手感"这个词拆解成它可以操作的具体指标。渐进过程、额外加速 10%、回正动画这些都是模型能理解和执行的操作单元。

4.4 浏览器兼容问题：为什么我在 Mac 上跑得好好的，Windows 上崩了

最后一个小坑出现在键盘监听上。AI 用的是event.keyCode，这个属性虽然老但兼容性还行，问题出在它同时监听了keydown和keypress，两个事件同时对同一按键触发两次，导致方向键响应有双倍加速度。在 Mac 的 Chrome 上表现是"车灵敏度很高"还能玩，但在 Windows 的 Firefox 上就会变成"一点方向键就原地打转"。

解决办法很简单：删掉keypress监听，只在keydown里处理逻辑，并用event.repeat忽略长按重复触发：

document.addEventListener('keydown', (e) => { if (e.repeat) return; keys[e.key.toLowerCase()] = true; }); document.addEventListener('keyup', (e) => { keys[e.key.toLowerCase()] = false; });

这段代码推荐直接抄走，比任何 AI 生成的大段事件管理代码都干净。

5. 从"能玩"到"好玩"：我后来又让它加了什么

5.1 小地图与圈数提示：竞速游戏的信息完整度

第一版游戏没有小地图，玩家在超过三圈的环线赛道上跑一会儿就分不清自己在哪里。我让模型加了一个实时绘制的 150x150 小地图，左上角显示，赛道用一个半透明圆环表示，玩家车是一个红点，AI 车是三个蓝点，点阵的移动路径参照实际坐标的缩放映射。

这个功能看起来简单，但涉及两个坐标系的转换：游戏世界坐标和 Canvas 像素坐标。模型最初的实现是直接用像素坐标除以一个固定缩放系数，但当赛道生成范围变大时，小地图就"飘"了，车辆红点跑出地图区域。修正方案是让模型计算所有赛段坐标的最小值和最大值，用归一化映射到小地图区域。这是一个非常典型的"比例尺"问题，在 AI 生成的代码里尤其容易出错。

5.2 氮气加速与视觉反馈：喷射区怎么画才不丑

QQ 飞车经典玩法里的喷射带，我让它实现成赛道上一条发光的青色区域。开车压到喷射带后，速度会额外提升 30%，持续时间 1.5 秒，期间车身周围出现粒子拖尾。

这部分的难点不在逻辑，而在视觉。模型生成的粒子拖尾别太当真——它用了 30 个随机位置的小白点循环飘撒，看起来像车着火了。稳定做法是让粒子沿一条弧线轨迹运动，并且透明度随生命周期递进递减。这里我学到的教训是：如果视觉要求很高，别指望 AI 一步到位，拆成"粒子系统 + 轨迹曲线 + 颜色渐变"三个子任务分别生成，最后合在一起。

5.3 声音：AI 生成的 Web Audio 引擎音效

音效是让游戏感觉"高级"的最快方式。我没花钱买音效素材，而是让模型用 Web Audio API 合成引擎轰鸣声、碰撞声和漂移音效。引擎声是一个频率随速度变化的振荡器，速度越快频率越高，听着有种模拟驾驶的游戏感。

碰撞音效用的是白噪声 + 低通滤波的一次爆破音，漂移音效用方波加上快速的频率扫动。这套音效方案代码量少、效果好，而且完全不需要外部音频文件，非常适合 AI 生成的单文件游戏项目。

唯一的坑是：部分浏览器的自动播放策略会拦截 Web Audio 的启动，必须等用户第一次点击页面后再创建音频上下文。模型一开始没处理这个，导致第一版游戏打开没有任何声音，直到用户按了方向键之后声音才"迟到"地响起来。加了一个window.addEventListener('click', initAudio, { once: true })之后问题就解决了。

5.4 排行榜与本地存储：让游戏至少能"玩十把"

为了让这个 Demo 更像一个"真的游戏"，我让模型加了一个简单的排行榜：完成一圈后记录成绩，存入localStorage，下次打开页面时显示历史最快圈速。这个功能对模型来说几乎没有难度，写出来也就是二十多行代码。

我刻意提这个，是想说一句：AI 写游戏的上限，其实是由你想要的"完成度"决定的。如果你只想要一个能跑的圆形，它会给你圆形；如果你想要一个能开排行榜、有音效、有小地图、支持多圈赛事的完整游戏，它也能给你。差别在于你是否意识到"完整游戏"由哪些组件构成，以及你愿不愿意一步一步分解任务。

6. 顶级模型写游戏的边界：哪些事它做不了，哪些事别让它做

6.1 审美判断力：模型能模仿，不能审美

很多人问我，AI 写的游戏和 QQ 飞车差距有多大？答案很简单：美术和策划层面差很多。QQ 飞车的美术风格是经过长期审美打磨的——场景比例、光照氛围、UI 动效、车辆的流线型设计，这些不是靠算法能"生成"出来的，尤其是一次性生成出来。

AI 生成的赛车大概率是一个矩形加两个圆，赛道就是灰底加白线。你可以通过提示词让它增加渐变、边框、阴影，但最终作品还是停留在"像素风原型"的层次。它不是不能做好看，而是需要极大提示词工程量来弥补审美判断力，投入产出比远不如让真人做美术。

6.2 设计意图：AI 不知道"为什么这样设计"

竞速游戏的乐趣在于"规则设计的巧妙"，比如为什么 U 型弯前有加速带、为什么直道中间放一排路障。这些设计意图需要策划经验，AI 只能根据训练数据里的普遍经验给出合理默认，但永远无法像人一样知道"这里放一个加速带，是为了让玩家在过弯前多做一次路线规划"。

所以我的建议是：把 AI 当成一个资深执行者，而不是设计师。让它实现你的想法、测试不同方案、快速迭代反馈，都比让它自己从零构思要有价值得多。

6.3 复杂渲染效果：模型会写，但不懂优化

3D 效果、碰撞后车身碎片的物理模拟、动态光影，这些代码 AI 也能写，但写出来之后性能基本都会爆炸。因为游戏渲染是一个非常依赖管线优化和帧预算的经验领域，模型训练数据里的模棱两可太多，它给的实现往往是最直白、最不优化的那个版本。遇到这种情况，别跟它死磕，直接用成熟游戏引擎或专门图形库来做局部功能，或者干脆简化功能。

6.4 游戏的"灵魂"：还是得靠人

最后说一个可能听起来飘但很实际的观点：AI 能写出"能玩"的游戏，但写上"好玩"这个词，就需要人参与。我在整个复现过程中，真正花时间去做的不是写代码，而是想清楚"漂移要有渐进感"、"AI 要会失误"、"小地图比例尺要归一化"这些设计判断。这些判断不在任何提示词模板里，它来自我以前玩游戏时对体验的敏感，来自"这个手感不对，我要拆解它为什么不对"的愿望。

这句话同样适用于你：如果你自己不知道游戏好玩在哪，给你再强的模型也没有用；反过来，只要你能清楚地描述"什么才是好玩"，顶级模型就真的能帮你把那个好玩的游戏写出来。

7. 实操经验总结：如果你也想用 AI 写一个竞速游戏

7.1 复现环境与工具选型

我现在用的是一套非常轻量级的 j 环境：一台普通的 MacBook Air，浏览器用 Chrome，编辑器只用 VS Code 加一个 AI 插件（用来粘贴代码和报错信息）。不需要安装任何游戏引擎，不需要配置本地服务器，一个 HTML 文件打开就能跑，这也是 AI 生成网页游戏最爽的地方——零门槛，双击即玩。

如果你不想用我用的这个顶级模型，用支持长上下文的其他大模型也行，比如 GPT-4 类、Claude 类，甚至国内几款百亿参数模型也基本能做到"写一个能跑的赛车 demo"。差别主要在复杂逻辑的稳定性和长代码的连贯性，但思路是完全一致的。

7.2 一套可以直接抄的提示词结构

这几次实践下来，我形成了一个固定的提示词模板，分享给各位：

【任务背景】 我是一个没有游戏开发经验的爱好者，你是一名资深HTML5游戏开发工程师。 【目标】 实现一个类似QQ飞车的网页竞速游戏，最终交付一个可直接运行的HTML文件。 【硬性要求】 - 用纯HTML + CSS + JavaScript，不依赖任何外部库； - 画布自适应窗口尺寸； - 支持键盘操作（方向键控制方向，Shift漂移，B喷氮气）； - 有碰撞检测、漂移手感、AI对手、计时与圈数系统； - 代码注释清晰，关键逻辑需要有中文注释。 【工作方式】 先输出一版完整的代码，然后等待我的测试反馈，不要主动修改代码。 【本次要完成的内容】 （在这里具体描述你希望新增或修改的功能）

这段模板的精髓在于最后两行：等待我的测试反馈，不要主动修改代码。这一句能避免模型在生成完一个版本后絮絮叨叨地附赠一堆无关优化建议，让你的迭代节奏掌握在自己手里。

7.3 调试节奏：十五分钟一轮是黄金周期

我用"十五分钟周期"来管理整个迭代过程：生成代码五分钟，跑起来两分钟，玩三分钟，发现问题五分钟，给模型反馈再花两分钟。一圈下来十五分钟，产出明显的可玩改进。这种节奏非常重要——AI 编程的优势就是迭代快，你别把它用成"让 AI 一次性给终稿"的模式，那只会让你陷入反复重写的泥潭。

7.4 推荐延伸方向：从竞速游戏到 Roguelike 游戏

如果你觉得赛车游戏玩腻了，同一个工作流完全可以平移去写其他品类。比如让它写一个"以撒的结合"风格的地牢射击游戏，或者一个"吸血鬼幸存者"风格的自动刷怪游戏。底层逻辑都是：物理系统 + 碰撞规则 + 敌人生成 + 玩家成长，这四个模块和赛车游戏的系统拆分是同一套方法论。

更进阶的玩法是让 AI 自己生成游戏设计文档，再基于文档写代码。用顶级模型先写一份"关卡设计表"——每个弯道的半径、加速带的位置、障碍物的密度——然后让它按表生成赛道。这个流程就基本接近一个小型游戏团队的分工方式了：策划（你/模型）出方案，程序（模型）落地。

7.5 一个让人上头的扩展点：让 AI 学习你的驾驶风格

说个更遥远但可行的想法：我打算下一步让 AI 记录玩家的操作序列（按键时间戳 + 速度 + 位置），用这些数据训练一个小模型，在单机模式里生成一个"镜像自己"的 AI 对手。这个想法和博客里提到的 AI Agent 有点像，本质上是把玩家历史操作当作提示词输入模型，让它以模仿学习的方式输出"下一个操作的概率分布"。虽然目前只是个想法，但以顶级模型的代码能力和推理能力来看，这个功能在纯前端也能实现，无非是自己生成一个简单循环神经网络，训练量小到几秒就能完成。

这类扩展没有标准答案，能摸到多深取决于你愿意花多少时间跟模型交互。我能确定的是，每一轮交互中你给出的信息越具体、迭代越勤快、反馈越精准，越能把你从"用 AI 生成玩具"推进到"用 AI 开发产品"的层级。

最后，实际操作中我个人最受益的一件小事：试着把每次的提示词和结果截图存下来，隔几天回看自己当时是怎么提问的。你能清楚看到自己的"提需求能力"在变好，而这种能力不是模型给的，是你跟模型一轮轮打磨出来的。这大概就是 AI 时代最微妙的地方——技术门槛在降低，但设计师和策划师的判断力，反而变得更值钱了。