企业官网建设流程全解析

1. 这笔账是怎么算的：一句话让 AI 写游戏

先说结论：我花了一个下午，用一句话提示词，让当前几个顶级大模型轮番上阵，最终产出了一个“能玩”的类 QQ 飞车网页赛车游戏。不是只有一辆车在直道上傻跑的那种“能玩”，而是有漂移手感、有弯道、有计时、有圈数、有碰撞反馈，能让人在页面上开上十几分钟不腻的简化版本。

先说清楚这次试验要解决什么问题。很多朋友用大模型写代码，最多让它生成一个“倒计时”或者“Todo List”，稍微复杂一点的项目就开始失控。赛车游戏是个非常好的测试样本——它涉及连续输入、逐帧更新、碰撞检测、场景渲染、状态管理、UI 交互，复杂度刚好卡在“一句话项目”的边界上。太简单测不出模型的规划能力，太复杂又容易让对话上下文失控，赛车游戏这个体量刚刚好。

这次实践过程中，我用到的核心思路有三个：把人话翻译成约束、把控制权交给模型但保留裁判权、用多轮对话而不是重开会话来修正问题。后面展开说。

适合谁来参考？如果你是刚开始用 AI 写小作品的新手，这篇文章可以告诉你提示词到底要怎么组织；如果你已经在用 AI 辅助开发，值得看看我是怎么拆解需求、怎么让模型自己找 bug 的。我会把提示词原文、模型生成的代码逻辑、我在调试过程中踩的坑都放出来，照着做也能复现。

2. 提示词设计：从一句话到可运行代码

2.1 一句话提示词的成型过程

先放最终版的提示词，这是整件事的起点：

请用 HTML、CSS 和 JavaScript 写一个单文件的网页赛车游戏。游戏风格类似 QQ 飞车，俯视视角，玩家控制一辆蓝色赛车在环形赛道上行驶。要求包括：方向键控制前后左右；赛车与跑道边缘有碰撞检测，撞墙后减速反弹；按住空格键漂移，漂移时赛车会有明显的侧滑轨迹特效；赛道呈圆形，路面颜色深灰，赛道边缘用红白相间路肩标示；游戏画面右上角显示当前圈数和总圈数（总圈数设为 3 圈），左上角显示用时；通过终点线自动计圈，跑完 3 圈弹出结算画面，显示总用时；背景允许为渐变色的公园俯视风格，配上简单的云朵图案；音量等设置一律不需要。所有代码放在一个 HTML 文件中，不要依赖任何外部库。

这段话一共 220 个字左右，但它里面其实塞了 12 个明确的“验收条件”。有人会奇怪，不是“一句话”吗？为什么还是一大段？

这里要说明一下“一句话”在 AI 生成任务里的真实含义。你给模型的第一条指令可以是一句话，但这句话内部必须有结构。大模型处理自然语言本质是在做“条件索引”，你把需求说得越具体，它就越容易把对应功能的代码块从训练数据里检索出来并组装到一起。如果你只丢一句“帮我写个赛车游戏”，模型很容易给你一个连碰撞都没有的 demo，因为你没有把生存空间给它限制死，它就走向了“最通用的实现”。

我一开始也没有这么复杂的提示词，第一版很短：

帮我写一个赛车游戏，用 HTML canvas。

结果生成的文件 500 行，能跑，但赛车可以无视物理规则直接穿墙，漂移更是完全不存在的功能。后面我把每一次测试发现的问题“翻译”成提示词里的约束，一轮轮加进去，才得到上面的最终版本。

2.2 为什么“一句话”比“长篇花哨提示”更可靠

有些朋友喜欢写那种充满形容词的提示词，比如“请以极致的专业水准设计一个优雅的赛车系统，充分体现逼真的物理引擎”，这类废话对模型没有任何增益，反而会稀释真实约束的权重。

我这次体会最深的点是：大模型是在用“概率”写代码，不是用“逻辑”写代码。它生成每个 token 的时候都在猜下一个最可能出现的字符是什么。你给它“逼真”这种模糊词，它可能猜你在说“用物理引擎”，但不会猜你要的是“卡丁车风格、抓地力低、漂移时要带尾迹”这种具体效果。

所以提示词工程的核心只有一句话：把抽象目标翻译成可验证的行为约束。就像你请一个外包工程师写代码时，你说“给我做一个能跑的赛车游戏”，他给你交付一个“能跑”的网页也就是 10 分钟的事；但如果你说清楚“遇到赛道边缘必须减速反弹”“按空格时赛车侧滑”这些行为条件，他交付的东西才是你真正想要的。

这里给一个非常实用的技巧：当你发现 AI 生成的代码不符合预期时，不要重新开一个对话重写提示词，而是在当前对话里追加一条修正指令。比如我第一版赛车穿墙，我就追加：

赛车不能直接穿过赛道边缘，碰到边缘时应该被反弹回来，同时速度降低。

修改后的代码马上引入了碰撞检测，而且只改了对应函数，其他逻辑没被破坏。这说明大模型的上下文记忆能力非常强，追加修正往往比重开会话效率高得多。

3. 核心功能拆解：赛车游戏中最容易被 AI 写崩的三块

3.1 移动与漂移：AI 最容易“偷懒”的部分

赛车游戏最难写，也是 AI 最不愿写的地方就是漂移。为什么？因为漂移的本质是“车辆在保持前进动量的同时施加横向速度”，这需要维护一组车辆状态变量：位置、速度向量、朝向角、角速度。很多 AI 生成的赛车游戏干脆不做漂移，只做“左右转弯时车身朝向跟随速度方向”——这是一种简化处理，玩家会感觉车像在冰面上滑行，但不是漂移。

我在提示词里专门把这个行为拆开写：按住空格时施加额外的横向力，同时生成尾迹粒子。模型最终给出的漂移实现用了这样一个流程：按键检测到空格时，velocity 不变但 lateralVelocity 增加一个恒定值，车身 angle 随横向速度逐渐偏移。它还把漂移期间画轮胎印的逻辑做成了每隔 16ms 在轨道上画一个小半透明圆点的粒子效果。这个思路不算精妙，但足够稳定。

如果你也想让 AI 写出靠谱的漂移，建议在提示词中给一个可参照的“行为曲线”：漂移是“先减速、再侧滑、最后回正”。光说“漂移”模型未必知道你要的是哪种手感，但你把它在玩家眼里的表现描述出来，模型就能更容易找到对应的实现模式。

3.2 赛道与碰撞：线段级判断不能省

第二个容易写崩的地方是碰撞检测。简单做法是给赛道边缘定义一组矩形，然后检测赛车矩形是否和边缘矩形相交。但圆形赛道用矩形模拟会出现锯齿状的碰撞边缘，难看且手感差。

我最初生成的那一版用的是矩形碰撞，跑起来之后赛车经常卡在某个拐角处抖个不停，很影响体验。后来追加提示词要求“碰撞检测必须基于赛道边缘线段与赛车圆心的距离”，模型改成了线段距离判断的方式：把赛道外圈和内圈分别拆成一圈线段，计算圆心到每条线段的距离，如果距离小于赛车半径就触发反弹。这样碰撞边界就圆滑了，手感大幅改善。

注意：这里有一个提示词技巧，不要和模型说要“用数学方法写碰撞检测”，而是描述行为：碰撞后赛车应该从圆心沿法线方向被挤出。模型听到“圆心”“法线”这种词会自动联想到几何运算，比你说“用圆和线段求交”更不容易把代码写坏。

3.3 计时、圈数与结算：状态机不能交给意外

最后一个容易崩的地方是“圈数统计”。很多 AI 甚至人类新手在处理计圈时都会犯一个错误：每碰到一次终点线就加一。如果玩家在终点线附近反复横跳，圈数会疯狂增加。

模型生成的思路倒是比较稳：它把终点线记录为一条线段，只在玩家“从赛道外方向驶入内方向跨越终点线”时才判定完成一圈。这里的关键是“方向性判定”，而不是单纯的距离判断。

它用了一个很聪明的检测：保存赛车上一帧的位置坐标，和当前帧坐标连成一条运动线段，再判断这条线段是否与终点线相交，同时检查赛车速度方向与终点线法向量的夹角度数。只有夹角小于 90 度才认定是正向通过。这个逻辑成功避免了倒车刷圈的情况，也让我省去了自己写状态机的功夫。

不过 UI 部分它做得比较糙：右上角圈数显示第一次生成时只有 5 像素大小，根本看不清。我在后续修正里加了一句“圈数文字至少 24 像素，加粗，且用半透明黑底衬托”，才算是真正“能看”。

4. 实操过程：第一版生成、调试与多 AI 协作

4.1 生成第一版：把对话当黑板报

第一次生成是最有仪式感的一步。我把最终版提示词输入模型，它用了大约 40 秒输出了一整个 HTML 文件，总共 870 行。我把文件拉下来，双击打开，第一感觉是：能跑，但问题和优点同样明显。

优点是整体架构是对的，主循环 requestAnimationFrame、键盘事件监听、车辆对象、赛道绘制数组、UI 文字，全部各就各位。缺点我钱一开始说了：碰撞是矩形模型，漂移压根没有实现，圈数统计还停留在“碰到线就加一”的朴素质朴阶段。

这批问题其实不是模型能力不够，而是提示词对“行为约束”的描述还不够细。我后来仔细比对了第一个版本的提示词和最终提示词，发现只增加了“漂移侧滑轨迹”“碰撞后减速反弹”“按方向判定计圈”三组行为描述，代码实现就出现了质变。

这说明一个规律：你用大模型写项目，第一版的期望值不应该是“直接能玩”，而应该是“骨架正确”。骨架对了，后面迭代才有价值。骨架错了，比如模型用 canvas 之外的技术栈，或者忘记了键盘事件，那就果断重开对话。

4.2 修 bug：让模型看错误日志改代码，而不是自己动手

我第一次让模型生成的版本在 Chrome 里打开，控制台立刻跳了一个 TypeError。本来我可以直接改那个变量名，但我故意把这个错误信息复制到对话框里，发了一句：

报错：Uncaught TypeError: Cannot read properties of null (reading ‘getContext’)，请分析原因并直接修复。

让我意外的是，它没有只改那一行，而是自动把初始化代码重构成了一个 init 函数，并在 DOMContentLoaded 事件里调用。原因是它判断出 canvas 元素在脚本执行时还没被解析加载完，原来的写法是脚本放在 body 末尾所以侥幸能跑，但如果有任何导致 script 提前执行的因素就会瞬间崩掉。这次重构成 init 函数后，我再把文件改成异步加载模式也没问题了。

这个经验我想重点强调：不要自己动手改 AI 的错误，而是让 AI 自己改自己的错误。你把错误信息发回给 AI，它能看到自己写的完整上下文，修复的成功率和准确性比你手动补一行代码要高得多。人类手动改一个局部错误往往不留神就把后面的逻辑带跑偏，AI 在改的时候会同时检查相关变量有没有被影响到，这种“全局复位式修 bug”的能力在多人协作项目里也确实少见。

当然，前提是每轮对话的上下文窗口足够大。我实测下来，一次会话连续修 15~20 轮 bug 以后，模型会开始“忘记”前面的一些约束，比如会突然把总圈数从 3 圈改成 5 圈。这时候一定要开新会话，把当前跑通的版本代码粘回去作为新上下文起点，再继续迭代。这种“粘贴当前版本+要求修改某个点”的操作，比在原会话里死磕，质量高非常多。

4.3 多 AI 协作：不同模型互相审代码

说到多 AI 协作，这是我这次试验最大的收获之一。我一开始只用了一个顶级模型生成代码，后来换了一个不同风格的模型，让它审查同一份代码。结果它立刻指出原版本在赛车出发位置的定义上存在边界风险：车辆初始坐标为 (0,0)，但画布左上角也是 (0,0)，如果车辆开始移动前没有先把坐标变换到赛道起点，第一帧画面赛车会闪烁在左上角。这确实是原模型没有处理的一个视觉细节。

我后来养成了一个“双模型交叉验证”的习惯：A 模型写代码，B 模型当代码审查员。你不一定要开两个浏览器，现在的聊天式编程工具都支持切换模型，我实际是在一个集成 AI 编程环境里并行开了两个会话，一个负责开发，一个负责评审，之间的对话可以随时拖拽。

这种协作模式的价值在于训练数据的不同分布会带来视野盲区的互补。一个模型觉得“这段代码没毛病”，另一个模型可能立刻指出“这段代码在低帧率环境下会累积误差”。机器之间互相挑刺，比人机之间单向提问更容易挖出深层问题，这也是我从“把 AI 当搜索引擎”到“把 AI 当结对程序员”的一次转变。

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

5.1 提示词不够具体，模型理解错需求

这是发生率最高的一类问题。同一句话说给 AI，它理解的和你心里想的可能完全不是一回事。

举个例子：我早期提示词里写了“游戏风格类似 QQ 飞车”，模型直接在赛道旁边写了密密麻麻的建筑物和立交桥，背景用了赛博朋克霓虹色。我没有说这是不对的，但和我设想的“公园俯视风格”完全不是一回事。

解决方法是：给风格描述提供一个“反面对照”。我在提示词里加了“背景允许为渐变色的公园俯视风格，配上简单的云朵图案”。模型从那以后就再也没有跑偏过。这个技巧其实适用于所有风格类描述——AI 不擅长从正面理解“高级感”“华丽感”，但擅长听“背景是什么”、“不要什么”。

我把常见需求表达错误列成了一张表，方便你对照检查：

5.2 生成的代码运行慢或者卡顿

还有一类问题是性能，尤其是粒子特效。模型第一版尾迹粒子会在漂移时不断往数组里 push，同时不限制粒子总数，跑了半分钟以后掉帧严重。模型本身没有性能意识，需要你在提示词或后续修正里明确“粒子数量上限不超过 100，超出后自动删除最早的粒子”。

这个限制条件是非常有用的。我实测在同一台低配笔记本上，不加粒子上限的帧率稳定在 28fps 左右，加上限制后稳定在 58fps 以上。

另外，如果你发现模型生成的主循环里使用了 setInterval 来做帧循环，一定要让它改成 requestAnimationFrame。因为 setInterval 的固定时间间隔在后台标签页会被浏览器节流，而 requestAnimationFrame 是浏览器原生优化过的逐帧回调机制，两者在不同性能设备上的流畅度差异非常大。

5.3 兼容性与其他坑

不同浏览器的 canvas 行为差异也是一个隐藏坑。Chrome 里一次绘制 200 个粒子很流畅，但在 Firefox 低版本需要把粒子绘制时的 shadowBlur 去掉才能保持流畅。这个属于极端情况，但如果你要分享出去给别人玩，建议生成代码后再加一条提示词“确保代码在 Chrome 和 Edge 浏览器中运行流畅”，模型通常会在绘制循环中做一次兼容性判断。

还有一个小坑是字体问题。模型生成的结算页面用了系统字体 Microsoft YaHei，在 macOS 上会自动降级成苹方，观感还行，但如果直接用中文项目发布，建议在提示词里不要指定具体字体名，而是用“无衬线字体，微软雅黑或苹方”这类描述，模型会自然生成合理字体栈。

6. 收个尾：一点个人体会和后续方向

最后分享一点我自己的体会。很多人把“AI 写游戏”当成一个魔法，期待一句提示词直接出神作，这其实是对 AI 能力的误判。AI 写代码更像是一个“高水平的初级工程师”，它能快速搭骨架、快速改 bug，但对需求的品控、对细节的把握、对代码下一步可能崩在哪里的预判，都需要你这个“技术负责人”来把关。你才是真正的项目经理，模型只是你的执行者。

整个试验做下来，我最喜欢的一个瞬间是把最终生成的 HTML 文件发给一个完全不写代码的朋友，她打开后玩了三圈，然后问我“你这个网页是从哪里下载的”。这句话比任何测试指标都让我满意，因为它说明产品已经“泯然众人”了，玩家根本不会去在意背后的技术是 AI 写成还是真人写成。

如果你想在这个项目上继续扩展，我建议下一步可以做两件事：一个是让赛车支持双人同屏分屏模式，把键盘操控拆成两套按键，这会对代码架构提出比较大的挑战；另一个是让 AI 生成一个简易的赛道编辑器，让玩家自己画赛道边界，再由程序自动生成碰撞线段。这两件事的核心都不是“写代码”，而是把“你想要的手感”翻译成“行为约束”，这是比任何提示词都重要的底层能力。

我的建议是，你可以直接拿我上面那版提示词去跑一遍，自己感受一下从第一版生成到最终调校完成的整个闭环。过程中你会遇到和我类似的坑，也会踩到一些新的坑，但只要你记住“把需求翻译成可验证的行为约束”“让 AI 改自己的错误而不是自己动手改”“必要时开新对话继承上下文”这三个原则，AI 就是一件趁手的工具，而不是一个炫技的玩具。