★ FEATURED ARTICLE 1. 游戏页面布局为什么值得单开一篇笔记写到这儿已经是Vibe Coding学习笔记的第九篇了。前面几篇我们主要在处理游戏逻辑——数据、状态、碰撞、事件代码跑通的那一刻确实挺爽的。但说句实在话每次打开浏览器看到那个光秃秃的页面时我都意识到一个很现实的问题逻辑能在控制台里跑通和玩家愿意点开你的游戏中间隔着的正是UI。而UI里最容易让人抓狂的就是布局。我之所以把“界面布局”单独拎出来写一篇是因为在Vibe Coding的完整流程里布局代码是我踩坑最多、迭代最频繁、也最考验“描述能力”的部分。AI生成逻辑代码通常一次就能跑得八九不离十但布局代码几乎没有一次是直接落地的。它生成的CSS经常是“看起来没毛病”浏览器一打开就原形毕露血条跑到了屏幕中间、弹窗点不透、手机上一缩放全乱了。这一类问题恰好又是最适合用自然语言去修的——你不需要告诉AI具体的像素值只需要说“血量面板整体偏右了往左下角挪距离边缘留16像素”它就能理解你的意图。这篇笔记主要面向两类人。第一类是和我一样的Vibe Coding新手能把AI当编程搭档使但还不清楚怎么描述空间关系、怎么引导AI改布局第二类是有一定前端基础、但想把游戏页面做得更规范的朋友。我会从布局拆分思路讲起把关键的prompt写法、实操过程、常见翻车场景都过一遍最后附上一份可以直接照着用的代码检查清单。这篇读完之后你至少能少走我当初三分之一的弯路。2. 动手之前把游戏UI拆成三层来想2.1 游戏UI不是网页UI先改变这个认知很多AI在没被明确引导时会把游戏页面当成一个普通网站来排版结果生成的是带导航栏、大通栏横幅、页脚那一套东西。游戏页面和网站页面的核心差异在于游戏UI是浮在游戏画面之上的“图层”而不是承载内容的文档流。网站可以滚动游戏不希望有滚动条网站的导航通常在顶部居中游戏信息则固定在四角网站讲究区块留白游戏讲究不遮挡核心画面。所以我在让AI生成游戏页面之前一定会先在描述里加一句“这是全屏游戏界面页面禁止滚动UI作为叠加层覆盖在整个画面上”。这句话能极大减少后续改造的成本。2.2 三层结构的拆分方法我自己的习惯是把游戏UI分成三层来思考和描述这比直接说“给我一个好看的界面”要有效得多。第一层是游戏世界层。这一层是canvas或者大背景区域它承载实时画面位置一般占满全屏会随着游戏逻辑产生变化。第二层是信息与控制层也就是HUD。血条、分数、计时器、道具栏、移动按钮都在这一层。它的特征是永远贴着屏幕边缘或者底部但不参与游戏本身的坐标体系。第三层是模态层包括主菜单、暂停菜单、设置面板、结算弹窗特征是画面中央弹出一张卡片背后有一层半透明遮罩用来强制聚焦玩家注意力。分层带来的直接收益是你在和AI沟通时有了统一的“语言坐标系”。比如我会直接说“把分数归到第二层放在屏幕右上角主菜单属于第三层卡片水平垂直居中”。AI能听懂这种描述而且生成的代码结构也会清晰很多z-index、position这些属性不会乱成一锅粥。2.3 先定技术栈再想prompt游戏页面用Canvas还是DOM直接决定了prompt怎么写。我目前的经验是如果你是Vibe Coding入门玩家项目的第一步尽量用DOM叠加的方式来做界面——HTML和CSS天然擅长布局AI生成这类代码的容错率也高。Canvas虽然渲染性能更强但它没有“元素”概念所有东西都要用坐标去画AI如果不了解你的画布逻辑很容易把坐标算歪出来的界面全靠调参。如果项目确实必须用Canvas做UI我会在prompt里额外说明“所有UI元素用坐标定位计算方式基于画布宽高的百分比”并且要求AI把每次定位计算都写成带注释的独立函数。这样即使位置不对我也能直接看注释去改而不是在一堆魔法数字里找哪里出了问题。3. 让AI听懂你想要的布局prompt怎么写3.1 写prompt前先想清楚三件事Vibe Coding最容易犯的错是让AI“盲写”——自己脑子里只有一句模糊的“做个游戏主页”然后就期待AI给出完美答案。我现在的习惯是开口之前先迅速在纸上敲定三件事。第一目标设备与画布比例。是PC横屏、手机竖屏、还是两者兼顾这决定所有长度单位的选择。我会明确告诉AI“目标设备为手机竖屏宽高比约9:16但页面需要适配桌面端浏览器等比缩放”。如果什么都不交代AI通常会写一套以px为绝对单位的桌面布局手机上一打开就崩。第二元素清单与层级关系。这一屏上到底要放哪些东西这些东西里哪些永远固定在屏幕角落哪些居中展示哪些在弹层之上我会把这些写成一个简单的列表比如“左上角血量、右上角分数、底部中间攻击按钮、中央显示倒计时”。这个列表本身就是给AI的最好的结构化输入。第三硬性约束。包括安全距离、最小点击区域、禁止遮挡。游戏UI最容易在手机上出问题按钮太小容易误触、底部被全面屏手势条遮住、HUD挡住敌人出现的位置。这些约束应该在prompt里前置声明而不是等生成完再补。比如“所有可点击按钮高度不小于48px底部元素预留至少30px安全区HUD的pointer-events设为none不要阻断画布接收操作”。3.2 一个能跑通的基础prompt模板我自己用得比较顺手的模板大概长这样现在开始做一款网页版手机射击小游戏的前端界面。使用原生HTML/CSS/JavaScript不用任何框架。 第一个任务实现游戏主菜单页面。 要求 1. 全屏显示禁止页面滚动背景使用深空蓝紫渐变并点缀星星。 2. 菜单卡片水平垂直居中包含游戏标题太空清道夫、一句副标题、一个主按钮开始游戏和一个次按钮设置。 3. 主按钮使用高亮的主题色悬浮时轻微放大次按钮使用半透明描边样式。 4. 按钮高度不小于48px卡片宽度在手机端不超过屏幕宽度的86%。 5. 所有样式写在一个style标签里结构尽量清晰。 请直接输出完整可运行的HTML文件。这套模板的关键在于我提供了项目背景、技术栈、任务范围、视觉方向、交互状态、尺寸约束、输出格式。AI拿到这些信息后生成的代码已经比较接近实际需求了。你不需要用标准格式的prompt只需要保证信息完整。如果我不提“卡片宽度不超过屏幕宽度的86%”AI大概率会用固定420px手机端就出问题如果不提“禁止滚动”AI很可能顺手生成一个带纵向滚动条的页面如果不提“pointer-events”后面还得回头补。所以这步不能省。3.3 迭代修改才是Vibe Coding的核心环节我刚开始学习Vibe Coding时有个错觉以为主要工作是“写一次prompt然后等结果”。真实情况恰恰相反写初始prompt只是前戏后面80%的时间都在迭代。而且迭代是否高效完全取决于你能不能把“视觉感受”翻译成“空间关系”。“这个界面不太好看”对AI没有意义。AI需要的是“标题和副标题之间的间距加大到24px”“按钮整体向左移动20像素”“卡片背景透明度太高了降到0.06并增加底部阴影”。每一条修改指令都应该尽量包含三层信息哪个元素、什么属性、什么目标值。迭代还有一种很好用的方式就是截图。现在的AI编程助手大多支持直接粘贴浏览器截图我会打开页面截一张图贴回去然后补一句“你看这张图主菜单卡片没有居中偏左上角了”。视觉语言空间描述的组合通常比纯文字描述好用得多。我有几次连续核对了三四轮其实就是靠“截图一句人话”修完的。4. 实操记录从空白页面到完整游戏界面4.1 第一步主菜单先解决“能打开”我这次用的是上一节那个基础prompt。AI生成的第一版HTML大致是这种结构——一个全屏背景层里面放一个居中的卡片容器卡片里依次排着标题、副标题、按钮。核心布局用了Flexbox这个选型是对的因为主菜单本质上是“单卡片垂直堆叠居中”Flexbox是目前最省心、兼容性又好的方案。.menu-wrap { position: fixed; inset: 0; display: flex; align-items: center; justify-content: center; z-index: 100; background: linear-gradient(135deg, #0b1026, #1a2a5e); } .menu-card { display: flex; flex-direction: column; align-items: center; gap: 18px; width: min(420px, 86vw); padding: 36px 28px; border-radius: 16px; background: rgba(255, 255, 255, 0.08); }这里有两个值得注意的细节。第一width用了min(420px, 86vw)这是我在prompt里要求“手机端不超过屏幕宽度86%”后AI自动写出来的桌面端最多420px手机上则收缩为视口宽度的86%相当于一份很基础的响应式处理。第二position: fixed把整个菜单钉在了视口上配合inset: 0展开全屏这样即使游戏画布在底下滚动主菜单也不会跟着跑。第一版跑通之后我在手机模拟器里检查了一遍发现两个问题按钮之间的间距在窄屏上偏小两个按钮快贴到一起了背景渐变在低亮度环境下太暗标题的对比度不够。于是迭代指令是“菜单卡片里的间距调整到20px背景渐变稍微提亮并在底部加一层很淡的蓝色光晕”。两条指令都指向具体属性AI很快改了回来没有再动到结构。4.2 第二步游戏HUD定位与层级是关键主菜单搞定之后下一步是游戏进行中一直要显示的那个HUD。HUD的布局逻辑和主菜单完全不同它不需要居中而是要往四个角和边缘上贴。我的prompt是这么写的现在实现游戏内的HUD界面。HUD作为覆盖层不能阻挡鼠标和触摸操作。 要求 1. 左上角显示血量数值和血条血条用两段式颜色绿色到黄色渐变。 2. 右上角显示当前分数右对齐字体突出。 3. 底部中间放一个暂停按钮。 4. HUD容器本身不接收任何指针事件但按钮要能正常点击。 5. 所有HUD元素使用fixed定位相对视口四角对齐不用transform去做居中偏移。AI生成的对应CSS大致如下.hud { position: fixed; inset: 0; z-index: 10; pointer-events: none; } .hud-health { position: absolute; top: 16px; left: 16px; } .hud-score { position: absolute; top: 16px; right: 16px; text-align: right; } .hud-pause { position: absolute; bottom: 24px; left: 50%; transform: translateX(-50%); }这段代码里最容易被忽略但最关键的是.hud上的pointer-events: none。没有这一句整个HUD虽然视觉上是透明的但它会像一堵看不见的墙一样拦在游戏画布前面导致玩家点击画面没有任何反应。而子元素按钮要能点击所以.hud-pause这个按钮上必须显式加回pointer-events: auto——这是CSS里少数能够被子元素“推翻”父级设置的属性之一。AI最初生成的版本里确实容易漏掉这个属性。我第一轮跑起来就发现点击画布没反应排查了几分钟才想到是HUD容器挡住了。这也侧面说明AI生成的代码即使结构正确也很容易出现这种“逻辑没毛病、交互全断开”的隐性bug人工验证是跑不掉的。4.3 第三步弹窗与结算界面处理遮挡关系HUD做完了接着是游戏结束后的结算弹窗。弹窗属于前面说的模态层需要盖在HUD之上。这里最核心的是层级和遮罩。我给的prompt是“生成游戏结算弹窗背景遮罩半透明黑遮罩之上居中显示结算卡片包含标题、最终分数、两个按钮遮罩点击不关闭弹窗”。AI输出如下.overlay { position: fixed; inset: 0; z-index: 200; display: flex; align-items: center; justify-content: center; background: rgba(0, 0, 0, 0.6); } .end-card { width: min(360px, 80vw); padding: 28px 20px; border-radius: 12px; background: #fff; text-align: center; }这里有个和HUD相反的注意点遮罩需要拦截点击所以不能加pointer-events: none而卡片内部的按钮要正常交互所以一切都保持默认。我踩过的一个坑是AI生成时顺手在overlay上加了pointer-events: none理由是让底下的游戏继续运行——但结算场景本来就应该阻断后面的交互这个“优化”反而成了问题。这种AI“自作聪明”的改动必须靠一遍一遍检查才发现。弹窗尺寸同样要处理手机适配宽度用min(360px, 80vw)不让它顶着屏幕边缘。另外弹窗出现时最好配合一个简单的淡入动画但动画不是重点我只会在布局稳定之后才让AI加避免一把梭全挤在第一步改了布局还要连带改动画。5. 布局翻车现场常见问题与排查思路5.1 “元素位置不对”的三种真凶布局问题中最常见的就是“位置不对”。我统计了一下自己这段时间的翻车原因基本集中在三类。第一类是绝对定位的祖先问题。AI生成了一个带position: absolute的元素但它的父容器没有设定position: relative于是这个元素的定位基准莫名其妙变成了视口外层的爷爷节点看起来就像元素到处乱飞。排查方法也很简单打开浏览器开发者工具选中那个元素看它的“定位上下文”是谁如果是html或者body基本就是这个问题。修复指令就是“给父容器加position: relative”。第二类是百分比计算错误。AI在生成相对于容器宽度的百分比时经常忽略padding和gap的影响。比如三个按钮各占30%加上gap之后总宽度超过100%最后一个按钮被挤到下一行。这种问题在CSS里几乎无可避免因为百分比总是基于父容器的content-box宽度算的而gap和padding是额外吃掉的。我的处理是让AI直接用Flexbox的justify-content: space-between来分配间距而不是逐一设置百分比这样彻底绕开了计算误差。第三类是transform居中理解错位。AI很喜欢用top: 50%; left: 50%; transform: translate(-50%, -50%)这套老方法做居中但它偶尔会只保留top/left、忘掉transform或者把transform写在了不该写的子元素上结果元素的位置整个偏移。现在我的做法是要求AI尽量用“父容器Flex align-items/justify-content居中”这套写法更直接也不容易遗漏一半。5.2 层级错乱z-index不是越大越好游戏页面天然多层级背景、HUD、菜单、弹窗我通常预设的规则是背景层默认不设z-indexHUD为10主菜单为100弹窗遮罩为200弹窗卡片为210。AI偶尔会把某个值写成1000或者直接不写看起来“够大”但真出问题时反而摸不着头脑。更隐蔽的一个问题是CSS里有几种属性会创建新的层叠上下文比如transform、opacity小于1、backdrop-filter、filter。一旦某个容器加了这些属性它的内部z-index就只能在那个容器内部排序没办法跟外部元素比较。我亲眼见过一个弹窗卡片明明z-index是300但因为它的父容器只设了z-index为1且带有一个transform整个弹窗被一个z-index只有50的HUD盖住了。排查这类问题不能靠改大数字而要看层叠上下文在哪里产生。现在我的prompt习惯是加上一句“所有定位元素的z-index值统一遵循约定HUD10菜单100弹窗200不要在非必要位置使用transform如需动画弹窗动画结束后移除或保持不与层叠冲突”。这算是从源头减少AI生成混乱层级的机会。5.3 不同屏幕尺寸下“直接崩掉”的适配问题适配问题是我最晚开始重视的因为它往往不在桌面浏览器里暴露只有切到手机模拟器或者真机才炸。踩得最多的几个坑来回来去就是这些元素用了固定像素宽度比如width: 420px手机屏幕只有375px宽出现横向溢出。底部按钮被全面屏手势条遮住点击区域只剩一半。字体大小用死值比如标题32px在窄屏手机上会换行打乱卡片内部高度。忘记设置viewport的meta标签手机浏览器按980px宽度渲染页面所有元素显得极其微小。这些问题AI在最初生成代码时大概率不会主动处理除非你在prompt里明确了目标设备并把适配约束写进去。我现在处理适配的方式是“全局尺度用相对单位关键锚点用安全区变量”。比如字体可以用clamp()底部按钮用env(safe-area-inset-bottom)做额外间距容器宽度用min(最大宽度, 视口宽度百分比)。这些写法看起来复杂但要求AI按这个思路改并不难它本身的模板库里有大量现成语法。6. AI生成的布局代码必须人工复核的地方6.1 布局代码里的四个隐性坑经过十几轮实操我发现AI生成布局代码时有四个反复出现的“隐性坑”它们不报错、不影响功能但会在后期突然跳出来咬你一口。第一个是硬编码尺寸。AI特别喜欢把间距、圆角、字体大小全部写成绝对像素值。屏幕不变时没问题一旦做响应式这些值就成了定时炸弹。我的检查点是凡是与视口大小相关的尺寸是否用了vw、clamp()或容器宽度百分比凡是间距类属性是否可以用CSS变量统一管理。第二个是overflow控制缺失。游戏页面理应没有滚动但如果某个容器内容超长AI没设overflow: hidden也没有控制卡片内滚动页面就会莫名出现滚动条。这个在游戏场景里非常出戏玩家往下一拖整个UI错位。第三个是点击目标面积不够。AI生成的按钮经常是“视觉上刚好”但可点击区域高度只有30px左右远低于移动端推荐的48px最低标准。这种问题手指粗一点的用户会在真机上立刻发现但开发者停留在桌面模拟器上反而毫无感觉。第四个是标签语义和可访问性被完全忽略。AI生成的是游戏UI顶部信息条就真的用div堆按钮没有aria-label装饰性元素没有屏蔽读屏器。游戏虽然是偏娱乐场景但如果你做的是H5小游戏、可能需要发布到公开环境这些基础问题最好还是顺手解决掉。6.2 我的布局代码检查清单现在我每次让AI完成一块布局后都会按固定顺序过一遍检查。这活儿不复杂但极其管用检查项具体做法常见问题页面禁止滚动检查body是否有overflow: hidden容器内容溢出导致全局滚动条定位上下文用开发者工具选中元素确认position: absolute的父级是预期的容器父容器缺position: relative元素乱飘层级约定确认z-index按预设分层不存在意外创建的层叠上下文transform、backdrop-filter引发层级穿透指针事件HUD容器是否有pointer-events: none可交互元素是否恢复auto画布点击被透明容器拦截移动端适配宽度是否使用min(最大px, 视口百分比)底部是否预留安全区固定宽度导致横向溢出底部按钮被遮点击区域所有可点击元素的高度是否达到48px以上小按钮在真机上难以点击视觉居中居中方案是否为Flex布局而不是依赖translate关键transform属性缺失导致偏移我一般花两到三分钟就能把这份清单过完比在模拟器里反复点来点去有效率得多。遇到好像有问题的地方我会直接把问题复述给AI让它修而不是自己动手改代码——这是Vibe Coding的另一个原则尽量把“修改意图”交给AI执行保持自己的工作流是“描述-验证-再描述”。6.3 一个能显著提效的prompt习惯最后分享一个我最近用着特别顺手的小技巧让AI在CSS注释里写明每一块布局的定位策略和层级约定。听起来很偏门但效果出奇的好。我只需要在布局类prompt里追加一句“在每一块有position属性的CSS规则前写一行注释说明它的定位策略、层级值和原因”AI就会生成类似这种代码/* 定位策略整体覆盖全屏作为HUD的底层容器 */ /* 层级约定10必须低于弹窗层(200)不接收指针事件 */ .hud { position: fixed; inset: 0; z-index: 10; pointer-events: none; }这个习惯的价值在于AI后续迭代时会参考这些注释来理解我之前定的规范不会越改越乱我自己在调试时扫一眼注释就知道这层是干什么的、它的层级为什么这样设。更重要的是注释能逼着AI写出更符合逻辑的布局代码——它一旦被要求解释自己的定位决策很多随手乱写的position和z-index就自动减少了。现在我新开的任何游戏页面项目都会在开头就建立好“三层层级约定”并写进项目状态描述里后续每一个布局相关的prompt都基于这个约定展开。实测下来生成的布局代码返工率比一开始低了不少。Vibe Coding并不是把“写代码”这件事外包出去就完事了你需要做的是一个验收者和修正者的角色尤其是布局这种“一看便知对错”的部分你只要在浏览器和手机里多跑几轮、多描述几次偏差AI给你产出的成品质量会一路往上涨。
阅读完成 · 觉得有帮助？
