非游戏开发者用AI做微信小游戏：5天开发与27天备案实录

1. 一个从没碰过游戏引擎的人，为什么敢接微信小游戏这个活

先说背景。我做了七八年后端和运维，写过接口、搭过流水线、处理过线上告警，但游戏开发这件事，跟我一直没什么交集。Unity 没打开过，Cocos 只听过名字，游戏引擎里那些坐标系、渲染管线、帧同步的概念，对我来说跟天书差不多。所以当朋友问我"能不能帮忙做个小游戏，微信上能玩的那种"，我第一反应是拒绝。

但事情有意思的地方在于，这两年 AI 编程工具的成熟度确实到了一个临界点。我平时用 Trae 这类 AI IDE 写业务代码，已经习惯了让它帮我补函数、写测试、查报错。于是我想，既然业务逻辑能靠 AI 辅助，那游戏逻辑是不是也能？微信小游戏本质上也是一个前端项目，有页面、有状态、有交互，只不过渲染层换成了 Canvas 而已。这个判断后来被证明是对的，但中间踩的坑远比我想象的多。

这篇文章要讲的就是完整的过程：怎么用聊天的方式让 AI 帮我从零搭出一个能跑的 MVP，微信开发者工具里怎么调试和分享给朋友试用，以及最折磨人的备案环节——整整 27 天。适合的读者是那些有编程基础、但没做过游戏、想用 AI 工具快速验证一个微信小游戏想法的人。如果你是完全零基础，也能看懂，只是有些环节需要多查一下文档。

先给一个整体预期管理：技术开发部分，借助 AI 工具，我大概花了 5 天做出可玩版本；但合规和备案流程，花了 27 天。这个比例非常反直觉，但它是真实情况。很多人以为难点在写代码，实际上真正的门槛在流程。

2. 用聊天把 MVP 聊出来：AI 辅助开发的真实工作方式

2.1 为什么选微信小游戏而不是 H5 或原生 App

这个决策值得先说清楚，因为它决定了后面所有的技术选型。当时有三个选项：做一个 H5 网页游戏、做一个原生 App、做微信小游戏。

H5 网页游戏开发最快，但分享和留存是硬伤。你发一个链接给朋友，他点开玩一次，下次想再玩就得重新找链接。没有入口，没有留存，做完就死。原生 App 更不用考虑，为了一个小游戏让用户下载安装包，转化率低得可怜，而且上架审核周期也不短。

微信小游戏的核心优势在于入口和社交关系链。用户从聊天窗口、群分享、朋友圈点进来就能玩，玩完可以直接分享给好友，这种传播路径是其他形态给不了的。而且微信小游戏有一套完整的运行时和 API，性能比 H5 好，又不需要用户安装。对于"快速验证一个想法"这个目标来说，它是最合适的载体。

代价是：你需要走微信的注册、认证、备案流程。这个代价后面会详细讲，它比技术本身麻烦得多。

2.2 和 AI 对话的正确姿势：不要让它一次写完整个游戏

我一开始犯了个错误，直接跟 AI 说"帮我做一个微信小游戏，玩法是 XXX"。结果它给我吐了一大段代码，结构混乱，跑不起来，报错一堆，我改都不知道从哪改。

后来我调整了策略，把整个游戏拆成几个独立的、可验证的小模块，一个一个跟 AI 聊。这个思路其实跟做后端开发一样：你不会让一个人一次性写完整个系统，而是先定接口，再分模块实现。

我的拆解顺序是这样的：

1. 先定游戏的核心循环：玩家做什么动作，系统给什么反馈，什么条件下游戏结束。这一步不写代码，就是纯文字描述，让 AI 帮我梳理逻辑漏洞。
2. 再定数据结构：游戏状态用哪些字段表示，比如分数、生命值、当前关卡、道具列表。让 AI 帮我设计一个清晰的状态对象。
3. 然后是渲染层：用 Canvas 把状态画出来。这一步我让 AI 先给一个最简单的版本，能显示方块和文字就行。
4. 最后是交互层：触摸事件怎么绑定，怎么把用户操作映射到状态变化。

这个顺序的好处是，每一步都有明确的输入和输出，AI 不容易跑偏，我也容易验证。比如数据结构那一步，我让 AI 输出一个 JSON 示例，我一看就知道字段够不够、命名合不合理。

2.3 一个具体的对话片段：让 AI 帮我设计游戏状态

举个实际例子。我做的游戏核心玩法是"躲避 + 收集"，玩家控制一个角色在屏幕上移动，躲避障碍物，收集金币。我跟 AI 的对话大概是这样的：

我：我要做一个微信小游戏，玩家控制一个圆形角色，屏幕上有障碍物从上方落下，还有金币随机出现。玩家碰到障碍物扣血，收集金币加分。请帮我设计游戏的状态数据结构，用 JavaScript 对象表示。

AI 给的回复大致是：

const gameState = { player: { x: 100, y: 300, radius: 20, speed: 5, hp: 3, score: 0 }, obstacles: [], coins: [], status: 'ready', // ready | playing | paused | gameover frame: 0, difficulty: 1 };

这个结构基本可用，但我发现两个问题：一是obstacles和coins里每个元素的结构没定义，二是缺少时间相关的字段（比如游戏已进行时长，用来做难度递增）。我继续追问，AI 补上了：

// obstacle 结构 { x, y, radius, speed, type } // coin 结构 { x, y, radius, collected, animationFrame }

然后我让它把difficulty的计算逻辑也写出来，比如每过 30 秒难度加一，障碍物下落速度乘以一个系数。这样一步步聊下来，状态层就清晰了。

这里有个关键经验：AI 给的代码不要直接信，要让它解释每个字段的用途，你才能判断合不合理。我见过太多人直接把 AI 代码贴进去，跑不通就怪 AI，其实是自己没理解代码在干什么。

2.4 渲染和交互：AI 最擅长的部分其实是"翻译"

渲染层和交互层，AI 的表现比我预期好很多。原因很简单：这两块有大量成熟的模式，AI 见过无数类似的代码。你只要把需求描述清楚，它给的代码基本能跑。

比如我跟它说："用微信小游戏的 Canvas API，写一个渲染函数，把 gameState 里的 player、obstacles、coins 都画出来，player 用蓝色圆，障碍物用红色圆，金币用黄色圆。"它给的代码结构很标准：

function render(ctx, state) { ctx.clearRect(0, 0, canvas.width, canvas.height); // 画玩家 ctx.beginPath(); ctx.arc(state.player.x, state.player.y, state.player.radius, 0, Math.PI * 2); ctx.fillStyle = '#3498db'; ctx.fill(); // 画障碍物 state.obstacles.forEach(o => { ctx.beginPath(); ctx.arc(o.x, o.y, o.radius, 0, Math.PI * 2); ctx.fillStyle = '#e74c3c'; ctx.fill(); }); // 画金币 state.coins.forEach(c => { if (!c.collected) { ctx.beginPath(); ctx.arc(c.x, c.y, c.radius, 0, Math.PI * 2); ctx.fillStyle = '#f1c40f'; ctx.fill(); } }); }

交互层同理，触摸事件绑定、坐标转换、状态更新，AI 都能给出可用的代码。我的角色从"写代码的人"变成了"审代码的人"，这个转变是 AI 辅助开发最核心的价值。

2.5 实测下来，AI 在哪些地方会翻车

不是所有环节都顺利。我踩过的坑主要有三类：

第一类是微信小游戏特有的 API。比如wx.createCanvas()、wx.onTouchStart()这些，AI 有时候会给出 H5 的写法（document.createElement('canvas')），因为微信小游戏的运行环境和浏览器不完全一样。这类问题需要你对照微信官方文档手动改。

第二类是性能相关的代码。AI 给的渲染逻辑往往是"每帧重画所有东西"，小规模没问题，但障碍物一多就卡。我后来自己加了对象池和脏矩形优化，这部分 AI 帮不上太多，得靠人判断。

第三类是游戏手感的调参。角色移动速度、障碍物生成频率、碰撞判定的宽容度，这些没有标准答案，AI 给的是"能跑"的参数，但"好玩"的参数得自己反复试。我大概调了两天才觉得手感对了。

提示：AI 生成的代码一定要在真机上测，不要只在开发者工具的模拟器里跑。模拟器的性能和真机差别很大，尤其是触摸响应和帧率。

3. 微信开发者工具里的调试、预览和分享试用

3.1 项目初始化的几个关键配置

微信小游戏项目不是随便建个文件夹就能跑的，需要在微信开发者工具里创建项目，并且有几个配置项必须一开始就设对，不然后面改起来很麻烦。

首先是appid。如果你还没有注册小游戏账号，可以用测试号先开发，但测试号有功能限制，比如不能真机预览某些能力。我的建议是尽早注册正式账号，因为备案流程很长，越早启动越好。

其次是项目目录结构。微信小游戏的标准结构大概是：

project/ ├── game.js // 入口文件 ├── game.json // 配置文件 ├── project.config.json // 项目配置 └── js/ ├── main.js ├── render.js └── logic.js

game.json里要配置屏幕方向、网络超时等参数。我一开始没注意deviceOrientation这个字段，默认是竖屏，但我的游戏设计是横屏的，结果画面被拉伸了。改过来之后才正常。

3.2 用真机预览收集反馈的正确流程

开发者工具里的"预览"功能会生成一个二维码，用微信扫码就能在手机上玩。这是收集试用反馈最直接的方式。但这里有几个细节：

第一，预览二维码有有效期，而且只有开发者本人和体验成员能扫。如果你想让朋友试用，需要把他们加到"体验成员"列表里。这个在微信公众平台的"成员管理"里设置，最多可以加几十个人，具体数量看账号类型。

第二，体验成员扫的码和开发者扫的码不一样。开发者扫的是预览码，体验成员扫的是体验版码。体验版需要你先"上传"代码，然后在后台设置为体验版。这个流程我一开始搞混了，发给朋友的码他们扫了没反应，后来才发现发错了。

第三，收集反馈最好做个简单的反馈入口。我在游戏结束页面加了一个"反馈"按钮，点击后跳转到一个问卷链接。这样朋友玩完可以直接反馈，不用另外找我。实测下来，有反馈入口的版本，收到的有效反馈量是没有入口的三倍以上。

3.3 调试时最常用的几个技巧

微信开发者工具的调试能力和 Chrome DevTools 很像，但有几个小游戏特有的点：

• Console 面板：console.log的输出会显示在这里，但真机上的 log 需要在手机端开启调试模式才能看到。
• Performance 面板：可以看帧率、内存占用。小游戏卡顿大部分是渲染问题，这个面板能帮你定位。
• Storage 面板：小游戏的本地存储用wx.setStorageSync，数据会显示在这里，方便你检查存档逻辑。

我遇到过一个诡异的问题：游戏在模拟器里跑得好好的，真机上玩几分钟就闪退。后来用 Performance 面板一看，内存一直在涨，是障碍物数组没有及时清理，导致内存泄漏。这种问题只能靠工具定位，光看代码看不出来。

3.4 分享给朋友试用时，怎么收集几天的反馈

朋友试用和正式上线是两回事。正式上线要审核，试用阶段只需要体验版就行。我的做法是：

1. 把体验成员加好，一般 10 到 20 个人足够。
2. 上传体验版，在后台生成体验版二维码。
3. 把二维码发到群里，附上一段简短的说明：怎么玩、大概玩多久、希望反馈什么。
4. 给一个明确的反馈截止时间，比如"这周五之前"。

收集反馈的时候，不要只问"好不好玩"，要问具体的问题：哪一关最难、哪个操作最别扭、有没有遇到卡顿或闪退。具体的问题才能得到有用的答案。

我收到的反馈里，最有价值的一条是"角色移动太灵敏了，手指稍微一动就飞出去"，这直接让我调整了移动的阻尼参数，手感好了很多。这种反馈，AI 是给不了的，只有真人玩过才知道。

4. 备案 27 天：流程、卡点和真实时间线

4.1 为什么小游戏也要备案

这是很多人容易忽略的一点。微信小游戏虽然跑在微信里，但它本质上是一个互联网信息服务，需要完成相关备案手续才能正式上线。没有备案，你只能停留在体验版阶段，无法发布正式版。

备案的流程大致是：先注册小游戏账号并完成主体认证，然后提交备案材料，等待审核。审核通过后才能提交代码审核，审核通过才能发布。整个链条是串行的，任何一环卡住，后面都得等。

4.2 我的真实时间线拆解

我把 27 天的完整时间线列出来，供你参考：

可以看到，真正卡时间的是备案材料的准备和审核。技术开发那 5 天，在整个周期里几乎可以忽略不计。

4.3 备案材料准备中最容易踩的坑

备案材料里，最容易出问题的是服务内容描述。你要用一段话说明这个小游戏是干什么的、面向什么用户、提供什么服务。这段话不能太笼统，也不能太具体到涉及敏感内容。

我第一次提交的时候，写的是"一款休闲娱乐小游戏"，结果被退回了，理由是"描述过于简单，无法判断服务内容"。后来我改成"一款以躲避障碍物和收集道具为核心玩法的休闲小游戏，用户通过触摸屏幕控制角色移动，游戏包含分数排行功能"，就通过了。

另一个坑是截图和演示材料。你需要提供游戏的界面截图，截图要清晰、能体现核心玩法。我一开始截的是开始页面，太简单，后来补了游戏进行中的截图和结束页面截图。

注意：备案材料里的所有描述，都要和你的实际游戏内容一致。不要为了通过审核而夸大或虚构功能，后续代码审核时会对不上。

4.4 备案期间可以做什么

备案等待期不是干等。我利用这段时间做了几件事：

• 继续打磨游戏：根据朋友反馈调整手感和难度曲线。
• 准备代码审核材料：微信小游戏的代码审核需要提供一些说明，比如游戏玩法、操作方式、是否有内购等。提前准备好，备案一通过就能立刻提交。
• 做上线后的运营准备：比如分享文案、排行榜规则、更新计划。这些看起来是小事，但上线后手忙脚乱的时候，有准备和没准备差别很大。

5. 非游戏开发者做小游戏，哪些能力是 AI 替代不了的

5.1 游戏设计判断力：AI 给不了"好玩"

AI 能写出能跑的代码，但写不出好玩的游戏。什么是好玩的？节奏感、难度曲线、反馈的即时性、挫败感和成就感的平衡，这些是设计问题，不是编码问题。

我举个具体的例子。游戏里障碍物的生成频率，AI 给的默认值是每 60 帧生成一个。这个值能跑，但玩起来很无聊，因为太稀疏了。我改成每 30 帧生成一个，又太难，几乎躲不开。最后我做成动态的：前 30 秒每 45 帧一个，之后逐渐加快到每 25 帧一个。这个曲线是我反复试出来的，AI 不会主动告诉你"应该做成动态的"。

这类判断，需要你把自己当成玩家，反复玩自己的游戏，感受哪里不舒服。这是 AI 替代不了的核心能力。

5.2 性能优化的直觉：知道哪里会出问题

非游戏开发者做游戏，最容易忽略的就是性能。AI 给的代码在小规模下没问题，但游戏是实时渲染的，每一帧都要在 16 毫秒内完成，稍微多一点计算就会掉帧。

我踩过的一个坑是：每帧都在创建新的对象（比如障碍物、金币），导致垃圾回收频繁触发，画面一卡一卡的。解决办法是用对象池，提前创建好一批对象，用的时候取，不用的时候还回去。这个优化思路，AI 不会主动提，因为它不知道你的运行环境有多苛刻。

类似的还有：减少 Canvas 的重绘区域、避免在渲染循环里做复杂计算、用离屏 Canvas 预渲染静态元素。这些都需要你对性能有基本的敏感度。

5.3 流程和合规意识：技术之外的另一半

前面反复强调的备案，就是典型的例子。很多技术出身的人会觉得"我把代码写好就行了"，但小游戏上线是一个完整的合规流程，代码只是其中一环。

你需要了解：账号注册、主体认证、备案、代码审核、发布，每一步都有要求和时间成本。这些信息在微信官方文档里都有，但很分散，需要你主动去查、去问、去踩。

我的建议是：在动手写代码之前，先把流程摸清楚。知道整个链条有多长，你才能合理安排时间，不会因为备案卡住而焦虑。

6. 从 MVP 到上线，我总结的几条实操经验

6.1 技术侧：先跑通再优化，不要过早追求完美

我一开始想做一个"完整"的游戏，有排行榜、有道具系统、有音效。结果做了三天，连核心玩法都没跑通。后来我砍掉所有非核心功能，只保留"移动、躲避、收集、计分"，两天就做出了可玩版本。

MVP 的意义就是验证核心玩法是否成立。如果核心玩法不好玩，加再多功能也没用。等核心玩法验证通过了，再逐步加功能，这时候加功能的效率也更高，因为框架已经稳定了。

6.2 工具侧：AI IDE 的选择和使用习惯

我用的是 Trae，它的优势是能理解整个项目上下文，不只是单个文件。比如我让它改一个函数，它会考虑这个函数在其他地方怎么被调用的，不会改出问题。

使用习惯上，我建议：

• 把 AI 当成结对编程的伙伴，不是代码生成器。多问"为什么这样写"，少说"帮我写完"。
• 每次只让它做一件事。一次改一个模块，改完验证，再改下一个。
• 保留对话记录。后面遇到类似问题，可以翻之前的对话，比重新问效率高。

6.3 流程侧：把备案当成项目的一部分来管理

备案不是"提交完等结果"这么简单，它是一个需要管理的流程。我的做法是：

• 建一个文档，记录每一步的状态、提交时间、预计完成时间、实际完成时间。
• 每次被退回，记录退回原因和修改内容，避免重复踩坑。
• 提前准备好所有可能用到的材料，比如截图、说明文档、主体证明。

这样整个流程是可控的，不会因为某个环节卡住而完全停摆。

6.4 心态侧：接受"技术不是瓶颈"这个事实

这是我最想分享的一点。作为一个技术出身的人，我习惯性地认为"技术难度决定项目难度"。但这个小游戏项目让我意识到，在成熟工具的加持下，技术门槛已经大幅降低了，真正的瓶颈在流程、在合规、在对用户需求的理解。

AI 能帮你写代码，但帮不了你备案，帮不了你判断游戏好不好玩，帮不了你决定什么时候上线。这些才是项目成败的关键。

如果你也想用 AI 做一个微信小游戏，我的建议是：技术部分大胆用 AI，快速做出 MVP；流程部分提前调研，留足时间；设计部分多找人试玩，相信真实反馈。这三件事做好了，一个非游戏开发者做出能上线的小游戏，是完全可行的。

最后分享一个我在调试时常用的小技巧：在游戏里加一个隐藏的调试面板，双击屏幕某个角落就能调出来，显示当前帧率、对象数量、内存占用。这个面板在开发阶段帮我定位了好几个性能问题，上线前记得把它关掉或者隐藏起来就行。