企业官网建设流程全解析

最近在GLM-5 Agent上试了一种新玩法：丢一张图进去，让它直接生成一个能玩的小游戏。我随手扔了张“牛马”卡通形象进去，结果它还真给我产出了一个叫“牛马快跑”的横版跑酷小游戏——玩家控制角色往前冲，跳坑、躲障碍、吃金币，跑得越远分数越高。整个过程我只输入了一条需求描述，没有手写一行游戏代码。

这个玩法听起来有点像“图生应用”，但真正跑通之后你会发现，它并不玄乎，背后就是一套多模态识别、任务规划、代码生成到自动验证的链路。这篇主要想讲清楚几件事：GLM-5 Agent是怎么把一张静态图片变成可玩游戏的、我在实操过程中踩了哪些坑、后续调优时最该动哪些参数，以及如何把你手里的素材图变成能反复复用的小游戏模板。如果你也想用AI快速做游戏原型，或者手头只有美术素材但缺个程序员，这篇可以直接照着抄作业。

1. 从图片到游戏：GLM-5 Agent内部到底做了什么

1.1 表面是“看图写代码”，实际是三段式协作

我第一次用的时候，以为这功能就是“文生图换了个输入方式”，但翻了Agent的执行日志才明白，它把整个需求拆成了三个阶段。

第一阶段是多模态识别。Agent拿到图片后，会先做目标检测和语义理解，识别出主体对象是“牛马角色”，同时提取轮廓、主色调、主体位置、朝向这些要素。比如我的图中角色偏右、背景偏浅，它就会在内部标记“角色主体位于右下区域，背景纯色，适合抠图”。

第二阶段是需求重构。识别结果不会直接变成代码，而是先转成一份类似“游戏设计文档”的东西。这份文档里会写清楚：角色是谁、场景怎么铺、玩家操作是什么、游戏目标是什么、失败条件又是什么。这个环节很关键，因为图片本身不会表达玩法，玩法要靠Agent根据常见游戏范式去推测并补齐。由于我在Prompt里明确说了“横版跑酷”，它就把设计文档定成了“自动左进、跳跃躲避障碍、吃金币加分、撞上障碍游戏结束”。

第三阶段是代码生成与自动验证。Agent会调用内置的代码运行环境，生成一个包含HTML、CSS、JavaScript的小项目，然后启动预览页面做测试。我注意到它每次生成完都会跑至少三轮自检：第一轮看图片资源能否正常加载、第二轮看主循环和绘制方法有没有报错、第三轮模拟点击键盘触发一次跳越，确认事件能通。任何一轮报错，它都会自动改代码再跑，直到全部通过。

1.2 为什么“一张图”比纯文字需求更高效

拿文字描述角色是个老大难问题。你跟Agent说“一只棕色的牛头人，穿着白色衬衫，戴顶草帽，表情很着急”，生成结果大概率跟你脑子里的形象差出一大截，因为同一句话在不同人脑子里对应完全不同的画风。

但图片不一样，它把所有模糊信息一次性锁死。主体长什么样、颜色怎么搭配、是厚涂还是平涂、有没有描边，这些全部被像素写死。Agent拿到图之后，任务从“无中生有”变成了“提取与增强”。它不需要想象“牛马长什么样”，只需要把图片里的角色信息抽出来，再放到新的游戏场景里。

有一点需要提前理解：图片在AI眼里是“需求说明书”，不是可以直接拖进游戏的“素材包”。你上传一张带复杂背景的JPG，Agent不会真的把那只牛从背景里抠出来再放进Canvas里，而是会先生成一份去背景的透明贴图，再基于贴图做角色动画。所以后续的抠图、裁剪、命名这些步骤，其实都是为了帮Agent把“说明书”转换得更干净。

1.3 一类图生成通用玩法的边界在哪

这种玩法适合什么样的需求？我觉得最典型的有几类：产品原型演示、活动H5互动页、课程作业、社区或社群里的病毒式小游戏，以及活动现场暖场互动。这类场景的共同点是“要快、要能玩、不强求商业级打磨”，一张图配一个智能体，半小时内就能掏出可点击的版本。

不适合的场景也很明确：需要联机对战、排行榜、账号系统、支付结算的正式商业游戏，或者对物理模拟精度要求极高的跑酷作品。AI生成的游戏本质上是一个“可运行的原型”，它帮你完成的是从0到1，后面的性能优化、玩法打磨、数值平衡、美术细化，依然需要人工介入。

2. 选图、提需求与玩法策划：决定游戏上限的三件事

2.1 怎么选图才不会翻车

在GLM-5 Agent上做“一张图小游戏”，选图选错了，后面再怎么调也救不回来。我整理了三条经验。

第一，主体要尽量大且位于画面中心或偏侧。跑酷游戏天然适合“侧面视角”的角色，如果你的角色是正面大头照，Agent做左右移动很难看，做上下跳也很别扭。我用的就是一张侧面站的牛马角色图，主体占比大概占画面高度的一半以上，这样识别轮廓时不会把背景杂物也算进去。

第二，背景要干净。纯色背景或接近纯色的背景最好用，后续抠图只需要做颜色切分。如果背景是花花草草或者复杂纹理，Agent生成的透明贴图边缘通常会有杂边，放到游戏里会显得很脏。实在没有干净背景，我建议先让Agent用图像处理工具把背景抠掉，再重新生成一份透明PNG喂进去。

第三，分辨率要够，但没必要过大。一张200x200的缩略图，放大到游戏角色之后全是马赛克；3000x3000的超大图，又会让Agent处理得很慢，而且压缩过程中容易失真。我实测下来，边长1024到2048之间、主体清晰的PNG最理想，导出的时候默认按两倍屏适配即可。

2.2 Prompt里必须写清的五个要素

很多人觉得“把图丢进去就完事了”，其实不是。Agent需要你告诉它“图片是角色素材”，否则它可能理解成“生成一张照片”或“识别照片里的场景”。我给了一个相对固定的提示词模板，直接复制就能用：

这是一个游戏角色素材图。请基于图片中的角色，开发一个横版跑酷小游戏“牛马快跑”： 1. 角色：使用图中的牛马形象，自动向右奔跑，带奔跑动画； 2. 操作：玩家按空格键或点击屏幕跳跃，支持二段跳； 3. 障碍物：随机生成高低不一的木箱，撞上则游戏结束； 4. 得分：每越过一个障碍物加10分，吃金币额外加5分； 5. 难度：速度随得分缓慢提升，障碍间隔随难度缩短； 6. 风格：背景为卡通天空、草地和云朵，整体明亮解压； 7. 输出：生成单页HTML文件，包含全部样式和脚本，不要依赖外部库。

五个关键要素分别是：角色来源、操作方式、障碍与得分规则、难度曲线、输出格式。缺了任何一个，Agent就会靠猜，猜的结果就经常是“能跑，但不好玩”。尤其“不要依赖外部库”这条一定要写，很多生出来的游戏会引外部CDN资源，网络一差直接白屏。

2.3 把“牛马快跑”的玩法规则写透

在我这次的案例里，玩法被我锁定成了“自动向右跑+手动跳跃+障碍躲避”。为什么选这个？因为它最稳。角色的运动是自动的，玩家只操作一个按键，对智能体来说实现成本最低、最容易跑通。双人对抗、道具系统、多角色切换这些，不是不能做，但每一次加功能都会增加代码生成的不确定性。

规则我最终定为三条：角色一直向右跑，速度从每秒260像素起步，每得100分提速10%；按空格或点击屏幕，角色跳起，再按一次可触发二段跳；撞上障碍物游戏结束，显示本局得分和最高分。这个规则简单到三岁小孩都能看懂，但做出来之后娱乐性并不差，因为“难度曲线”和“手感”才是决定好不好玩的关键，这部分放在后面专门细说。

3. 实操拆解：一张牛马图片是如何变成可玩游戏的

3.1 喂图之前的预处理，其实只需两步

在正式把图丢给GLM-5 Agent之前，我建议先做两个轻量预处理：方向校正和背景清理。

方向校正是因为很多图片拍出来或下载下来默认带EXIF旋转，或者角色是躺着的。如果直接上传，Agent可能把角色识别成“水平方向的物体”，生成出来的游戏里角色方向就是歪的。在本地相册或系统自带编辑器里旋转一下，让角色呈现“脚踩地、头顶天、身体朝右”的姿态，Agent的理解就会准确很多。

背景清理这一步不一定非要抠得像素级完美，但最好把角色四周的大块干扰元素裁掉。你可以在Prompt里让Agent上来自动调用图像处理工具去背景：

先去掉背景，保留透明区域，再开始做游戏，不要直接用原图当角色贴图。

加了这句之后，Agent通常会用像素分割或色键的方式生成透明PNG，后续放到Canvas里才能和背景叠加，不会出现一个大白方块挡在角色后面。

我想强调一个观察：很多人生成失败，不是Agent能力问题，而是喂图太脏。一张主角只有画面三分之一、背景里还有其他人物的图，识别成功率会断崖式下跌。预处理花五分钟，后面少踩一小时坑。

3.2 Agent内部的“素材生产流水线”

预处理做完，Agent的处理流程其实是这样的：先从图片里抽取角色主体，得到“角色帧”；然后根据颜色分布生成背景层的配色模板；再根据主题生成障碍物贴图、金币贴图等附加素材。

在“牛马快跑”这个例子里，Agent自动生成了一张角色奔跑用的Sprite图。它不是简单地把原图放大缩小，而是会把牛马角色拆成几个关键帧，用轻微旋转和位移模拟奔跑。从效果上看，就是角色在跑的时候，前腿和后腿会小幅度摆动，虽然不是细腻的手绘动画，但已经足够让人产生“这是活的”的错觉。

背景方面，它生成了三层滚动背景：远景天空云朵、中景草地和树木、近景道路和障碍物。三层以不同速度滚动，形成视觉纵深感，这是跑酷游戏常用的“视差滚动”手法。很多人以为视差滚动很高端，其实底层就是三个背景层用不同系数滚动，代码量不大。

3.3 核心代码逻辑：跑酷游戏的三个支柱

跑酷类小游戏的代码，核心就三块：游戏主循环、物理模拟、碰撞检测。我在生成的代码里简化出下面这个骨架，完全可以照着搭。

// 1. 主循环：用requestAnimationFrame驱动 let lastTime = 0; function update(time) { const dt = Math.min((time - lastTime) / 1000, 0.05); lastTime = time; player.update(dt); obstacles.forEach(o => o.update(dt)); coins.forEach(c => c.update(dt)); draw(); requestAnimationFrame(update); } requestAnimationFrame(update);

// 2. 物理：重力和跳跃 class Player { update(dt) { this.vy += GRAVITY * dt; // 重力加速度 this.y += this.vy * dt; // 垂直位移 if (this.y >= groundY) { // 落地判定 this.y = groundY; this.vy = 0; this.canJump = true; } } jump() { if (!this.canJump) return; // 在地面才能起跳 this.vy = -JUMP_VELOCITY; this.canJump = false; } }

// 3. 碰撞：AABB矩形检测 function checkCollision(rect1, rect2) { return rect1.x < rect2.x + rect2.w && rect1.x + rect1.w > rect2.x && rect1.y < rect2.y + rect2.h && rect1.y + rect1.h > rect2.y; }

主循环里把时间增量dt限制在0.05秒以内，是为了防止切后台再回来时，角色瞬间穿过障碍物。这个细节非常关键，不及时处理的话，玩家切个页面回来，游戏可能已经结束或角色穿到地下去了。

3.4 从生成到可玩：Agent的自动验证过程

生成完代码，Agent并不会直接把HTML文件扔给你，而是先在沙箱里跑一遍。它会启动一个无头浏览器加载页面，检查控制台有没有报错，再模拟一次按键事件触发跳越，最后把截图或状态报告返回给你。

我这次遇到过一次典型报错：图片资源路径写成了相对路径，但预览是无头浏览器临时目录，导致角色贴图加载不出来，页面把报错信息打印了一长串。Agent定位到是路径问题后，自动改成了内嵌Base64图片，把图片直接嵌进HTML文件，问题当场解决。这也是为什么我建议在Prompt里写“单页HTML+不要依赖外部资源”，出包即用，拷贝到任何地方都能跑。

4. 跑通之后的打磨重点：手感、画面与细节调优

4.1 核心手感参数：跳跃高度、重力、速度的搭配

一个跑酷游戏好不好玩，九成是手感决定的。而手感就是几个物理参数不断试出来的结果。先看初始参数表，这是Agent第一次生成时的默认值，我一并贴上实际调整方向。

第一次生成的版本手感很虚，角色跳起来像飘在太空。我把重力从900调到1200，跳跃初速度从-420调到-480，落地明显更清脆。紧接着把水平速度起步值维持在260，但每得100分增加10%，让玩家在破个人纪录时能明显感觉到“变快了”。

跳跃缓冲是很多人忽略的地方。它本意是：玩家在落地前60毫秒内按了跳跃键，系统会记住这次按键，等角色一落地立刻起跳。没有这个缓冲，玩家总觉得自己按键按早了没用，体验很差。加上之后，按键的“跟手”程度会有质的提升。

4.2 音效和反馈：让每一次成功都有回应

GLM-5 Agent生成的版本默认没有音效，玩起来特别安静。我在Prompt里追加了一条要求：

添加简单音效：跳跃时播放短促上升音，吃金币播放清脆“叮”声，撞击障碍播放低沉撞击声。全部用Web Audio API合成，不引入外部音频文件。

Agent还真用Web Audio API现写了一小段音频合成逻辑。比如吃金币的核心代码大概是这样：

const ctx = new AudioContext(); function playCoin() { const osc = ctx.createOscillator(); const gain = ctx.createGain(); osc.type = 'sine'; osc.frequency.setValueAtTime(880, ctx.currentTime); osc.frequency.exponentialRampToValueAtTime(1760, ctx.currentTime + 0.1); gain.gain.setValueAtTime(0.3, ctx.currentTime); gain.gain.exponentialRampToValueAtTime(0.01, ctx.currentTime + 0.2); osc.connect(gain).connect(ctx.destination); osc.start(); osc.stop(ctx.currentTime + 0.2); }

这段音频方案完全不需要素材文件，所有游戏文件仍然是一个HTML。视觉反馈也一样重要，我要求角色撞到障碍物时画面闪红、角色抖动、速度骤降，让玩家第一时间知道自己死了。这个反馈可以通过Canvas的变形和滤镜实现，代码量很少，但玩游戏时的“痛感”立刻就有了。

4.3 Agent给不了的“美术感”，用代码补

AI生成的美术资源基本等于“能看懂”，谈不上精美。牛马快跑这个游戏里，角色贴图是从一张图片里抠出来的，放到游戏里总感觉有点贴纸感。这时候与其反复让Agent改图，不如加一些覆盖式的视觉效果来提升档次。

我加了三种很便宜但效果明显的特效：得分数字跳动时略微放大再回弹、金币被吃时散出三个小光点、障碍物出现时自带半秒钟的下落阴影。这些效果本质上都是几行颜色填充和位移，但玩家感知到的“精致度”会高一个台阶。

还有一个土办法：给角色加一个半透明阴影。Canvas里直接画一个带Alpha的椭圆放在角色脚下，角色跳起来时阴影变小变淡，落地时变回原样。这个简单的“锚点阴影”能极大缓解“贴纸感”，让角色看起来像是真的站在地面上，而不是飘在空中。

4.4 性能优化与移动端适配，一次做完

从生成到可玩，跑在电脑浏览器上一般没问题，但如果要在手机上玩，就需要注意三件事：Canvas最大尺寸、设备像素比、触摸事件。

我要求Agent把Canvas缩放系数固定为window.devicePixelRatio的两倍以内，这样在高清屏上不会糊，但又不至于因为像素太高导致波动严重。障碍物和金币采用对象重用的方式，不持续创建新对象，减少GC压力。背景视差层控制在三层以内，再多对性能影响会指数级上升。

移动端适配最容易被忽略的一点是，HTML页面默认允许双指缩放和点击高亮。我让Agent在meta标签里禁用了缩放，并给Canvas绑定了touchstart事件，把触摸映射成跳跃。改完以后，手机打开页面就能直接玩，手感与键盘一致。

5. 换一张图等于换一个游戏：模板化复用与扩展思路

5.1 让Agent生成“配置模版”，而不是“一次性代码”

这个项目做完之后我在想，如果下次换一张角色图，是不是又要重新生生成一遍？试了几次发现可以偷懒：在Prompt里要求Agent把游戏参数抽离成顶部的独立配置对象，这样换图等于换配置。

我在Prompt里追加了这样一段：

把游戏所有可调参数抽离到代码顶部的一个GAME_CONFIG对象中，包括角色图片路径、角色尺寸、重力、跳跃初速度、跑步速度、障碍物间隔、背景速度系数、主题颜色。后续我只需修改这个对象即可换图换玩法。

于是Agent把原本散落在代码里的所有魔法数字集中到了一个配置块，看起来是这样：

const GAME_CONFIG = { playerSrc: 'data:image/png;base64,...', playerSize: { w: 72, h: 96 }, gravity: 1200, jumpVelocity: -480, runSpeed: 260, obstacleInterval: [1.2, 2.5], bgSpeedScale: 0.5, theme: { ground: '#6ec47a', sky: '#b8e6ff', cloud: '#ffffff' } };

有了这个对象，我再换一张图，只需要让Agent重新识别素材、生成新的Base64、替换playerSrc和playerSize，游戏主体代码一行都不用改。

5.2 批量换图的实操流程

我测试下来，一套“新图换皮”流程大概是四步：把新图保存下来，统一命名为角色名称；让Agent用同样Prompt生成一次新游戏；把新游戏的GAME_CONFIG和基准版本做diff，只保留差异部分；把差异部分手动合并到基准HTML里。

这个流程熟练之后，一张图换一个游戏只需要两三分钟。我拿同一套代码试过切换三种角色：牛马、小汽车、飞船。“牛马快跑”是横版跳跃，“飞船跑酷”就变成了躲避陨石，“小汽车跑酷”则变成了自动贴地飞行。同一个飞机关卡，因为GAME_CONFIG里的重力、速度、主题配色变了，玩起来完全像新游戏。

5.3 进一步扩展：从单机小游戏到互动页面

单机跑酷已经能玩，但如果你想让更多人一起玩或者想做一个活动页面，可以在这个骨架基础上继续扩展。

一个方向是加“分享得分图”。游戏结束后把本局得分和最高分绘制到Canvas上，用canvas.toDataURL()导出图片，再让玩家长按保存或直接调用分享接口。做社区裂变的时候这一招特别有用。

另一个方向是接一个简单的后端排行榜。但这里要注意，真正上线的排行榜需要防作弊、防重放、限流，这些已经不是“一张图生成”能覆盖的范围。短期活动或者内部演示，可以把 JSON 数据存储在本地浏览器 localStorage 里，做一个“本地排行榜”，体验和真实排行榜相差无几，成本却低到可以忽略。

我个人觉得，这个玩法最妙的地方在于：GLM-5 Agent并不需要真的理解“牛马”的梗，它只需要理解“一张图、一条需求、一份配置”，就能把游戏原型搓出来。后面真正要用到的，还是你对玩法、手感和边界条件的思考，AI只是在替你干那些不愿意干的重复劳动。

最后分享一个实际操作中的心得体会：我在调跳跃参数的时候，前前后后改了十几版，手感和玩家的“爽感”完全不是靠文字能拍脑袋定的。最好的办法是让Agent在游戏页面右上角放一组实时参数调试面板，拖动滑块就能在线调整重力、速度和障碍间隔，调到满意再把参数写回GAME_CONFIG。这个方案我自己用了之后效率翻倍。如果你也在用类似方式做小游戏原型，强烈建议把调试面板这条加进Prompt里，一次投入，后面每次换图都能直接用。