实测Gemini 3做小游戏：全过程记录与协作技巧

我这两天拿Gemini 3折腾了几个小游戏说实话成品质量超出我预期但过程比想象中凶狠多了。所谓凶狠不是它怼人而是它写代码、改代码、甚至删代码的风格特别果断经常一口气给我重构一大片逻辑完全不跟你商量。你要是没点心理准备真会被它突如其来的操作吓一跳。这篇文章不聊虚的就是我实际用Gemini 3做小游戏的完整记录包括我到底让它做了什么、提示词怎么写的、中间踩了哪些坑、以及最后跑起来的成果到底怎么样。适合两类人看一是想用AI辅助做小游戏但一直停留在“问来问去”阶段的新手二是在意AI协作效率、想看看新一代模型到底能扛多大事的开发者。看完你会发现Gemini 3不是那种只会输出样板代码的工具它更像一个手速极快、想法很多、偶尔用力过猛的实习生。1. 为什么选Gemini 3做小游戏一次有点冒险的尝试1.1 以前做小游戏的老路子和痛点在小游戏这块以前我最常用的套路是去开源社区扒现成模板然后自己改逻辑。这方式稳是稳但有两个问题一直绕不开一是老代码的架构通常很“远古”想加新功能得先理解人家十年前的命名习惯二是很多模板的渲染性能一言难尽手机上一跑就发热改起来比重新写还费劲。后来我也试过用其他AI工具辅助但体验比较割裂。你给它一句“做个贪吃蛇”它确实能给你一个能跑的页面但只要你稍微提点进阶要求比如“蛇碰到墙壁别死而是穿墙”它就会在原有代码上打补丁打到最后逻辑全是补丁摞补丁没过多久自己都看不懂了。这也是我对AI写小游戏一直持保留态度的原因AI生成代码能跑不代表能维护。所以这次我抱的心态是“试一试翻车也不亏”。Gemini 3这名字听起来就像个大模型的新版本我想看看它在代码生成、多轮修改、逻辑理解上到底有没有质的提升。1.2 Gemini 3让我印象最深的三个反常表现第一它不问你需求细节。你给它一个模糊想法它不会追着你问“规则是什么”“边界条件怎么处理”它直接先把完整方案甩给你连背景、逻辑、交互说明都写好了然后再上代码。这个“默认当你是懒人”的风格一开始让我很舒服但后来发现也有风险——它默认的太充分了反而可能跟你心里想的不一样。第二它改代码是“砍瓜切菜”式的。我让它把贪吃蛇的固定速度改成动态速度结果它不只是改个速度变量而是把整套食物生成、计分、碰撞检测、移动逻辑全部重写了一遍。你说这是好事还是坏事产品角度是好事代码角度是真吓人。我等于失去对部分代码的控制权只能靠跑起来的效果判断对不对。第三它会主动给自己加戏。比如写物理弹球的时候我明明只要简单的重力模拟它顺手把粒子特效、音效播放、响应式适配全加进去了。这确实惊艳但也让页面代码体积从预期的一百行膨胀到五百多行。性能是好了可调试范围也变大了。我在上手第一天就想明白一件事跟Gemini 3协作不能把它当搜索引擎用要把它当成一个比较有主见的结对编程伙伴。你每次都得好声好气说清楚自己的底线否则它真的会在你一个不留神就把全局变量改成函数式写法。2. 我用Gemini 3做的三个小游戏2.1 第一个会“咬人”的贪吃蛇AI自动调难度的蛇这个游戏的核心创意很简单贪吃蛇的移动速度会跟着得分自动变快但关键变化是“蛇的尾巴会越来越紧”。意思是随着分数提高蛇转弯的平滑度会下降整条蛇会变得越来越“硬”操作难度陡增。这个灵感来自老式街机的渐进式难度设计但Gemini 3的凶狠之处在于它把这个难度判断做得极其细致。我只给了它两句话“做贪吃蛇难度要曲线上升别线性上升玩家能明显感觉到但又不至于劝退。”它返回的代码里居然有一个基于帧数的动态调节公式每过一定分数就改变移动间隔还会根据玩家的死亡次数做衰减。也就是说如果你连续死亡三次它会偷偷把难度降一档让你喘口气。这逻辑我之前只在商业游戏里见过Gemini 3居然自己就实现了我当时人都是懵的。实机测试的时候画面上蛇身颜色的饱和度会随速度提升而变化跑快之后整条蛇会变成淡红色视觉上真的有“狂暴化”的感觉。这种细节没人在提示词里提过它自己加的属于纯纯的惊喜。2.2 第二个一把梭的物理弹球自己算碰撞的那种这个游戏开始前我明确说了“不要用现成的物理引擎自己写碰撞公式。”我本意是想看它会不会老老实实照做结果它真的全程手写了圆球和挡板的碰撞响应连摩擦力、弹性系数、空气阻力都模拟得有模有样。我不否认这有点“大炮打蚊子”但正因为是手写的物理我才可以很方便地调参数不需要去翻引擎文档。Gemini 3写碰撞检测的时候用了向量反射的思路。球碰到倾斜挡板时法向量计算会被精确处理而不是简单的上下左右反转。这一点很让我满意因为这正是大多数五毛特效游戏做得最烂的地方。它居然在一个提示词周期内就写对了我跑测试的时候球以不同角度砸到挡板反弹路径肉眼可见地符合直觉。要硬说缺点那就是它默认把所有逻辑塞进了一个文件里画布绘制、物理计算、事件监听全在同一个匿名函数里。我想单测其中一个函数都费劲得先把它手动拆出来。所以那个项目我后面又花了半小时抽离代码这大概就是“凶狠”的代价。2.3 第三个自动生成关卡的2048改版2048这种游戏正常逻辑就是固定4x4网格但我这次想让Gemini 3做一个“自定义形状棋盘”也就是棋盘可以不是正方形可以是三角形、十字形甚至不规则多边形。这需求在逻辑上并不简单因为合并方向的计算要完全重写。结果Gemini 3真把这事干成了。它用数组的数组表示连通网格每个单元格记录相邻格子的位置关系。滑动方向会自己去查相邻关系表而不是像传统写法那样按行列遍历。看到那段代码时我确实被震到了因为它没有参考我给的任何示例完全是自己设计的邻接矩阵方案。虽然效率不算最高但在网页游戏这个量级上完全够用。它还给这个2048改版加了一个“最少移动步数提示”系统会在界面角落显示一个建议滑动方向新手用起来特别友好。我承认这功能有点犯规但这个加戏我还是很吃的。3. 实操记录从提示词到能玩的完整路径3.1 提示词怎么写才不会被它带偏经过这三轮折腾我自己总结出一套针对Gemini 3的提示词模板。核心原则是把“预期目标”和“不允许行为”写清楚尤其是“不允许行为”格外重要。这家伙胆子太大你要是不设红线它连WebSocket联机对战都敢给你上。我实测下来比较稳的格式是做一个HTML小游戏核心玩法是[玩法一句话]。 要求 1. 不需要外部图片资源所有图形用Canvas绘制 2. 运行环境是PC浏览器不考虑移动端适配 3. 不要引入任何第三方库原生JavaScript完成 4. 如果规则太简单试着加入[某个进阶机制] 5. 代码里逻辑部分必须有注释特别是复杂算法 6. 最后给我一个可以整体复制运行的独立HTML文件。这个模板我试了三次每次生成的代码都能直接跑没有一次出现“还需引入jQuery”之类的尴尬依赖。Gemini 3很吃这套“清单式”描述它会完全按编号一条条实现甚至你自己遗漏的细节它都会补全。但要小心的地方是它非常容易误解“不吃外部图片资源”这句话。在贪吃蛇项目里它虽然没有引入图片却用Canvas内置的渐变绘出了蛇身的纹理画出来像是啃了一嘴彩虹。这倒也不算错只是美术风格跟我预期差别有点大。3.2 它写代码的特点一口气给你重构我第一次用Gemini 3写小游戏时最不习惯的就是它那种“全量重写”的毛病。哪怕你只是希望它修正一个碰撞检测的小bug它也会把整个检测函数重写一遍连带着把相关的变量命名也改了。这意味着你给它看旧的代码它回给你的是一套“优化版”而不是局部修改版。举个例子我让它给物理弹球加一个“挡板宽度随分数变窄”的功能它直接把游戏主循环改了。原来游戏循环里用的是requestAnimationFrame它改成setInterval理由是“通过固定时间步长来控制物理稳定性”。从工程角度讲这话没毛病但当时我还没准备好接受这么大的改动于是整个页面突然掉帧我排查了十分钟才发现是循环机制变了。后来我学乖了每次让它改东西之前都先加上一句“只修改与本次需求有关的功能不要改动其他部分不要重构不要优化性能。”这会极大降低它的“凶狠度”。但有趣的是即便加了这句话它偶尔还是会忍不住在一些无关紧要的变量名上加装饰性注释。这可能就是模型被训练得太注重代码美观的结果吧。如果你想保留一部分代码不被它碰那最好的办法是把这部分代码单独放到一个函数里然后明确说“这个函数不要动”。它会老老实实只调用这个函数修改函数之外的内容。这是我实测下来最有效的方式。3.3 调试与修正凶狠的另一面是容易走过头Gemini 3大部分时间里生成的代码质量很高但它有个显著毛病一旦发现运行错误它会把问题往大处解决。比如物理弹球里小球偶尔会卡进挡板里面正常修复思路是“调整碰撞判断的临界值”它倒好直接给整个挡板加了物理引擎式的“推挤逻辑”也就是当球嵌入挡板时挡板会产生一个推力把球弹开。这种修复方式很彻底但也让代码量多了一倍。这种“走过头”的修正在AI协作里其实挺常见。模型的训练数据里包含了大量“更好的工程实践”所以它在修复bug时会倾向于采用更底层的通用方案而不是最简洁的局部补丁。这跟人类新手的心态一样知道得越多越想把问题解决得光鲜亮丽反而忽略了最直接的做法。我的应对策略是三步走。第一步先截图或描述现象不直接给它代码让它猜第二步我自己定位到可疑函数把那一段代码单独拿出来让它在限定范围内修正第三步修正完必须运行一次全链路测试不能再让它继续改。这流程下来踩坑概率大幅降低而且每一轮修改的代码差异也能看得更清晰。4. 常见问题与排查技巧和Gemini 3协作的避坑指南4.1 它喜欢“自作聪明”地重构怎么约束我前面提到过Gemini 3的默认行为是“顺手优化一切”。这个问题在小游戏这种小型项目里尤其明显因为代码总量不大它很容易一眼就看出一堆可以改进的点然后全给你改了。约束的关键在于“命令式语气”加“范围限定”。我用下来最有效的是这句话“请严格只修改我提到的函数/功能块不要修改其他代码即使你认为它们有改进空间。”加上这句话之后它的重构冲动会降低一半左右。但你也别指望它能100%听话偶尔还是会蹦出一行你都看不懂的“优化注释”。如果实在约束不住还有一种终极办法把它改之前和改之后的代码丢到diff工具里对比自动找出多余修改然后再把需要还原的片段复制回去。虽然这样很费手工但至少能保证代码确实在你的掌控范围内。毕竟AI大模型写出来的代码不是每行都需要为它负责但每行都需要被你审查。4.2 代码真跑不起来了先自己做个最小复现有两次我拿到Gemini 3生成的代码满怀期待地打开浏览器结果整个页面是白屏连报错都没有。这种时候千万别急着找它算账更不要把这个大段代码原封不动扔给它问“为什么坏了”它大概率会一脸迷茫地回你一句废话“可能是你的环境有问题。”正确的操作是先自己排查。我通常在浏览器F12控制台里看日志如果没有任何报错就用二分法把代码块里的关键函数一个个注释掉看看哪一步开始出现渲染异常。等你把这个“最小复现版本”整理出来再拿给Gemini 3看它一下子就能精准找到问题。举一个我实际遇到的例子2048改版里它生成的棋盘初始化函数里有一行多余的sort()调用导致每回合数组顺序被重新洗牌。这bug非常阴因为数值和布局看起来都正常但合并就是不符合预期。我花了好久才发现而当我把这个sort()拎出来问Gemini 3它秒回“这行代码没有任何必要应该是调试时残留的。请删除。”你看它也不是全知全能还是得靠人工定位。4.3 资源占用和渲染性能小游戏也不能瞎搞让我有点意外的是Gemini 3生成的代码在性能上居然比我手写的还激进。它默认会开启大量的Canvas离屏渲染还会在每一帧里重新计算全局的背景渐变。我的电脑配置不算低跑起来还稳定60帧但一旦切换到低性能设备表现就很难说了。如果你也有用Gemini 3做小游戏的想法建议拿到代码后先看一眼主循环里有没有明显的重复计算。最常见的问题是把不依赖时间的常量渐变放在requestAnimationFrame里面每一帧都重新执行一次。把这种计算挪到循环外性能立刻能提升一个台阶。另外我还发现它会生成一些“看起来很有表现力但实际没必要”的代码比如用shadowBlur做发光效果在多元素场景下非常吃性能。这类效果在桌面浏览器没啥问题但在移动端上发热严重。所以如果你打算给朋友发过去用手机玩建议提前跟Gemini 3加一条约束“所有特效最多用透明度和颜色变化实现不要用shadowBlur不要用复杂的离屏缓存。”它确实会听话。5. 我个人在实际操作中最深的几点体会如果让我用一句话形容Gemini 3做小游戏的体验那就是它像一个动手能力极强但性格有点固执的朋友。你说想要个简单的游戏它给你一个完整的游戏你说修改一个参数它给你重写一套架构。跟它搭档你必须不断练习“说清楚边界”的本事。我给它写提示词的熟练度已经从一开始的“请做个贪吃蛇”进化到“请做一个贪吃蛇但禁止使用全局状态所有变化都要通过状态对象传参”。Gemini 3确实听得懂而且它会严格按照我的路子去写哪怕那个状态对象管理得有点绕它也不会提出异议。这让我觉得跟AI协作的爽点不在于它有多聪明而在于你能力范围越清晰它越能发挥价值。最后分享一个我自创的小技巧每次让它“新增功能”之前我都会先让它“把当前代码压缩到最小可运行版本”。这不是为了省字而是逼着它把核心逻辑暴露出来省得它在花花绿绿的特效里藏一堆难维护的代码。实测下来光是这一步就能减少我半天的debug时间。以后你自己玩起来也可以试试这个穷举式的瘦身法。