1. 一个非游戏开发者为什么敢碰微信小游戏先说背景。我做了七八年后端和工具类产品游戏开发经验基本为零。Unity 没打开过几次Cocos 只停留在“听说过”的阶段美术资源更是完全不会画。按传统路径一个不会游戏引擎、不懂渲染管线、没有美术资源的人去做微信小游戏基本等于劝退。但我还是做出来了而且上线了。整个过程从想法到拿到备案号、跑通审核、正式发布前后大概两个月其中备案单独占了 27 天。这篇文章就是把这段实录完整摊开怎么用 AI 把一个模糊的想法聊成 MVP微信开发者工具里到底怎么落地备案为什么卡了 27 天以及我踩过的那些坑。如果你也是非游戏背景想用 AI 辅助做一款能上线的小游戏这篇内容应该能帮你省掉至少一半的试错时间。核心关键词就几个微信小游戏、AI、MVP、微信开发者工具、备案。我会围绕这几个点把每一步的真实操作和判断逻辑讲清楚。需要提前说明的是我不是要教你“三天做出爆款游戏”那是不现实的。我要讲的是一个普通开发者借助 AI 把“不可能”变成“能上线”的完整过程。这里面有技术选型的取舍有备案流程的坑也有 AI 协作时那些只有真正用过才知道的细节。2. 用 AI 把想法聊成 MVP 的完整思路2.1 为什么选择“聊天出 MVP”而不是直接写代码很多人一上来就让 AI 写代码结果发现 AI 给的东西跑不起来或者跟微信小游戏的运行环境对不上。我一开始也犯过这个错。后来我调整了策略先让 AI 帮我把需求聊清楚再让它输出可执行的技术方案最后才写代码。这个顺序很重要。因为微信小游戏有一套自己的运行环境它基于 JavaScript但又不是完整的浏览器环境没有 DOM没有 BOM很多在网页上能跑的库直接拿过来是用不了的。如果一上来就让 AI 写一个“贪吃蛇”它很可能给你一个基于 Canvas API 的网页版本你放到微信开发者工具里会发现各种报错。所以我用的方法是把 AI 当成一个“技术合伙人”先跟它对齐约束条件。我会这样问我要做一个微信小游戏玩法是 XXX目标用户是 XXX我只有前端基础不会游戏引擎。请帮我分析这个玩法在微信小游戏环境下用原生 Canvas 实现是否可行如果可行核心的技术难点有哪些如果不可行最小的可行替代方案是什么这样问的好处是AI 会先帮你做可行性判断而不是直接给你一堆代码。我实测下来这种“先聊清楚再动手”的方式至少能减少 60% 的返工。2.2 MVP 的功能边界怎么定非游戏开发者最容易犯的错就是把 MVP 定得太大。我一开始想做一个带关卡、带道具、带排行榜的完整游戏AI 也很配合地给我列了一堆功能模块。但我冷静下来算了一下光是排行榜就要涉及后端存储、用户鉴权、数据同步这些对我来说都是额外成本。后来我把 MVP 砍到只剩三个核心功能核心玩法循环玩家能完成一次完整的操作得到反馈再进入下一次操作。分数记录本地存储最高分不涉及后端。重新开始一局结束后能立刻再来一局。就这三个。其他全部砍掉。这个判断的依据是MVP 的唯一目标是验证“玩法是否成立”而不是“功能是否完整”。如果核心玩法不好玩加再多功能也没用如果核心玩法好玩后面再迭代也来得及。我把这个思路跟 AI 对齐之后它给出的技术方案就清晰多了用原生 Canvas 做渲染用wx.setStorageSync做本地存储用requestAnimationFrame做游戏循环。整个项目不需要任何第三方游戏引擎也不需要后端。2.3 AI 协作时的提示词怎么写才有效这里分享几个我实测有效的提示词写法。不是那种“万能提示词模板”而是针对微信小游戏这个具体场景的。第一个约束前置。不要先描述需求再补约束而是把约束放在最前面。比如运行环境微信小游戏基于 JavaScript无 DOM无 BOM可使用 wx.* API。我的技术背景会 JavaScript不会游戏引擎。需求实现一个 XXX 玩法。请给出最小实现方案代码要能直接在微信开发者工具里运行。第二个要求 AI 解释“为什么”。我经常会在提示词最后加一句“请解释你选择这个方案的原因以及有没有更简单的替代方案。” 这样我能判断 AI 给的方案是不是过度设计。第三个分步验证。不要让 AI 一次性输出整个游戏的代码。我会让它先输出“游戏循环”的部分我跑通了再让它输出“碰撞检测”的部分。每一步都验证避免最后拿到一堆跑不起来的代码。2.4 从聊天记录到可运行代码的转化AI 聊出来的方案最终要变成微信开发者工具里能跑的项目。这个过程我总结了一个固定的转化流程让 AI 输出项目结构包括game.js、game.json、project.config.json这几个核心文件的内容。在微信开发者工具里新建小游戏项目选择“小游戏”类型填入自己的 AppID。把 AI 生成的代码按文件粘贴进去注意game.json的配置项要跟微信官方文档对齐AI 有时候会给出过时的配置。在模拟器里跑一遍看有没有报错有报错就把错误信息复制给 AI让它给修复方案。真机预览用微信扫码在手机上跑一遍看触摸事件、性能表现是否正常。这个流程我跑了大概十几轮每一轮都是“AI 给代码 → 我跑 → 报错 → 反馈给 AI → 修复”。听起来很笨但对于非游戏开发者来说这是最稳的路径。3. 微信开发者工具里的实操细节3.1 项目初始化的关键配置微信开发者工具入口打开之后新建项目时有两个选择小程序和小游戏。这里千万别选错小游戏的项目结构跟小程序完全不一样。小游戏没有 WXML 和 WXSS入口文件是game.js配置文件是game.json。game.json里几个关键配置我列一下{ deviceOrientation: portrait, showStatusBar: false, networkTimeout: { request: 5000 } }deviceOrientation决定横屏还是竖屏我做的是竖屏游戏所以设成portrait。showStatusBar设成false可以让游戏画面全屏体验更好。networkTimeout我设了 5 秒虽然 MVP 阶段没用到网络请求但留着后面迭代用。project.config.json里最重要的是appid和projectname。appid必须是你自己注册的小游戏 AppID不能用测试号因为后面备案和审核都要用到正式 AppID。3.2 Canvas 渲染的核心逻辑微信小游戏的 Canvas 跟网页上的 Canvas 用法基本一致但获取方式不同。网页上是用document.getElementById获取小游戏里是用wx.createCanvas()。const canvas wx.createCanvas(); const ctx canvas.getContext(2d);拿到ctx之后就可以用标准的 Canvas API 做绘制了。我做的游戏核心渲染逻辑大概是这样的function gameLoop() { ctx.clearRect(0, 0, canvas.width, canvas.height); updateGameState(); drawGameScene(ctx); requestAnimationFrame(gameLoop); } gameLoop();这里有个坑要注意requestAnimationFrame在微信小游戏里是全局可用的不需要wx.前缀。但它的执行频率跟设备刷新率有关不同手机可能不一样。所以游戏逻辑里的时间计算不能用“每帧固定时间”的假设而要用实际的时间差。我是这样处理的let lastTime Date.now(); function gameLoop() { const now Date.now(); const deltaTime now - lastTime; lastTime now; updateGameState(deltaTime); // ... }这样不管设备刷新率是多少游戏逻辑的速度都是一致的。3.3 触摸事件的处理方式微信小游戏的触摸事件是通过wx.onTouchStart、wx.onTouchMove、wx.onTouchEnd来监听的。跟网页上的addEventListener不一样这里没有 DOM 元素的概念整个屏幕就是一个触摸区域。wx.onTouchStart((e) { const touch e.touches[0]; const x touch.clientX; const y touch.clientY; handleTouch(x, y); });clientX和clientY是相对于屏幕左上角的坐标。这里要注意不同设备的屏幕尺寸不一样所以游戏元素的坐标不能写死要根据canvas.width和canvas.height做比例计算。我踩过一个坑在模拟器里坐标是对的真机上偏了。后来发现是因为模拟器的屏幕比例跟真机不一样。解决办法是用相对坐标比如canvas.width * 0.5表示屏幕水平中心而不是写死200。3.4 本地存储与分数记录MVP 阶段不需要后端最高分直接用wx.setStorageSync存在本地// 读取最高分 let highScore wx.getStorageSync(highScore) || 0; // 更新最高分 if (currentScore highScore) { highScore currentScore; wx.setStorageSync(highScore, highScore); }这个 API 是同步的用起来很简单。但要注意存储的数据类型只能是字符串、数字、布尔值、对象和数组。我一开始想存一个自定义的类实例结果读出来变成了普通对象方法全丢了。后来改成只存数字就没问题了。3.5 真机调试与性能观察微信开发者工具自带的真机调试功能很好用。点击“真机调试”用手机扫码就能在手机上跑同时在电脑上看到 console 输出和性能面板。性能面板里我主要看两个指标帧率和内存占用。帧率低于 30 就要注意了可能是渲染逻辑太重。内存持续增长不回落可能有内存泄漏通常是事件监听没解绑或者定时器没清除。我遇到过一次帧率骤降排查后发现是每帧都在创建新的对象导致垃圾回收频繁触发。解决办法是把不变的对象提到循环外面创建循环里只更新属性值。这个优化做完帧率从 25 左右稳定到了 55 以上。4. 备案 27 天的完整流程与踩坑记录4.1 备案为什么需要提前启动很多人以为游戏做完了才需要备案其实不是。微信小游戏的备案是在“开发完成、准备提审”之前就要做的而且备案通过之前游戏是不能正式发布的。我一开始不知道这个流程等游戏开发完了才去备案结果硬生生等了 27 天。如果一开始就把备案和开发并行推进这 27 天完全可以省下来。所以第一条经验就是项目立项之后第一件事就是去备案不要等开发完。备案需要填的信息包括游戏名称、游戏类型、玩法简介、技术方案等这些在立项阶段就能确定不需要等代码写完。4.2 备案材料的准备清单备案需要提交的材料我整理了一个清单材料名称说明注意事项游戏名称正式上线名称不能与已有游戏重名建议准备 2-3 个备选游戏类型休闲、益智等选择最贴近的分类不要选太宽泛的玩法简介200 字以内说清楚核心玩法不要写技术实现技术方案简要说明说明使用微信小游戏原生框架无第三方引擎主体信息个人或企业个人主体有部分类目限制企业主体更灵活承诺书官方模板按模板填写不要自己发挥这里有个坑游戏名称一旦提交修改很麻烦。我第一个名字因为跟已有游戏太像被驳回了重新提交又等了好几天。所以名字一定要提前查重微信小游戏有官方的名称查询入口提交前先查一遍。4.3 备案审核的各个阶段备案提交之后会经历几个阶段平台初审一般 1-3 个工作日主要看材料是否齐全、格式是否正确。补充材料如果材料有问题会通知你补充这个来回可能耗掉 3-5 天。深度审核这个阶段最耗时我这次花了将近两周。审核人员会实际体验游戏判断玩法是否合规、内容是否健康。备案通过通过之后会拿到备案号这个号要填到小游戏的配置里。我这次 27 天里初审花了 2 天补充材料来回花了 4 天深度审核花了 18 天最后 3 天是备案号下发和配置。所以真正卡时间的是深度审核这个阶段没有捷径只能等。4.4 备案期间可以并行做的事虽然备案要等但开发工作不能停。我在备案期间做了这几件事继续打磨核心玩法备案不影响开发我利用这段时间把游戏手感调了好几轮。准备审核素材小游戏提审需要提供游戏截图、玩法说明、测试账号等这些可以提前准备。测试不同机型借了几台不同型号的手机测试触摸响应和帧率表现。写用户反馈收集方案提前想好上线后怎么收集反馈比如在游戏里加一个“反馈”按钮。这样等备案通过的时候我这边所有准备工作都做完了直接提审没有浪费任何时间。4.5 备案被驳回的常见原因我这次被驳回过一次原因是“玩法简介描述不清”。后来我重新写了一遍把核心操作、反馈机制、结束条件都写清楚了就通过了。根据我的经验和跟其他开发者的交流常见的驳回原因还有名称违规包含敏感词或与已有游戏重名。玩法涉及随机抽取如果有抽奖、开箱等机制需要额外说明概率。内容不符合公序良俗这个不用多说大家都懂。技术方案描述不清比如没说清楚用的是什么框架审核人员无法判断技术合规性。避免这些问题的办法很简单提交前把材料给一个不了解这个项目的人看一遍如果他能看懂玩法是什么基本就没问题。5. 常见问题与排查技巧实录5.1 微信开发者工具里的典型报错我在开发过程中遇到最多的报错是这几类第一类wx is not defined。这个通常是因为代码在非小游戏环境下运行了。比如你把小游戏代码直接放到浏览器里跑就会报这个错。解决办法是确保代码只在微信开发者工具或真机上运行。第二类canvas is null。这个是因为wx.createCanvas()调用时机不对。必须在game.js的入口处调用不能放在异步回调里。我一开始把它放在setTimeout里结果拿不到 canvas。第三类requestAnimationFrame is not a function。这个在旧版本的微信开发者工具里会出现。解决办法是升级到最新版本或者用setTimeout做降级处理。5.2 真机上触摸不灵敏的排查真机上触摸不灵敏通常有三个原因触摸区域太小游戏元素的点击区域要足够大建议不小于 44x44 像素。触摸事件被覆盖如果有多个触摸监听后面的会覆盖前面的。确保只注册一次。帧率太低导致响应延迟如果帧率低于 20触摸响应会明显变慢。优化渲染逻辑把帧率提上去。我遇到过一次触摸不灵敏排查后发现是每帧都在重新注册触摸事件导致事件队列堆积。改成只注册一次之后问题就解决了。5.3 AI 生成代码的常见问题AI 生成的代码直接拿来用通常会遇到这些问题问题类型表现解决办法API 过时用了废弃的 API对照微信官方文档替换成新 API环境不匹配用了浏览器 API替换成微信小游戏对应的 API逻辑不完整缺少边界处理让 AI 补充异常处理逻辑性能问题每帧创建新对象把不变的对象提到循环外配置错误game.json 格式不对对照官方文档逐项检查我的经验是AI 生成的代码永远不要直接上线一定要自己跑一遍把报错信息反馈给 AI让它修复。通常来回两三轮代码就能稳定运行了。5.4 提审被拒的应对策略提审被拒是常态不要慌。微信小游戏的审核反馈会说明拒绝原因你按照原因修改后重新提交就行。我总结了几条应对策略不要改无关的地方只改审核指出的问题改多了可能引入新问题。保留修改记录每次修改都记下来方便对比和回溯。提前准备申诉材料如果认为审核有误可以申诉但要有理有据。留足审核时间提审到通过一般需要 1-7 天不要卡着上线日期提审。5.5 上线后的数据观察与迭代游戏上线之后我主要看几个数据次日留存如果低于 20%说明玩法吸引力不够。平均游戏时长如果低于 1 分钟说明核心循环太短或太无聊。分享率如果没人分享说明缺少分享动机。根据这些数据我做了几轮迭代增加了难度递增机制让游戏时长从 40 秒提升到了 2 分钟左右加了一个“分享给好友挑战”的按钮分享率提升了 3 倍。6. 非游戏开发者做小游戏的经验总结6.1 技术选型上的取舍逻辑回顾整个项目我在技术选型上做了几个关键取舍不用游戏引擎。Unity 和 Cocos 虽然功能强大但学习成本高打包到微信小游戏还需要额外的适配工作。对于 MVP 阶段来说原生 Canvas 足够用了。不用后端。MVP 阶段所有数据都存在本地不需要服务器。这样省掉了服务器成本、接口开发、数据同步等一系列问题。等用户量上来了再考虑加后端。不用复杂的状态管理。游戏状态就用一个普通对象存着每帧更新。不需要 Redux 或 MobX 那套东西。这些取舍的核心逻辑是MVP 阶段只做必要的事把复杂度降到最低。每增加一个技术栈就多一份学习成本和维护成本。对于非游戏开发者来说少即是多。6.2 AI 协作的边界在哪里AI 在这个项目里帮了我很多但它不是万能的。我总结了一下 AI 能做什么、不能做什么AI 擅长的生成基础代码框架解释技术概念提供多种实现方案排查报错原因优化代码结构AI 不擅长的判断玩法是否好玩做产品决策处理微信小游戏特有的环境问题保证代码在真机上的表现替代官方文档所以我的用法是AI 负责“怎么写”我负责“写什么”和“能不能跑”。产品判断、环境验证、真机测试这些必须自己来。6.3 时间分配的真实记录我记录了一下整个项目的时间分配阶段耗时占比需求梳理与 MVP 定义3 天5%AI 协作开发10 天17%真机调试与优化7 天12%备案等待27 天45%提审与修改5 天8%上线后迭代8 天13%可以看到备案占了将近一半的时间。如果备案和开发并行总周期可以从两个月压缩到一个月左右。这是我最想告诉后来者的一条经验。6.4 给非游戏开发者的实操建议如果你也是非游戏背景想用 AI 做微信小游戏我的建议是第一先做最小可玩原型。不要一上来就想完整游戏先做一个能玩 30 秒的版本验证玩法是否成立。第二备案和开发并行。立项就去备案不要等开发完。备案期间继续开发两不耽误。第三AI 生成的代码必须自己跑。不要相信 AI 说的“这段代码可以直接运行”一定要在微信开发者工具里跑一遍报错了就反馈给 AI 修复。第四真机测试不能省。模拟器上跑得再好真机上也可能出问题。触摸、帧率、内存这些都要在真机上验证。第五留足审核时间。提审到通过一般需要几天备案需要几周这些时间都要提前算进去。6.5 后续可以扩展的方向游戏上线之后我还在继续迭代。后面打算做的方向包括加后端排行榜用微信云开发做排行榜不需要自己搭服务器。加社交分享让玩家可以分享成绩给好友增加传播。加关卡系统从无限模式扩展到关卡模式增加内容量。加音效和动画提升游戏的反馈感和沉浸感。这些都不着急一步一步来。MVP 已经验证了核心玩法是成立的后面的迭代就是锦上添花。最后分享一个我在这个项目里体会最深的心得非游戏开发者做游戏最大的障碍不是技术而是心态。你总会觉得自己“不够格”觉得“不会引擎就做不了游戏”。但实际上微信小游戏的门槛比想象中低很多AI 又能帮你补上大部分技术短板。真正重要的是你有没有一个想做的玩法以及你愿不愿意花时间去把它磨出来。技术问题都能解决心态问题只能自己过。 非游戏开发者如何用AI两个月上线微信小游戏：MVP开发与备案全记录
1. 一个非游戏开发者为什么敢碰微信小游戏先说背景。我做了七八年后端和工具类产品游戏开发经验基本为零。Unity 没打开过几次Cocos 只停留在“听说过”的阶段美术资源更是完全不会画。按传统路径一个不会游戏引擎、不懂渲染管线、没有美术资源的人去做微信小游戏基本等于劝退。但我还是做出来了而且上线了。整个过程从想法到拿到备案号、跑通审核、正式发布前后大概两个月其中备案单独占了 27 天。这篇文章就是把这段实录完整摊开怎么用 AI 把一个模糊的想法聊成 MVP微信开发者工具里到底怎么落地备案为什么卡了 27 天以及我踩过的那些坑。如果你也是非游戏背景想用 AI 辅助做一款能上线的小游戏这篇内容应该能帮你省掉至少一半的试错时间。核心关键词就几个微信小游戏、AI、MVP、微信开发者工具、备案。我会围绕这几个点把每一步的真实操作和判断逻辑讲清楚。需要提前说明的是我不是要教你“三天做出爆款游戏”那是不现实的。我要讲的是一个普通开发者借助 AI 把“不可能”变成“能上线”的完整过程。这里面有技术选型的取舍有备案流程的坑也有 AI 协作时那些只有真正用过才知道的细节。2. 用 AI 把想法聊成 MVP 的完整思路2.1 为什么选择“聊天出 MVP”而不是直接写代码很多人一上来就让 AI 写代码结果发现 AI 给的东西跑不起来或者跟微信小游戏的运行环境对不上。我一开始也犯过这个错。后来我调整了策略先让 AI 帮我把需求聊清楚再让它输出可执行的技术方案最后才写代码。这个顺序很重要。因为微信小游戏有一套自己的运行环境它基于 JavaScript但又不是完整的浏览器环境没有 DOM没有 BOM很多在网页上能跑的库直接拿过来是用不了的。如果一上来就让 AI 写一个“贪吃蛇”它很可能给你一个基于 Canvas API 的网页版本你放到微信开发者工具里会发现各种报错。所以我用的方法是把 AI 当成一个“技术合伙人”先跟它对齐约束条件。我会这样问我要做一个微信小游戏玩法是 XXX目标用户是 XXX我只有前端基础不会游戏引擎。请帮我分析这个玩法在微信小游戏环境下用原生 Canvas 实现是否可行如果可行核心的技术难点有哪些如果不可行最小的可行替代方案是什么这样问的好处是AI 会先帮你做可行性判断而不是直接给你一堆代码。我实测下来这种“先聊清楚再动手”的方式至少能减少 60% 的返工。2.2 MVP 的功能边界怎么定非游戏开发者最容易犯的错就是把 MVP 定得太大。我一开始想做一个带关卡、带道具、带排行榜的完整游戏AI 也很配合地给我列了一堆功能模块。但我冷静下来算了一下光是排行榜就要涉及后端存储、用户鉴权、数据同步这些对我来说都是额外成本。后来我把 MVP 砍到只剩三个核心功能核心玩法循环玩家能完成一次完整的操作得到反馈再进入下一次操作。分数记录本地存储最高分不涉及后端。重新开始一局结束后能立刻再来一局。就这三个。其他全部砍掉。这个判断的依据是MVP 的唯一目标是验证“玩法是否成立”而不是“功能是否完整”。如果核心玩法不好玩加再多功能也没用如果核心玩法好玩后面再迭代也来得及。我把这个思路跟 AI 对齐之后它给出的技术方案就清晰多了用原生 Canvas 做渲染用wx.setStorageSync做本地存储用requestAnimationFrame做游戏循环。整个项目不需要任何第三方游戏引擎也不需要后端。2.3 AI 协作时的提示词怎么写才有效这里分享几个我实测有效的提示词写法。不是那种“万能提示词模板”而是针对微信小游戏这个具体场景的。第一个约束前置。不要先描述需求再补约束而是把约束放在最前面。比如运行环境微信小游戏基于 JavaScript无 DOM无 BOM可使用 wx.* API。我的技术背景会 JavaScript不会游戏引擎。需求实现一个 XXX 玩法。请给出最小实现方案代码要能直接在微信开发者工具里运行。第二个要求 AI 解释“为什么”。我经常会在提示词最后加一句“请解释你选择这个方案的原因以及有没有更简单的替代方案。” 这样我能判断 AI 给的方案是不是过度设计。第三个分步验证。不要让 AI 一次性输出整个游戏的代码。我会让它先输出“游戏循环”的部分我跑通了再让它输出“碰撞检测”的部分。每一步都验证避免最后拿到一堆跑不起来的代码。2.4 从聊天记录到可运行代码的转化AI 聊出来的方案最终要变成微信开发者工具里能跑的项目。这个过程我总结了一个固定的转化流程让 AI 输出项目结构包括game.js、game.json、project.config.json这几个核心文件的内容。在微信开发者工具里新建小游戏项目选择“小游戏”类型填入自己的 AppID。把 AI 生成的代码按文件粘贴进去注意game.json的配置项要跟微信官方文档对齐AI 有时候会给出过时的配置。在模拟器里跑一遍看有没有报错有报错就把错误信息复制给 AI让它给修复方案。真机预览用微信扫码在手机上跑一遍看触摸事件、性能表现是否正常。这个流程我跑了大概十几轮每一轮都是“AI 给代码 → 我跑 → 报错 → 反馈给 AI → 修复”。听起来很笨但对于非游戏开发者来说这是最稳的路径。3. 微信开发者工具里的实操细节3.1 项目初始化的关键配置微信开发者工具入口打开之后新建项目时有两个选择小程序和小游戏。这里千万别选错小游戏的项目结构跟小程序完全不一样。小游戏没有 WXML 和 WXSS入口文件是game.js配置文件是game.json。game.json里几个关键配置我列一下{ deviceOrientation: portrait, showStatusBar: false, networkTimeout: { request: 5000 } }deviceOrientation决定横屏还是竖屏我做的是竖屏游戏所以设成portrait。showStatusBar设成false可以让游戏画面全屏体验更好。networkTimeout我设了 5 秒虽然 MVP 阶段没用到网络请求但留着后面迭代用。project.config.json里最重要的是appid和projectname。appid必须是你自己注册的小游戏 AppID不能用测试号因为后面备案和审核都要用到正式 AppID。3.2 Canvas 渲染的核心逻辑微信小游戏的 Canvas 跟网页上的 Canvas 用法基本一致但获取方式不同。网页上是用document.getElementById获取小游戏里是用wx.createCanvas()。const canvas wx.createCanvas(); const ctx canvas.getContext(2d);拿到ctx之后就可以用标准的 Canvas API 做绘制了。我做的游戏核心渲染逻辑大概是这样的function gameLoop() { ctx.clearRect(0, 0, canvas.width, canvas.height); updateGameState(); drawGameScene(ctx); requestAnimationFrame(gameLoop); } gameLoop();这里有个坑要注意requestAnimationFrame在微信小游戏里是全局可用的不需要wx.前缀。但它的执行频率跟设备刷新率有关不同手机可能不一样。所以游戏逻辑里的时间计算不能用“每帧固定时间”的假设而要用实际的时间差。我是这样处理的let lastTime Date.now(); function gameLoop() { const now Date.now(); const deltaTime now - lastTime; lastTime now; updateGameState(deltaTime); // ... }这样不管设备刷新率是多少游戏逻辑的速度都是一致的。3.3 触摸事件的处理方式微信小游戏的触摸事件是通过wx.onTouchStart、wx.onTouchMove、wx.onTouchEnd来监听的。跟网页上的addEventListener不一样这里没有 DOM 元素的概念整个屏幕就是一个触摸区域。wx.onTouchStart((e) { const touch e.touches[0]; const x touch.clientX; const y touch.clientY; handleTouch(x, y); });clientX和clientY是相对于屏幕左上角的坐标。这里要注意不同设备的屏幕尺寸不一样所以游戏元素的坐标不能写死要根据canvas.width和canvas.height做比例计算。我踩过一个坑在模拟器里坐标是对的真机上偏了。后来发现是因为模拟器的屏幕比例跟真机不一样。解决办法是用相对坐标比如canvas.width * 0.5表示屏幕水平中心而不是写死200。3.4 本地存储与分数记录MVP 阶段不需要后端最高分直接用wx.setStorageSync存在本地// 读取最高分 let highScore wx.getStorageSync(highScore) || 0; // 更新最高分 if (currentScore highScore) { highScore currentScore; wx.setStorageSync(highScore, highScore); }这个 API 是同步的用起来很简单。但要注意存储的数据类型只能是字符串、数字、布尔值、对象和数组。我一开始想存一个自定义的类实例结果读出来变成了普通对象方法全丢了。后来改成只存数字就没问题了。3.5 真机调试与性能观察微信开发者工具自带的真机调试功能很好用。点击“真机调试”用手机扫码就能在手机上跑同时在电脑上看到 console 输出和性能面板。性能面板里我主要看两个指标帧率和内存占用。帧率低于 30 就要注意了可能是渲染逻辑太重。内存持续增长不回落可能有内存泄漏通常是事件监听没解绑或者定时器没清除。我遇到过一次帧率骤降排查后发现是每帧都在创建新的对象导致垃圾回收频繁触发。解决办法是把不变的对象提到循环外面创建循环里只更新属性值。这个优化做完帧率从 25 左右稳定到了 55 以上。4. 备案 27 天的完整流程与踩坑记录4.1 备案为什么需要提前启动很多人以为游戏做完了才需要备案其实不是。微信小游戏的备案是在“开发完成、准备提审”之前就要做的而且备案通过之前游戏是不能正式发布的。我一开始不知道这个流程等游戏开发完了才去备案结果硬生生等了 27 天。如果一开始就把备案和开发并行推进这 27 天完全可以省下来。所以第一条经验就是项目立项之后第一件事就是去备案不要等开发完。备案需要填的信息包括游戏名称、游戏类型、玩法简介、技术方案等这些在立项阶段就能确定不需要等代码写完。4.2 备案材料的准备清单备案需要提交的材料我整理了一个清单材料名称说明注意事项游戏名称正式上线名称不能与已有游戏重名建议准备 2-3 个备选游戏类型休闲、益智等选择最贴近的分类不要选太宽泛的玩法简介200 字以内说清楚核心玩法不要写技术实现技术方案简要说明说明使用微信小游戏原生框架无第三方引擎主体信息个人或企业个人主体有部分类目限制企业主体更灵活承诺书官方模板按模板填写不要自己发挥这里有个坑游戏名称一旦提交修改很麻烦。我第一个名字因为跟已有游戏太像被驳回了重新提交又等了好几天。所以名字一定要提前查重微信小游戏有官方的名称查询入口提交前先查一遍。4.3 备案审核的各个阶段备案提交之后会经历几个阶段平台初审一般 1-3 个工作日主要看材料是否齐全、格式是否正确。补充材料如果材料有问题会通知你补充这个来回可能耗掉 3-5 天。深度审核这个阶段最耗时我这次花了将近两周。审核人员会实际体验游戏判断玩法是否合规、内容是否健康。备案通过通过之后会拿到备案号这个号要填到小游戏的配置里。我这次 27 天里初审花了 2 天补充材料来回花了 4 天深度审核花了 18 天最后 3 天是备案号下发和配置。所以真正卡时间的是深度审核这个阶段没有捷径只能等。4.4 备案期间可以并行做的事虽然备案要等但开发工作不能停。我在备案期间做了这几件事继续打磨核心玩法备案不影响开发我利用这段时间把游戏手感调了好几轮。准备审核素材小游戏提审需要提供游戏截图、玩法说明、测试账号等这些可以提前准备。测试不同机型借了几台不同型号的手机测试触摸响应和帧率表现。写用户反馈收集方案提前想好上线后怎么收集反馈比如在游戏里加一个“反馈”按钮。这样等备案通过的时候我这边所有准备工作都做完了直接提审没有浪费任何时间。4.5 备案被驳回的常见原因我这次被驳回过一次原因是“玩法简介描述不清”。后来我重新写了一遍把核心操作、反馈机制、结束条件都写清楚了就通过了。根据我的经验和跟其他开发者的交流常见的驳回原因还有名称违规包含敏感词或与已有游戏重名。玩法涉及随机抽取如果有抽奖、开箱等机制需要额外说明概率。内容不符合公序良俗这个不用多说大家都懂。技术方案描述不清比如没说清楚用的是什么框架审核人员无法判断技术合规性。避免这些问题的办法很简单提交前把材料给一个不了解这个项目的人看一遍如果他能看懂玩法是什么基本就没问题。5. 常见问题与排查技巧实录5.1 微信开发者工具里的典型报错我在开发过程中遇到最多的报错是这几类第一类wx is not defined。这个通常是因为代码在非小游戏环境下运行了。比如你把小游戏代码直接放到浏览器里跑就会报这个错。解决办法是确保代码只在微信开发者工具或真机上运行。第二类canvas is null。这个是因为wx.createCanvas()调用时机不对。必须在game.js的入口处调用不能放在异步回调里。我一开始把它放在setTimeout里结果拿不到 canvas。第三类requestAnimationFrame is not a function。这个在旧版本的微信开发者工具里会出现。解决办法是升级到最新版本或者用setTimeout做降级处理。5.2 真机上触摸不灵敏的排查真机上触摸不灵敏通常有三个原因触摸区域太小游戏元素的点击区域要足够大建议不小于 44x44 像素。触摸事件被覆盖如果有多个触摸监听后面的会覆盖前面的。确保只注册一次。帧率太低导致响应延迟如果帧率低于 20触摸响应会明显变慢。优化渲染逻辑把帧率提上去。我遇到过一次触摸不灵敏排查后发现是每帧都在重新注册触摸事件导致事件队列堆积。改成只注册一次之后问题就解决了。5.3 AI 生成代码的常见问题AI 生成的代码直接拿来用通常会遇到这些问题问题类型表现解决办法API 过时用了废弃的 API对照微信官方文档替换成新 API环境不匹配用了浏览器 API替换成微信小游戏对应的 API逻辑不完整缺少边界处理让 AI 补充异常处理逻辑性能问题每帧创建新对象把不变的对象提到循环外配置错误game.json 格式不对对照官方文档逐项检查我的经验是AI 生成的代码永远不要直接上线一定要自己跑一遍把报错信息反馈给 AI让它修复。通常来回两三轮代码就能稳定运行了。5.4 提审被拒的应对策略提审被拒是常态不要慌。微信小游戏的审核反馈会说明拒绝原因你按照原因修改后重新提交就行。我总结了几条应对策略不要改无关的地方只改审核指出的问题改多了可能引入新问题。保留修改记录每次修改都记下来方便对比和回溯。提前准备申诉材料如果认为审核有误可以申诉但要有理有据。留足审核时间提审到通过一般需要 1-7 天不要卡着上线日期提审。5.5 上线后的数据观察与迭代游戏上线之后我主要看几个数据次日留存如果低于 20%说明玩法吸引力不够。平均游戏时长如果低于 1 分钟说明核心循环太短或太无聊。分享率如果没人分享说明缺少分享动机。根据这些数据我做了几轮迭代增加了难度递增机制让游戏时长从 40 秒提升到了 2 分钟左右加了一个“分享给好友挑战”的按钮分享率提升了 3 倍。6. 非游戏开发者做小游戏的经验总结6.1 技术选型上的取舍逻辑回顾整个项目我在技术选型上做了几个关键取舍不用游戏引擎。Unity 和 Cocos 虽然功能强大但学习成本高打包到微信小游戏还需要额外的适配工作。对于 MVP 阶段来说原生 Canvas 足够用了。不用后端。MVP 阶段所有数据都存在本地不需要服务器。这样省掉了服务器成本、接口开发、数据同步等一系列问题。等用户量上来了再考虑加后端。不用复杂的状态管理。游戏状态就用一个普通对象存着每帧更新。不需要 Redux 或 MobX 那套东西。这些取舍的核心逻辑是MVP 阶段只做必要的事把复杂度降到最低。每增加一个技术栈就多一份学习成本和维护成本。对于非游戏开发者来说少即是多。6.2 AI 协作的边界在哪里AI 在这个项目里帮了我很多但它不是万能的。我总结了一下 AI 能做什么、不能做什么AI 擅长的生成基础代码框架解释技术概念提供多种实现方案排查报错原因优化代码结构AI 不擅长的判断玩法是否好玩做产品决策处理微信小游戏特有的环境问题保证代码在真机上的表现替代官方文档所以我的用法是AI 负责“怎么写”我负责“写什么”和“能不能跑”。产品判断、环境验证、真机测试这些必须自己来。6.3 时间分配的真实记录我记录了一下整个项目的时间分配阶段耗时占比需求梳理与 MVP 定义3 天5%AI 协作开发10 天17%真机调试与优化7 天12%备案等待27 天45%提审与修改5 天8%上线后迭代8 天13%可以看到备案占了将近一半的时间。如果备案和开发并行总周期可以从两个月压缩到一个月左右。这是我最想告诉后来者的一条经验。6.4 给非游戏开发者的实操建议如果你也是非游戏背景想用 AI 做微信小游戏我的建议是第一先做最小可玩原型。不要一上来就想完整游戏先做一个能玩 30 秒的版本验证玩法是否成立。第二备案和开发并行。立项就去备案不要等开发完。备案期间继续开发两不耽误。第三AI 生成的代码必须自己跑。不要相信 AI 说的“这段代码可以直接运行”一定要在微信开发者工具里跑一遍报错了就反馈给 AI 修复。第四真机测试不能省。模拟器上跑得再好真机上也可能出问题。触摸、帧率、内存这些都要在真机上验证。第五留足审核时间。提审到通过一般需要几天备案需要几周这些时间都要提前算进去。6.5 后续可以扩展的方向游戏上线之后我还在继续迭代。后面打算做的方向包括加后端排行榜用微信云开发做排行榜不需要自己搭服务器。加社交分享让玩家可以分享成绩给好友增加传播。加关卡系统从无限模式扩展到关卡模式增加内容量。加音效和动画提升游戏的反馈感和沉浸感。这些都不着急一步一步来。MVP 已经验证了核心玩法是成立的后面的迭代就是锦上添花。最后分享一个我在这个项目里体会最深的心得非游戏开发者做游戏最大的障碍不是技术而是心态。你总会觉得自己“不够格”觉得“不会引擎就做不了游戏”。但实际上微信小游戏的门槛比想象中低很多AI 又能帮你补上大部分技术短板。真正重要的是你有没有一个想做的玩法以及你愿不愿意花时间去把它磨出来。技术问题都能解决心态问题只能自己过。