用AI零基础开发微信小游戏：从Canvas起手到过审上线的全流程实战

"如果说两年前有人告诉我，一个前后端都写过、但完全没碰过游戏开发的人，能一个人靠 AI 把微信小游戏从零做到上线，我是不太信的。但这事我真做成了。整个过程可以压缩成三条线：和 AI 聊天聊出一个 MVP，大概十天；微信小游戏备案等了 27 天；剩下的时间全在踩坑和填坑。想把这套过程完整写出来，是因为我发现现在很多和我一样的普通开发者，其实是被'游戏开发'四个字吓住了——以为必须得会 Unity、Cocos，熟悉物理引擎和渲染管线才能进场。可 AI 把门槛砍掉之后，真正卡住你的已经不是'写不写得出来'，而是'能不能过平台这道关'。这篇文章就写给想用 AI 做微信小游戏、但对平台规则和技术选型完全没底的人，我会把路线、提示词、备案时间线和踩过的坑全部摊开讲。"

1. 先想清楚路线：没有游戏开发经验，凭什么敢碰 Canvas

1.1 我劝退自己的那次 Unity 尝试

我不否认 Unity 是正经做游戏的标配，但对我这种非游戏开发者来说，Unity 根本不是"学一下就行"的事。我一开始也走了弯路：装了 Unity Hub，建了个 2D 项目，跟着教程把角色控制场景搭到一半，然后开始研究怎么导出成微信小游戏的包。走到这一步，劝退感直接拉满。Unity 官方并没有一键把项目导出成微信小游戏的开关，社区里常见方案是 WebGL 转小游戏，再把引擎的适配层塞进去，出来的包动辄十几兆。微信小游戏主包限制是 4MB，总包也卡得死，Unity 的 WebAssembly 文件本身就大，还要处理内存占用、启动加载、纹理压缩，一套流程下来，游戏还没影，我先被构建工具折磨了。

后来我想明白一个事：我犯的错不是"选错了引擎"，而是"所有学习成本都砸在了技术实现上，而不是玩法和上线"。我做的是一个点击跳跃类的休闲小游戏，玩法极其简单，连物理引擎都用不上。为了这种项目去啃 Unity，等于为了拧一颗螺丝，先去学开机床。如果你的目标是把玩法验证跑通、尽快上线见用户，Unity 这条路的投入产出比是灾难级的。

1.2 最终路线：纯 Canvas + 原生微信小游戏 API

我最后定的路线非常朴素：JavaScript 写逻辑，Canvas 2D 负责绘制，微信小游戏提供的那套 API 用来处理触屏、音频、存储。不引入任何游戏引擎，不用任何第三方渲染库。入口就是一个game.js，微信开发者工具自动识别并加载。这里贴一下最开始的骨架，你会发现这东西根本没想象中复杂：

const canvas = wx.createCanvas() const ctx = canvas.getContext('2d') const W = canvas.width const H = canvas.height function draw() { ctx.clearRect(0, 0, W, H) // 在这里画角色、画障碍物、画分数 requestAnimationFrame(draw) } wx.onTouchStart(() => { // 响应触屏事件，控制角色跳跃 }) draw()

就这么点事。没有 DOM，没有document.getElementById，没有浏览器里的那些东西。微信小游戏就是一个非常封闭的 Canvas 环境，你画什么它显示什么。我第一次把这段代码丢进微信开发者工具，看到自己的角色在模拟器里动起来的时候，说实话松了一口气：AI 能理解这个结构，我也能理解这个结构。

你可能会问：那 AI 在这里面到底起了多大作用？我自己的感受是，AI 最大的作用不是"替我写代码"，而是"替我快速试错"。我想实现某个效果，不用去查半天文档，直接把描述丢给 AI，它写出来，我贴进去跑，看到不对再让它改。原来可能要花一晚上琢磨的 Canvas 绘制细节，现在十分钟就把初版跑起来了。

1.3 什么游戏适合这种"轻路线"，什么情况下真得上 Unity

这条路线不是万能药。经过这次实战，我给自己划了一条选择标准：

我后来跟一个用 Cocos 做小游戏的朋友聊天，他说如果你要做的是有层级节点、动画编辑器、资源管线这些东西的项目，那引擎是省时间的；但如果你的玩法用 Canvas 手绘就能表达，引擎反而成了负担。这次项目让我意识到，AI 时代做技术选型，第一原则是"让 AI 能完整理解你的代码库"。一个 3000 行的game.js，AI 可以整段接管；一个动辄几十个预制体、场景文件的 Unity 工程，AI 反而帮不上什么忙。

2. 聊天出 MVP：我用提示词代替游戏引擎

2.1 第一条提示词，AI 给我上了一课

我的 MVP 玩法很简单：控制一个角色跳跃，躲避迎面滚来的障碍物，得分越高障碍物越快。这个需求如果放在以前，我大概会先画原型图，拆模块，写代码框架，再慢慢调。现在我的第一步是打开对话窗口，输入下面这段提示词：

你是一名微信小游戏开发工程师，熟悉微信小游戏的开放接口。 请帮我开发一款休闲小游戏： - 玩家点击屏幕控制角色跳跃，躲避从右侧滚来的障碍物 - 碰到障碍物游戏结束，显示本次分数 - 入口文件为 game.js，使用 wx.createCanvas 创建画布 - 使用 wx.onTouchStart 监听触屏事件 - 用 wx.getStorageSync / wx.setStorageSync 保存最高分 - 不使用任何第三方库，代码控制在 500 行以内 - 直接在顶部显示当前分数和最高分 请输出完整可运行的代码。

AI 生成第一版不到一分钟。我把它粘进微信开发者工具，能跑，但手感很糟。角色的跳跃高度固定，重力感觉像在月球上，障碍物刷新完全没有规律，有时候连续出三个，有时候十秒钟不出一个。这个阶段我学到的第一课是：AI 写出来的代码，永远是"能运行"和"好玩"之间距离很远的那种状态。你要做的事，不是重新写一遍，而是把问题精确地反馈给它。

2.2 把游戏拆成原子需求再交给 AI

聊天出 MVP 的真正技巧，不是"把需求一句话甩给 AI 就完事"，而是把游戏拆成 AI 容易执行的原子任务。我后来把整个游戏拆成了七个模块，每个模块单独对话，最后再合并：

• 画布与游戏主循环：负责初始化、清屏、requestAnimationFrame 循环
• 角色系统：位置、绘制、跳跃、重力参数
• 障碍物系统：生成、移动、淘汰、速度随分数增长
• 碰撞检测：矩形碰撞或圆形碰撞，判断游戏结束
• 计分与保存：当前分、最高分、本地存储
• 游戏状态管理：待开始、进行中、结束、复活
• 音效与反馈：跳跃音效、碰撞音效、得分震动感

每个模块我单独开一轮对话，让 AI 生成一个函数或一个对象，然后我再命令它把几个模块组装到一起。这样的好处很明显：AI 不会因为上下文太长而遗忘前面的约定，每个模块内部的变量命名、接口边界也更干净。你在提示词里给的信息越结构化，拿回来的代码越少返工。这就是我现在理解的"AI 工程实践"——不是让 AI 无脑生成，而是由人当架构师，AI 当实现者。

这里给一个我当时用的碰撞检测修正片段。第一版 AI 用的是中心点距离判断，导致角色明明没碰到障碍物也判死。我直接把现象描述给它，让它用 AABB 矩形碰撞重写：

function checkHit(px, py, pw, ph, bx, by, bw, bh) { return px < bx + bw && px + pw > bx && py < by + bh && py + ph > by }

这段代码十二个字就能读懂，放在以前的游戏教程里属于"基础得不能再基础"的内容，但对第一次写游戏的软件开发者来说，AI 帮你把这一层补上，省下的是你从文档和别人的源码里大海捞针的时间。

2.3 修 bug 的正确姿势：让 AI 自己写检查清单

我很早发现，直接把报错信息丢给 AI，它往往东改一下西改一下，越改越乱。后来我换了个套路：让它自己列一个"可能导致这个 bug 的原因清单"，再逐条排查。

举个例子，游戏里出现过"分数到某个值后障碍物速度突然归零"的诡异现象。我把现象描述过去，让它先别改代码，只列可能原因。它列了三条：

1. 速度变量在某个分支里被意外重置
2. 速度计算用了整数除法，超过阈值后结果溢出
3. 障碍物生成间隔与速度耦合，间隔归零导致循环卡死

我让它在代码里把这三条逐一检查，最后找到的根因是第二条——JavaScript 里score * 0.1本身没问题，但我在别处用了Math.floor之后又赋值给速度变量，数值一大就出了问题。这个排查过程与其说是我在修 bug，不如说是我在带着 AI 做代码审查。它负责提出候选假设，我负责判断哪些假设符合实际现象。两个人的组合，效率远高于一个人闷头查。

2.4 多 AI 协作的真实分工

这次项目里我同时用了三个 AI 工具，不是赶时髦，是被实际项目逼出来的。它们各有各的习惯，我最后形成了固定的分工：

项目里最典型的一次分工是：我用 Claude 把整个游戏状态机重构了一遍，然后让 ChatGPT 从玩家视角找出"什么情况下操作会失灵"，最后在 Cursor 里逐个修掉它找出的问题。三个工具各干各擅长的活，比我之前只用单一工具来回粘贴效率高多了。后来我也给用 PyCharm 写后端的朋友提过里面的 Fitten 插件，但那是做 Web 服务的事，跟小游戏这种前端 Canvas 项目关系不大——总之一句话，工具是给流程服务的，流程要比工具本身更早想清楚。

3. 备案 27 天全记录：比写代码更磨人的环节

3.1 材料准备：身份证、名称、类目一个都不能错

2023 年 9 月开始，微信小游戏上线前必须完成备案，这是硬门槛，绕不过去的。我一开始以为备案就是填个表等审批，结果打开微信公众平台的后台，看到「备案」入口点进去，才发现要准备的东西比想象中多得多。

首先是材料：身份证正反面照片、本人手持身份证照片、手机号、邮箱。听起来简单，但我第一次提交就因为身份证照片反光被打了回来。手持身份证照片也有隐藏要求——不能戴帽子、不能遮挡面部、证件字迹必须清晰可辨，我在家里折腾了四十分钟才拍出一张合格的。

然后是名称和简介。这里特别容易踩坑：名称不能带"官方""测试""demo"这类词，也不能有营销夸大表述，长度还要控制在 30 字以内。我在名称里放了个自认为很俏皮的谐音梗，结果平台初审直接打回，理由是"名称含有易混淆词汇"。后来把名称改成了直白的「跳跃挑战王」，一次通过。类目方面，如果你的产品是明确的游戏玩法，按规范应当选择"游戏"类目并准备相应资质；如果本质上是一个互动工具或者休闲应用，可以选择"工具"类目。这里的核心不是"怎么选更容易过"，而是"你的产品实际是什么就诚实地选什么"。审核并不会只看你选了什么，它会打开你的小程序实际体验交互，玩法性质明显的东西硬往工具类目塞，大概率被驳回，还会留下不良记录。

3.2 第一次提交被打回：细节败给了一台手机

我的时间线可以用一张表说清楚，真实经历就是 27 天：

被打回那几次，回忆起来都是一些小细节。比如手持身份证照片，我以为手机像素高就行，但审核要求的是"能看到手臂完整姿态"，自拍杆拍出来会被判定为"疑似翻拍证件"。还有一次是主体的办公地址和身份证地址不一致，我填了居住地址，被要求补充证明材料。这些坑没有一个是技术问题，全是"你对规则的理解程度"问题。

3.3 管局审核阶段：等，就是流程的一部分

提交完平台初审之后，材料会进入管局审核阶段。这个阶段的时长，不同省份差别很大，有的地方几个工作日就过，有的地方能拖到二十多天。我能做的只有等，但等待期间有三件事值得做：

第一，把备案编号需要展示的位置提前预留好。小游戏上线后，用户可以在"关于"页或设置页看到备案号，我一开始根本没留这个位置，通过后又补了一版界面。第二，趁等待期把用户隐私保护指引、软件著作权登记这些前置事项一起排上日程。软著登记周期比备案还长，如果依赖它拿资质，一定要提前申请。第三，别频繁改动主包代码。备案期间我因为想优化手感，一天提三个版本，后来发现在某些状态下，备案状态会被锁定审核中的版本，反而容易造成混乱。

等的那二十多天里我悟出来一个道理：备案这件事，心态上要当成"产品上线前的一次重资产投入"，而不是"顺手点一下就能完成的后台操作"。你得给它排足够的时间冗余，并且尽早提交。

3.4 备案通过后，你还需要干的几件事

拿到备案号不等于马上能卖。我当时以为通过就万事大吉，结果漏了两个步骤：第一，回小程序后台设置页把备案号填进去，有些类目还需要在页面中展示；第二，确认隐私保护指引状态正常，否则提审时还会被拦。这里补一句我的粗浅经验：如果你像我一样，小游戏里没有任何收集用户信息的功能，就在后台把「不收集不处理用户信息」的选项如实勾选并通过指引确认。重点是别在代码里偷偷调用隐私相关接口，审核系统是会检测行为轨迹的。老老实实的项目，备案通过反而是最轻松的一步。

4. 代码能跑和能上架是两回事：上线前填坑清单

4.1 开发工具里一切正常，真机第一秒全白

备案等待期间，我一直在折腾代码。做得差不多之后第一次用手机预览，直接蒙了：微信开发者工具里明明流畅得很，真机上打开却是白屏，大概三秒之后才画出画面。排查发现根因是我把资源加载逻辑放在了主循环里，背景图是一张 1MB 多的大图，加载期间整个画面完全空白。

解决方法非常粗暴：在game.js最前面先画一帧纯色背景，再异步加载后续资源。别小看这一步，用户打开小游戏的前三秒体验，基本决定了会不会留在你的页面里。

// 加载资源前先给一个底色，避免白屏 ctx.fillStyle = '#87CEEB' ctx.fillRect(0, 0, W, H) wx.showLoading && wx.showLoading({ title: '加载中...' })

这个坑并不是 AI 能提前帮你规避的，它取决于你有没有在真实设备上测过。所以我的建议是，从 MVP 出来的第一天起，每改一版都用预览二维码扫一次真机，别依赖模拟器。

4.2 首包 4MB 限制下的体积管理

微信小游戏的代码包限制非常现实：主包不能超过 4MB，总包最好控制在 20MB 以内。我没用大引擎，最终包体只有 1.2MB，但即便如此，我也在压包这件事上踩过坑。

一开始我把一张背景原图直接放进项目里，图片 750KB，差点把主包干掉三分之一。后来把背景图压缩成 JPEG 80% 质量，换成 250KB 的分辨率降级版，画质几乎没差。音频文件也是，我最初放了一段 30 秒的完整背景音乐，M4A 格式，单个文件 800KB。后来我把循环片段截到 8 秒，还特意把码率压到 64kbps，文件一下子缩到 120KB。如果你也用 AI 写小游戏，压包这件事最好从第一天就建立意识：所有图片素材过一遍压缩工具，所有音频素材能用短片段就别用完整循环。这个习惯能让你后期少睡两天好觉。

4.3 全面屏与安全区：每个机型都来给你捣乱

非游戏开发者的另一个知识盲区，是屏幕适配。我最初在模拟器上用的分辨率是固定设计稿，结果真机一跑，iPhone 刘海屏把右上角的分数挡住了，安卓全面屏的下巴操作条又把按钮挡了。

微信小游戏提供了一个安全区信息，通过wx.getSystemInfoSync()可以拿到。我的改法是先拿到屏幕实际尺寸，再按设计稿宽度换算缩放比例，绘制时把内容约束在安全区范围内：

const sysInfo = wx.getSystemInfoSync() const screenW = sysInfo.windowWidth const screenH = sysInfo.windowHeight const safeArea = sysInfo.safeArea const scale = screenW / 375 // 以 375 逻辑宽为设计基准 canvas.width = screenW * sysInfo.pixelRatio canvas.height = screenH * sysInfo.pixelRatio ctx.scale(scale * sysInfo.pixelRatio, scale * sysInfo.pixelRatio)

这段代码建议直接抄走。很多 AI 生成的代码不会主动处理安全区，你不提醒它，它就默认所有手机都是完美矩形。把平台适配的要点写进提示词，比事后修 bug 省力得多。

4.4 新用户视角：没有引导，再好的玩法也留不住人

我的第一版产品有个严重的设计失误：用户打开游戏立刻开始跑酷，没有开始界面，没有玩法说明。结果发布到小范围测试时，很多用户第一反应是不断点击屏幕，又不知道目标是什么，十几秒就退出了。AI 能帮你写逻辑，但"新手引导"这件事完全得靠人自己想清楚。

后来我补了一个简单的开始界面，三行字说明规则，加一个「点击开始」按钮。别嫌这东西土，它把新用户跳出率直接降了一半。而且你在界面上写清楚"点击屏幕跳跃，躲避障碍物，碰到即结束"，用户一眼就知道游戏目标，留存自然就上来了。游戏开发里常说的话是"玩家不是白痴，但玩家很忙"，这句话我这次彻底领教了。

5. 审核员的脾气，我领教了三轮

5.1 第一拒：隐私协议不完整

游戏开发完成、备案号也拿到了，我以为提审只是走个流程，结果第一次提交就被打回，理由是大意"用户隐私保护指引未配置完整"。我去后台一看，发现「用户隐私保护指引」里虽然有默认模板，但我没有逐项确认，系统判定为"未完成配置"。

这个事情的教训是：微信小游戏从 2023 年起对用户隐私信息处理这块管得特别严格。哪怕你的小游戏不收集任何用户信息，你也必须在后台明确声明"不收集不处理用户信息"。如果涉及隐私接口，就要在代码里弹窗询问用户授权并如实说明用途。我当时只想着"反正不收集信息，不用管"，结果就栽了。后来我老老实实把指引逐项过了一遍，每一种信息处理类型都确认了"不收集"，再提交就正常进入下一环节。所以提审之前，务必检查三件事：用户隐私保护指引是否确认、备案号是否填写、页面文案有没有违反平台规范的字眼。

5.2 第二拒："官方"两个字差点让我翻车

第二次被驳回更冤。我的游戏里有一个高分彩蛋，角色达到一万分时会弹出一张卡片，文案写的是"官方推荐进阶玩法"。审核驳回理由是：非腾讯官方渠道不得使用"官方"字样，容易让用户误解为平台推荐。

这个坑，非游戏开发者根本意识不到。我们写惯了"官方推荐""官方攻略"这类营销词，觉得挺正常，但在微信小游戏的内容规范里，"官方"这个表述有着很强的歧义风险。我后来把所有文案里的"官方"全部替换成"进阶玩法"，卡片文案改成"你已经很强了，试试连续不落地"。顺利通过。这里提醒大家，在提审前可以用「游戏内文案自查」的视角把所有可见文字过一遍，涉及"官方""第一""最高"这类绝对化表述的，统统删掉。给 AI 的提示词里也可以加一句"文案要使用中性、非绝对化的表述风格"。

5.3 第三轮通过：提审素材和节奏同样重要

第三次提交我做了几件事：提前在手机上完整跑了两遍流程，确认无闪退、无文案错误；把 4 张提审截图换成了干净无弹窗的界面截图；选择周一提审，避开节假日前后的审核高峰。结果两天后就收到了通过通知。

复盘这三次提审经历，我发现审核其实不是玄学，它的背后是一套可以预测的检查逻辑。审核员关注的核心永远是：你的产品能不能正常玩、有没有欺骗或误导用户、有没有收集不该收集的信息、有没有违反平台内容规范。把这些点提前自查完，被驳回的概率会大幅下降。还有一个小细节：审核期间不要频繁提交新版本。我第一轮被拒之后手痒改了个 bug 又提交了一版，结果发现等于重新排队，反而拉长了整体周期。

6. 上线后的真相与复盘

6.1 我以为会爆，结果只是"活下来了"

游戏上线后的第一个月，我用四个字形容：平淡无奇。没有爆发式增长，没有媒体主动报道，靠着朋友圈里朋友转发攒了几百个用户，广告收入低到可以忽略不计。这个结果说实话一点也不意外，微信小游戏的红利期早就过去了，现在想靠一个人在没有任何推广预算的情况下一夜爆红，概率约等于零。

但换个角度看，这一步对我的意义非常大。几百个真实用户里，有几十个人把它玩到了最高分超过 500，有人主动在游戏里点了个赞，还有人留言"重力感有点怪，但停不下来"。这些反馈是开发工具模拟器永远给不了你的东西。我上线前最担心的不是下载量，而是"AI 做的游戏会不会被玩家一眼看穿"。真实数据告诉我，玩家在乎的是玩法好不好玩、反馈跟不跟手，至于代码是人写还是 AI 写的，他们根本不关心。

6.2 这份踩坑清单，建议复制走

把这次从头到尾的坑整理成一张表，每个刚想用 AI 做小游戏的人都可以少走一堆弯路：

这张表里没有一条是 AI 技术问题，全是"平台规则+真实设备"层面的东西。你信不信，一个正经游戏开发老手看到这些坑，只会一笑："这些不是常识吗？"但对我们这种半路出家的人来说，每一条都是真金白银的时间。

6.3 如果再让我做一次，流程会更短

这次最浪费时间的地方，是"边等备案边修代码"没有安排好。如果再来一次，我会这样排：

第一步，先定产品名、简介、类目，第一时间提交备案。备案要等 27 天，那就让备案先跑。第二步，备案等待期间用 AI 做原型，把核心玩法的代码写到 MVP 程度。第三步，拿到备案号后立刻配置隐私保护指引，然后提审。第四步，审核通过前只修 bug 不加大功能。这样安排下来，整个流程能压短到 20 天左右，比这次少了整整一个月的无效等待。

另外，我会把玩法文档提前写好。这次很多 AI 生成的代码，因为我没有在提示词里给出完整的设计约束，导致后期反复重改。如果提前把玩法、手感参数、界面布局写成一页 PRD，每一次 AI 生成的代码都会更接近目标。这也是"AI 工程实践"里非常重要的一条：不是提示词越详细越好，而是你把需求定义得越准，AI 的产出越稳。

6.4 给也想用 AI 做小游戏的人几句掏心话

如果你和我一样，不是游戏开发出身，但想用 AI 做微信小游戏，我的核心体会是：技术门槛已经被 AI 抹平了很多，真正卡人的是两件事——把需求描述清楚的能力，和对平台规则的敬畏心。AI 帮你写跳跃、写碰撞、写计分，都很快；但你要面对的是备案、审核、类目、隐私保护指引这些事。它们不写代码，但它们决定你的产品能不能活下去。

最后分享一个我后来一直在用的小技巧：每次让 AI 改代码之前，先给它一分钟时间"复盘"——让它描述一下当前代码的设计意图，再让它指出最可能出问题的三个点。这一步看起来很费 token，实际上能省掉大量反复。AI 是个很好的执行者，但如果你想让它帮你避坑，你就得先学会"问对它问题"。

我现在的感受是：AI 做小游戏这条路，适合所有愿意接受"写代码只是其中一环"的开发者。玩法靠你的脑子，质量靠你的态度，代码靠 AI，而上线靠你对规则的敬畏。把这几件事摆放整齐，哪怕你是个没碰过游戏的后端程序员，也完全有可能做出一个真正上线的微信小游戏。