企业官网建设流程全解析

2. prompt工程：把“我想要个游戏”变成能跑的需求文档

先说一个我踩过无数次的坑：很多人一上来就写“帮我做个好玩的游戏”，这句话在AI眼里约等于“给我做个好吃的菜”——它只能从记忆里翻一个最眼熟的东西丢给你，至于是不是你想要的，完全听天由命。想要稳定拿到能跑、好玩、长在你审美点上的游戏，你得学会把prompt当成一份需求文档来写，而且是那种“实习生看完不用来追问你”的需求文档。

2.1 写游戏prompt的四层结构

我调试了上百个生游戏prompt之后，总结出一套固定四层结构，基本覆盖了所有能跑出好结果的prompt写法：

第一层，设定角色与背景。让AI进入一个专业开发者状态，比如开头写“你是一名有20年经验的前端游戏开发工程师，擅长用原生JavaScript在单HTML文件里实现像素风小游戏”。这一步非常关键，它决定了AI输出的代码风格、注释习惯、是否会自动加UI布局等细节。没有这层设定，AI代码生成会倾向于“根本不管你最终跑在哪”，默认给你输出一堆堆砌的类和方法。

第二层，描述核心玩法。国内游戏圈普遍把这块叫“玩法三要素”，我沿用这个习惯：操作方式、计分规则、胜利条件。每一条都要是精确到可执行的程度，三句话内说清。比如“方向键上下左右控制主角移动，碰到敌人扣血，血量为0游戏结束；金币每吃一个加10分，吃到50分时通关进入下一关”。这一个描述就是游戏骨架，AI生成的逻辑会完全围绕这三要素展开。

第三层，列出关键技术需求。这个容易被新手忽略，但经验告诉我，它决定游戏代码后期改起来的成本。比如“所有资源内联在单个HTML文件里”“图片使用canvas绘制，不用外部素材”“样式使用CSS Grid而不是Flexbox”。这一层一定要写清楚你自己用的技术栈或运行环境，不然AI默认输出现代ES6+模块化风格，直接双击打开文件大概率报跨域错误。

第四层，约束输出格式和结构。你要在prompt尾部明确写“最终只输出一份完整HTML文件，不要分多段粘贴，不要输出Markdown代码块，不需要任何解释文字”。很多平台（比如部分在线生成器）的AI默认喜欢输出一段文字说明加一段代码，这种结果复制的时候极易出错，甚至会把中间的解释内容一并粘贴进去导致js脚本报错。这层约束能直接把输出格式钉死，极大减少后期处理成本。

四层结构写完之后，哪怕需求再复杂，也要确保整个prompt控制在500个汉字以内。超过这个长度，AI的注意力容易发散，一些关键约束会在生成过程中被“遗忘”，最后出来的游戏跟你的描述对不上。

2.2 用伪代码描述游戏逻辑，是最被低估的技巧

纯新手最容易犯的就是用自然语言“洋洋洒洒”描述游戏规则：“一颗陨石从空中掉落，碰到玩家飞船就爆炸，爆炸的时候要有一个特效还要把声音放出来，同时左上角显示得分……”这种描述又好读又流畅，但AI真正动手写代码时，会发现里面一堆细节不足：陨石怎么生成？多久生成一次？碰到飞船是判断矩形碰撞还是圆形碰撞？爆炸是普通销毁还是粒子系统？每个问题AI都得替你做“阅读理解”，充满不确定性。

我自己试下来最稳的办法，是直接在prompt里用伪代码（pseudocode）描述核心逻辑。伪代码不用理会具体语法，只要表达出逻辑顺序和分支条件就行。举个例子，我要做一个接果子的小游戏，第二层玩法描述可以这么拆：

当游戏开始： - 每1.5秒从屏幕顶部生成一个水果，落在随机x坐标 - 水果下落速度初始为2像素/帧，每接住5个加速0.3像素/帧 - 玩家操作一个100x30的篮子，鼠标左右拖动控制位置 - 水果碰到篮子底部即接住，得分+1 - 水果碰到屏幕底部即丢失，生命-1，生命值归0时显示游戏结束画面与总分 - 所有碰撞判定采用矩形相交

这段话里的每个条件都是“可执行”的，AI在转化成具体代码时几乎不需要额外做判断，生成的逻辑自然干净。伪代码描述还有个隐藏好处：如果游戏后续要加功能，你直接把伪代码补充一段，AI能精确识别“这是新增逻辑”，而不是打乱原有代码结构。

我在实际跟AI协作做小游戏时，流程固定的三步如下：

1. 先把完整伪代码写清楚，放prompt里让AI生成游戏第一版。
2. 跑起来看效果，把不满意的条件在追加对话中直接改伪代码数值（比如把下落速度改成1.8像素/帧）。
3. 每积累三个改动需求，就合并成一条新prompt重新生成一次完整版。

这套流程比在对话里反复追加“再调一下”“左边一点”“加快一点”的描述词高效太多了——那些模糊的形容词AI是真听不懂，而伪代码里的具体数值是百分百能听懂。

2.3 数值、边界与美术风格：容易被忽视的“隐形需求”

实操中我发现，大多数“AI生成的游戏不好玩”的根源，根本不是AI智商不够，而是你没给它具体的数值和边界。数值包括移动速度、生成间隔、计分规则、初始生命这些“硬数字”；边界包括角色出界怎么处理、敌人到达底部的后果、分数达到多少触发胜利等。

举一个真实的翻车案例：我曾让AI生成一个“宝石迷阵”换皮小游戏，核心玩法是点击相邻宝石交换位置，三个相同就消除。第一版跑起来后，点击手感非常差，因为宝石尺寸不一致、交换动画1秒太长，整个体验像站在棉花里。后来在prompt里补了一条“宝石格子固定为8x8，每格边长60像素，交换动画时长控制在150毫秒以内，使用ease-out缓动”，重新生成的版本手感立刻接近商业游戏标准。你看，一个“动画时长”的数值，就是成品和半成品的分水岭。

美术风格描述也建议具体化，不要只写“好看一点”。我常用的表述套路是“像素风，主色调为深蓝+金黄，背景为星空渐变，所有角色用8bit像素块绘制，UI字体使用Press Start 2P风格”。AI在实现时会对画布尺寸、颜色取值、渲染模式有一个一致性的审美基准，生成的游戏画面观感会好很多。

3. 从想法到成品的实操记录：一次完整的prompt打磨流程

光讲理论容易飘，我用一个自己最近实际做的“反击小蜜蜂”游戏把完整流程过一遍。这个游戏的最终效果是按住鼠标左键持续开火，打落上方不断左右移动入侵的敌机，同时要躲开敌机的俯冲攻击。看起来不算复杂，但通过一步步打磨prompt，最后成品的完成度让我自己都惊讶。

3.1 第一版prompt：只写玩法，不写约束，结果能跑但很“糙”

第一版我非常偷懒，原话大致是：“帮我做一个反击小蜜蜂游戏，用鼠标控制下方的飞船，按左键发射子弹打上方的敌机，躲避敌人攻击，做完给我一份完整HTML。”

AI在十几秒内给了一版可运行的HTML文件。双击打开后开始玩，问题密集到让我怀疑人生：飞船移动是“瞬移式”的，鼠标指哪飞哪，完全没有目标移动的平滑感；子弹发射速度偏慢，密集敌阵反复穿过弹幕；炸弹没有爆炸效果，击中敌机就凭空消失，一点反馈都没有；得分数字在左上角小得几乎看不见，而且没有最高分记录。

这一版我可以负责任地说：属于“能跑但绝对没人愿意多玩一分钟”的状态。它的意义只在于验证了玩法模型在程序层面的可行性，所有细节都像是AI在自然语言模糊指令下的“随机猜测”。

3.2 第二版prompt：结构化+伪代码+数值参数，成品完成度直线上升

有了第一版问题清单，我重写了一条完整的结构化prompt，核心改动包括：加入“资深前端游戏开发工程师”角色设定；把玩法描述改写为伪代码风格；追加美术风格与UI细节；指定输出为完整HTML单文件。完整prompt贴出来供大家抄作业：

你是资深前端游戏开发工程师，擅长用原生JavaScript和Canvas在单个HTML文件内创建复古像素风游戏。 请开发一款横卷轴防守类游戏，操作与逻辑如下： - 玩家飞船固定在屏幕底部，用鼠标水平控制左右移动，目标坐标由鼠标x决定 - 按住鼠标左键连续发射子弹，子弹向上飞行，速度为6像素/帧，每次射出间隔不超过3帧 - 敌方战机从画布顶部随机水平坐标生成，以左右摆动方式向下移动，移动速度为0.8像素/帧 - 敌机每被击中一次即爆炸，播放10帧爆炸扩散动画并结算10分 - 敌机随机俯冲攻击，俯冲时速度提升到3像素/帧，主飞船被撞则扣1条命 - 初始生命3条，生命归0时显示“GAME OVER”画面并展示本次得分 - 游戏难度随时间提升，时长每过15秒，敌机生成间隔减少15% 美术风格与交互细节： - 整体为深蓝夜空，背景绘制3层星星滚动视差 - 玩家飞船使用绿色像素块绘制，敌机使用红色像素块 - 子弹为黄色短条，爆炸动画为橙白双色扩散 - 所有碰撞判定使用矩形相交 UI与输出： - 画布固定为800x600 - 左上角实时显示分数与生命数 - 鼠标悬停画布时显示自定义十字光标准星 - 最终只输出一个完整HTML文件，JS内联，无外部依赖

这条prompt生成的版本我整整玩了三局才停手。飞船移动已经变成“平滑跟随当前鼠标坐标移动，靠近但不瞬移”的体验；子弹射速翻倍后扣除敌机的爽感彻底释放；爆炸动画让每一发命中都有比杀敌更直接的反馈；夜空视差和十字准星极大增强了沉浸感。把第一版和第二版对照来看，区别就像“程序员的测试页”和“商店里的独立游戏”。

3.3 结果验证与迭代：带着checklist去测试，小步快跑地补prompt

拿到第二版后我列了个六项验证清单：游戏难度曲线是否合理、操作是否有0.5秒以上的延迟、敌机生成频率在5分钟局内是否失控、爆炸动画是否造成卡顿、有没有卡死的边界场景、UI信息是否清晰可见。

实测发现一个交互比较影响手感：飞船“跟随鼠标”的效果是用插值实现的，在快速甩动鼠标时飞船会像橡皮筋一样多抖两下，看起来有种“粘滞感”。这个我用追加prompt的方式修复了：“优化飞船移动逻辑，取消插值平滑，改为实时设置坐标但添加边界缓冲。”这样调整后鼠标指哪飞船立刻到哪，手感更接近街机风格。

另一处是性能问题：敌机数量最高时在屏幕上会同时存在15架以上，爆炸动画帧率偶尔掉到40以下，我判断是每帧大量绘制特效造成的掉帧。于是追加写法“爆炸动画的粒子数量上限调整为每帧最多15个，避免高性能消耗；超出部分直接用纯色方块淡出代替。”改完后全流程操作起来丝滑无明显掉帧。

迭代的重点是：不要幻想一次prompt生成就成成品，游戏开发本身就是不断试玩→找问题→改需求→再生成的过程。每一次追加prompt是在原有代码上做增量修改，AI会根据上下文在已有文件上打补丁，这种模式下你对“变化是什么、影响在哪”的控制力是清晰的。真正忌讳的是每次bug修复都用“再帮我重新做一个”这种推倒重来的写法——那会让AI在全新基础上加回你之前已经修好的bug，陷入死循环。

4. 十分钟排查实录：prompt闪退、invalid prompt、token超限怎么解决

你大概率也碰到过这些情况：prompt写了一大段，点生成按钮直接弹报错；生成到一半控制台提示某种错误然后退出；生成出来的代码能看，但复制运行时报错一堆。这三个问题的根因通常都不是“AI能力不行”，而是prompt的某个隐藏特性踩上了平台的限制规则。这里我把常见的几类问题逐一拆开讲清楚。

4.1 invalid prompt报错：你的提示词“越界”了

“invalid prompt: your prompt was flagged as potentially violating our usage policy”这个报错，很多第一次见的用户会慌，觉得是不是AI发疯了。其实它的意思是：你输入的prompt被内容安全过滤器判定为潜在违规。这个过滤器通常不会告诉你具体哪句话有问题，有几次我连续改版本都是靠手动排查才定位到出问题的词。

结合我自己在多个AI平台上实践的经验，最容易触发的词汇集中在几类：明确描述暴力血腥的特效（例如真实断肢、血液飞溅画面）、模拟非法装置的制造流程、直接要求破解或绕过系统限制（比如“不检查用户权限”）的表述、以及带有明显骚扰或仇恨导向的角色设定。

解决办法并不复杂。一是将暴力元素全部替换为卡通风格的等效描述，比如把“打断敌人的腿”改成“敌人倒地闪烁消失”，既保留玩法交互又不会触发过滤器。二是若有“关闭系统限制”“绕过安全检查”之类的需求，务必改写为“基于用户权限设计功能入口”的正向表述。三是尽量不使用真实品牌名、药物名、地名及人物名作为游戏素材，用一个虚构名称代替即可。

这条报错偶尔还会因为prompt里包含一些有歧义的符号触发，比如使用大量连续感叹号、全大写单词、刻意重复标点，建议保持prompt文案接近正常表达习惯。如果反复调整后仍然报错，最快的办法是先把prompt截成两半，分别提交，确定具体是哪一半有问题再改。

4.2 闪退和输出截断：token限制与上下文长度的博弈

“prompt闪退”是这个词在搜索平台热起来的主要原因。实际上大部分情况不是程序闪退，而是生成结果被token数上限截断了。在代码类任务里，一个中型游戏完整代码最少也在3000~7000 tokens之间，而很多在线AI生成平台的单次输出上限通常在4000~8000 tokens，一旦超限，模型会直接从中间某个位置停止输出，结果就是一个不完整的HTML文件，浏览器解析时就会出现脚本错误甚至白屏。

解决思路有两种。第一是“控制单次prompt的输出量”：在prompt里显式注明“代码中函数抽离公共模块，减少重复区块”“基础配置统一在头部声明，压缩常量的重复定义”“节点坐标使用变量循环生成，不用手写每一帧数值”。这些表述能让模型自动生成更精简的代码，显著减少token消耗。我实测同样一个飞机大战游戏，加了这段优化表述后单次生成的代码体积至少缩小20%-30%，基本能稳定在全平台可输出的范围。

第二种思路是分步生成。第一轮prompt只让AI生成核心玩法部分，比如“输出一个能跑通的HTML页面，包含玩家飞船移动与子弹射击两个功能，不需要敌机、计分、音效”。第二轮再追加“在上一个文件基础上添加敌机生成与碰撞逻辑”。每轮输出控制在2000 tokens以内，基本不会碰到输出截断，而且这样“一层一层盖房子”的结果在逻辑上反而更可控。

还有一类闪退的表现是“AI卡在游戏的某一步逻辑里不断重复输出”，这通常是prompt里的逻辑分支存在循环条件或者描述中缺少“结束条件”的说明。比如生成生命周期脚本时如果没有写“当生命值小于等于0时停止一切更新”这个终止条件，AI可能会持续生成一堆无效死代码。解决方案是在伪代码描述里把终止条件写得非常明确。另外，在API调用的场景下可以显式设置生成长度参数，并将温度设为0.2~0.4之间，保证输出偏确定性和稳定，不过在线网页端多数不开放这项调节，分步生成就更实用了。

4.3 prompt optimizer 用不用？不要神化它

现在很多平台内置prompt optimizer（提示词优化器），配置很简单：把你的一句话想法丢给它转成结构化prompt。它的本质是一个“翻译工具”——把模糊的自然语言重写成角色设定、上下文线索、约束条件和输出格式的集合。我在不少平台的实战中发现：optimizer在把玩法描述转换成伪代码方面效果还凑合，但一旦涉及像素美术风格、具体控制参数这些“主观创作细节”，它基本是瞎猜，完全不会替你决策。

因此我对optimizer建议是：使用但不依赖。你可以用optimizer当草稿生成器，拿它输出的一版内容当底稿，然后自己在里面替换美术风格、修正具体数值、增加输出格式约束。绝对不要跳过最后的审核直接开跑，否则生成结果大概率不是你要的东西。有效的流程是：“原始想法”→“optimizer草稿”→“人工修改成四层结构标准”→“提交给AI生成游戏”。

顺带一提，optimizer在缩token方面有一定作用，它会自动精简多余的表态语和铺垫性描述，留下更紧凑的需求点。如果你分步生成的思路配合optimizer的预处理，能进一步压低tokens占用，为代码输出腾出更多空间。

4.4 坑点速查表：一次看清对应关系

说了这么多原理和排查方法，最后分享一个我日常用得最顺手的prompt模板。这个模板不是从零开始的教科书案例，而是直接套用就能出效果，你自己做的时候只需要把斜体部分替换成自己的游戏描述就行。

你是一名资深HTML游戏开发者，擅长用纯JavaScript和Canvas实现复古街机风格的游戏，不需要任何外部库，所有代码生成在一个HTML文件里。 我想做一款[游戏类型]，核心操作是[操作方式]，目标是[目标描述]。 游戏逻辑请按下面的伪代码执行： - 核心循环：[主要内容，比如生成敌人、更新位置、检测碰撞、更新分数] - 角色控制：[具体键位或鼠标事件，以及边界条件] - 胜负条件：[胜利条件和失败条件，以及失败后展示画面] - 难度设计：[如何随时间变化让游戏更有挑战性] 美术风格： - 画面尺寸：800x600 - 主题色：[主色+辅色] - 特效：[命中/爆炸/奖励的视觉表现方式] 补充要求： - 所有代码用原生JS和Canvas编写，CSS内联在style标签中 - 避免使用外部图片或字体，全部用代码绘制 - 在HTML页面顶部展示游戏标题与操作说明 - 最终输出一份可直接保存为HTML文件的完整代码，不需要Markdown代码块，不要附解释文字

我拿这个模板做过重力弹跳、消消乐、地牢射击三个不同品类的游戏，只要把伪代码部分按我前面说的“具体到数值”的方式写详细，出来的成品完成度普遍在80%以上。剩下的20%就是你自己试玩后对着清单补prompt的迭代时间。

5.1 实测记录：用模板5分钟完成一个“不动手就会失败”的小游戏

我拿这个模板现场做了一次“接水滴”小游戏，完整过程用文字记录一下。

第一轮prompt按模板填写，伪代码写成：玩家操作一个水桶在屏幕底部左右移动，从上方随机掉落水滴，水滴落到水桶里计一分，落地上则游戏结束；水滴生成间隔初始0.8秒，每分钟缩短0.05秒；背景用夜空和月光配色，水滴用浅蓝色圆形，接住时溅开水花特效。

第一版运行后有两个问题：一是鼠标控制的水桶移动太快到了屏幕边缘会有“冲出屏幕”的视觉bug，二是接住水滴的水花特效看不清楚，反馈感很弱。第二轮追加prompt：“水桶边界限制在canvas左右边缘各6像素范围内，不允许超出；水花特效增加为12个粒子向外扩散，持续时间为0.3秒”，就完全解决了。全程从写prompt到改完，大概9分钟，比起手写整套代码省了至少一小时。

还有一个细节要强调：这个模板里写的“不需要Markdown代码块，不要附解释文字”不是随便写的。我所有遇到“生成的HTML粘出来直接是乱码文本”的情况，基本都是因为聊天窗口把AI输出的包裹块一起复制了，导致浏览器整个把代码块当作普通文本显示。输出约束写在prompt里之后，这类粘贴事故基本绝迹。

5.2 版本管理经验：迭代AI生成游戏的正确姿势

很多人跟AI协作开发游戏是“改一版丢一版”，这个习惯很要命。AI每次生成的版本之间可能会有代码结构上的跳变，你上次修好的bug在下一版里大概率会原地复活。我的建议是：每拿到一个能跑的版本，立即复制保存到一个独立文件夹，按日期加序号命名存档。折腾三四个版本之后你回头对比，会发现某一版在某些手感上明显优于其他版本，把它当基座继续迭代比从头开始顺得多。

另一个做法是把每次迭代中用到的追加prompt记录下来，形成你自己的“修改指令集”。比如“加快敌人速度到1.5倍”“增加震屏效果反映受击”“画面背景换成黄昏色”，这些指令都是清晰可复用的，下次做新游戏的时候能直接搬过去用，等于给自己积累了一套游戏调优CLI工具集。

6. 写在最后：prompt生成游戏这件事，真正难在哪

看到这里你应该明白了，提示词生成游戏是个“看似简单，实则充满细节活”的事。第一关是让AI理解你想要的，第二关是让生成结果限制在你自己可控的技术栈里，第三关是围绕体验细节无限迭代打磨。

我个人的体会是：prompt生成游戏跟传统写代码最大的不同，在于“离代码更远了，离产品判断更近了”。你不必盯语法细节和依赖报错，但必须想清楚操作手感、难度曲线、反馈反馈强度、美术一致性这些更上层的产品问题。这其实是一个很舒服的创作方式——你的精力花在决定“游戏该是什么样”上，而不是花在把抽象想法翻译成代码上。

如果非要给第一次尝试的人一句建议，那就是：第一次的目标不要定“做一款大作”，先做一个“3分钟内能玩开心的小东西”。把分步生成、四层prompt结构、数值具体化这些基本功先用熟，你在prompt上投入的每一分钟，都会以十倍杠杆变现成游戏完成度。这大概就是我现在最推荐把“做游戏”当成prompt练手项目的原因——门槛低，反馈快，成就感来得直接。