我至今还记得后台页面跳出备案已通过那五个字时的心情——离首次提交整整27天中间被驳回两次我几乎以为这个游戏要死在黎明前。说几乎是因为它最后活下来了。一个没有任何游戏开发背景的人用AI做了一款微信小游戏从聊天出MVP、完成备案、提审到上线完整链路走了一遍。写这篇实录是想把这段经历摊开给你看非游戏开发者怎么用AI做出MVP、备案27天里到底在等什么、以及那些真正让人失眠的坑长什么样。如果你也有一个想做个小游戏的念头无论你是后端、前端还是完全不会写代码希望这篇东西能帮你少走几个月的弯路。1. 先把账算清楚非游戏开发者离微信小游戏有多远1.1 我是什么背景以及为什么敢碰这件事先交代一下我的底子写了几年后端日常就是Java和Go熟悉HTTP、数据库、缓存这些但从来没写过一行游戏代码。Unity下载过两次打开之后被编辑器界面劝退Cocos听说过没敢碰像素画、音效、关卡设计这些词在我脑子里属于另一个世界。之所以动了要不做个微信小游戏的念头纯粹是因为AI编程工具已经成熟到可以对话生成代码的地步——我有需求拆解能力AI有代码生成能力理论上这个组合能覆盖掉不会游戏开发这个致命短板。当时的判断是微信小游戏的用户场景明确点开即玩、社交裂变强、个人开发者也能注册上线而AI恰好能把最烧钱的内容生产和代码编写两个环节的成本打下来。最坏的结果无非是做个没人玩的小东西成本也就几千块和几个月的业余时间这个风险我愿意赌。1.2 拆开看技术、内容、合规三扇门现在是什么状态决定动手之前我花了两个晚上把微信小游戏上线这件事拆成了三个门槛逐个评估AI到底能帮多少。技术门槛。过去做小游戏要用Unity或Cocos引擎要懂生命周期、碰撞检测、渲染、音频管理这些东西对一个后端来说学习曲线太陡。但现在AI可以把大部分逻辑直接写出来关键是选对游戏类型——凡是涉及复杂物理引擎比如弹球、切水果、合成大西瓜那种带碰撞的AI就容易翻车而棋盘类、答题类、点选合成类这种状态机清晰、交互单一的玩法AI生成代码的可靠性非常高。内容门槛。美术、音效、策划是个人开发者的三座大山。AI能生成像素风格素材、能提供音效选型建议、能在对话里帮你头脑风暴玩法机制。这里有个版权雷区要注意AI生成的图片和音乐如果素材库有版权限制商用是有风险的我的做法是美术全部用自绘像素块和基础几何图形音效从明确标注可免费商用的音效站选规避掉最麻烦的授权问题。合规门槛。这是AI完全帮不上忙的部分也是我之前最陌生的部分——小程序备案、软著、隐私政策、提审材料。但拆开看会发现它其实是一套透明、可查询、有固定流程的行政事务只是耗时长、琐碎、容错率低。真正等到你头上的不是技术而是耐心。我对这个项目的最终判断是技术门槛AI能填内容门槛AI能降合规门槛只能硬着头皮走流程。想明白这件事之后我反而踏实了。1.3 什么样的游戏适合AI辅助做如果你也想用AI做微信小游戏选玩法是第一关。我的建议是把玩法压缩到一句话能说清楚。比如我最后做的是一款9x9棋盘点选合成的游戏点击一个元素选中再点击相邻的同类型元素两者合成升级目标是合成到最高等级。规则就这么简单但可玩性靠数值曲线和收集图鉴撑起来。为什么选这个玩法因为它的核心逻辑可以在一个数组上完成——棋盘状态就是一个9x9的二维数组合成就是数组元素的替换渲染就是把数组画到Canvas上交互就是一个click事件。没有物理计算没有复杂动画没有多角色AI整个游戏的逻辑复杂度对AI来说完全在可控范围内。反过来如果你选了一个需要实时碰撞检测粒子特效多关卡地图的玩法AI生成的代码大概率会在某个边界条件上崩给你看而你根本不知道怎么修。2. 聊天出MVP我和AI协作的完整工作流2.1 一个反直觉的选择不用Unity用原生Canvas先说一个可能让不少人意外的决定我全程没用Unity也没用任何游戏引擎技术栈就是微信小游戏原生JavaScript Canvas 2D。很多人会问为什么不用Unity——毕竟网上Unity微信小游戏打包的教程一抓一大把。我对比过Unity打包到微信小游戏需要装WebGL转小程序环境的插件构建链长报错信息对新手极不友好而原生Canvas方案的学习路径非常短——微信小游戏本质上就是一个Canvas画布我只需要告诉AI没有DOM、用wx API、所有绘制都在canvas上进行它就能理解因为这种代码在AI的训练语料里到处都是反而是Unity工程的转译过程AI并不擅长。这个选择有一个附加好处代码包体积小。原生JS代码的包体可以控制在几百KB到1MB左右完全不用为分包发愁而Unity打包出来的包动辄十几MB起步光过包体限制就要费一番功夫。2.2 项目宪法每次对话前必发的提示词模板用AI做开发最怕的是对话上下文漂移——聊到第20轮AI已经忘了最开始定的约束开始给你生成浏览器页面的代码。我的解法是维护一份项目说明文档我管它叫项目宪法每次新开对话的第一条消息就整段粘贴给它。我当时用的提示词模板大致长这样你是微信小游戏开发专家。请严格遵循以下项目约束 1. 技术栈微信小游戏原生JavaScript Canvas 2D禁用DOM操作没有document、没有window禁用任何框架API必须使用wx.*系列。 2. 游戏玩法9x9棋盘格点击元素选中点击相邻同类型元素触发合成升级合成获得分数合成到最高等级判定过关。棋盘状态用一维数组表示索引0-80。 3. 界面结构游戏主界面棋盘分数步数、图鉴界面查看已合成过的元素、结算界面过关/失败。 4. 适配要求兼容iPhone和主流Android机型触摸坐标换算必须考虑pixelRatio和窗口尺寸。 5. 代码风格每个文件顶部用注释写明职责关键函数必须写注释不要生成任何未被要求的功能。 本轮任务请生成棋盘初始化模块包括数组初始化、元素类型概率表、最高等级常量定义。这个模板的关键不是把需求说清楚而是把边界划清楚。AI就像外包程序员你只说帮我做个游戏它会给你一坨华丽但跑不起来的代码你把验收标准和禁区写清楚它反而能给你一份可维护的东西。2.3 分模块推进我如何把一整个游戏拆成AI能hold住的片段一口气让AI生成完整游戏是我踩过的第一个坑。当时我确实试过让AI直接写一个完整的游戏文件它回给我一份800行的代码看着逻辑齐全跑起来各种报错引用了一个还没定义的函数、变量作用域混乱、数组越界……根本没法用。后来我调整了策略把整个游戏拆成五个模块每次只和AI聊一个模块棋盘初始化与状态管理数组创建、元素类型概率、等级常量渲染模块把棋盘状态画到Canvas上处理不同元素类型的颜色和文字标识触摸交互模块点击坐标到棋盘索引的换算、选中态高亮、相邻性判断合成逻辑模块合成条件、升级规则、得分计算、过关判定UI与图鉴模块分数显示、步数显示、图鉴收集进度、界面切换逻辑。每个模块大约花一个晚上。我的节奏是晚上8点给它一个模块的需求让它输出完整代码我把它贴进微信开发者工具跑一遍有报错就把报错堆栈整段粘贴回去附带相关代码片段让它改改通之后允许它进入下一个模块。到第四天晚上五个模块全部跑通MVP诞生。这个小步快跑的策略还有一个额外好处因为每个模块都是独立的AI不会把上个模块的代码改坏。它改触摸交互的那一轮不会动棋盘初始化的逻辑——我要的就是这种隔离性。2.4 报错闭环与自查清单让AI当自己的QA很多人在AI编程时卡在报错处理上其实有个技巧报错信息一定要整段贴回去不要自己转述。它报了个错和它报了这个错对AI来说是完全不同的信息密度。我一般是这样处理的下面是我的代码文件game.js和微信开发者工具报的完整错误栈 [贴代码] [贴报错栈] 请分析根因给出最小改动方案不要重写整个文件。注意最后那句不要重写整个文件很关键因为AI遇到问题倾向于丢给你一个全新改进版但新版会引入你没看过的新逻辑风险反而更高。让它做最小改动改动范围可控review成本也低。所有功能模块跑通之后我还会让AI做一轮自查现在请扮演QA工程师检查当前游戏代码重点排查 1. 棋盘数组是否存在越界写入 2. 触摸坐标在iPhone刘海屏和安卓全面屏下是否都会偏移 3. 左下角步数归零后游戏能否正常进入失败结算 4. Canvas绘制是否存在每帧全量重绘导致的性能问题 5. 合成到最高等级后元素表是否还有溢出逻辑。 请逐项给出结论和修改建议。这一步相当于让AI替我做了一轮代码审查。它列出来的问题我再挑着修比自己啃代码快得多。整个MVP阶段下来AI写了大约3000行代码而我做的事情是把需求拆碎、把边界说清、把报错喂回去——这本质上就是一个人扮演项目经理和测试AI扮演开发者的极简协作闭环。3. 备案27天复盘等待之外真正该做对的几件事3.1 先搞清楚我要备案的到底是什么这里必须先说一个容易混淆的概念微信小游戏的备案指的是小程序备案ICP备案解决的是这个主体是谁、在做什么内容的问题。它和游戏版号是两套体系——后者涉及出版审批尤其是有内购功能的游戏流程要长得多。我的游戏没有做任何虚拟支付所以不需要碰版号那条线只需要完成小程序备案。想通了这一点心态就稳了备案是一个确定性流程材料齐全、类目正确、内容合规剩下的就是等待。3.2 材料准备阶段花费的时间比想象中多我的27天不是从提交开始算的而是从开始准备材料就开始计时了。真正跑起来之后发现最耗时的不是提交而是材料准备——因为很多东西不能临时现做。首先是小程序账号的主体认证。我的主体用的是个体户执照在微信公众平台注册并完成认证这一步大约1个工作日。然后是小程序名称预查游戏名字不能和已有小程序重名、不能含有敏感词、不能带夸张宣传语。我当时准备了3个候选名第一个就有问题换到第二个才过预查。接着说软著。我提前大概两周递交了软件著作权申请选择的是电子版权证书通道比纸质证书快不少。虽然备案环节不强制查验软著但提审时审核方可能要求提供早办早安心。然后是游戏截图。这里有个细节后来坑到了我见下一节。总之材料准备阶段我花了3天其中一半时间耗在软著和名称上。3.3 两次驳回教会我的规则首次提交后第6天等来了第一次驳回。驳回理由是游戏类目选择与提交内容不符——我在后台选的类目是游戏-休闲游戏但提交的服务内容描述里写着棋牌玩法审核方认为棋牌类目需要额外资质文件。这个驳回其实合理微信小游戏后台对休闲游戏和棋牌游戏的审查尺度不一样棋牌涉及概率、博弈等敏感点审核更严。我本来做的只是合成玩法不是真棋牌问题出在我的服务内容描述用词不当。修改方式是把描述里的棋牌相关表述全部去掉改成基于棋盘的休闲合成玩法重新提交。第二次驳回是在第25天要求补充用户隐私保护指引。我之前以为游戏不收集任何个人信息就不用填了实际上需要在小程序后台的隐私保护设置中明确声明未收集用户个人信息并补充一份隐私保护指引说明。这个不算难题但前后又走了两天流程。到第27天备案通过。3.4 等待期的正确打开方式从第11天到第24天几乎是纯粹的等待期——系统状态一直停在等待管局审核你能做的非常有限。这段时间很容易焦虑我的做法是把它当成游戏打磨期把提审截图全部换成真机截图、优化了一轮低端机卡顿、把音效素材全部替换成统一风格的免费授权素材。等备案通过的时候游戏本身也已经比MVP阶段完整了一个档次。所以我的核心建议是尽早提交备案别等游戏做完了再走流程。备案需要的时间是刚性的而开发打磨是可以灵活压缩的。让两者并行整体时间反而最短。4. 从跑通到过审踩过的坑没有一个在文档里写清楚4.1 技术坑真机与开发者工具的温差第一版AI生成代码在微信开发者工具里跑得很欢一到真机预览就黑屏。排查了半天发现是AI默认用了一个浏览器里的Canvas初始化方式而小游戏环境必须用wx.createCanvas()。这算是我项目宪法没写到位的后果——AI太习惯生成浏览器代码了即便你说了没有DOM它还是会在细节处滑向Web习惯。第二个类似的问题是真机触摸坐标偏移。在开发者工具里点击坐标是正常的真机上点的位置永远偏了那么一点。根因是Canvas在做高清适配时设置了canvas.width screenWidth * pixelRatio但触摸事件的clientX还是按逻辑像素算的没有乘以pixelRatio换算回去。AI第一次给的代码完全没处理这个我在微信开放社区的帖子堆里翻了半天才定位到。修这个问题时的核心代码长这样// 触摸坐标换算逻辑像素 - Canvas物理像素 const info wx.getSystemInfoSync(); const pixelRatio info.pixelRatio; const stageWidth info.windowWidth; const scale canvas.width / stageWidth; // 等于pixelRatio canvas.addEventListener(touchstart, (e) { const touch e.touches[0]; const canvasX touch.clientX * scale; const canvasY touch.clientY * scale; // 再用canvasX/canvasY换算棋盘索引 });这类开发者工具正常、真机异常的问题是AI编程的典型盲区——AI没有真机它只能根据文档推断。所以我的工作流里加了一条铁律每完成一个功能模块立刻真机预览一次不要等全部做完了再上真机否则bug堆在一起根本没法定位。4.2 合规坑审核员的视角和我的视角不一样提审被驳回的第一次理由是提交的游戏截图与游戏实际内容不符。问题出在我之前偷懒用了AI生成的UI示意图当截图因为那几张图视觉效果比真机截图好看。审核员点开试玩一看界面完全不是那张图直接驳回。这事给我的教训是提交审核的材料里所有展示给审核员看的东西必须来自真机截图或模拟器截图不要用任何设计效果图。审核员对图实不符的容忍度为零。第二个合规坑是隐私保护前面提到过一次这里展开说。微信小游戏的提审流程里会要求开发者确认用户隐私保护指引。AI生成代码的时候用的是Canvas绘制不读取相册、不获取位置、不收集任何用户信息但后台仍然要求明确声明本小程序不收集用户个人信息。我当时漏掉了这一项直接被拦在提审入口。补上声明之后审核流程才继续走。第三个坑是游戏内文案。我游戏里有个最强合成的按钮文案提审之后被提示使用了极限类用语。后来我把这个文案改成了终极合成一次通过。国内应用审核对这类词普遍敏感写游戏文案的时候尽量用中性词别自找麻烦。4.3 工具链坑AI对话会失忆Git替我把关AI编程有一个少有人提的隐患对话上下文是有限的AI会忘记它自己上上轮做过的约定。比如它第四轮修改渲染模块时可能会顺手换了元素类型的配色方案结果图鉴模块还在用旧配色两边就对不上了。我的应对办法有两个。第一每次让AI改代码前追问一句你打算改哪些文件、哪些函数让它先列修改计划我再审查计划是否限定在当前模块确认后才让它动手。第二所有AI改动的代码先过Git diff再提交——我会逐个文件对比改动内容看到顺手改动的无关逻辑就revert掉。这可能是我在整个项目里最笨但最有效的动作。AI确实能帮你写代码但它没有风险判断能力Git diff就是我给AI加的一道人工审核闸门。4.4 性能与包体一个很容易被AI带偏的细节AI生成代码有个毛病倾向于把功能实现得完整且豪华于是塞进去很多你根本没要求的工具函数和初始化逻辑。我的主包一度到了3.5MB逼近微信小游戏4MB的主包限制。排查发现AI在前几轮对话里生成了一整套通用工具类包含事件总线、图片缓存池、日志系统——这些对一个小游戏来说是纯负担。解决方案是把用得上的工具函数挑出来剩下全部删掉接着把音乐、音效和部分图鉴图片拆到分包里。分包后主包降到700KB加载速度明显提升。另外AI默认会让每一帧全量重绘canvas低端安卓机上掉帧严重。我让AI改成脏矩形重绘只更新发生变化的棋盘格区域帧率从20帧左右升到了50帧以上。这些细节AI不会替你想——它只会给你一个功能完整的代码而运行流畅需要你作为开发者去提要求。所以做微信小游戏哪怕不写代码至少也要懂包体、主包、分包、帧率这几个词的意思否则连给AI下指令都说不清楚。5. 如果要重来我会把这些事放在最前面5.1 给新手的第一选择标准玩法能不能一句话说清走过完整一遭之后如果让我给也想试水的人一个最优先的建议那就是选玩法时问自己一句这个玩法最复杂的逻辑是什么如果一句话说不清就换一个。我说的是逻辑复杂度不是创意复杂度。创意的部分可以百花齐放但逻辑复杂度直接决定AI能不能帮你把代码写对。比如点选合成加图鉴是一句话能说清的逻辑数组、点击、比对、合并、画格子。而物理弹射加真实碰撞就说不清它涉及帧率、加速度、碰撞检测、粒子系统AI生成代码的失败率指数级上升。我见过太多人用AI做微信小游戏翻车九成死在第一步选型上后面根本不是技术问题。5.2 最后分享一点关于AI协作心态的事整个项目做下来我最深的体会是AI不是帮你做游戏的魔法师而是一个需要带的新人程序员。你的项目管理能力、需求拆解能力、review能力决定了AI发挥的上限。我自己写了十几年代码到这个项目才真正体会到把需求说清楚比把代码写出来难得多也重要得多。另外心态上做好大概率会失败的准备反而更容易做下去。我把这个项目当成一次试验成本几千块、时间是周末和晚上最坏的结果是游戏没人玩。但哪怕没人玩我也把微信小游戏的整套链路——开发、备案、提审、上线的每一个环节都跑通了这个经验本身就值回票价。如果你决定做我还有个很实在的建议注册完账号、确认好主体认证之后立刻去了解备案材料清单当天就启动流程然后再慢慢打磨游戏。备案那27天不会因为你焦虑就变快但会把你的游戏打磨时间拉长到足够从容。这大概就是个人开发者与AI协作做游戏的常态——AI负责从0到1而我们负责从1到上线中间那段路就留给坑吧。