企业官网建设流程全解析

1. 从一句"两小时出demo"说起：这件事到底靠不靠谱

先把结论摆在前面：AI 两小时生成一个能跑、能玩、有完整循环的游戏 demo，是可行的，但前提是你得把"生成"这两个字理解对。很多人第一次听到这个说法，脑子里浮现的画面是——打开某个工具，输入"做一个赛博朋克地牢游戏"，然后泡杯咖啡回来，一个成品就躺在那里了。如果你抱着这个预期，那大概率两小时后你会对着屏幕骂人。

我这次做的《霓虹地窖》（Neon Cellar），是一个俯视角的霓虹风格地牢探索小 demo：玩家控制一个发光的小方块，在随机生成的地窖房间里移动、躲避巡逻的敌人、收集能量核心、找到出口进入下一层。核心循环就四件事——探索、躲避、收集、下楼。听起来简单，但从零到能玩，中间涉及代码架构、美术资源、音效、数值调优、打包发布一整条链路。

我实际记录了一下时间：从打开编辑器到 demo 能完整跑通一轮，净耗时 1 小时 52 分钟。这个数字不是用来炫技的，而是想说明一个事实——AI 把"从想法到可运行原型"这段路压缩了，但没有把"从原型到好玩"这段路压缩。两小时能给你的是一个骨架完整、逻辑自洽、可以拿给别人试玩的 demo，而不是一个能上架的产品。

这篇文章写给两类人：一类是想快速验证游戏创意的独立开发者，手里有一堆点子但没时间一个个做原型；另一类是好奇 AI 在游戏开发里到底能干到什么程度的从业者。我会把整个流程拆开，讲清楚每一步 AI 做了什么、我做了什么、哪些地方 AI 帮了大忙、哪些地方它反而拖了后腿。关键词里的AI、游戏 demo、游戏原型这三个词，基本就是全文的主线。

需要提前说明的是，下面提到的所有工具选型和参数，都是基于我个人实践和常见行业做法给出的合理方案，不是唯一解。你完全可以用别的组合达到类似效果，重点是理解每一步背后的逻辑。

2. 开工前的取舍：为什么我选择"文本驱动 + 程序化美术"这条路

2.1 两小时的时间预算，决定了技术栈必须"轻"

时间预算是整个项目的隐形约束。两小时意味着我不能碰任何需要长时间学习或配置的东西。所以我在开工前五分钟就定下了三条铁律：

• 引擎选最熟的。我选了 Godot，因为它的场景系统轻、脚本语言 GDScript 上手快、导出流程简单。如果你更熟 Unity 或别的引擎，别换，换引擎的学习成本会直接吃掉你的时间预算。
• 美术全部程序化生成或极简几何体。不做手绘、不做建模、不找素材包。霓虹风格天然适合用纯色矩形加发光效果来表现，这正好是程序化美术的舒适区。
• 音频用合成音效。不下载音源，用代码生成简单的方波、噪声，或者用引擎自带的音频工具现场调。

这三条铁律的本质是：把"需要审美判断和手工劳动"的部分压到最低，把"需要逻辑和结构"的部分交给 AI。因为 AI 目前最擅长的是写有明确规则的代码，最不擅长的是替你做审美决策。

2.2 AI 在游戏开发链路里，到底站在哪个位置

很多人对 AI 辅助开发有个误解，以为它是"全能代打"。实际用下来，我的体感是：AI 是一个执行力极强但需要清晰指令的初级程序员，外加一个不会累的文档查询器。它能干的事包括：

• 根据你的描述生成完整的代码模块（玩家控制器、敌人 AI、房间生成算法）
• 解释你不懂的 API 用法
• 帮你把一段能跑但很丑的代码重构干净
• 生成占位用的美术资源描述、音效参数

它干不了或者干不好的事：

• 判断"这个手感对不对"——这需要你亲自试玩
• 决定"游戏好不好玩"——这是设计决策，AI 没有品味
• 处理引擎特有的、版本相关的坑——它经常给出过时的 API

所以正确的分工是：你负责决策和验收，AI 负责实现和填充。你越清楚自己要什么，AI 的输出质量越高。这也是为什么我在第 3 节会花大篇幅讲"怎么把需求描述清楚"。

2.3 先定核心循环，再动一行代码

这是我最想强调的一点。很多人用 AI 做原型失败，不是因为 AI 不行，而是因为自己没想清楚要做什么，上来就让 AI"生成一个游戏"。AI 会给你一堆能跑但互相不搭的代码，最后拼不起来。

我的做法是，开工前用十分钟在纸上（其实是文本编辑器里）写下核心循环：

进入房间 → 观察敌人巡逻路线 → 规划移动路径 → 收集能量核心 → 抵达出口 → 进入下一层（难度递增）

然后把这个循环拆成可独立实现和测试的模块：玩家移动、房间生成、敌人巡逻、收集判定、关卡切换、UI 显示。每个模块单独让 AI 生成、单独测试，最后组装。这个"分而治之"的策略，是两小时能跑通的关键。如果你让 AI 一次性生成整个游戏，调试时间会爆炸。

3. 把需求翻译成 AI 能听懂的指令：提示词的真实写法

3.1 为什么"帮我做个游戏"是最烂的提示词

我先给你看一个反面例子。如果你对 AI 说"帮我做一个地牢探索游戏"，你会得到什么？大概率是一段泛泛的、基于某个教程的代码，可能用了一些你根本没装的库，变量命名混乱，逻辑还未必符合你的预期。因为这句话里没有任何约束条件，AI 只能靠猜。

好的提示词要包含四个要素：技术栈、功能边界、输入输出、约束条件。我拿《霓虹地窖》的玩家控制器举例，实际用的提示词大概是这样组织的：

用 Godot 4.x 的 GDScript 写一个俯视角 2D 玩家控制器。需求：WASD 八方向移动，移动速度 200 像素/秒，带加速度和摩擦力让手感不那么生硬。角色是一个 32x32 的矩形，用CharacterBody2D实现。移动时角色朝向要跟随输入方向。不要处理攻击和碰撞伤害，那些我另外做。给出完整脚本和节点结构说明。

你看，这段话里技术栈（Godot 4.x、GDScript、CharacterBody2D）、功能边界（只做移动，不做攻击）、输入输出（WASD、速度值）、约束条件（32x32、加速度）全都齐了。AI 拿到这种指令，输出质量会高一个档次。

3.2 参数不能拍脑袋：200 像素/秒是怎么来的

上面那个"200 像素/秒"不是随便写的。这里有个简单的换算逻辑，值得展开讲，因为很多新手在这一步会卡住。

假设你的游戏窗口是 1280x720，一个房间大概占满屏幕。如果玩家速度是 200 像素/秒，那么横穿整个屏幕需要 1280 / 200 = 6.4 秒。这个速度对于俯视角探索游戏来说偏慢，适合那种需要谨慎规划路线的潜行玩法。如果我想让节奏更快，可以提到 300，横穿时间降到 4.3 秒。

我的选择逻辑是：先确定"我希望玩家横穿一个房间用几秒"，再反推速度值。我定的目标是 5 秒左右，所以 1280 / 5 ≈ 256，取整到 250。但实测下来 250 在躲避敌人时有点飘，最后调到 220。这个过程说明一件事：AI 给的初始参数只是起点，真正的数值必须靠试玩来定。你可以在提示词里让 AI 给一个合理初值，但别指望它一次到位。

3.3 让 AI 解释它自己的代码，比让它重写更有价值

有个技巧我用了很多次：当 AI 给出一段代码，我不完全理解时，我不会直接让它重写，而是问它"这段代码里move_and_slide()具体做了什么，为什么这里要用它而不是直接改position"。通过这种追问，我能快速补齐引擎知识，后面遇到类似问题就能自己判断了。

这在两小时的时间预算里看似"浪费"，实际是省时间的。因为如果你不理解 AI 给的代码，一旦出 bug，你连从哪查起都不知道，调试时间会成倍增加。理解代码是调试的前提，而调试是原型开发里最耗时的环节。

4. 模块逐个击破：房间生成、敌人巡逻、收集判定的实现细节

4.1 随机房间生成：从"能生成"到"生成得像样"

地牢生成是这类游戏的核心。我一开始让 AI 生成一个简单的随机房间布局，它给了一个基于网格的算法：把地图划分成若干格子，随机决定每个格子是墙还是地板。跑起来确实能生成房间，但问题是——它生成的是随机噪声，不是地牢。玩家会在里面迷路，因为房间之间没有合理的连通性。

于是我调整了需求，改成"房间 + 走廊"的经典结构：先随机放置若干个不重叠的矩形房间，然后用走廊把它们连起来。这个算法 AI 一次就写对了，因为它是一个有明确规则的经典问题。核心逻辑大概是：

# 伪代码示意，实际实现更长 func generate_dungeon(room_count, min_size, max_size): var rooms = [] for i in range(room_count): var new_room = create_random_room(min_size, max_size) if not overlaps_any(new_room, rooms): rooms.append(new_room) connect_rooms_with_corridors(rooms) return rooms

这里有个坑我要提醒：房间数量不能太多。我一开始设了 15 个房间，结果地图大到玩家要跑很久才能找到出口，节奏拖沓。后来降到 6 到 8 个，体验立刻好了。这个数字取决于你的房间大小和玩家速度，没有标准答案，但"少即是多"在原型阶段基本成立。

4.2 敌人巡逻：状态机是最省事的方案

敌人 AI 我用了最经典的状态机：巡逻 → 发现玩家 → 追击 → 丢失目标 → 返回巡逻。每个状态就是一个函数，状态之间用条件切换。AI 生成这个逻辑毫无压力，因为状态机是游戏 AI 里最成熟的模式。

巡逻路径我用的是"在房间内随机选点，走到后再选下一个点"。这里有个细节：如果敌人直接朝目标点直线移动，会卡在墙角。解决办法是加一个简单的避障——检测前方是否有墙，有就临时改变方向。这个逻辑 AI 也能生成，但需要你在提示词里明确说"要处理撞墙情况"，否则它默认给你直线移动。

追击逻辑里我加了一个"视野范围"参数，比如 150 像素。敌人在这个范围内才可能发现玩家，超出就丢失目标。这个参数直接决定了游戏难度：范围越大越难。我实测下来 150 到 200 之间比较合适，太小了敌人形同虚设，太大了玩家无处可躲。

4.3 收集判定与关卡切换：简单但容易出 bug 的地方

收集能量核心的判定，本质就是"玩家矩形和核心矩形是否重叠"。Godot 里用Area2D的body_entered信号就能搞定。这部分 AI 生成得很快，但有个坑：信号可能会重复触发。如果玩家在核心上停留，或者核心没有被及时销毁，收集计数会多加。解决办法是在收集后立刻把核心queue_free()掉，并且用一个标志位防止重复触发。

关卡切换更简单：玩家碰到出口，就重新调用一次房间生成函数，清空当前地图，重置玩家位置，层数加一。但这里要注意清空旧地图的顺序——如果先重置玩家位置再清空地图，玩家可能会被卡在旧墙里。正确顺序是先清空、再生成、最后放玩家。

这些细节 AI 不会主动帮你考虑，因为它们是"经验性"的，不是"逻辑性"的。这也是为什么我在第 6 节会专门讲踩坑。

5. 美术与音效：程序化方案怎么做出"霓虹感"

5.1 霓虹风格的视觉本质：高对比 + 发光 + 暗背景

霓虹风格看起来酷，但实现起来其实很省事，因为它不依赖精细的贴图，靠的是颜色对比和发光效果。核心就三条：

• 背景用接近黑的深色，比如#0a0a12，带一点点蓝紫调。
• 主体元素用高饱和的亮色，比如青色#00ffff、品红#ff00ff、亮黄#ffff00。
• 给亮色元素加发光（glow）后处理，让边缘有光晕扩散。

Godot 里开启 WorldEnvironment 的 glow 效果，调一下强度和阈值，整个画面立刻就有霓虹味了。这个操作不需要写代码，在编辑器里点几下就行。我实测下来，glow 的强度别调太高，否则画面会糊成一片，0.5 到 0.8 之间比较舒服。

5.2 用几何体代替美术资源：省时且风格统一

《霓虹地窖》里所有东西都是几何体：玩家是方块，敌人是三角形，能量核心是小圆点，墙壁是带描边的矩形。这种极简风格的好处是——你不需要任何美术资源，而且风格天然统一。因为所有元素都是同一套几何语言，不会出现"这个贴图很精致那个很粗糙"的割裂感。

如果你想让画面更丰富，可以让 AI 生成一些程序化的装饰，比如在地板上随机撒一些暗色的小点模拟纹理，或者让墙壁的描边有轻微的呼吸动画。这些都是几行代码的事，但能显著提升观感。

5.3 音效：合成音比找素材快得多

音效我全部用代码合成。Godot 里可以用AudioStreamGenerator实时生成波形，但更简单的做法是提前用工具生成几个短音效文件。我用的方案是让 AI 给我一段生成方波音效的代码，参数包括频率、时长、衰减曲线。

比如收集核心的音效，我用的是一个从 880Hz 快速滑到 1320Hz 的短音，时长 0.1 秒，带快速衰减。这种"上升音"在游戏里天然传达"获得"的感觉。敌人发现玩家的音效则相反，用一个下降的、带点噪声的音，传达"危险"。

这里的心得是：音效的音高走向比音色本身更重要。上升=正面，下降=负面，这是人类听觉的直觉。你不需要复杂的音色设计，把走向做对，玩家就能 get 到。

6. 实测踩坑记录：AI 生成代码里那些"看起来对但跑不通"的地方

6.1 版本 API 不匹配：AI 的记忆可能停留在旧版本

这是最频繁的坑。AI 生成的代码里，经常出现 Godot 3.x 的 API，但我用的是 4.x。比如KinematicBody2D在 4.x 里已经改名叫CharacterBody2D，move_and_slide()的参数也变了。如果你直接复制粘贴，编辑器会报一堆错。

我的应对方法是：在提示词里明确写引擎版本，比如"Godot 4.2"。即便如此，偶尔还是会有漏网的旧 API。这时候不要慌，把报错信息复制给 AI，让它修正。通常一两轮就能解决。关键是你要能看懂报错，知道是"API 不存在"还是"逻辑错误"。

6.2 信号连接方式的变化：一个让我卡了十分钟的坑

Godot 4 里信号连接推荐用代码signal.connect(callable)而不是编辑器里的节点连接。AI 有时候会混用两种方式，导致信号连不上，表现为"明明写了收集逻辑但计数不变"。

我排查这个问题的过程是这样的：先确认核心的body_entered信号有没有触发（加打印），发现没触发；然后检查信号连接代码，发现 AI 用的是旧式的connect("body_entered", self, "_on_body_entered")，而 4.x 需要body_entered.connect(_on_body_entered)。改过来就好了。这个坑的教训是：当逻辑"看起来对"但没反应时，优先怀疑信号和事件绑定。

6.3 随机数种子：为什么每次运行地图都一样

房间生成用了随机数，但我发现每次运行游戏，地图布局完全一样。原因是 AI 生成的代码里用了固定种子，或者根本没初始化随机数生成器。Godot 4 里需要调用randomize()来让随机数基于时间变化。

这个问题很隐蔽，因为代码逻辑没错，只是"随机"没生效。如果你发现随机生成的东西每次都一样，第一反应就该是检查随机数种子。这个坑在原型阶段特别值得注意，因为你会反复运行测试，如果地图不变，测试覆盖的场景就有限。

6.4 性能问题：节点太多导致的卡顿

我一开始给每个地板格子都创建了一个独立节点，一个房间几百个格子就是几百个节点。跑起来帧率明显下降。解决办法是用TileMap或者把静态的地板合并成一个绘制调用。AI 默认生成的代码往往是"一个格子一个节点"的朴素写法，因为它不考虑性能。

在原型阶段，性能问题通常不致命，但如果你发现画面卡顿，先检查节点数量。一个经验法则是：静态的、不交互的元素，尽量合并渲染。

7. 从"能跑"到"能玩"：最后二十分钟做了什么

7.1 手感调优：加速度、摩擦力、屏幕震动

代码跑通不代表好玩。最后二十分钟我几乎全花在手感上。玩家移动加了加速度后，起步和停止不再是瞬间的，而是有个短暂的过渡，操作感立刻柔和了很多。具体参数是加速度 1500 像素/秒²，摩擦力 2000 像素/秒²。这两个值让玩家大约 0.15 秒达到最大速度，0.1 秒停下。

屏幕震动是另一个提升打击感的小技巧。收集核心时给相机一个极短、极小幅度的震动，能让"获得"这个动作更有反馈。Godot 里用Camera2D的offset随机抖动几帧就行。幅度别大，2 到 3 像素足够，大了会晕。

7.2 难度曲线：敌人数量和速度的递增

第一层只有 1 个敌人，速度是玩家的 60%。每下一层，敌人数量加 1，速度加 5%，直到某个上限。这个递增逻辑很简单，但效果明显——玩家能感受到压力在增加，但不会突然被劝退。

这里有个数值设计的经验：难度递增要"可感知但不可怕"。如果每层难度跳跃太大，玩家会觉得不公平；太小又觉得无聊。5% 的速度递增和每层加一个敌人，是我试了几次后觉得比较舒服的节奏。

7.3 反馈闭环：让玩家随时知道自己在干什么

最后加的是 UI：左上角显示当前层数和已收集的核心数，收集时数字有个弹跳动画，进入下一层时有个短暂的过渡效果。这些反馈让玩家始终清楚自己的进度，不会玩着玩着不知道目标是什么。

原型阶段最容易忽略的就是反馈。因为开发者自己知道游戏怎么玩，但第一次上手的人不知道。加反馈的原则是：任何玩家可能困惑的地方，都给它一个视觉或听觉的回应。

8. 两小时之后：这套流程能复用到哪些场景

8.1 什么类型的游戏适合这套流程

这套"AI 生成 + 程序化美术 + 快速迭代"的流程，最适合机制驱动、美术需求低、逻辑清晰的游戏类型。比如：

判断标准很简单：如果你的游戏核心乐趣来自"机制"而不是"内容"，这套流程就适用。反过来，如果乐趣来自精美的画面或大量的剧情，AI 能帮的忙就有限。

8.2 把 demo 继续做下去，下一步该补什么

两小时的 demo 是个起点，不是终点。如果要继续做，我会按这个优先级补：

• 内容量：更多的房间模板、敌人类型、道具。这部分可以继续用 AI 生成，但需要人工筛选和调优。
• 存档系统：让玩家能中断后继续。这是产品化的必备功能。
• 音效和音乐：目前只有音效，加一段循环的背景音乐能大幅提升氛围。
• 新手引导：教玩家怎么玩。原型阶段可以省略，但面向真实玩家必须有。

8.3 关于 AI 辅助开发的一点个人体会

用 AI 做游戏原型这两个小时，我最大的感受是：AI 改变的不是"能不能做"，而是"多快能试"。以前一个想法从脑子里到能玩，可能要一两天，现在两小时就能验证。这意味着你可以用同样的时间试更多的点子，找到真正有潜力的那个再深入。

但我也要泼盆冷水：AI 不会让你变成游戏设计师。它能把你的想法快速实现，但想法本身好不好，还是得靠你的判断和试玩。我见过太多人用 AI 生成了大量代码，但做出来的东西不好玩，因为问题从来不在实现，而在设计。

所以我的建议是：把 AI 当成一个"实现加速器"，把省下来的时间花在试玩、调优、思考玩法上。这才是它真正的价值所在。两小时生成 demo 不是目的，两小时验证一个创意、然后决定要不要继续投入，才是。

最后分享一个我反复用的小技巧：每次让 AI 生成代码后，别急着往下做，先花一分钟问自己"这段代码如果出 bug，我大概知道去哪查吗"。如果答案是"不知道"，那就让 AI 解释一遍再继续。这个习惯看起来慢，实际能帮你省下大量后期调试的时间。原型开发最怕的不是写得慢，而是写到一半发现底层逻辑自己都不懂，那时候返工的成本就高了。