企业官网建设流程全解析

1. 大考设计：为什么拿赛车游戏当考题

最近拿到 Opus5.5 的内测入口，我一直在琢磨怎么给它出一张真正能拉开差距的考卷。常规的问答、摘要、代码练习都太温和，这次我直接选了“做一个赛车游戏”——主题锁定秋名山车神，用纯网页跑起来。说实话，这个测试比我预想的要难得多，也比我预想的要有意思得多。电脑和手机都能打开、能控制、有AI对手、有计时和圈数，整个就是一个完整的、可玩的小游戏闭环。

这个任务对模型来说确实是一场“大考”：需求是模糊的，玩法是有闭环的，物理手感是主观的，bug修复是不可避免的。任何一个环节掉链子，最终交付的东西都不像样。我更看重的是模型在面对这种“半叙述”需求时的表现，而不是它能否背出一段标准答案。所以这篇文章不是单纯夸它有多神，而是把整个实操过程、踩坑过程、修复过程都摊开来讲，给同样喜欢拿大模型“烤”点小东西的朋友做个参考。

1.1 赛车类小游戏，天然就是最合适的“考卷”

为什么偏偏选赛车游戏？这背后有我的考虑。常见的大模型代码测试题通常是“写一个排序算法”“写一个爬虫”“实现一个接口”，这种题目标签清晰、边界明确，模型很容易调用训练数据里的模板，很难测出真实的工程能力。而赛车游戏不一样，它至少要同时处理下面几件事：

• 输入系统：键盘按键的监听、转向和油门的映射；
• 物理表现：速度、加速度、转向、漂移、摩擦，哪怕简化版也得有；
• 碰撞检测：车辆与赛道边界、车辆与车辆之间；
• AI行为：对手车要能自己跑、会刹车、会变线；
• UI反馈：速度表、计时器、圈数、排名；
• 手感调优：转向太灵敏不行、太钝不行，漂移太容易也不行。

这么多子系统集合在一个不到2000行的HTML文件里，既有逻辑，又有交互，还有视觉反馈。对一个号称很强的大模型来说，这是绝佳的综合性考题。需求一句话就能描述清楚，但做成什么样全看模型的理解力和补全能力。游戏能不能玩、好不好玩，一眼就能看出差距，完全不需要什么专业测评工具。

1.2 考纲与评分维度：我给 Opus5.5 立的规矩

考试不能没标准。我在开跑之前先定了一个简易的评测框架，正好也把最近圈子里流行的“鹈鹕测试”玩法套了进去。“鹈鹕测试”的思路很简单：像鹈鹕把一条鱼囫囵吞进嘴里再慢慢化开，你只给它一句模糊的需求，然后看它会不会主动追问关键信息、能不能把模糊描述拆解成可执行的方案，最后再看成品质量。这套玩法非常适合用来测对话型大模型，因为现实开发中几乎没有需求是完全清晰的。

我给这次考试定的核心维度五条：需求还原度、代码可运行率、手感表现、对话迭代效率、bug修复能力。表格如下：

技术栈方面我提前限定为“HTML + Canvas + 原生JavaScript”，要求单文件实现，因为这样最方便直接跑。我没有限定更细的玩法，也没告诉它赛道长什么样，想看看它在“俯视角2D赛车”这个大前提下能补全出什么。说实话，第一轮输出就让我有点意外，后面几轮迭代更是刷新了我对它的判断。

2. 首轮对话：从一句需求到第一版能跑的游戏

这次测试我没有做任何铺垫，没有给示例代码，也没有写“请一步一步思考”这种提示词，直接抛出了需求。我想看的就是它面对原始需求的第一反应。

2.1 我丢给模型的第一句话

我用的原始Prompt是这样的：

请用HTML+Canvas+原生JavaScript，做一个赛车小游戏，名字叫“秋名山车神”。俯视角2D，玩家用方向键控制一辆白色赛车，在蜿蜒山路赛道里跑圈。要有至少3辆AI对手车，有速度表、圈数和计时，有简单的漂移效果。所有代码写在一个HTML文件里，方便浏览器直接打开运行。

这个Prompt里我故意保留了一些模糊地带：没有说赛道具体多长、没有说漂移的触发方式、没有说AI对手的难度、没有说页面长什么样。好的模型应该能自己补全这些细节，而不是反过来只给你一个空架子。Opus5.5收到后没有反问，而是直接给了一版完整的实现，并且附带了一小段说明：它选2D俯视角是因为这个视角实现赛车游戏手感最直接；用Canvas是因为单文件跑起来零依赖，不需要构建工具；AI对手采用“路径点跟随”方案，因为比真实的自动驾驶逻辑简单得多，但视觉效果已经足够。

这轮输出我很满意的一点是，它在代码注释里写清楚了关键参数的含义和调法。比如转向角限制、摩擦系数、AI跟随的路径点间隔，都是单独成块的常量。这种“工程意识”在纯代码生成任务里并不常见，大多数模型只会把逻辑跑通，不会考虑你之后怎么改。

2.2 第一版Demo的运行效果与核心代码

把代码存成qiushan.html，浏览器打开，第一眼还挺像那么回事：深灰色路面、白色虚线、绿色草地背景，一辆白色小赛车在屏幕中央，右边有三辆不同颜色的AI车在跑，左上角是速度表和圈数，右上角是计时器。方向键控制，上键加速，下键刹车，左键右键转向，按一下空格触发漂移。

第一版代码的核心是一个标准的主循环加更新函数，结构非常规整：

function update(delta) { // 玩家输入处理 if (keys['ArrowUp']) car.speed += car.accel * delta; if (keys['ArrowDown']) car.speed -= car.brake * delta; if (keys['ArrowLeft']) car.angle -= car.turnRate * delta; if (keys['ArrowRight']) car.angle += car.turnRate * delta; // 速度衰减（摩擦与风阻） car.speed *= Math.max(0, 1 - car.friction * delta); // 车辆位置更新 car.x += Math.sin(car.angle) * car.speed * delta; car.y -= Math.cos(car.angle) * car.speed * delta; // 漂移：按住空格时横向滑动量增大 if (keys['Space']) { car.slideAmount = Math.min(car.slideAmount + 20 * delta, car.speed * 0.35); car.x += Math.cos(car.angle) * car.slideAmount * delta; car.y += Math.sin(car.angle) * car.slideAmount * delta; } }

运行下来第一感受是“能玩但不好玩”。方向键响应没问题，圈数也能正常累加，AI车也确实在赛道里跑，但从秋名山车神的标准看，手感完全不合格：转向像在冰面上转圈，车辆几乎没有惯性和抓地力；所谓的漂移只是横向滑一下，车身姿态完全没变化；赛道虽然弯多，但AI车到了弯道也不减速，经常直直冲进草地里再瞬移回来，观感很出戏。

这里我需要给Opus5.5一个客观评价：第一版能做到“能跑、能开、能计数”，已经超过了大多数通用模型的平均水平。我以前拿其他模型试过同样的题，有的第一轮就输出一大堆组件代码结果跑起来白屏，有的连Canvas尺寸都会搞错。但第一版也确实只是骨架，离“玩起来有手感”还差得远。所以真正的考试才刚刚开始，接下来才是考验理解力和迭代能力的时候。

3. 手感攻坚：飘移、碰撞与赛道设计

一句话需求里最难的部分不是“跑起来”，而是“好玩”。方向盘轻重、漂移手感、AI对手的强度、赛道的节奏感，这些主观且难以量化的东西，恰恰是大模型生成代码时最容易翻车的点。第二三轮对话，我全部精力都花在调这些细节上。

3.1 车辆物理与“秋名山”漂移手感调教

要谈漂移，先得让模型理解“漂移不是横向瞬移，而是抓地力与侧滑的平衡”。第一版的实现是伪漂移：按空格就往侧边滑一下，跟车辆方向和速度完全没有联动，真开过赛车游戏的人一眼就能看出问题。我把这个问题直接反馈给Opus5.5，它在第二轮给出了一套简化物理模型：

// 将速度分解为车头方向分量和横向分量 let forwardV = car.speed; // 沿车头方向的速度 let lateralV = car.lateralSpeed; // 横向滑动速度 // 正常抓地时，横向速度快速衰减 lateralV *= Math.pow(0.05, delta); // 普通状态恢复极快，保证稳定性 // 漂移时，横向速度衰减变慢，同时前向速度轻微损失 if (keys['Space'] && forwardV > 40) { lateralV = Math.sin(steerDiff) * forwardV * 0.45; forwardV *= (1 - 0.012 * delta); // 漂移损速 }

这套模型的思想很清晰：把车辆速度分成“纵向”和“横向”两个独立分量，正常情况下横向分量快速归零，让车保持稳定；一旦按下漂移键，横向分量不再急于归零，而是根据转向角度产生侧滑效果，同时前向速度适当损失一点，模拟轮胎打滑的代价。我用“简单但物理上说得通”来评价这个方案，它虽然远不如真实物理引擎精细，但在小游戏里已经足够还原漂移的核心体验。

代码改完，手感比第一版好了不止一个档次。但我又遇到了新问题：漂移太容易失控，有时按一下空格车就直接甩到赛道外面。这就是参数调校的活。我在对话里要求模型把转向灵敏度、漂移强度、摩擦系数这些全部抽成带默认值的参数区，然后自己在浏览器控制台里用不同的数值试手感。最后定下来的一组参数是：转向灵敏度0.045、前向摩擦系数0.25、漂移横向速度系数0.45、漂移损耗系数0.012。这套数值跑起来，秋名山那种“入弯减速、出弯加油、甩尾过弯”的节奏基本能实现。

3.2 赛道边界与AI对手：让游戏“活”起来

第一版的赛道是手工画在画布上的，边界只是一圈绿色和灰色交替的色块，车压到草地并没有任何反应，随便开哪都不会被拦。这对赛车游戏来说是致命伤：玩家的成就感来源于“在赛道内跑出好圈速”，如果赛道没有约束力，游戏就失去了核心挑战。我要求Opus5.5加上真正的赛道碰撞检测，并且尽量让赛道看起来更像山路：连续弯道、稍微收紧的路肩、偶尔出现的窄路段。

模型给出的方案是基于路径点的赛道生成：赛道由一列路径点定义中心线，通过垂直于中心线方向扩展得到左右边界，玩家车辆每帧检测与左右边界最近的线段距离来判断是否撞墙。这套方案的优点是赛道形状可配置，改路径点坐标就能重排赛道布局，非常适合快速迭代。它生成的默认赛道路径点有14个，第1组坐标模拟连续S弯，中间组模拟长直道加发卡弯，后半程又加了两个连续的急弯，整体布局有点秋名山的意思了。

AIAI车方面，Opus5.5直接做了一个“路径点循环追踪”逻辑：每辆AI车都有一个目标索引，不断朝下一个路径点前进，到终点附近就切换索引；转弯时根据前方路径点的夹角自动减速，如果检测到玩家在正前方，会稍微横向偏移让出路线。这个AI虽然简单，但跑起来效果不赖，配合不同AI车各自的“激进参数”（有的入弯才减速，有的提前很远就刹车，有的最高速偏慢但极稳），让排名变动很有戏剧性。第一版AI那种直直冲出赛道再瞬移的问题彻底消失。

赛道边界加上之后，游戏的可玩性明显上了一个台阶。我第一次完整跑完三圈竟然产生了“再开一圈练练手感”的念头，这已经比市面上不少粗糙的网页小游戏要好了。但我心里清楚，这背后的功臣不是某一段代码，而是Opus5.5在多轮对话中表现出的“迭代吸收能力”：它能准确理解我上一轮反馈的痛点，在保留原有代码结构的前提下做外科手术式的修改，而不是每次需求变化就重写整个游戏。这一点非常关键，后面我会展开讲。

4. 实测问题与排查实录

任何项目做得再顺，也一定有翻车时刻。这轮测试我特地全程记录了bug出现和修复的过程，因为这一块最能看出大模型的真实debug能力：是“瞎猜着改”还是“读懂错误后精准下手”，差别很大。分享两个最典型的bug复盘，附上我的排查思路以及我是怎么跟Opus5.5对话的。

4.1 两个典型bug的完整复盘

第一个bug是圈数识别混乱。第1圈正常，第2圈开始计时器和圈数显示有时候会跳，我明明刚过起跑线，它却显示“已完成2圈”，下一圈又跳回“当前第1圈”。这属于逻辑层bug，常见的错误是把“检测到通过检测点”当成了“完成一圈”，或者检测点设置在了起跑线附近导致来回横跳时重复触发。

我把这个现象连同描述发给Opus5.5，让它检查一下圈数判定逻辑。它很快定位到问题：第一版代码里圈数增加的条件是“玩家通过最后一个路径点”，但最后一个路径点离起跑线太近，玩家如果在起跑线附近来回掉头或者擦边过线，就会重复触发计数。它的修复方案是增加“圈数状态机”：记录当前圈数、通过哪些检测点，只有按顺序完整通过所有检测点之后，圈数才加1，同时重置检测状态。这修复了乱跳问题，但引入了一个新的小问题：如果玩家从中间某段赛道反向行驶，检测点顺序永远无法满足，圈数就会卡住不动。我继续反馈，它在下一轮又加了一个反向修正逻辑，检测到反向行驶时先不惩罚玩家，而是要求玩家先掉头再正常跑圈。整体修复过程非常顺利，没有出现把好代码改坏的情况。

第二个bug是高速漂移时直接穿墙。车辆明明撞到赛道边界了，却没有触发应有的减速和回弹，车子像幽灵一样穿过边界到外侧草地，随后又穿回来，非常出戏。这类bug通常出在碰撞检测的采样逻辑上：如果只检测车辆中心点在不在赛道内，连续两帧之间的位移很大时，中心点可能一帧在赛道内、下一帧已经跨过边界到了赛道外，由于采样点跳过边界，碰撞永远检测不到。

Opus5.5给出的修复思路是“扫掠检测”：不是只看当前帧的车辆中心位置，而是把上一帧到当前帧之间车辆走过的线段作为检测样本，跟左右边界的线段做交点计算，一旦有交点就判定碰撞发生，并把车辆位置回退到交点位置，同时把沿边界方向的速度分量保留、垂直方向的速度分量衰减。这个方案在赛车游戏开发里是比较标准的做法，模型能自己提出“扫掠检测”而不是简单地把碰撞检测频率翻倍，说明它对这类问题的经验覆盖面确实广。修复后我再试高速漂移，车辆撞到路肩时会有明显的“擦一下”减速效果，偶尔还会触发一个侧滑修正，手感反而更真实了。

4.2 从“鹈鹕测试”的角度看它的表现

我前面提到的“鹈鹕测试”，核心玩法就是给模型一句高度模糊的需求，看它能否通过追问或自行假设来推进任务。这次Opus5.5的表现让我印象很深，它没有在收到第一句需求后喋喋不休地问问题——那其实是很多模型的通病，动不动就是“请问您需要2D还是3D？需要移动端适配吗？需要后端吗？”，问完十来个问题用户已经失去耐心。Opus5.5的策略是先按最合理默认补全，再在输出说明中标注“我假设了XX，如果需要调整可以告诉我”。

这个策略在真实协作里非常讨喜。你看，用户要的是一个能直接玩起来的赛车游戏，不是一套需求调研问卷。先交付一版可运行的demo，再通过对话调优，这才是大模型对话式开发的正道。到第三轮迭代时，我已经对它的“需求补全能力”打了很高分：我提“秋名山车神”，它会主动联想到“山路、连续弯道、漂移、发夹弯”这些关键词，而不是做一个普通环形赛道；我提“手感差”，它会从物理参数层面反向推导可能的原因，而不是简单地把速度调慢或者把转向调灵敏。

鹈鹕测试视角下的一个小遗憾是：它不会主动做可玩性验证。也就是说，它生成完代码不会自己去跑几圈，感受手感如何，它的世界没有“手感”这个概念。所有主观调优仍然依赖我把感受反馈给它。这不算缺点，但大家在使用AI生成游戏类项目时要有预期：AI负责逻辑，你负责品味。

5. Opus5.5 综合能力评价与适用边界

游戏跑顺以后，我回过头来给整体表现打了一个比较客观的分。很多人一看到AI写游戏就喊“牛逼”，但我更关注它在整个流程里到底哪些环节强、哪些环节弱，这决定了你以后能不能放心把类似项目交给它。

5.1 分项打分表

按我预定的五条维度打分，满分为20分，最终总分90分：

单项最强的其实是“需求还原度”。它抓概念很有一套，几乎没有出现文不对题的情况。最弱的是“手感表现”，不是说它物理模型写得差，而是它没法自己感受“漂移是否爽快”，这需要人的主观判断。不过这也提醒了我：大模型目前最适合做“从0到80分”的工作，剩下20分的手感调优，本质上是艺术，必须真人上阵。

5.2 适合做什么，不适合做什么

这一轮测试让我对Opus5.5的边界有了更清楚的认知。先说适合的场景：

• 小型游戏原型：像赛车、贪吃蛇、打砖块这类一两千行内的单文件游戏，它担当主力没问题；
• 数据处理脚本：清洗、转换、统计，有输入输出样例就可以让它直接上手；
• 前端页面组件：写一个可复用弹窗、轮播图、表格组件，效率极高；
• 自动化脚本：文件批处理、批量改格式、定时任务，描述清楚需求直接出脚本；
• 教学示例代码：需要“简单、完整、可运行”的示例，比在文档里找半天要快。

不适合的场景也有几个。需要实时物理引擎强表现力的项目，比如给车辆做多悬挂模拟、给轮胎做热衰减模型，它给的方案会比较简化，撑不起专业赛车模拟，真要做专业方向还得靠Unity或UE，让AI去写插件脚本可以，让它直接造核心物理层不行。多语言大型工程也不适合，跨文件调用、模块依赖、复杂构建链，它单次对话的上下文根本装不下。还有一个明显的短板：一旦需求本身有审美判断，比如“这个界面要有高级感”“这个配色要更赛博一些”，模型的理解会落入泛化模板，出来的东西常常一眼AI味，需要大量人工调教。

所以我的结论是：它是很好的“结对程序员”，但不是“独立外包团队”。你让它单独做一个小游戏很靠谱，让它带你干一个大项目很靠谱，唯独让它从零给你交付一个完整商业级产品还不太现实。设定合理预期，才能真正用好它。

6. 做这类小游戏时，我给自己的三个实操建议

测试结束了，但我自己从这轮对话里学到的东西，可能比模型输出的代码更有价值。最后分享三个实操层面可以直接复用的经验，都是我反复踩坑后摸索出来的。

第一点：一定要用“多轮短对话”，不要用“一次性超长Prompt”。我最开始试过把“要什么赛道、什么手感、什么AI难度、什么UI风格”全部写进一句话里，结果模型输出的代码反而更糟糕，因为约束条件太多，它反而抓不住重点。更聪明的做法是：第一轮只给最少需求，跑起来以后再逐轮加细节。这和真人开发是一样的，先打通主干，再填枝叶。Opus5.5对“改动”的理解能力很强，你完全不需要怕多轮对话会把它绕晕。

第二点：把报错信息原封不动地扔给它。遇到bug的时候，不要用“车子穿墙了我很烦”这种情绪化描述，最好的输入就是浏览器控制台的错误原文，加上你做了什么操作导致的。比如“ReferenceError: car is not defined at update (qiushan.html:line 87)”，它几乎能秒回定位和修复方案。Opus5.5在处理具体报错时精准度惊人，但前提是你要给它精准的线索。

第三点：让模型把可调参数集中放在代码开头。这个习惯真的值回票价。模型生成的游戏代码，如果参数都硬编码在逻辑深处，你每次想改手感都得在几百行代码里找。我在第二轮就让Opus5.5把所有变量抽成配置区，之后每次调漂移强度、AI速度、赛道宽度，都只需要改前几行的数字，浏览器刷新即可生效。这种“调试友好的结构”对任何代码生成任务都适用——你把调参区单独提出来，模型后续的修改也能精准定位到对应变量，大幅减少改动引入的副作用。

如果你也想拿Opus5.5或者类似的模型自己做一个赛车游戏，我的建议是找个下午，先定好一句话需求，然后把每一轮的感受和想法都记下来，像跟真人协作一样去反馈。它写出第一版可能很粗糙，但那只是起点，真正有意思的是后面那一轮轮的打磨过程，你会亲眼看到模型怎么把一块毛坯变成一件勉强能炫耀的作品。至少这轮“秋名山车神”测试，我总体是满意的，也期待后续模型在手感这类“主观领域”能更进一步。