企业官网建设流程全解析

先说结论：我用一条大约150字的高质量提示词，让当前能力最强的大模型之一，在没有手写一行代码的情况下，生成了一款能玩的标准竞速小游戏。画面是2D俯视视角，玩家操控一辆赛车在环形赛道上跑圈，有护栏碰撞、有漂移手感、有圈数统计，甚至连小地图都有。整个过程大概就是：组织需求、发给模型、复制代码、保存为HTML文件、双击打开，然后就能用方向键开跑了。

这事情有意思的点在于：一个500行左右的单文件HTML，居然能做出“能玩”的体验，而不是那种镜头飘浮、手感稀烂的Demo。它说明一个事实——AI写代码这件事，瓶颈已经不在模型能力，而在你能不能把需求说清楚。这篇文章就是要把“说清楚需求”这个环节掰开揉碎：提示词到底怎么设计、参数凭什么那样给、AI生成的代码里有哪些坑、以及怎么把“能跑”调成“好玩”。

适合三类人看：想了解AI编程能力边界的好奇玩家；正在评估AI辅助开发工具的技术人员；以及打算用AI快速做小游戏原型验证的独立开发者。看完之后，你不一定能一次复现一模一样的赛车游戏，但至少会知道，和AI描述一个软件需求时，哪些话值得说，哪些话是废话。

1. 内容整体设计与思路拆解

1.1 为什么拿“AI写游戏”当试验场

AI编程这个话题，从大模型普及之后就一直是热点，但大多数人对它的认知还停留在“能补全代码”“能写个爬虫”“能解算法题”这个层面。我自己在判断一个大模型编程能力强不强时，标准很朴素——让它做一个有状态、有交互、有视觉反馈的完整小项目，而不是跑一个课后习题。游戏恰恰是最合适的试金石，因为它同时考验模型对需求的理解能力、对代码结构的组织能力、对细节的还原能力。

一辆赛车要动起来，光会画一个Canvas可不够。它背后必须有游戏主循环、物理参数、碰撞检测、输入响应、状态判定，这是一个完整的闭环。任何一个环节缺失，游戏就不可玩。所以“一句话能否生成一个能玩的赛车游戏”这个测试，本质上是在测试“模型能不能把碎片需求组装成一个闭环系统”。

选赛车题材还有一层私心。它的核心机制足够简单，几十行就能搭出雏形；但外圈又足够丰富——漂移、氮气、道具、战绩记录、地形变化，任何一个点都能横向扩展。对AI来说，这种“下限低、上限高”的项目最容易出效果，不至于一上来就露怯。

另外我特意把游戏锁定在“单文件HTML5”这一个约束上。没有服务器、没有构建工具、没有依赖下载，一个文件双击就能跑。这个约束有大用途：它把AI的发挥空间限制在了前端三件套加一个Canvas里，所有逻辑都摆在明面上，任何报错都能直接从浏览器控制台看到，调优时也不会被编译链路干扰。对验证“一句话能不能生成可用软件”这件事来说，这是最快的路径。

1.2 一句话提示词的三层信息结构

很多人以为“一句话提示词”就是随口说一句“给我写个赛车游戏”。如果你真的这么干，大概率会收到一个看起来差不多、但完全不可用的东西——要么车辆移动的逻辑是全屏瞬移，要么没有任何完成目标，要么速度参数崩坏到一按油门就飞出赛道。这不是模型笨，而是你给的信息熵太低，它在海量可能性里随机选中了一个平庸的实现。

我这次用的一句话，表面是一句，内部其实压缩了三层信息：角色描述、任务目标、完成标准。

举例，我最初的提示词是这样写的：

请生成一个单文件HTML5赛车游戏，用Canvas绘制。风格类似经典竞速手游：玩家控制赛车在环形赛道上行驶，最短时间内完成3圈。要求：1) 键盘控制，方向键或WASD驾驶，Shift键漂移；2) 赛车有质量和摩擦力，转弯会减速，撞到护栏会弹回；3) 赛道由深灰色路面和白色路肩线组成，赛道外是草地和树木；4) 屏幕显示圈数、计时、当前速度、最快单圈；5) 2D俯视视角，自动适应窗口大小。直接输出完整HTML代码。

“角色描述”是让模型明白它在扮演资深游戏开发者，而不是只会罗列接口的工程师。虽然这个角色设定看起来玄学，但实际影响很大——同样的需求，加上了角色预设之后，模型会更倾向于给出工程化、可维护的代码结构，而不是一个玩具脚本。“任务目标”是生成可玩的赛车游戏，并且玩起来像经典竞速游戏——这句话决定了画面风格和操作手感。“完成标准”则藏在五条要求里，把“能玩”拆成了控制系统、物理反馈、界面信息、运行方式四个维度，模型不是靠猜，而是照着清单实现。

你可能会注意到，提示词里我没有写任何一行代码，也没有指定某个算法。这类“声明式”描述在生成式编程里效果最好，因为它把决策空间整个交给模型，让模型在自己的能力范围内找最优实现，而不是被我的“实现偏见”困住。这也是我常用的提示词策略：告诉模型你要什么结果，而不是教它怎么写代码。

2. 提示词设计与核心细节解析

2.1 提示词版本迭代：从“能生成”到“能玩”

我第一次用上面那个提示词，生成的版本能跑，但只算是“能运行”：车确实能走能停，但过弯没有任何减速，撞到树和护栏直接穿过去，圈数计时器显示在那里——但那个数字从来没动过。第一次跑完我差点以为“AI写游戏”就是个噱头，后来耐着性子看了代码，发现问题出在我要求的东西和模型理解的东西之间出现了偏差。

第二次我改了提示词，加了两条关键约束：“车辆每帧的位置更新必须基于向量和速度计算，不能直接改x/y坐标”——这一条是针对“瞬移式移动”这个通病的；“提供明确的圈数判定逻辑，当赛车中心点经过起点线时视为完成一圈”——这一条把抽象需求变成了可实现的判定规则。修改后的第二个版本，已经完全是一个能玩的小游戏了，手感、碰撞、计时都正常工作。

这段经验让我意识到提示词工程里一个容易被忽略的事实：模型不是不理解你的需求，而是它没法判断“减速”到底是怎么个减、“撞墙”的碰撞范围到底是什么形状。你越是把边界条件说清楚，它写出来的逻辑就越接近你的意图。

我把三版提示词的核心差异整理成一个对照表：

看到没有，v1到v2的改动，本质上不是去“修Bug”，而是修正需求描述。AI生成代码的过程像一个盲人摸象：你描述得越具体，它摸到的部分越准确。而所谓“一句话”，其实是在一句话的长度里复述一整套隐性需求。

2.2 游戏核心参数：手感不是玄学

AI生成了代码，但真正让游戏“好玩”的，是隐藏在代码背后的一堆参数。这也是“能玩”和“好玩”的分水岭。我调优时最关注的几个值，是判断一款赛车游戏手感的核心维度，写在这里供你参考：

• 最大速度：控制在180~220之间比较合适。太低没有速度感，太高跑一圈要很久，体验反而疲惫。
• 加速度：决定了从静止到全速需要多久。我调到约8~10，大概是2秒多能加到接近限速，这个节奏玩起来最跟手。
• 摩擦力：地面摩擦和空气阻力的合体。它决定了松开油门后能滑行多久，处理不好会感觉车像在冰面上飘。
• 转向角：响应最直接的参数。我最后取的是每帧0.045弧度左右，并且配合速度变化做动态加权——速度越高，转向越钝，这是符合日常驾驶直觉的。

这些参数从哪来？我一开始是让AI“自己看着办”，它给的数值总是偏理想化，比如不会考虑视角距离和赛道宽度对速度感知的影响。后来我直接在提示词里加上“参数范围参考”这一段，比如“最大速度参考值180~220，加速度参考值8~10”，模型的输出立刻正常了不少。

有意思的是，参数本身没有绝对正确，关键是它们之间的比例关系。转向角不匹配最大速度，车就会要么没法过弯、要么极易甩尾——这类比例问题，AI第一次是根本算不出来的，得靠人在试玩中感受。调试时我的建议是：把常数抽出来放到文件顶部的配置对象里，一边跑一边调。AI生成的第一版通常把这些值散落在代码各处，我会让它“把运行参数集中到一个对象里”，它马上照做——这种重构需求对模型来说是小菜一碟。

2.3 赛道与地图的生成逻辑

赛道写法，我用的是“路径点加宽度”的思路。模型定义了一组二维坐标点作为赛道中线，再在绘制时用两个相邻路径点的法线方向往左右两侧延伸出路面宽度，最后用多边形填充成整条赛道。这样做的好处是：调整赛道形状只需要改坐标数组，路面宽窄、弯道急缓都直观可控，加一个换皮赛道几乎不用改逻辑。

导航系统更简单，赛车位置在每个渲染帧里都会换算成“距离赛道起点的累计里程”，再折算成圈数和进度百分比显示在左上角。起点线判定是一个矩形区域，当车辆中心点穿过它且累计里程超过一圈距离时，圈数加一——这就是我强调的“圈数判定逻辑”的落地形式。

碰撞检测部分，AI默认用了最简单的轴对齐包围盒方案：把赛道护栏和障碍物画成一个个矩形区域，每帧检测赛车矩形与它们是否相交。这个方案在2D俯视视角下够用，唯一的问题是视觉上不够精确——护栏边缘和判定边缘会有几个像素的偏差，玩的时候偶尔会觉得“我没撞上怎么就弹回来了”。改善办法是缩小判定矩形，让它比视觉图形小20%，这样手感会宽容很多，不挫伤玩家的操作欲。

3. 实操过程与核心环节实现

3.1 从AI输出到本地运行：三步启动游戏

拿到AI生成的代码之后，整个启动流程快到几乎不需要思考，你需要做的只有三步。

第一步，新建一个文本文件，命名game.html，把AI给的单文件HTML完整粘贴进去。如果你的AI对话输出里有markdown代码块，记得用“复制代码块内容”而不是“复制整段对话文本”，否则会带进去一堆```html的标记，一打开就白屏。

第二步，保存编码选UTF-8。我用VS Code直接存的，如果用的是系统自带的记事本，保存时默认编码容易出错，里面中文注释会变成乱码，这个小坑我在下面的排查清单里细说。

第三步，双击文件，用浏览器打开，方向键开车，Shift漂移。如果你的机器上装了开发者工具，可以顺手按下F12看控制台有没有报错。没有报错，说明游戏已经可以玩了。

我在浏览器里跑第一次的时候，控制台干净得让我意外，除了一个favicon缺失的404提示，没有任何语法错误。坦白说，AI写代码这几年进步最大的就是“能一次性不报错地给出完整可运行文件”，这在早几年想都不敢想。

3.2 关键代码结构解析：AI写得怎么样

为了写这篇笔记，我把AI生成的代码做了结构整理，拆成五个核心部分，几乎对应一个标准游戏的全部要素。

第一部分是全局状态管理。一个游戏状态对象管理了当前速度、转向角、位置坐标、里程、圈数、总时间。这里用对象集中管理状态，比散落一堆全局变量合理得多，后续想加“暂停”或“重新开始”都方便。

第二部分是赛车物理主循环。核心公式就是“位置等于位置向量加上速度向量乘以时间步长”，再叠加摩擦力和转向对速度方向的影响。漂移的实现，本质是让速度方向与车头方向之间多了一个夹角——车辆保有侧向速度，同时把轮胎抓地力调低。这就是为什么甩尾时车会有“横着滑”的视觉效果。这是AI对漂移很聪明的简化处理，起码在2D层面是最优解。

第三部分是赛道渲染。赛道路面用Canvas的路径填充，树木和草地用近大远小的伪3D方式绘制，目的是制造速度感。这部分大量使用了坐标变换，把绘制坐标系从屏幕中心平移到赛车位置，再旋转到车头朝向，这样赛道只需要按全局坐标填充即可，旋转和缩放交给Canvas内部处理。这个设计写得很扎实，我在二次开发时几乎没有重写这块。

第四部分是碰撞检测。前面说过它用的是矩形相交判定，这里我看了一下代码结构，它把护栏拆成了若干个小矩形，每帧拿赛车矩形去和全部护栏杆遍历检测，在正常赛道规模下性能没问题。但如果碰撞体数量成百上千，这块会变成性能瓶颈，优化方式是用空间网格，不过这个Demo完全用不上。

第五部分是UI与输入监听。键盘事件绑定在window上，圈数、速度、时间通过DOM更新。值得注意的一个小细节是：AI把键盘监听分成了keydown和keyup两个事件，而不是用按键状态轮询，这让按住方向键开车时的手感稳定了很多，不会出现忽停忽走的情况。

3.3 第一轮调优：让游戏从“能跑”变成“能玩”

第一次生成就能玩的游戏，离“好玩”还有一段距离。我的第一轮调优只做了四件事，每一件都直击手感软肋。

第一，把参数集中到配置对象里，并在浏览器里开了实时调试面板。我让AI把运行参数全部集中到一个对象里，然后随时改参数、刷新页面就能看到效果。这把调优周期从“改代码-刷新-试驾”缩短成“拖滑块-试驾”，效率提升非常明显。

第二，把转向角随速度变化的曲线改成非线性。AI默认的是恒定转向角，结果高速直行时轻轻一按方向键，车就像跳舞一样横着转。我让它把转向速率挂钩当前速度：车速低于60时，转向最大；车速超过150时，转向角按比例降低。这样高速变稳、低速灵活，驾驶体感立刻上了一个台阶。

第三，修正漂移的恢复逻辑。AI写的漂移，是按下Shift后直接把横向摩擦系数降为零，一松按键立刻恢复正常——结果就是漂移结束的一瞬间车会猛地弹直，非常出戏。我在调优时要求它在松开Shift后的200到300毫秒内，把横向摩擦系数从低值缓慢恢复到正常值，那种“蹭”一下的突兀感就没有了。

第四，加了一个低成本但有效的手感辅助：转向时给车头一个指向速度方向的微小权重，让车辆在转向时自动向切线方向滑一小点。这实际上模拟了一点前驱车“推头”的感觉，玩起来会觉得车是有重量的，而不是一个飘在冰面上的点。

4. 常见问题与排查技巧实录

4.1 AI写游戏时的经典翻车现场

这一轮实测下来，我自己踩过、也帮朋友排查过很多AI生成游戏代码的翻车现场，挑最有代表性的五个说说。

页面白屏。最常见的原因是复制代码时把markdown代码块标记也复制进来了，或者文件保存成了带BOM的编码，导致第一个字符变成一个不可见字节。处理办法是用IDE或纯文本编辑器重新保存一遍，编码格式选UTF-8无BOM。

计时器不走。这个Bug是v1版本的亲历者。根因是圈数判定区域过小或者判定方向搞反，车辆从边缘擦过时没有触发。解决思路是增大判定区域，并且把“穿过”判定逻辑从轴对齐改成“上一帧在起点线左侧、这一帧在右侧”这种方向判断。

方向键控制失灵。大多数情况是页面没有获得焦点，键盘监听加在特定元素而不是window上，或者浏览器里别的扩展抢占了快捷键。我的排查顺序是：先点一下页面空白区再试，然后按F12查控制台看事件绑定报错，最后检查监听目标。

动画很卡。大概率不是AI代码的问题，而是浏览器在一个高刷新率显示器上跑，帧率顶得过高导致性能饱和。可以让AI把requestAnimationFrame里的时间间隔做一次差值计算，让物理更新不再依赖帧率，这同时能解决“在不同电脑上跑速度不一致”的问题。

车穿墙。碰撞盒太小，或者碰撞检测逻辑压根没绑定到正确对象上。前面说过一个通用解法：视觉尺寸和判定尺寸分开，判定盒放宽到视觉尺寸的110%到120%，碰撞体验反而更好，因为玩家感知的碰撞范围通常比精确几何范围大。

这五个问题其实可以合并成一个排查心法：AI生成的代码，先别急着否定它，也别急着删了重写。按“数据是否流动、事件是否绑定、判定是否合理”这个顺序去看，很多时候一条补充说明的提示词就能让它自己修复，比人肉改代码快得多。

4.2 提示词工程的3个避坑点

试了这么多轮之后，我对“提示词写得好不好”总结出三个最容易踩的坑，每一个都是用真实翻车换来的。

坑一：直接给代码，不给意图。很多人在提示词里写“减速方式用摩擦系数0.98”，但完全没告诉模型这个摩擦系数是用来达到什么手感。结果模型照做之后，手感还是不对，因为“0.98”只是手段，你真正要的是“松开油门后2秒内自然停下”这种效果。正确做法是描述效果，让模型自己选参数。

坑二：一次要太多，超过模型的“工作记忆”。把十五个功能全部塞进一句提示词，模型会为了满足所有文字要求，把代码写得臃肿堆砌，甚至顾此失彼。我的建议是分步走：第一轮只要核心驾驶和碰撞；跑通了，第二轮加小地图；再跑通，第三轮加漂移和音量。这样做还有一个额外的好处：每轮新增的需求都是明确边界，模型不会为了兼容所有需求而牺牲主循环质量。

坑三：完全不提“完成标准”。如果你只写“做个赛车游戏”，模型大概率会给你一个没有终点的驾驶模拟器。赛车游戏之所以是“游戏”，在于有胜负和目标。提“完成三圈”或者“限时跑完”，它会想尽办法实现目标状态，代码里才会出现状态机、计时器、排名这些游戏框架的要素。

这三点如果都避开了，提示词的质量就已经超过了大部分用户。

4.3 从“能玩”到“好玩”：后续还能怎么扩展

游戏已经能玩了，剩下的就是纵向加料。我自己后续会按下面这个顺序继续折腾，给大家做个参考。

先加视觉反馈：漂移时留轮胎印、加速时排气管喷火、撞墙时屏幕闪红光。这些效果代码量不大，但对游戏质感的提升是翻倍的，AI实现起来也毫无压力。

再加音乐和音效：引擎轰鸣、漂移摩擦声、冲刺提示音。浏览器自带的音频接口可以直接合成，不需要任何音频文件，AI对这一套其实很熟。

然后加对手：简单做法是往里塞几辆AI控制的赛车，它们的路线直接复用赛道路径点，再给每辆车一个带误差的偏移量——模拟每个车手的走线习惯不同。这一步会让游戏从“单机练习”变成“有对抗感”的竞速。

最后加统计和回放：把每一帧的速度和轨迹记录下来，跑完之后画在赛道小地图上。这个功能的难点又回到数据结构的组织上，AI有能力做，前提是提示词里把“记录哪些数据、画在哪个画布”说清楚。

每做完一项，我就把改动后的完整代码再交回给AI问一句：“基于现在的代码，加某个功能，给我改动级别的说明。”这一步能让AI的增量修改兼容已有代码，而不是每次推倒重来。这也是我目前认为最值得推荐的AI编程工作流——不是一次生成就完事，而是通过一次次的“需求对话”把产品做厚。

最后再分享一个我实际用下来的小技巧：当你发现AI写出来的程序行为和你想的不一样时，先别急着写“修复”两个字，把你观察到的具体现象贴给它。比如“当车速超过120时按左转向，车会先向右滑一段”“圈数在反向穿过起点线时也会加一”。这种带条件的现象描述，比任何抽象的“手感不对”“Bug很多”都更能帮它快速定位问题。本质上，你把它当成一个和你共享代码库的实习生，你的描述越像真实环境里的现象反馈，它给出的修复就越准。

这大概就是“AI写出了能玩的赛车游戏”给我最大的感受：它真正改变的不是“会不会写代码”，而是“一个不会写代码的人，也能把脑子里的游戏做出来”。剩下的关键，就是你愿不愿意先把需求想清楚、把话说明白。