最近我又上线了一款“蚂蚁搬家”主题的小游戏这次从头到尾没碰过任何游戏引擎代码全部是靠AI一句一句磨出来的。标题里写“游戏引擎都没用”真不是标题党——一只蚂蚁、一堆食物、一个巢穴最后交付的就是一个能在浏览器里直接跑的HTML文件。身边不少朋友第一反应是“不用引擎怎么做游戏”第二反应是“AI真能写出能玩的东西吗”这篇文章就把整个过程完整复盘一遍怎么选型、怎么跟AI描述需求、AI写出来的代码有哪些坑、最后怎么发到网页和微信小游戏上。先说下我的背景做小游戏也有几年了平时常用的路线无非是Unity配C#、Cocos配TypeScript或者干脆用原生JavaScript写H5。这次选“纯AI无引擎”路线不是一时兴起而是我把蚂蚁搬家的需求列完之后发现这个体量的小游戏用引擎反而是负担。如果你也写过一点HTML或者正想试试“AI帮你做游戏”这篇操作记录应该能让你少走很多弯路。1. 先想清楚蚂蚁搬家为什么不需要游戏引擎1.1 从需求清单倒推技术选型接到“蚂蚁搬家”这个点子后我做的第一件事不是打开Unity而是拿张纸把游戏需求写下来游戏类型2D休闲、单屏、俯视视角核心循环蚂蚁从巢穴出发在场景中找到食物搬运回巢凑够目标数量过关玩家交互点击空地投放食物可能需要障碍物或加速道具视觉表现卡通风格蚂蚁和食物用简单图形即可运行环境浏览器直接打开就能玩手机端也能流畅运行这张清单一列完技术选型基本就定了。2D单屏、鼠标交互、没有物理模拟、没有3D场景这些需求用HTML5的Canvas API就能全覆盖。游戏引擎的核心价值在于渲染管线、物理模拟、资源管理和跨平台打包但一个画面里只有几十只蚂蚁、几堆食物的小游戏浏览器原生API处理起来绰绰有余。判断标准其实就一条你的游戏里有没有哪个要素是“离了引擎就实现不了”的比如3D渲染、粒子特效、刚体碰撞、复杂关节物理。蚂蚁搬家一个都没有。它需要的只是每帧清屏、画背景、画蚂蚁、画食物然后做距离判断。这种项目如果套Unity光是把编辑器界面、场景、预制体、导出设置折腾明白的时间就够我用AI把整个游戏写完三遍了。1.2 引擎的额外负担小项目装大轮子很多人谈游戏开发必提引擎但没想过引擎是有“启动成本”的。Unity项目一开就是一个完整的工程目录里面躺着编辑器版本配置、各种依赖包、场景文件、资源管线构建之后产出的包体动辄十几兆甚至几十兆而且首帧加载还要跑引擎初始化。对一个小游戏来说这些都是实打实的用户成本。纯HTML文件的好处就很明显一个文件就是整个游戏双击就能在浏览器里跑转发给别人就是一个链接加载完秒开。手机扫码也能玩不需要安装任何东西。我后来把它往微信小游戏方向适配时发现纯Canvas写的游戏改起来也特别容易比从Unity导出再走转换管线省事得多。这倒不是说引擎没用。如果你要做的是一个有完整养成系统、有特效、有连续关卡的复杂游戏引擎依然是更稳的选择。但“蚂蚁搬家”这个量级用引擎属于杀鸡用牛刀。选型首先要诚实面对项目本身的复杂度别为了“显得专业”而背上不必要的包袱。1.3 纯AI方案的边界AI能写但你要懂验收“纯AI”这个词容易让人误以为我全程当甩手掌柜。实际经历告诉我AI确实能生成一整套可运行的游戏代码但它的能力边界非常清晰AI擅长的部分把自然语言需求翻译成结构化代码调标准API比如Canvas 2D、requestAnimationFrame实现常见算法状态机、碰撞检测、简单寻路生成非核心的重复代码比如初始化、绘制函数、计分逻辑AI不擅长的部分理解你脑子里的“那种感觉”——具体的美术风格、手感、节奏兜住所有边界情况比如蚂蚁重叠、食物生成在巢穴里、玩家狂点鼠标代码跑挂之后自己定位问题它需要人类帮它看报错信息、确认现象所以我的角色更像“测试员加产品经理”AI负责写脚本我负责验收、提修改意见、在它写错的时候帮它圈定出错范围。这套协作方式用好了产出速度确实比我手写快很多。2. 核心玩法拆解让AI听懂“蚂蚁搬家”2.1 先用一句话定义游戏再拆成可执行规则给AI下需求最忌讳开口就是“帮我做个游戏”范围太大AI只能给你一套空壳。我习惯先自己用一句话把游戏定义清楚再把这句话拆成AI能逐条执行的小规则。我对蚂蚁搬家的定义是玩家通过点击制造食物蚂蚁自动往返于巢穴与食物之间进行搬运抢先搬回指定数量食物即过关。这个定义里有四要素产食物、自动寻路搬运、往返循环、数量目标。四要素对应到代码里就是四件事点击生成食物对象、蚂蚁渲染与移动、状态切换、计分与胜利判定。把规则列成自然语言再丢给AI比直接丢程序术语更稳因为AI本身是在预测“你想要的代码”你描述得越像需求文档它越不容易跑偏。我建议第一版提示词里包含游戏对象清单、各自的行为规则、胜负条件、交互方式、界面布局。五个维度齐全AI生成的第一版通常就能直接跑。2.2 第一版提示词设计把需求文档翻译成对话下面是我实际用的第一轮提示词你可以直接抄请用HTML CSS 原生JavaScript Canvas写一个“蚂蚁搬家”小游戏 1. 画布尺寸800x600背景为草地绿色左上角显示“已搬运数量/目标数量”文字。 2. 场景右下角固定一个褐色圆形巢穴巢穴周围随机分布8个食物点食物用黄色小圆点表示。 3. 页面加载后自动生成10只蚂蚁蚂蚁用黑色小椭圆表示从巢穴出发。 4. 蚂蚁的行为规则先向外游走寻找食物找到最近的食物后移动到食物旁食物消失蚂蚁携带食物返回巢穴回到巢穴后已搬运数加1蚂蚁重新外出寻找食物。 5. 玩家点击画布任意空白处在该位置生成一个新食物点。 6. 当已搬运数量达到30时弹窗提示“过关”并停止游戏。 7. 代码要包含完整的游戏循环、碰撞判定和注释确保在浏览器中可直接运行。这段提示词的技巧在于我没有让AI“自由发挥玩法”而是把规则一条条钉死。特别是第4条我把状态切换的流程完整描述出来AI就能很自然地生成一个状态机而不是写一堆散乱的if分支。第一版生成后基本能跑但我对其中的移动算法完全不放心所以专门补了一句“请确保蚂蚁朝目标移动时按向量归一化处理速度要一致”。这句话很有用后面实测踩坑时发现不加这句AI很容易写出“越靠近目标走得越慢”的bug也就是没有归一化的方向向量问题。2.3 数值平衡速度、数量、目标数的微妙关系AI能把功能写出来但“数值手感”它不太擅长这得人自己调。蚂蚁搬家看起来简单数值稍微一乱就出问题蚂蚁太多画面拥挤食物瞬间被抢空蚂蚁太少搬运过程干等节奏拖沓食物点密集时蚂蚁全挤在一起画面观感大打折扣。我第一版默认参数是10只蚂蚁、8个初始食物点、30个过关目标、蚂蚁速度120像素/秒。实测下来蚂蚁速度偏慢30个目标要跑两分多钟玩家早就没耐心了。后来把速度调到200像素/秒初始食物加到12个目标降到20节奏立刻紧凑起来。这里可以给个参考表方便你直接套用参数第一版调整后调整原因蚂蚁数量1012搬运效率提升画面不拥挤蚂蚁速度120 px/s200 px/s原速度观感拖沓初始食物812开局画面更丰富过关目标3020单局控制在1分钟左右点击生成食物半径无限制离巢穴3倍半径外避免食物生成在巢穴内被秒收数值这块的经验是第一版按“中间值”给然后自己在浏览器里跑一局用计时器记录通关耗时目标是把单局控制在60到90秒。超过这个区间玩家流失率很高。3. 从一句话到能玩的DemoAI生成全过程复盘3.1 第一版让AI先交一份能跑的骨架把提示词发给AI之后它会在几十秒内给你一份完整代码。我建议第一版不要提太多“优化”需求目标是让它给你一个四要素齐全的最小可玩版本能显示画布、蚂蚁能动、碰食物能拾取、回巢能计分。只要这四件事成立后面所有迭代都有抓手。第一版代码通常长这样!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title蚂蚁搬家/title style body { margin: 0; display: flex; justify-content: center; align-items: center; height: 100vh; background: #f0f8e8; } canvas { background: #ddebca; border-radius: 8px; } /style /head body canvas idgame width800 height600/canvas script const canvas document.getElementById(game); const ctx canvas.getContext(2d); const NEST { x: 700, y: 520, r: 45 }; const GOAL 20; const ANT_SPEED 200; const EAT_RADIUS 12; let ants []; let foods []; let delivered 0; let running true; function createAnt(x, y) { return { x, y, speed: ANT_SPEED, state: SEEKING }; } function createFood(x, y) { return { x, y, r: 7 }; } function distance(a, b) { return Math.hypot(a.x - b.x, a.y - b.y); } function moveTo(entity, target, dt) { const dx target.x - entity.x; const dy target.y - entity.y; const len Math.hypot(dx, dy); if (len 0.5) return; entity.x (dx / len) * entity.speed * dt; entity.y (dy / len) * entity.speed * dt; } function findNearestFood(ant) { let best null, bestDist Infinity; for (const food of foods) { const d distance(ant, food); if (d bestDist) { bestDist d; best food; } } return best; } function updateAnt(ant, dt) { if (ant.state SEEKING) { const target findNearestFood(ant); if (target) { moveTo(ant, target, dt); if (distance(ant, target) EAT_RADIUS) { foods foods.filter(f f ! target); ant.state CARRYING; } } } else { moveTo(ant, NEST, dt); if (distance(ant, NEST) NEST.r) { ant.state SEEKING; delivered 1; } } } function update(dt) { for (const ant of ants) updateAnt(ant, dt); if (delivered GOAL) running false; } function draw() { ctx.clearRect(0, 0, canvas.width, canvas.height); // 巢穴 ctx.fillStyle #a67c52; ctx.beginPath(); ctx.arc(NEST.x, NEST.y, NEST.r, 0, Math.PI * 2); ctx.fill(); // 食物 for (const f of foods) { ctx.fillStyle #e6b800; ctx.beginPath(); ctx.arc(f.x, f.y, f.r, 0, Math.PI * 2); ctx.fill(); } // 蚂蚁 for (const ant of ants) { ctx.fillStyle ant.state CARRYING ? #4a2f1b : #222; ctx.beginPath(); ctx.ellipse(ant.x, ant.y, 8, 5, 0, 0, Math.PI * 2); ctx.fill(); } // 计分 ctx.fillStyle #333; ctx.font 20px sans-serif; ctx.fillText(已搬运 delivered / GOAL, 16, 32); } let lastTime 0; function loop(t) { const dt Math.min((t - lastTime) / 1000, 0.05); lastTime t; if (running) { update(dt); } draw(); requestAnimationFrame(loop); } // 初始化 for (let i 0; i 12; i) { ants.push(createAnt(NEST.x, NEST.y)); } for (let i 0; i 12; i) { foods.push(createFood(80 (i * 60) % 640, 60 (i * 40) % 420)); } canvas.addEventListener(click, (e) { const rect canvas.getBoundingClientRect(); const x e.clientX - rect.left; const y e.clientY - rect.top; if (running distance({ x, y }, NEST) NEST.r * 3) { foods.push(createFood(x, y)); } }); requestAnimationFrame(loop); /script /body /html这份代码放到浏览器里刷新一下画面里蚂蚁会立刻涌向食物搬运回合转起来我已经完成一次能玩的Demo了。注意第36行的Math.hypot和第79行的(dx / len)这其实就是前面说的向量归一化AI在提示词的引导下很轻松就写对了。3.2 迭代改需求不要推翻重来要精准下指令第一版能跑之后后续迭代才是重头戏。很多人的错误做法是发现不满意直接复制全部代码丢给AI“请重写一个更好玩的蚂蚁搬家”。AI会非常听话地给你重写但代价是之前所有调整过的细节全都没了等于推倒重来。我的做法是“增量式指令”把当前代码作为一个整体背景交代清楚然后只告诉AI“要在这个版本基础上改哪一点”。基于当前代码做修改 1. 蚂蚁在搬运食物返回途中把食物画在蚂蚁身后表示它正在拖着食物走。 2. 巢穴左侧增加一条蜿蜒的障碍带蚂蚁遇到障碍物时不会穿墙而是绕过障碍物行走。 3. 画面下方增加一个“剩余时间”条初始60秒每秒减1时间归零游戏结束。这样每一轮改动都是局部覆盖AI只需要理解“在哪里改”不需要理解你整个项目的重构意图。实测下来增量式指令的落地效果远好于全量重写出bug的概率也低得多。还有一个小技巧每轮修改前先把当前版本代码备份一份。AI改代码偶尔会把原本好的功能改没了这时候直接回退到上一份备份继续提需求比你自己人肉改回来快得多。我习惯用类似ant_v1.html、ant_v2.html这样的命名保存版本改崩了就回到最近可用版。3.3 一次生成整包还是分模块生成我的实操结论我把AI生成策略分成两种一种是“一次生成整包”把所有代码一次性让AI输出另一种是“分模块生成”先后台逻辑、再渲染、再交互最后自己拼装。对蚂蚁搬家这种小项目我最终选择的是“一次生成整包然后分轮补丁”。原因有两个第一整包生成时AI能看到完整的上下文变量命名、函数调用关系是自洽的分模块生成最大的问题是接口不一致AI第一个模块里定义了一个函数名第二个模块里可能就忘了。第二小游戏的代码量本身只有几百行一次生成完全在AI的能力范围内没必要人为拆分。但如果你的游戏模块之间有强耦合比如战斗系统、背包系统、地图系统互相调用那“先让AI生成主架构再逐个模块迭代”是更好的路径。先搭骨架、再补肌肉而不是让AI一次把所有器官都长出来。4. AI写的蚂蚁为什么“看起来很聪明”核心逻辑解析4.1 蚂蚁状态机寻找、搬运、归巢的切换“蚂蚁看起来在思考”的错觉来自状态机的切换足够干脆。整个蚂蚁行为被拆成两个状态SEEKING外出找食物和 CARRYING搬运回巢。AI实现状态切换的方式并不神秘function updateAnt(ant, dt) { if (ant.state SEEKING) { const target findNearestFood(ant); if (target) { moveTo(ant, target, dt); if (distance(ant, target) EAT_RADIUS) { foods foods.filter(f f ! target); ant.state CARRYING; } } } else { moveTo(ant, NEST, dt); if (distance(ant, NEST) NEST.r) { ant.state SEEKING; delivered 1; } } }这个结构非常好读外出→找到食物→吃掉→切换搬运→回巢→放下→再外出。每个状态只做一件事切换条件都是距离判定。你不需要给蚂蚁加载任何高级算法只要保证“一个时刻只执行一个目标”视觉上就会觉得很自然。后面我测试时发现一个有意思的现象当食物被搬得差不多、只剩角落里一个时所有蚂蚁都会朝同一个目标涌过去画面像一队蚂蚁在排队抢食。这是符合预期的因为findNearestFood对每只蚂蚁都返回同一个最近食物。如果不想让他们扎堆可以让AI加入“每个食物最多同时被一只蚂蚁锁定”的分配机制画面就会散开很多。4.2 不搞A*用向量移动加一点随机扰动提到寻路很多人第一反应是A算法。但蚂蚁搬家的场景里根本没有复杂的网格迷宫地图是开阔的障碍也少A属于过度设计。AI在这里用的是最简单有效的方案朝着目标点的方向直接移动每一步都重新计算目标方向。function moveTo(entity, target, dt) { const dx target.x - entity.x; const dy target.y - entity.y; const len Math.hypot(dx, dy); if (len 0.5) return; entity.x (dx / len) * entity.speed * dt; entity.y (dy / len) * entity.speed * dt; }这里的关键是(dx / len)。如果不除以长度物体移动速度会随距离变化离目标远时一步跨老远离目标近时几乎挪不动这就是著名的“越走越慢”bug。除过长度之后dx和dy被归一化成一个只有方向的单位向量乘以固定速度值蚂蚁全程匀速前进。只做直线移动会让蚂蚁轨迹太“机械”所以我让AI在每只蚂蚁身上加了一点随机偏移寻路方向上叠加一个15度到30度的随机摆动蚂蚁的路径就会变得弯弯曲曲观感上很像真实蚂蚁的探索行为。代码量只多了三行但画面生动程度是完全不同级别的。4.3 拾取与送达判定距离碰撞检测的正确姿势Canvas小游戏里最常用的碰撞判定就是距离检测如果两个圆心的距离小于半径之和就算碰撞。AI写的版本通常也遵循这个逻辑但这里有几个容易踩的细节拾取半径不能太大否则蚂蚁隔着两三个身位就“隔空取物”也不能太小否则蚂蚁需要精确压到食物中心才能触发视觉上就像蚂蚁绕着食物跳交谊舞。我实测下来的理想值是拾取半径等于蚂蚁半径加食物半径再加2像素容差。蚂蚁视觉触碰到食物边缘的瞬间触发拾取观感最自然。送达判定同理到巢穴中心距离小于巢穴半径即可不建议用“回到巢穴中心坐标”这种严格条件蚂蚁会因为永远差零点几像素而卡在巢穴门口。如果你在后面加了障碍物还需要在moveTo之前先做一次“目标点是否被障碍物阻挡”的判断。简单做法是把障碍物也当成排斥点检测到前方有障碍时把移动方向临时转向、绕行。复杂的做法才需要网格寻路对蚂蚁搬家这种体量绕行方案已经足够。5. 实测排错记录AI代码跑起来之后的那些坑5.1 蚂蚁原地打转方向向量忘记归一化第一次实测时我碰到一个非常典型的bug有部分蚂蚁不出巢穴一直在巢穴边缘小幅度抖动像卡住了一样。打开控制台细看发现这些蚂蚁的目标点距离它们其实很近但每次moveTo移动的距离极短肉眼几乎看不出变化。根因就是方向向量没有归一化。当目标距离len很小时(dx / len)里的dx和dy都趋近于零乘上速度之后每帧位移可能只有0.01像素蚂蚁看起来就像在原地“抖”。这个问题在“目标点刚好在巢穴边上”时特别明显。修复方案有两个层面一是让moveTo在len小于某个阈值时直接返回二是拾取判定要早于移动的最小步长。我让AI在moveTo开头加了if (len 0.5) return同时把拾取半径稍微放宽一像素问题立刻消失。这个坑如果你自己手写八成也会踩一次属于Canvas小游戏的经典问题。5.2 食物搬运错位坐标系偏移的锅第二个坑出现在加了“蚂蚁拖食物走”的表现之后。我给AI提了需求搬运状态下食物画在蚂蚁身后。AI照做之后我发现两个诡异现象一是蚂蚁走到巢穴门口时食物还挂在身后十几像素外二是计分在蚂蚁还没进巢穴时就触发了。排查下来AI把“食物绘制偏移”和“碰撞圆心”混在了一起。它在绘制时给食物坐标减了一个偏移量但碰撞检测用的还是食物最终的显示坐标。蚂蚁看着已经咬住了食物实际碰撞点却靠后很多。修复思路很清晰显示坐标和逻辑坐标必须分离。给食物加一个carryOffsetX和carryOffsetY字段绘制时用偏移值渲染但碰撞检测始终用逻辑坐标。我在提示词里明确要求“所有渲染偏移只影响绘制不影响距离计算”这个问题就再没出现过。5.3 蚂蚁一多页面就卡渲染循环的性能优化玩家人数一多网页端最容易暴露的问题是性能。我把蚂蚁数量拉到30只、食物50个之后画面帧率明显下降特别是每只蚂蚁都带阴影特效时。排查后发现性能瓶颈在“每帧重复创建临时对象”。AI默认写法会在draw函数里频繁new对象、拼字符串、反复设置fillStyle这些操作在每帧循环里被成百上千次执行再快的浏览器也扛不住。优化手段依次是复用绘制函数、减少fillStyle切换次数、用单个字符串拼接文本、把shadowBlur这类高开销渲染全部去掉。更立竿见影的一招是引入对象池。蚂蚁总数固定食物也不会超过一定数量级提前创建好对象数组、复用闲置对象而不是用push和filter频繁增删数组。把foods foods.filter(...)改成标记删除触发垃圾回收的次数立刻降下来实测帧率能提升一倍以上。5.4 AI排错方法论一次只改一个变量跟AI协作排错最怕的是“一次性让AI改五处”。AI有上下文窗口限制改动点一多它很可能告诉你“全部改好了”但实际改了前半截忘了后半截或者改A的时候破坏B。我给自己定的规矩是一次只提一个明确的修改目标。发现蚂蚁原地打转就只描述“蚂蚁在目标附近抖动请修复moveTo的归一化问题”发现绘制错位就只描述“食物偏移影响碰撞判断请分离渲染与逻辑坐标”。一个问题修完、验证通过再提下一个问题。因为AI没有运行环境它只能靠读代码猜现象你得把自己当成它在浏览器里的眼睛“我看到的是X现象我怀疑是Y函数导致的请你检查这一段。”这样描述AI的修复命中率高很多。如果现象实在说不清就把报错信息原样贴给它报错信息是排错时最有效的上下文。6. 部署分发从浏览器到微信小游戏6.1 网页端首发三分钟让朋友能用手机玩到游戏在本地跑通之后第一步是部署成网页。最简单的方案是把HTML文件推到任意静态托管平台比如GitHub Pages或者国内各种对象存储加静态网站托管。上传完拿到链接用二维码工具生成一个二维码手机扫开就能玩。纯H5小游戏在手机上的体验有几个注意点一是viewport适配确保页面在手机上不会出现横向滚动条二是点击事件要把触摸和鼠标事件都绑上移动端用户用的是touch而不是click三是尺寸适配手机屏幕比例和桌面不一样我做的800x600画布在手机上两侧会有黑边可以接受但如果你追求满屏可以让AI生成一套根据屏幕尺寸动态缩放的逻辑。这部分我的经验是不要等游戏“全部完美了”再部署第一版能玩就立刻挂上去把链接发给三五个朋友实际玩一下他们的反馈比你自己调十轮参数都值钱。6.2 微信小游戏适配Canvas游戏换壳思路很多做小游戏的朋友会关心“能不能上微信小游戏”。答案是肯定的。微信小游戏的运行环境其实就是一个阉割版浏览器Canvas API基本通用迁移成本比Unity导出低很多。Unity项目要上微信小游戏通常是走官方提供的Unity微信小游戏适配方案把Unity webgl版本转换过去过程涉及资源压缩、加载优化、包体瘦身。但我们是原生Canvas写的H5游戏根本不需要那套重型管线主要工作是把浏览器API替换成微信小程序API// 浏览器环境 const canvas document.getElementById(game); const ctx canvas.getContext(2d); // 微信小游戏环境 const canvas wx.createCanvas(); const ctx canvas.getContext(2d);其他像坐标获取、窗口尺寸这些直接用对应API换一遍即可。它本质上是同一个游戏逻辑只换了一个启动壳。主要的额外工作是把游戏拆成主包和子包、设置分屏适配和系统信息获取。如果你完全没接触过微信小游戏开发第一次提审前需要准备小游戏类目选择、隐私合规声明、测试账号信息。内容本身没问题就正常走流程。顺带提一嘴如果你一开始就是冲着微信小游戏去的甚至可以直接让AI按wx.createCanvas的写法输出代码一步到位省掉后面改壳的功夫。6.3 交付前的内容自查与避坑清单上线之前有几个和内容相关的事项我会习惯性检查一遍。虽然做的是休闲小游戏但既然要面向公众分发我会确认游戏文案里没有不良诱导和违规词不需要收集用户任何隐私数据点击类交互不涉及支付及诱导分享界面尺寸在不同机型上不会造成明显错位。这些自查项不是平台强制的“高大上”要求而是省得后面被退回再来回折腾。最后给想要复刻这个流程的人一份避坑清单第一版提示词把规则写细宁可写得像需求文档不要只丢一句“做个蚂蚁游戏”每轮迭代只改一件事改完先备份再进下一轮移动代码里必须做向量归一化否则蚂蚁会“越走越慢”显示偏移和逻辑坐标必须分离画出来的位置要和判定位置一致性能卡顿时先查每帧渲染里是不是new了太多临时对象部署后立刻拿手机实测一次触摸操作别只在电脑上自嗨我做完这个项目最大的体会是AI把“从想法到能跑的小游戏”这条路的门槛压得极低。以前写一个这样的游戏从搭页面到调手感至少得一个下午现在从零到上线Demo一小时就走完整个流程。剩下的事情——调参数、修手感、做细节——才是一个游戏真正“活起来”的部分而这一块恰恰是AI替代不了、也最值得投入时间的地方。