非游戏开发者用AI做微信小游戏：从开发到备案上线全记录

1. 一个非游戏开发者的真实起点

我做了八年后端开发，主要写Java和Python，游戏开发的经验基本为零。Unity没碰过，Cocos只会新建项目，微信小游戏对我来说一直是个“看起来不难但不知道从哪下手”的东西。直到去年年底，我想做一个轻量的答题类小游戏放到微信上，才真正开始动手。这篇文章就是整个过程的完整记录，从用AI聊出MVP、到备案花了27天、再到踩过的各种坑，全部如实写出来。

先说结论：非游戏开发者用AI做微信小游戏，技术上完全可行，但真正的门槛不在写代码，而在备案流程、平台规则和发布环节。代码部分AI能帮你搞定七八成，剩下的是你要理解微信小游戏的运行机制和审核逻辑。这篇文章适合那些有基础编程能力、想尝试小游戏但不知道从哪开始的人，也适合已经在做但卡在某个环节的开发者参考。

整个项目从想法到上线，前后大概花了六周时间。其中写代码和调试用了不到两周，备案和审核占了将近四周。这个时间分配本身就说明了很多问题，后面我会详细展开。

2. 用AI聊出MVP：从模糊想法到可运行原型

2.1 为什么选择“聊天式开发”而不是直接写代码

我最开始的想法很简单：做一个答题小游戏，用户可以选择不同题库，限时作答，最后看排名。但我不知道怎么在微信小游戏里实现页面切换、怎么做计时器、怎么存储用户数据。如果按照传统方式，我得先花几天看文档、学框架，然后才能开始写第一行代码。

我换了个思路：把AI当成一个懂微信小游戏开发的技术合伙人，用对话的方式让它帮我做技术选型和架构设计。具体做法是，我先用自然语言描述需求，让AI给出技术方案，然后逐步细化到具体代码。这个过程不是一次性的，而是反复迭代的。

我用的AI工具主要是两个：一个通用大模型用来做方案讨论和代码生成，另一个专门用来查微信小游戏的API文档。两者配合使用，效果比单独用一个好很多。通用模型负责逻辑和架构，专用工具负责确认API的调用方式和参数格式。

2.2 第一轮对话：让AI帮我做技术选型

我的第一轮提问大概是这样的：“我想做一个微信小游戏，答题类的，用户选择题库后限时答题，最后显示得分和排名。我没有游戏开发经验，有后端开发基础。请给出技术方案，包括用什么引擎、怎么组织代码、数据怎么存储。”

AI给出的方案是：使用微信小游戏原生框架，不引入Unity或Cocos等重型引擎，因为答题类游戏不需要复杂的渲染和物理引擎。代码结构分为三层：页面层负责UI渲染和用户交互，逻辑层负责题目管理和计分，数据层负责本地存储和云端同步。本地存储用wx.setStorageSync，云端用微信云开发。

这个方案的好处是轻量、启动快、不需要额外学习游戏引擎。坏处是如果以后想加复杂的动画效果，可能需要重构。但对我这个MVP来说，轻量是首要考虑。

提示：让AI做技术选型时，一定要把你的背景和约束条件说清楚。比如“我没有游戏开发经验”这个信息，直接影响了AI是否推荐Unity。如果你不说，AI可能会默认你有游戏开发基础，给出一个你根本跑不起来的方案。

2.3 第二轮到第五轮：逐步细化到可运行代码

技术方案确定后，我开始让AI帮我写具体代码。这个过程是分模块进行的，每次只处理一个功能点。比如第一轮写游戏主页面，第二轮写答题逻辑，第三轮写计时器，第四轮写得分计算和排名展示。

每一轮我的提问方式都是：“我要实现XXX功能，当前代码是这样的（粘贴代码），请帮我补充XXX部分的实现。”AI会给出代码和解释，我复制到微信开发者工具里运行，遇到报错再贴回去让AI分析。

这里有个关键技巧：不要一次性让AI写完整项目，而是按功能模块逐个突破。一次性生成的代码往往有很多隐藏问题，而且你很难定位错误。分模块的好处是每个部分都能单独测试，出了问题也容易排查。

我大概用了五轮对话就完成了核心功能的代码。具体包括：游戏主页面布局、题库数据结构、答题交互逻辑、倒计时功能、得分计算、本地排行榜存储。代码总量不大，核心逻辑大概三百多行JavaScript。

2.4 MVP的功能边界怎么定

做MVP最容易犯的错误是功能贪多。我一开始想加好友对战、想加每日挑战、想加成就系统，后来全部砍掉了。MVP只保留最核心的闭环：选题库、答题、看得分、存本地排名。其他功能全部放到后续迭代。

这个决策的依据是：MVP的目的是验证核心玩法是否成立，而不是做一个完整产品。如果核心玩法不成立，加再多功能也没用。而且功能越多，备案和审核时被卡的概率越大。

我最终上线的MVP只有三个页面：首页（选择题库）、答题页（显示题目和选项）、结果页（显示得分和排名）。没有登录、没有支付、没有社交分享。这些“没有”反而让审核过程顺利了很多。

3. 微信开发者工具实操：从零到本地跑通

3.1 环境搭建与项目初始化

微信开发者工具是官方提供的IDE，下载安装没什么难度，但有几个细节需要注意。首先，必须用邮箱注册微信开放平台账号，并且完成开发者资质认证。个人开发者可以注册，但部分类目的小游戏需要企业资质。答题类小游戏个人开发者可以发布，但如果有社交或支付功能，就需要企业资质。

安装完成后，新建项目时选择“小游戏”类型，不是“小程序”。这两个是不同的技术栈，小游戏用的是Canvas渲染，小程序用的是WebView渲染。选错了后面改起来很麻烦。

项目初始化后，目录结构大概是这样的：game.js是入口文件，game.json是配置文件，project.config.json是项目配置。AI生成的代码需要按照这个结构组织。我一开始把代码全写在game.js里，后来发现太乱了，就拆成了几个模块文件，用require引入。

3.2 核心代码结构与关键实现

我的代码结构最终是这样的：game.js作为入口，负责初始化和页面路由；pages目录下放三个页面的逻辑；utils目录下放工具函数，比如题库加载、得分计算、存储读写。

答题逻辑的核心是一个状态机：当前题目索引、剩余时间、得分、答题记录。每次用户点击选项，状态机更新，然后判断是否还有下一题。如果没有，跳转到结果页。

计时器用的是setInterval，每秒更新一次剩余时间。这里有个坑：setInterval在页面切换时不会自动清除，会导致内存泄漏和计时错乱。我后来改成在页面隐藏时清除计时器，显示时重新创建。

// 计时器管理示例 let timer = null; function startTimer() { if (timer) clearInterval(timer); timer = setInterval(() => { this.remainingTime--; if (this.remainingTime <= 0) { clearInterval(timer); this.endGame(); } }, 1000); } function stopTimer() { if (timer) { clearInterval(timer); timer = null; } }

这段代码看起来简单，但实际调试时我遇到了计时器在后台继续运行的问题。微信小游戏在切到后台时，setInterval会被暂停，但切回来后会继续执行，导致时间计算错误。解决方案是用Date.now()记录开始时间，每次更新时计算实际经过的时间，而不是依赖setInterval的累加。

3.3 本地调试与真机预览

微信开发者工具支持模拟器预览和真机预览。模拟器适合快速调试逻辑，但有些问题只有在真机上才能发现，比如触摸事件、屏幕适配、性能表现。

真机预览需要用手机微信扫描开发者工具生成的二维码。这里有个细节：预览二维码有时效性，过期后需要重新生成。而且预览版本和体验版本不同，预览版本只有开发者自己能扫，体验版本可以分享给其他人。

我在真机调试时发现了一个模拟器上没出现的问题：在部分安卓机型上，Canvas的触摸事件坐标有偏移。原因是不同机型的屏幕密度不同，需要做坐标转换。解决方案是用wx.getSystemInfoSync()获取屏幕信息，然后按比例换算。

注意：真机调试是必须的环节，不要只依赖模拟器。模拟器上的表现和真机差异可能很大，尤其是涉及触摸、音频、性能的场景。

3.4 把体验版发给别人试用的正确姿势

微信开发者工具里有个“上传”功能，上传后可以在微信公众平台的后台看到版本管理。在这里可以把某个版本设为体验版，然后生成体验二维码。体验版最多可以添加一定数量的体验成员，具体数量根据账号类型不同。

我当时的做法是：上传代码后，在后台设为体验版，然后把体验二维码发给几个朋友，让他们试玩并反馈。收集反馈大概用了三天，主要问题集中在题目难度和计时器体验上。根据反馈调整后，才提交审核。

这里有个容易忽略的点：体验版的数据和正式版是隔离的，体验版的本地存储不会带到正式版。所以如果MVP依赖本地存储，体验版和正式版的数据是分开的。这个不影响功能测试，但要注意别把体验版的数据当成正式数据。

4. 备案27天：最耗时的环节没有之一

4.1 备案流程全解析

微信小游戏的备案和网站备案类似，但流程更长。整体步骤是：在微信公众平台提交备案申请，填写主体信息和游戏信息，然后等待审核。审核分为两个阶段：平台初审和管局审核。

平台初审一般1到3个工作日，主要检查材料是否齐全、信息是否一致。管局审核是主要耗时环节，官方说法是20个工作日内，实际我用了27天。这个时间不可控，只能等。

需要准备的材料包括：主体证件（个人是身份证，企业是营业执照）、负责人信息、游戏内容说明、技术方案说明。个人开发者还需要提供个人承诺书。所有材料都需要扫描件或照片，清晰度要够。

4.2 备案被卡住的三个常见原因

我的备案被退回过一次，原因是游戏内容说明写得太简单。管局要求详细描述游戏玩法、内容来源、是否有用户生成内容、是否有社交功能。我第一版只写了“答题类小游戏”，被退回后补充了题库来源、答题机制、无社交功能的说明，才通过。

第二个常见原因是主体信息不一致。比如身份证上的名字和微信公众平台注册的名字不一致，或者证件照片模糊。这个只能仔细核对，没有捷径。

第三个原因是游戏名称或内容涉及敏感词。答题类游戏如果题库涉及某些领域，可能会被要求提供额外说明。我的题库是通用知识，没有这个问题，但如果你做的是特定领域的答题，需要提前确认。

4.3 备案期间可以做什么

备案审核期间，代码不能提交审核，但可以继续开发和调试。我利用这段时间做了几件事：优化UI、增加题库、写用户反馈收集逻辑、准备审核材料。

另外，备案期间可以先把体验版发给更多人试用，收集更多反馈。体验版不需要备案，但也不能正式发布。这个阶段适合做产品打磨，等备案通过后直接提交审核。

提示：备案时间不可控，建议在项目启动初期就同步准备备案材料，不要等代码写完再开始。备案和开发可以并行，能节省不少时间。

4.4 备案通过后的审核环节

备案通过后，还需要提交微信平台审核。这个审核主要检查游戏内容是否符合平台规范，比如是否有违规内容、是否有诱导分享、是否有未声明的功能。审核一般1到7个工作日。

我的审核一次通过，因为MVP功能简单，没有社交和支付，内容也是通用知识。如果你要做带社交或支付的小游戏，审核会更严格，可能需要提供额外资质。

5. 踩坑实录与排查技巧

5.1 代码层面的五个坑

第一个坑是Canvas渲染的坐标系统。微信小游戏的Canvas坐标原点在左上角，但不同机型的屏幕比例不同，需要做适配。我一开始用固定像素值，在部分机型上显示不全。后来改用相对坐标，按屏幕宽高比例计算。

第二个坑是本地存储的容量限制。wx.setStorageSync单个key最大1MB，总容量10MB。我的题库数据一开始全存在一个key里，超过了限制。后来拆分成多个key，每个题库单独存储。

第三个坑是音频资源的加载。微信小游戏支持音频，但加载是异步的，如果没加载完就播放会报错。解决方案是预加载音频，加载完成后再开始游戏。

第四个坑是页面切换时的状态管理。微信小游戏的页面切换不像Web那样有完整的生命周期，需要在切换时手动保存和恢复状态。我后来用了一个全局状态对象来管理。

第五个坑是代码包大小限制。微信小游戏主包最大4MB，总包最大20MB。我的代码和资源加起来不到1MB，没遇到这个问题，但如果做复杂游戏，需要分包加载。

5.2 备案和审核的四个坑

第一个坑是材料格式。管局对照片的格式、大小、清晰度有要求，不符合会被退回。建议用扫描件而不是手机拍照，清晰度更高。

第二个坑是信息一致性。所有材料上的信息必须一致，包括名字、证件号、联系方式。不一致会被退回。

第三个坑是游戏内容说明。要详细、具体，不能笼统。最好附上游戏截图和玩法说明。

第四个坑是审核期间的修改。提交审核后不要修改代码，否则需要重新提交。我有个朋友在审核期间改了代码，结果审核通过后版本不对，又重新走了一遍流程。

5.3 常见问题速查表

5.4 独家避坑心得

心得一：备案材料提前准备。不要等代码写完再准备备案，可以在项目启动时就同步准备。备案时间不可控，提前准备能节省至少一周。

心得二：MVP功能越少越好。每增加一个功能，备案和审核的复杂度就增加一分。社交、支付、用户生成内容这些功能，能不加就不加。

心得三：真机测试覆盖主流机型。至少测试安卓和iOS各两台不同品牌的手机，屏幕比例和性能差异会暴露很多问题。

心得四：保留所有审核记录。备案和审核的每一次提交、退回、通过都要截图保存，万一后续有问题可以追溯。

心得五：不要依赖单一AI工具。不同AI工具擅长的领域不同，通用模型适合方案讨论，专用工具适合查API文档。多工具配合使用，效率更高。

6. 上线后的数据与后续迭代方向

6.1 上线初期的真实数据

上线第一周，日活大概几十人，主要来自朋友圈分享。留存率不高，次日留存大概20%左右。这个数据不算好，但对于一个没有推广的MVP来说，能跑通完整流程已经是达到了预期目标。

用户反馈主要集中在两个方面：题目难度不均匀，有些太简单有些太难；计时器在最后几秒没有提示，容易错过。这两个问题在后续版本中做了优化。

6.2 后续可以扩展的方向

如果继续迭代，我会优先做三件事：一是增加题库分类和难度分级，让用户可以选择适合自己的难度；二是增加答题结果的分享功能，但要注意微信对分享的规范；三是增加简单的用户系统，用微信登录，记录历史成绩。

但这些都是后话。MVP的核心价值是验证了“非游戏开发者用AI做微信小游戏”这条路是走得通的。代码不是门槛，备案和审核才是。理解了这一点，后面的迭代就有方向了。

6.3 给后来者的实用建议

如果你也想走这条路，我的建议是：先用AI做一个最小可运行的版本，跑通本地调试和真机预览；然后立刻开始准备备案材料，不要等；备案期间继续打磨产品和收集反馈；备案通过后提交审核，审核期间不要改代码；上线后先看数据再决定迭代方向。

整个过程最需要的是耐心，尤其是备案阶段。技术问题AI基本都能帮你解决，但流程问题只能自己走。踩过的坑我都写在上面了，希望能帮你少走弯路。