1. 一个写文档的凭什么做微信小游戏先交代一下我的背景我平时的工作是写技术文档、做产品需求梳理连一次正经的游戏开发经验都没有Cocos 和 Unity 只停留在听说过的程度。之所以会碰微信小游戏纯粹是因为一个朋友做的小游戏在朋友圈火了几天让我意识到这个赛道并不完全是专业游戏团队的天下——特别是现在 AI 写代码的能力已经到了一种你只需要把需求说清楚剩下的交给它的程度。我的出发点和大多数非游戏开发者一样想低成本验证一个小游戏能不能跑起来、有没有人玩的想法而不是一上来就搞一个完整的商业产品。所以我的目标很明确花尽量少的时间用 AI 辅助做出一款能上线微信小程序平台的游戏 MVPMinimum Viable Product走通从想法到上线全流程并且把过程中的真实成本、时间和坑记录下来。这篇文章就是我完整实践记录的整理。如果你也是非游戏开发者或者你手里有个游戏创意但一直被不会写代码拦住那么这篇文章就是为你写的它不会教你怎么成为一个游戏开发者而是告诉你一个普通人如何借助 AI 工具完成从聊天到上线的整个过程以及最容易被忽视的那些环节——尤其是备案审核那 27 天的等待。先给所有想复制这条路径的人一个总的时间表后面我会逐个阶段展开。阶段耗时关键产出创意与 MVP 定义2 天可玩的原型概念AI 辅助开发5 天可运行的 MVP 代码平台适配与打包3 天微信小游戏安装包备案申请与等待27 天备案号提审与上线2 天正式上线版本这条路径走下来最核心的工具只有一个对话式 AI 编程助手。如果你以为它只能用来写写代码片段、回答几个技术问题那你就低估它了。我用它完成了从游戏规则设计、代码生成、Bug 修复到 UI 界面调试的全过程。但这中间也有大量细碎的坑不是在 ChatGPT 里敲一句帮我做个游戏就能解决的。2. 选型逻辑为什么非游戏开发者应该从 HTML5 原型起步刚开始我犯了个典型错误一上来就想去学 Cocos Creator。网上搜索微信小游戏开发铺天盖地的教程都是 Cocos 或 Unity 的我跟着配环境配了半天还没到写代码就已经被编辑器界面劝退了。这也是很多非游戏开发者死在这个阶段的原因——你被专业工具的门槛拦住根本没机会接触到真正的编程部分。冷静下来后我换了一条路径先用 AI 生成一个纯 HTML5 版本的游戏原型跑通玩法逻辑再转成微信小游戏版本。为什么这样选微信小游戏本质上是一个运行在微信环境中的游戏应用但它有一个很特殊的点它不支持直接操作 DOM网页文档对象模型游戏画面是通过 Canvas画布来绘制的。这导致一个结果——你在浏览器里写一个网页游戏很简单但要让它在微信小游戏里跑起来需要做一层适配转换。大多数 AI 编程助手对普通 HTML/JavaScript 的熟悉程度远超过它对微信小游戏 API 的熟悉程度。如果你直接让 AI 写微信小游戏代码它会生成一堆wx.createCanvas、wx.createContext之类的调用但这些 API 的细节经常随着微信基础库的更新而变化AI 的知识库很容易滞后。而如果你先做 HTML5 版本AI 会把 99% 的精力放在游戏逻辑本身——碰撞检测、计分系统、动画帧循环——这些是核心也是 ChatGPT 最擅长的部分。我的最终技术方案是这样的开发语言JavaScript因为它是微信小游戏唯一原生支持的语言不需要转译原型阶段HTML5 Canvas在浏览器里直接把游戏逻辑跑通转换阶段基于微信小游戏适配层把浏览器 API 替换为微信小游戏 API开发工具微信开发者工具这是微信官方提供的 IDE用于预览、调试和上传代码如果你也是零基础我建议你把游戏玩法控制在三分钟以内能上手的休闲品类。我做的是类跳跃收集型小游戏玩家控制一个小方块在平台间跳跃收集金币躲避障碍物。这个品类逻辑简单没有复杂的物理引擎需求非常适合 AI 生成代码。3. 五天聊出一个 MVP我是怎么让 AI 理解需求的从开始到跑通一个可玩的 MVP我用了五天的下班时间。这五天里我几乎每天都在和 AI 对话前三天像是产品经理和研发的对谈后两天像是测试和开发的拉扯。3.1 第一天的核心动作写出一份人话版需求文档第一天我做的事情可能和你想的不太一样——我花了大半天时间写需求文档但这份文档不是给 AI 看的项目说明而是给 AI 的结构化描述。我发现和 AI 协作的第一条铁律是你说得越具体它写得越准确。我的第一版对话大概是这样请帮我用 JavaScript 写一个微信小游戏画布尺寸 375x667玩家是一个蓝色小方块可以通过点击屏幕跳跃从左边平台跳到右边平台每跳上一个平台得 1 分如果掉出底部就游戏结束。请用 Canvas 绘制所有元素保持代码在浏览器里可以直接运行。这个描述看起来很简单但里面包含了 AI 生成代码所必需的五个要素画布大小、核心玩法、交互方式、计分规则、结束条件。结果 AI 第一次生成的代码就能在浏览器里跑起来了画面很简单就是几个平台方块和一个小方块在跳。但体验很粗糙跳跃高度固定无法控制跳跃距离平台间距也是写死的。这时候我明白了一个事实——游戏体验不是 AI 凭空想出来的而是你通过需求迭代逼出来的。3.2 第二到三天的迭代把好游戏拆解成可描述的规则第二、三天我开始逐一细化体验。这里我分享一个关键思路不要对 AI 说优化手感要说把跳跃高度改成按屏幕点击时长变化。AI 听不懂抽象的美学描述但它能准确执行具体规则。我每天的迭代清单都会拆成几个具体的小任务要求跳跃力度等于点击屏幕的时长点击超过 0.5 秒按 0.5 秒计算平台间距从固定值改为随机范围但要确保有斜向跳台让你们有选路空间增加金币系统金币随机出现在平台上方碰到金币加 5 分画一个障碍物碰到障碍物游戏结束增加一个简单的分数显示用白色文字绘制在左上角这个过程中我踩了一个到现在都觉得无语的坑我以为 AI 生成的代码一定是前后一致的结果发现每轮对话它在修改一个功能时可能把之前已经好好的功能弄坏。比如第三轮我让它加障碍物它把平台的碰撞检测逻辑改得互相矛盾了导致方块直接穿透平台掉下去。一开始我很崩溃后来才悟到一个关键的协作习惯每次让 AI 修改代码前我都会让它先输出完整的新代码而不是只输出修改片段同时我会手动保存每个稳定版本的副本回退时直接把旧代码贴回去。这就像你在写文章时要频繁存稿因为 AI 不像人它不会记得自己上一版写过什么——它只会根据当前对话上下文继续发挥。3.3 第四到五天的测试驱动让 AI 自己找 Bug当游戏功能齐备后我还剩一个任务把游戏从能跑变成稳定不崩。这个过程我用了特殊的方法——让 AI 当测试员。我会把完整的代码复制到对话里然后要求这是目前完整的游戏代码请仔细阅读并找出所有会导致游戏崩溃或体验异常的问题比如数组越界、空对象访问、帧率不稳定、碰撞逻辑错误。有意思的是这种让 AI 审视自己代码的方式确实能找出不少问题。它发现了一个我在浏览器里完全没注意到的 Bug当方块速度过快时可能直接跳过一整块平台导致穿模穿透平台掉下去的情况。它的建议是增加一个连续碰撞检测的逻辑——在移动前先计算方块在这帧会移动到的位置再和平台做碰撞判断而不是每帧只判断当前坐标。这里我要插一个对于非游戏开发者特别重要的知识游戏循环是帧驱动的。每一帧通常是每秒 60 次代码会执行一次处理输入、更新位置、绘制画面。如果方块一帧移动了 10 像素而平台厚度只有 5 像素那么在某一帧里方块可能正好跨过平台——上一帧在平台上面下一帧已经在平台下面碰撞检测根本没机会触发。这就是穿模的本质原因。这个问题的解决方案是让碰撞检测不只是检查当前是否碰到而是检查移动路径上是否碰到。这条知识是我在 AI 提示下学会的但理解了原理后我后续修改碰撞逻辑就再也没出过问题。这就是 AI 协作的核心价值——它给你代码你负责理解它为什么这么写才能驾驭它。4. 转成微信小游戏版本适配层的核心原理和三大坑原型跑通后真正的挑战才开始。HTML5 游戏在浏览器里运行没有任何限制但微信小游戏运行在一个受限的环境中核心差异我总结为三点对应三大坑。4.1 坑一没有 DOM页面结构完全由 Canvas 接管在浏览器里你可以在 HTML 里写div标签来显示分数、按钮但在微信小游戏里没有 DOM 概念所有画面都必须绘制在 Canvas 上。这意味着我之前用 HTML 元素实现的 UI分数显示、开始按钮、结束提示要全部改成 Canvas 绘制。我手动改第一个 UI 元素时挨个找 AI 生成对应的绘制代码做得很痛苦。后来我学聪明了——在给 AI 的准备提示词里直接声明注意微信小游戏环境没有 document、window。所有 UI 文本必须用 ctx.fillText 绘制所有按钮要自己实现点击区域判断。加上这句话之后AI 生成的代码就规范了很多。它的启蒙知识是微信小游戏有 wx.createCanvas() 这类特有的 API不能直接用 document.getElementById。实际上微信小游戏确实提供了一套全局 APIwx.*是一整套微信 SDK包括触摸事件wx.onTouchStart、存储wx.setStorageSync、震动反馈wx.vibrateShort等。适配的关键就是把浏览器写法替换为这些微信 API。4.2 坑二触摸事件和鼠标事件是完全不同的逻辑HTML5 游戏在桌面浏览器里用鼠标事件click、mousedown在手机上用 touch 事件。但微信小游戏只提供触摸事件touchstart、touchmove、touchend并且不支持 mouse 事件。我的游戏是点击屏幕跳跃在浏览器里我让 AI 用的是canvas.addEventListener(click, ...)在微信里运行就完全没有响应。我花了整整一个晚上才找到原因——不是代码逻辑错了而是事件根本就没绑定上。解决办法也很简单把事件绑定换成wx.onTouchStart(function(e) { ... })。这里我额外分享一个细节微信小游戏的触摸事件 e 对象和浏览器触摸事件的结构有点差异它拿不出 clientX/clientY只能用e.touches[0].clientX。如果你直接在微信开发者工具里调试这个差异不会暴露得很明显但真机测试时会发现点击位置偏移。我在真机预览阶段就被这个坑害过后来统一用e.changedTouches[0].clientX才稳定了。4.3 坑三主包大小限制与静态资源配置微信小游戏主包体大小限制是 4MB包含 main.js 代码和所有本地资源文件。我的第一版游戏把所有图片、音效打包进去后直接超了 500KB。这样的问题不懂游戏打包的人真的很难注意到。解决方案有两个一是代码压缩混淆去掉空白字符和注释这个让 AI 帮我处理二是把静态资源放到 CDN内容分发网络上用远程加载替代本地打包——我这里用的是微信云开发就是微信官方提供的一个轻量后端先把图片传到云存储游戏启动时异步下载。这一步的代码实现我让 AI 写了一个资源加载管理器先加载一个清单文件清单里列出所有图片的远程 URL全部加载完毕后显示开始游戏按钮加载失败则重试 3 次。这个设计让我在上线初期规避了大量网络加载失败导致的崩溃。5. 备案那 27 天微信小游戏最容易被忽略的隐形门槛如果你以为小游戏写完代码就能立刻上线那你跟我一样天真了。从开发者工具上传代码到正式上线之间还隔着一道峡谷备案审核。这段经历是我整条路径里耗时最长、也最没有确定性的环节如果你也想做小游戏这部分一定得提前规划。微信小游戏备案全称叫微信小游戏内容备案是从 2024 年开始成为新上架小游戏的强制要求。没有备案号你的代码写得再好也传不到用户手机上。整个备案流程分为以下几步第一步在小程序后台注册你的 AppID就是你的游戏身份证完成开发者认证第二步提交小游戏基本信息包括游戏名称、游戏分类、游戏简介、视觉素材、隐私保护指引第三步提交主体信息个人开发者需提供身份证信息企业开发者需同步营业执照认证第四步等待审核这也是最消耗时间的一步我的备案时间线是这样的其中具体工作日和初审/复审耗时根据官方流程估算时间节点操作内容耗时第 1-2 天注册 AppID、下载微信开发者工具、完成个人认证2 天第 3-5 天准备备案材料包括游戏截图、简介、隐私说明3 天第 6 天提交备案申请1 天第 7-15 天平台初审约 9 个工作日第 16-26 天内容复审约 10 个工作日第 27 天备案号下发可进入提审阶段1 天其中每个环节的填写都有容易返工的地方我挑三个有代表性的说游戏名称名字不是随便起的一个是你不能用纯英文命名除非你有商标另一个是不能跟已有小游戏重名。我本来想用跳跳方块一查已经被占了。我花了整整一下午在取名——不能违规、不能重名、还要有点记忆点最后定了跳跳金币。游戏分类分类选错了直接导致审核被驳回。小游戏的分类里有很多细类比如休闲、动作、角色扮演、益智等。我一开始想选休闲因为它是最大众化的分类但提交时发现休闲需要勾选游戏玩法是否涉及随机抽取因为我的游戏里有金币掉落机制——虽然没有付费但平台判定这种随机掉落不属于概率玩法只要不是抽卡、开宝箱这类强随机付费机制就不用额外说明。最终我选了益智分类这个分类的审核要求相对宽松一些。隐私保护指引这个是最容易被个人开发者忽略的。微信要求游戏即使不涉及用户信息收集也必须提交一份隐私保护指引说明本游戏不收集任何用户信息。如果你偷懒不填后台会直接提示你隐私接口调用权限不足连真机预览都做不了。备案等待期的无聊和焦虑只有经历过的人懂。你无法催也看不到具体的审核进度只能干等。这 27 天实际上可以并行做很多事——我把这段时间用来做 UI 界面优化、增加游戏音效、写应用商店描述、准备上线素材。备案期间你以为自己啥也做不了其实能做的确定性的活儿非常多别傻等。6. 提审与过审非游戏开发者无从预料的细节规范备案号下来后我满心以为提审是走个流程。实际上我又被现实教育了一顿——提审阶段依然有各种看似不重要的细节规范稍不注意就被驳回。6.1 类目选择与资质要求游戏和普通小程序不一样游戏需要单独的游戏类目。个人主体可以发布的游戏类目有休闲、益智等但有几类游戏个人开发者不能碰棋牌类必须要求营业执照且有相关资质涉及虚拟支付的小游戏需要前置条件。如果你的游戏想做内购个人主体通常是不行的——个人主体的小游戏不能开通虚拟支付只能通过广告变现这类方式。这个我提前查过所以我的 MVP 只做了激励视频广告看完广告复活一次绕开了支付限制。6.2 审核人员到底在意什么第一次提审被驳回时反馈意见写了三条每一条都是我没想过的问题游戏截图需包含网络加载界面的截图——意思是你的游戏如果启动时有加载过程素材里必须包含这个加载界面的截图请补充游戏说明说明中需描述游戏玩法、操控方式、元素含义——听起来很蠢但其实审核人员拿到一个陌生的游戏确实需要通过你的说明来确认这个游戏没有违规内容提示游戏英文内容需提供中文对照——我的游戏分数显示用了 SCORE 英文平台要求界面文字必须中文或提供中英对照这第三条把我逗乐了但也提醒我一件事微信小游戏的审核规则里对内容本地化的要求比一般小程序更严格。我后来把 SCORE 改成了分数并顺手把所有界面文字统一成了中文。6.3 代码上传与版本管理提审前最后一个技术细节是版本号管理。微信开发者工具上传代码时需要填一个项目版本号必须符合类似 的格式三段式而且每次提审提交的版本号必须比上一次大。这个看起来微不足道的细节我在第二次提交时因为忘了改版本号被后台直接拒绝——系统不会提示你版本号重复它只会告诉你提交失败请检查版本信息。提审后正常审核时长是 1-7 个工作日。我的版本在提交后第二天就显示审核通过相比备案的 27 天这个速度让我觉得很惊喜。但审核通过不等于线上可用——你还需要在后台操作发布并且设置小游戏的正式版本体验范围。7. 上线后的真实数据与运维一个 MVP 的生命周期上线比想象中的平淡但也比想象中的复杂。我用 MVP 上线后的头两周做了几件事第一是数据埋点。我让 AI 在游戏代码里加了一套非常简单的数据上报逻辑启动时有 launch 事件游戏结束时上报 Playtime游戏时长和 Score得分点击广告复活时有 revive 事件。这套数据通过微信小程序后台的数据助手接口上报我在后台能看到 DAU日活跃用户数、次日留存率、人均游戏时长这些核心指标。第二是真机兼容测试。微信开发者工具里的模拟器跑得再流畅换到真机上也会暴露问题。我最明显的一个体验是iPhone 的刘海屏对全面屏的适配很糟糕。我的画布是固定的 375x667在 iPhone 13 上实际显示偏小而且底部有小黑条。我用微信提供的wx.getSystemInfoSync()接口读取了屏幕实际宽度和高度动态计算了画布缩放比例并且让游戏适配了安全区域safeArea才算基本解决。第三是iOS vs Android 差异。同一个游戏Android 端的帧率明显比 iPhone 端低——因为这个游戏的碰撞检测逻辑里频繁使用的Math.sqrt函数在低端 Android 机上性能压力太大。AI 的建议是把开方运算改成平方比较也就是把distance 50改成distanceSquare 2500省掉一次开方。这个优化在上线后明显提升了 Android 端的流畅度。上线两周的数据不算好也不算坏累计 DAU 峰值 480次日留存率约 18%人均游戏时长 2 分钟出头。作为零成本冷启动的 MVP这个数据已经能说明问题游戏玩法没有社交裂变属性纯粹靠自然流量是起不来的。我的收获不在于数据本身而在于我终于跑通了一个非游戏开发者从零到上线的完整闭环。后续我的迭代计划是加上排行榜功能用微信开放数据域实现因为排行榜是小游戏天然的社交钩子再做一个每日挑战限时关卡来提升次日留存。这两件事里排行榜的开放数据域 API 需要单独适配每日挑战则纯粹是玩法配置都可以继续用 AI 辅助完成。最后聊几句实在的整个项目从启动到上线前后一共 40 天左右真正花掉的现金成本只有指纹认证的 30 元认证费和少量云资源费用。备案那 27 天如果算进去这确实是一个慢启动的过程但如果你做好了心理准备一次性跑通全流程的价值非常大——因为你知道这条路长什么样了第二次、第三次只会越来越快。最后分享一个我自己的切身体会AI 最擅长的不是你让它做一个好游戏而是你给它非常具体的小任务。每当我试图让 AI 一次完成太多事情结果往往是一段连我自己都看不懂的混乱代码当我冷静下来把事情拆成调整跳跃高度增加一个音效修复碰撞 bug这样的小任务时AI 的表现几乎从不让我失望。这不是什么高深的方法论而是和 AI 相处就像带新人你交代得越细它干得越靠谱。希望我的这份完整实录能帮后来者少走几个同样的弯路。