1. 一个不会写游戏的人怎么用 AI 把微信小游戏推到上线先说结论我本职是做后端和数据处理游戏开发经验基本为零Unity 只在大学时打开过一次就关了。但过去一个多月我完整走完了一个微信小游戏从想法到提审的全流程代码有相当一部分是 AI 帮我写的中间经历了备案卡壳、包体超限、真机白屏、审核驳回最后在提交备案后第 27 天拿到了通过结果。这篇东西不是教程更像一份流水账加复盘。我会把每个阶段我实际做了什么、为什么这么做、AI 在哪些环节真帮上忙、哪些环节纯属帮倒忙全部摊开讲。如果你也是非游戏背景想用 AI 辅助做一个能上线的微信小游戏这篇应该能帮你少走至少两周弯路。核心链路其实就四段用聊天把 MVP 聊出来 → 用微信开发者工具把工程跑起来 → 处理备案和资质 → 真机调试与提审。听起来简单但每一段都有坑而且坑的位置往往和你预想的完全不一样。下面按这个顺序拆。2. 用聊天把 MVP 聊出来AI 协作的真实边界2.1 为什么我选择聊天式开发而不是直接让 AI 写完整项目一开始我也想过让 AI 直接吐一个完整的小游戏工程出来试了两次就放弃了。原因很现实AI 生成的完整项目代码结构看着漂亮但依赖版本、构建配置、平台 API 全是看起来对的状态你根本不知道哪一行会在真机上炸。对于没有游戏开发经验的人来说调试一个 AI 生成的完整工程比自己从零搭还痛苦。所以我换了个思路把 AI 当成一个随时在线的技术顾问而不是代码生成器。我先用自然语言把玩法描述清楚让它帮我拆成模块再一个模块一个模块地聊实现方案最后才让它写具体代码。这个顺序很关键因为拆模块的过程本身就是你在理解这个游戏的过程。我做的游戏很简单就是一个基于点击和计时的休闲玩法核心循环不超过三个状态。选这个方向不是因为它好玩而是因为MVP 的第一原则是能跑通全流程不是好玩。你要验证的是备案能不能过、包体能不能压下来、真机能不能跑玩法复杂度在这个阶段是负资产。2.2 我是怎么跟 AI 描述需求的这里有个很实用的技巧不要用帮我做一个游戏这种话开头。我实际用的开场是这样的我要做一个微信小游戏玩法是屏幕上有一个目标物玩家点击后目标物消失并在随机位置重新出现每次点击得分30 秒倒计时结束后显示总分。请帮我拆成几个模块并说明每个模块用什么技术实现最省事。注意最后那句用什么技术实现最省事。这句话会逼着 AI 从教科书方案切换到工程实用方案。我第一次问的时候它给我推荐了一堆游戏引擎和物理系统加上最省事之后它直接建议用微信小游戏原生 Canvas 2D API不引入任何引擎。这个建议后来证明是对的——引擎会带来包体膨胀和构建复杂度对一个点击游戏来说完全是杀鸡用牛刀。模块拆出来大概是四块渲染层Canvas 绘制、状态管理分数、倒计时、游戏状态、输入处理触摸事件、数据持久化最高分存储。每块我都单独和 AI 聊了一轮实现细节重点问这个 API 在微信小游戏环境里有什么限制。2.3 AI 在 MVP 阶段真正帮上忙的地方说几个具体的。第一是API 用法查询。微信小游戏的 API 文档虽然全但对新手不友好很多参数的实际行为要踩过才知道。我直接问 AIwx.createCanvas 在小游戏里和普通 H5 有什么区别它给出的回答里有一条很关键小游戏环境没有 DOM所有 H5 里习惯用的 document 操作全部不可用。这一条如果我自己去文档里翻可能要翻半小时。第二是代码骨架生成。状态管理那块我完全没思路AI 给了一个基于简单状态机的写法我改了几个变量名就直接用了。第三是边界情况提醒。比如它主动提到倒计时结束时如果玩家正在点击要防止重复触发结算这种细节新手根本想不到。但 AI 也有明显帮倒忙的时候。它生成的触摸事件处理代码用了 H5 的写法在真机上完全没反应它推荐的某个存储 API 在小游戏里需要额外权限声明文档里藏得很深。所以我的经验是AI 给的代码必须当成草稿每一行都要在真机上验证尤其是涉及平台 API 的部分。2.4 MVP 阶段我踩的第一个大坑坑出在我以为 MVP 就是随便做做。我第一版做出来功能确实能跑但代码里到处是硬编码的坐标和尺寸。结果换一台分辨率不同的手机测试整个画面全乱了。后来花了大半天把所有坐标改成基于屏幕宽高的比例计算才解决。这个坑的教训是MVP 可以功能简单但架构不能偷懒。分辨率适配、状态边界、异常处理这三样哪怕功能再简单也要一开始就做对否则后面改起来比重写还累。AI 在这件事上帮不了你因为它不知道你的目标机型是什么你得自己定。3. 微信开发者工具从工程跑起来到真机预览3.1 工具入口和项目初始化微信开发者工具的入口就是官方下载页装完之后用微信扫码登录。新建项目的时候有个关键选择项目类型要选小游戏不是小程序。这两个的工程结构和 API 完全不同选错了后面全得重来。我第一遍就选错了建完发现目录结构不对删了重建。初始化之后工具会生成一个基础工程包含 game.js、game.json、project.config.json 这几个核心文件。game.json 是配置文件里面控制屏幕方向、网络超时这些project.config.json 是项目配置appid 就在这里填。appid 需要你先在微信公众平台注册一个小游戏账号才能拿到这一步没有捷径必须提前做。3.2 把 AI 写的代码接进工程AI 给我的代码是零散的模块我需要把它们组织成小游戏能识别的结构。小游戏的入口是 game.js所有逻辑最终都要从这里被引用到。我的做法是建一个 src 目录放业务代码game.js 里只做初始化和模块加载。这里有个细节小游戏支持 CommonJS 的 require但不支持 ES Module 的 import。AI 默认生成的代码经常用 import直接粘进去会报错。我后来养成了习惯每次让 AI 写代码都加一句用 CommonJS 写法省得自己改。接进去之后第一次在工具里点编译报了一堆错。大部分是路径问题小部分是 API 不存在。排查的时候我发现工具的控制台信息其实挺全的报错会直接指到行号比我想象中好用。新手容易犯的错是看到报错就慌其实一条一条读大部分都是拼写和路径问题。3.3 真机预览从能编译到能玩的距离工具里能跑不代表真机能跑这是我踩的第二个大坑。工具里一切正常扫码真机预览直接白屏。排查过程很折磨最后定位到两个原因一是某个 API 在工具里有兼容层真机上没有二是我用了工具环境里默认存在的某个全局变量真机上根本不存在。解决白屏的通用思路是二分法加日志。我把代码从入口开始一段一段注释掉看哪一段注释后白屏消失逐步缩小范围。同时在关键节点加 console.log真机预览时可以在工具的真机调试面板看到日志输出。这个方法笨但有效我大概花了两个小时定位到问题。真机预览还有个实用功能是预览和真机调试的区别。预览是生成一个二维码扫码就能在手机上打开适合快速验证真机调试会建立调试连接能在电脑上看到手机端的日志和性能数据适合排查问题。日常验证用预览出问题用真机调试这个分工能省很多时间。3.4 怎么把版本发给别人试用收集反馈这一步标题里也提到了我实际的操作是这样的在开发者工具里点上传填一个版本号和备注代码就传到微信后台了。然后在公众平台的版本管理里把这个版本设为体验版生成体验版二维码。把二维码发给指定的人对方扫码就能玩不需要审核。体验版有个限制体验成员需要在后台手动添加最多加几十个人。我加了大概十个朋友让他们玩了两天收集到的反馈里最有价值的是某个按钮在全面屏手机上被挡住了和玩到第三关会卡一下。这两个问题我自己测试时完全没发现因为我的手机不是全面屏而且我玩得太熟练没触发那个卡顿路径。收集反馈的时候我建议做个简单的表格让测试的人填机型、系统版本、遇到的问题、复现步骤。口头反馈很容易漏细节尤其是机型相关的 bug没有机型信息根本没法复现。4. 备案 27 天流程、材料和那些没人告诉你的细节4.1 备案为什么是最大的时间变量技术问题再难熬几个通宵总能解决。备案不行它是纯等待而且等待期间你什么都做不了。我提交备案到通过用了 27 天这期间我查了很多资料发现时间波动很大有人两周就过了有人一个多月。所以如果你的项目有时间要求备案必须最早启动最好在写第一行代码之前就开始准备材料。备案的前提是你得先有一个注册好的小游戏账号账号本身需要主体资质。个人主体和企业主体的流程不一样我走的是个人主体材料相对简单但可选的类目也少。这里有个关键点小游戏的类目选择会直接影响备案能不能过选错了会被驳回重来一来一回又是好几天。4.2 我准备的材料清单和踩的坑个人主体备案需要的核心材料大概是身份信息、账号信息、游戏的基本介绍、以及一份承诺说明。听起来不多但每一项都有格式要求。我踩的坑主要在游戏介绍这一项第一版写得太简单被驳回了理由是描述不清晰无法判断内容。后来我重新写把玩法、目标用户、内容特点都写清楚特别强调了无社交功能、无用户生成内容、无付费。这几句话很关键因为审核方最关心的就是你的内容会不会有风险。主动说明你的游戏没有什么比强调有什么更能加快审核。还有一个坑是游戏名称。我一开始起的名字里带了一个比较通用的词结果和已有游戏重名了被要求改名。改名又涉及账号信息变更又是一轮等待。所以起名之前一定要在微信里搜一下确认没有重名再定。4.3 27 天里我做了什么等待备案的 27 天我没有干等而是把能做的事全做了。第一是继续打磨游戏把体验版发给更多人测试收集了第二轮反馈。第二是准备提审材料包括游戏截图、玩法说明、类目证明这些。第三是研究审核规则把可能被驳回的点提前改掉。这里有个经验备案和提审是两条线可以并行准备。备案通过之前不能正式提审但提审需要的材料可以提前弄好备案一通过立刻提交能省几天。我当时就是备案通过的当天下午就提交了提审第二天就进入审核了。4.4 备案通过后的第一件事备案通过后账号状态会变成已备案这时候才能提交审核。我第一次提审被驳回了理由是游戏内容与备案描述不符。原因是我在备案之后又加了一个小功能虽然很小但审核方认为和备案时描述的不一致。这个坑很典型备案之后尽量不要改功能尤其是涉及玩法核心的改动。如果非要改改完要重新评估是否需要更新备案信息。我最后的做法是把那个功能删了保持和备案描述一致第二次提审就过了。5. 提审、驳回与上线最后的临门一脚5.1 提审材料怎么准备才不容易被驳回提审要填的东西比我想象中多游戏名称、图标、截图、简介、类目、以及一份内容说明。截图有尺寸要求图标有格式要求简介有字数限制。我第一次提交的时候截图尺寸不对直接被系统拦下来了连人工审核都没到。截图建议用真机截图不要用开发者工具的模拟器截图。模拟器的截图分辨率不对而且有些渲染效果和真机不一样。我后来是用真机预览然后用手机自带的截图功能截的尺寸刚好符合要求。简介的写法也有讲究。我第一版写得太营销用了很多夸张的词被驳回了。后来改成平实的描述只说玩法是什么、怎么玩、有什么特点就过了。审核方要的是准确描述不是广告文案。5.2 被驳回的常见原因和应对我总共被驳回过两次加上备案那次算是三次。除了前面说的内容与备案不符还有一次是图标不清晰。图标这个坑很隐蔽我用的图标是自己用工具生成的看着挺清楚但审核方认为分辨率不够。后来我重新做了一个更高分辨率的就过了。常见的驳回原因我整理了一下大概有这几类内容与描述不符、图标或截图不合规、类目选择错误、名称违规、以及功能不完整。功能不完整这条要特别注意如果你的游戏有明显的半成品感比如某个按钮点了没反应会被判定为功能不完整。所以提审前一定要自己完整玩一遍把所有能点的都点一遍。5.3 上线后的第一周上线之后我每天看后台数据发现一个有意思的现象大部分用户在前 30 秒就流失了。这个数据让我意识到MVP 阶段我关注的是能不能跑但用户关注的是好不好玩。这两件事完全是两回事。不过这不代表 MVP 的思路错了。恰恰相反正是因为 MVP 阶段把技术问题都解决了上线后我才能快速迭代玩法。如果上线后还在修白屏 bug根本没精力管留存。所以我的体会是MVP 解决的是能不能上线上线后才开始解决能不能留住人这两个阶段的目标不能混。6. 复盘AI 辅助开发微信小游戏的真实经验6.1 AI 在哪些环节真的省了时间按省时程度排序第一是API 用法查询尤其是那些文档里写得含糊、需要实际试错才知道的参数。第二是代码骨架生成状态管理、事件处理这些模板化的代码AI 写得比我快也比我对。第三是边界情况提醒它能在你没想到的地方提醒你这里可能会出问题。但 AI 在平台特定配置上基本帮不上忙比如 game.json 的字段、备案的流程、审核的规则这些它要么不知道要么给的是过时信息。这部分只能靠官方文档和实际踩坑。6.2 非游戏开发者做小游戏的真实门槛门槛不在编程在平台规则。编程部分有 AI 辅助一个有点编程基础的人都能搞定。但备案、类目、审核这些规则没有任何捷径只能一条一条读、一次一次试。我花在规则上的时间比花在代码上的时间多得多。另一个门槛是耐心。备案 27 天驳回两次真机调试两小时这些都需要耐心。如果你指望一周做完上线大概率会失望。把预期放到一个月以上心态会好很多。6.3 如果重来一次我会怎么调整第一备案最早启动在写代码之前就把材料准备好提交。第二MVP 阶段就把分辨率适配做对不要留到后面改。第三提审前用真机完整玩三遍把所有能点的都点一遍。第四不要在上线前改功能保持和备案描述一致。最后分享一个小技巧微信开发者工具里有个性能面板能看到帧率和内存占用。我上线前用它发现了一个内存泄漏是某个定时器没有正确清除。这个问题在真机上表现为玩久了会卡但短时间测试发现不了。上线前跑一次长时间测试用性能面板盯着内存曲线能提前发现很多问题。这个项目后续我打算做的是把玩法再打磨一下重点解决前 30 秒流失的问题。具体方向是加一个更明确的新手引导让用户一进来就知道要干什么。这个改动不涉及备案可以直接迭代。等留存数据好一点再考虑要不要加更多内容。