我做了六年后端开发写过接口、啃过数据库却完全没碰过游戏引擎。年初被朋友激了一句AI都能写游戏了你敢不敢白手做一个微信小游戏我就真去试了。结果比我预想的顺——从跟AI聊天聊出一个能跑的MVP到备案用掉27天再到踩坑、被驳回、修bug、最终上架整个过程是完整走下来了。这篇实录写给跟我一样的非游戏开发者你不需要先学会Unity再谈做游戏AI在你和一版可运行的小游戏之间已经架起了一条比想象中窄得多的路。但它不是没有代价坑一个不少我这篇就是把坑位和爬坑姿势全部摊开。1. 聊天出MVP一版提示词、五轮报错循环、一千行代码1.1 为什么选原生Canvas而不是Unity调试链路是决定性因素看过unity微信小游戏打包这个热词的人应该不少Unity确实是做微信小游戏最常见的路径我以前也以为要做游戏就得从它入手。但真正上手后我发现对非游戏开发者来说Unity这条路的隐性成本高得吓人。Unity的工作流是在Unity编辑器里写完玩法用导出工具转成微信小游戏适配的包再导入微信开发者工具调试。这一条链路上任何一环出了问题你都要同时搞懂Unity版本、导出插件配置、微信SDK版本、C#和JS的差异。AI生成代码的报错一旦出现在这种混合环境里定位问题的难度是成倍增长的——你分不清到底是Unity的问题还是微信适配的问题还是AI生成代码本身的问题。所以我当时直接选了原生JavaScript加Canvas的方案。理由很实在微信小游戏的原生开发环境就是JS和CanvasAI训练语料里这类代码的密度远比Unity专用脚本高生成质量更稳更关键的是调试链路短——把代码粘进微信开发者工具跑起来报错直接丢回给AI它修复我再跑。这个闭环是否顺畅直接决定你从有点子到有MVP是花一星期还是一个月。对小体量休闲游戏来说原生Canvas的能力边界完全够用不需要为了炫技把复杂度拉满。1.2 第一批提示词约束写得越具体AI代码越接近可运行很多人第一次让AI做游戏给的话是帮我写一个微信小游戏然后看着AI输出一大坨华丽但跑不起来的代码干瞪眼。问题出在约束太少。我实际用的第一版提示词是这样的我需要开发一款微信小游戏玩法玩家控制角色在迷宫中移动收集金币躲避敌人。请用微信小游戏原生JavaScript Canvas实现一个MVP版本要求使用 wx.createCanvas() 创建主画布角色、金币、敌人先用简单几何图形绘制不要使用图片素材触摸滑动控制角色移动游戏循环使用 requestAnimationFrame碰到金币加分碰到敌人游戏结束代码尽量保持单文件方便我调试和运行。MVP版本简单几何图形单文件这三个约束是这套提示词里最关键的部分。几何图形意味着你不需要处理素材版权、图片加载和尺寸适配单文件意味着你不用管模块拆分的工程化问题MVP版本则是告诉AI不需要提前把排行榜、音效、关卡这类东西一起塞进来。AI一旦自作主张增加功能代码复杂度会骤增而你还看不懂它写的部分。拿到代码后直接运行不要指望一次通过。我数过从第一版代码到跑通基础循环大概来回修了五六轮每一轮都是把开发者工具的报错原样喂回去。这个过程中最忌讳的一句话是顺便加个排行榜——你一旦让AI在修bug的同时加新功能它大概率会把核心逻辑一起改乱。一次只验证一个闭环这个纪律从第一天就要立住。1.3 MVP边界清单几何图形、单文件、一次只做一件事我给MVP划定的是一个极窄的范围一个房间、一个敌人、十个金币、一个分数显示。听起来简陋得不像游戏但它足以验证整个游戏循环是否成立——角色能否动起来、碰撞有没有效果、分数会不会变、死了之后游戏能不能结束。在跑通这个循环之后我追加了重新开始和暂停两个功能。为什么要加这两个因为用户在真机上玩的时候不能死了一次就只能重启小程序这是最基础的可玩性问题。但排行榜、音效、多关卡、道具系统我全部毫不犹豫地砍掉。砍功能的理由不是偷懒而是削减AI代码的不可控变量——每多一个功能就多几十行你不知道如何调试的逻辑多几个不知道何时触发的边界bug。让MVP阶段代码总量控制在1000行以内是当时给自己定的硬指标。跑通标志我也定义得很明确在微信开发者工具里完整玩一局无报错、触摸跟手、重开能正常重置状态。真机兼容性这个阶段不用管那是后续版本的事。这个跑通标准看起来基础但它决定了你能不能从一个模糊想法迈入下一个阶段——备案。2. MVP之后的第一道坎备案27天到底在等什么2.1 先分清备案和版号别被网上的说法吓退从MVP到上架中间有一道绕不开的坎备案。我第一次搜微信小游戏备案时被各种要版号必须有软著个人开发者做不了的说法唬得够呛。实际执行下来情况比网传的简单一些。微信小游戏上架前需要完成备案这是平台的基础流程要求而游戏版号是针对涉及虚拟支付、内购等商业模式的游戏资质。如果你做的是一款纯休闲、无内购、无付费内容的小游戏通常只需要走备案流程就行。当然这个判断不能只凭记忆最权威的标准在微信公众平台后台的实际提示里你提交后会看到明确的材料要求以那个为准。这里还有个容易被忽略的点备案的主体可以是个人。也就是说个人开发者认证的小游戏账号也能走备案流程并非只有企业才能上架小游戏。我全程用的就是个人主体流程没有因为个人两个字被卡住。2.2 材料提交顺序与时间线27天都花在了哪我的备案从提交到通过一共用了27天这27天拆开看大概是这个节奏时间段做什么花费时间第1-3天注册小游戏账号、填写基础信息、选择服务类目3天第4-7天整理材料主体信息、名称、简介、隐私保护指引、玩法说明4天第8-10天后台提交备案进入平台初审3天第11-24天平台初审通过后进入备案审核等待期14天左右第25-27天审核通过收到通知小游戏状态变为可发布3天这个时间分布里真正需要我们主动做事的就是前7天后面大多数时间是在等审核。具体天数会因提交时间、材料复杂程度有浮动但总体节奏大概都是准备材料小一周、等待审核两三周这个量级。我第一次提交时因为材料整理得比较细初审一次就过了省了不少来回沟通的时间。2.3 真实驳回案例名称不符、隐私指引、截图不清晰备案初审最容易驳回的地方我总结了身边几个案例加上自己的经历主要有三类。第一类是名称或简介与内容不符。我最初给游戏起的名字叫迷宫冒险家听上去没什么问题但审核意见写的是名称、简介与玩法内容关联度不足。说白了他们一眼看去不知道这游戏具体是什么、怎么玩。后来我改成指尖迷宫收集金币的小游戏一句话把平台、玩法、目标全讲清楚一次通过。第二类是隐私保护指引不完整。小游戏只要用了微信的存储能力保存游戏进度就牵扯到用户信息处理。隐私保护指引里必须声明收集了什么信息、用途是什么、有没有第三方共享。AI不会帮你写这个它是纯人肉工作但也不难照着后台模板填清楚就行。第三类是截图材料太敷衍。我第一次提交时截了一张游戏标题页审核反馈无法判断具体玩法。重新提了三张图——主界面、游戏中、游戏结束——再配上玩法文字说明就没再被挑过毛病。这类材料宁可多给细节也千万别图省事。2.4 等待期不是空闲期真机适配、性能日志、素材替换备案等待的那两周很多人选择干等我是建议别这么做。我当时的计划是真机适配测试、性能日志埋点、素材替换三件事并行。真机适配测试尤其重要。微信开发者工具里的渲染效果和真机的差异比你想的大得多。刘海屏怎么避让、低端机型会不会掉帧、触摸灵敏度是否合适这些在开发者工具里几乎感知不到。我在等待期里借了两台不同价位的Android机轮着测发现的第一个问题是游戏在特定机型上首屏白屏时间有点长查了半天是首包加载的问题后来压缩了一个背景图资源才解决。性能日志埋点则是为后续优化做准备。我在游戏循环里加了简单的帧数统计记录每局平均帧率真机上跑几局就大概知道哪些机型需要重点优化。这样备案通过时游戏已经不是开发者工具里的能跑版本而是接近可发布的稳定版本了。3. 六个坑每个都是用真机测试和驳回通知换来的3.1 Unity打包陷阱包体限制与调试链路的双杀如果你还是想走Unity打包微信小游戏的路线先搞清楚三个事实。第一微信小游戏首包有4MB基础限制超出后加载失败或白屏的概率极高Unity项目的导出包体积通常不会太友好。第二首次加载时长决定了你的用户留存包体越大加载越慢用户等不住就流失了。第三Unity项目的调试链路实在太长AI生成的代码一旦出问题在最坏情况下你要同时排查Unity版本冲突、导出配置错误、微信SDK兼容性三件事这对非游戏开发者来说几乎是劝退级的难度。所以我还是那个建议马尔可夫地写MVP阶段项目就用原生Canvas后续如果真要上复杂的3D效果或重型物理模拟再考虑Unity。小体量休闲游戏用原生Canvas完全能撑住而且AI生成的代码可用性最高。3.2 基础库版本陷阱AI写出过时API的典型场景AI生成微信小游戏代码时最爱踩的坑之一就是API版本错位。微信的API是分基础库版本的AI训练数据里新老版本混在一起它就可能给你生成已经废弃的调用方式。我踩得最典型的两个一是wx.getUserInfo和wx.getUserProfile的混淆老API在最新基础库上已经拿不到用户信息了新的API还需要你在代码里明确声明调用目的和触发时机二是wx.login的调用时机问题AI有时会把登录逻辑放在游戏启动第一行但实际场景里应该由用户主动触发时才调用登录否则在审核阶段就会被判定为强制收集用户信息。规避方法其实简单每一次让AI生成涉及微信API的代码在提示词里明确加一句请使用最新基础库的API并在代码中标注所需基础库版本号。然后每次在开发者工具里跑代码时留意控制台有没有弃用API的警告——那个黄字警告往往比红字报错更有价值。3.3 同步存储与全帧重绘小游戏性能的两个隐形杀手AI特别爱用wx.setStorageSync和wx.getStorageSync因为写起来一行就能存数据代码简洁得像作弊。但同步存储有个副作用它会阻塞JS线程存的数据一多调用一频繁游戏就会卡顿。MVP阶段我存一个分数没什么感知后来加上了关卡进度、金币总数、设置项打开游戏时卡顿感就明显出现了。换成了异步接口之后问题才消失。经验是凡是牵扯到数据量稍大的持久化一开始就直接写异步存储别等卡了再改。另一个隐形杀手的渲染性能。AI生成的Canvas代码有一个通病每帧都clearRect清掉整个画布再全部重绘。小场景看不出来但当你加了背景图片、更多敌人、更多金币投影帧率就开始往下掉了。我当时的优化方式是让AI实现脏矩形渲染只重绘状态发生变化的区域效果立竿见影。我给它的提示词很简单请实现脏矩形渲染优化只重绘发生变化的区域并说明优化前后的性能差异。AI给出了方案也标注了哪些部分适合改、哪些部分不建议改这比让它盲目优化一整页代码要可控得多。3.4 分享与排行榜为什么AI的建议不能直接照搬微信对诱导分享的打击非常严格。AI在设计玩法时会天然倾向于生成分享给好友解锁新关卡分享到群才能复活这种代码原因是它的训练数据里大量成熟小游戏都用了类似机制。但你要知道这类设计一旦被判为诱导分享轻则功能被下线重则整个小游戏被限制传播。合规的做法是核心玩法绝不绑定分享分享只作为用户自愿行为且分享后的奖励不能影响核心体验。比如分享后获得一个提示道具是可以接受的不分享就卡在第三关则大概率出问题。这个边界必须由你来把握AI不会替你判断。排行榜同理。AI会直接生成调用wx.setUserCloudStorage、wx.getFriendCloudStorage的云排行代码听起来很厉害但它忽略了最基础的两件事一是云排行榜需要用户明确授权二是不同基础库版本的云存储行为有差异调试成本不低。我强烈建议第一版本先做本地排行榜存本地、按分数排序、展示前十名。等游戏跑出用户量再考虑云排行榜也不迟——毕竟用户数据都没积累起来的时候云端排行只是一张空榜。3.5 边界测试抓幻觉AI不会发现的三种bugAI生成代码最大的隐性成本是幻觉——语法没问题、逻辑看起来也对但隐藏着只有在特定条件下才会暴露的bug。我没有精力逐行审查所有代码所以用了行为验证法每让AI生成一段功能就手动设计三组最坏场景测试。我的固定测试用例是参数为零、快速连点、极端速度。举个例子我让AI实现角色碰到敌人后游戏结束并显示分数验证时发现当分数为0时结束界面不弹出来。追根因发现AI用if(score)做判断而不是if(score 0)——分数为0时这个判断是false游戏死循环一样卡在那一局。这类bug在正常玩法里几乎测不出来只有边界测试能抓到。测出来的bug让AI修的时候我会把测试场景原样贴给它分数为0时游戏结束界面不显示请修复判断逻辑。这样修的效率比泛泛地说有bug高太多。3.6 审核驳回快照白屏、说明缺失、素材风险正式审核阶段的驳回我整理的典型情况有三类。第一类是打开后白屏通常是首包加载问题对应方案就是减包体、压缩资源或做分包加载。第二类是玩法说明缺失审核方需要明确知道你的游戏怎么玩、有什么核心循环所以在版本描述里写清楚玩法核心、操作方式、每局流程能减少一大半审核来回。第三类是素材存在侵权风险——AI生成的图片和音效未必都能直接商用尽量用可商用素材库或干脆几何图形绘制审核风险低得多。还有个小提示提交审核时的版本描述认真写哪怕你没有额外材料要说明也把游戏核心玩法用户信息来源及用途素材来源三行字交代清楚。这份描述不是走形式它直接影响审核速度和我后续修改的定位效率。4. 多AI协作工作流项目说明书、任务拆分与代码审查4.1 项目说明书让每个AI从失忆变成上岗即熟手当AI承担了大部分编码任务后你很快会发现它的最大缺陷是失忆。每次新开对话AI都不知道你的项目背景都要从零理解微信小游戏是什么。我的解法是做一份项目说明书每次开新对话时先粘给它。我的项目说明书长这样项目指尖迷宫微信小游戏 平台微信小游戏原生JavaScript Canvas 当前版本v0.8 已实现角色移动、金币收集、敌人AI、分数计算、本地排行榜、暂停与恢复 代码结构main.js入口与游戏循环、player.js角色、enemy.js敌人、storage.js存储 已知问题真机偶发首屏进度条卡顿待定位 代码风格函数式为主避免class继承注释用中文变量名用英文 重要约束不使用任何外部框架不使用同步存储接口投放功能需标注授权时机这份说明书的本质是AI上下文缓存。它让每一个AI对话都能在几秒内进入工作状态而不是花大量来回去理解背景。如果你同时用多个AI协作这份说明书更是必须——否则不同AI对项目的理解会互相矛盾改代码时甚至可能互相覆盖逻辑。4.2 任务拆细一次只做一件事减少连带破坏我把整个开发拆成十几个小任务每个任务一句话控制规模在现有进度存储中添加反作弊时间戳为暂停界面增加背景遮罩把敌人巡逻路径改为随机移动。每个任务单独开一个AI对话完成后再合并。这个模式背后是AI一个非常典型的毛病为了加一个新功能它经常改动原本好好的代码制造连带破坏。我在加背景音乐时经历过一次AI为了实现音频开关把触摸事件绑定也顺手改了结果角色直接不能移动。从那以后我再也不让它顺便调整任何无关代码每次任务只动该动的部分。任务粒度细AI可控性强审查成本低出bug后回滚也容易——如果你把十几个改动混在一个AI对话里出问题时根本定位不了是哪个改动引发的。4.3 分层审查核心逻辑逐行看边缘逻辑抽样看不要盲信AI说的这版改好了。我的机制是每次AI交付代码必须做三件事跑本地测试在微信开发者工具里过一遍代码检查再手动走查核心逻辑。审查权重也要分主次。分数计算、游戏结束、存储读取这种核心逻辑必须逐行看背景绘制、音效开关、视觉修饰这类边缘逻辑抽几个关键点看看就行。AI生成代码的bug率在简单逻辑上确实很低但在多状态联动上非常高——比如暂停和游戏结束同时发生时状态该谁优先比如存储读写失败时是否有兜底。这些场景AI几乎不会自己暴露只能靠人来盯。我的理解是AI写代码你负责业务。你不需要懂每一行Canvas绘制但你一定要懂游戏的状态流转、数据流向这些业务层面的东西。这些是AI最不擅长也最容易写乱的部分恰恰是你该盯紧的地方。4.4 发布检查清单与AI分工谁写架构、谁写交互、谁查bug多AI协作时我会给不同AI分不同的岗位保持对话历史的单一职责。负责架构的AI专门做迷宫生成、碰撞检测这类核心算法负责交互的AI专门做触摸控制、按钮响应这类UI逻辑还有一个AI专门做代码审查我会让它看边界条件和变量命名它给出的意见往往能补上其他人的盲区。发布前我会让AI帮忙生成一份发布检查清单包体是否在4MB内、真机适配情况、分享按钮在无授权时是否可用、退出重进是否正常、是否有未处理的同步存储调用。清单逐项过完版本才提交审核。整个过程里AI协助的代码占比接近九成但计分、状态机、退出重进这类关键逻辑我全部人肉审查过。要知道AI可以帮你把门槛从需要学一年引擎压缩到需要认真面对逻辑和合规但最后那道门还是得你自己跨过去。我自己踩过几次坑之后的体会是AI做小游戏最强的地方不是生成代码而是把不会的事快速变成能跑的事。但真正决定游戏能不能上架、能不能留下用户的还是你对玩法逻辑的理解、对平台规则的敬畏、对每一条审核意见的认真回应。至于从MVP到正式版的扩展我的建议是先做本地排行榜再攒用户再考虑云排行和商业化——步子大了容易摔在审核这一关。