1. 一个不会写游戏的人怎么把微信小游戏从聊天框里抠出来先说结论我做了个微信小游戏全程没写过一行游戏引擎代码核心玩法逻辑是跟 AI 一句一句聊出来的从有想法到提交审核花了大概两周但备案卡了 27 天。这篇文章不讲虚的把整个链路——怎么用 AI 聊出 MVP、微信开发者工具怎么配、备案为什么慢、哪些坑我替你踩过了——全部摊开讲。如果你是不会游戏开发的普通开发者或者产品、运营想自己搓个小游戏验证想法又或者你只是想搞清楚微信小游戏到底能不能一个人搞出来这篇应该能省你不少时间。我不聊 Unity 打包那套重流程也不聊什么宏大叙事就讲一个非游戏开发者用 AI 辅助、在微信生态里把东西真正跑起来的过程。需要提前说明的是我不是科班游戏开发主业偏后端和工具类开发对渲染、物理引擎、帧同步这些概念只有模糊认知。所以我的路径注定跟游戏行业的人不一样——他们从引擎出发我从能跑起来的最小闭环出发。这个差异后面会反复体现也是我觉得对同类开发者最有参考价值的地方。整个项目我给它起了个内部代号叫聊天出 MVP因为它的核心玩法逻辑、状态机、甚至部分 UI 文案都是我在跟 AI 的对话里逐步收敛出来的。下面按真实时间线拆但重点放在为什么这么做和哪里会翻车上。2. 用 AI 聊出 MVP从一句话需求到可运行原型2.1 为什么我选择聊而不是画原型大多数人做小游戏的第一步是画原型图、写策划案然后找引擎。我反着来原因很实际我不会画图也不确定玩法到底好不好玩。策划案写得再漂亮做出来不好玩就是白费。所以我需要一个能快速验证这个玩法有没有意思的路径。AI 在这里的价值不是帮你写代码而是帮你把模糊的想法逼成具体的规则。我一开始只有一句话我想做一个基于聊天记录的解谜小游戏。这句话根本没法落地因为聊天记录和解谜之间有无数种组合方式。我就开始跟 AI 对话让它不断追问细节玩家看到的是什么操作是什么失败条件是什么一局多长这个过程大概持续了两三个小时来回几十轮。最后收敛出来的核心循环是玩家看到一段被打乱的对话需要通过选择不同的回复分支还原出对话原本的逻辑顺序。规则简单到一句话能说清但又有解谜的乐趣。这就是 MVP 该有的样子——规则简单、能验证、能快速做出来。提示跟 AI 聊玩法时别问帮我设计一个游戏要问如果玩家只能做 A 和 B 两个操作这个玩法还成立吗。把开放问题逼成封闭问题AI 才能给你可落地的答案。2.2 把玩法规则翻译成状态机玩法确定后下一步是把它变成代码能理解的结构。这里我用了一个笨但有效的办法让 AI 帮我把玩法写成状态机。状态机说白了就是现在处于什么状态、玩家做了什么、下一步跳到哪个状态。我当时的对话大概是这样的我把玩法用大白话描述一遍然后让 AI 输出一个状态列表每个状态包含进入条件、可执行操作、退出条件。AI 第一版给的状态有十几个太碎了我砍到五个核心状态。砍的过程也是跟 AI 讨论的问它这个状态能不能合并到上一个它会给理由我再判断。这一步的产出不是代码而是一张状态转移表。这张表后来直接变成了我写逻辑的骨架。我强烈建议非游戏开发者都走这一步因为游戏逻辑的本质就是状态转移你把这个理清楚写代码就是填空。状态进入条件玩家操作退出条件展示对话关卡开始阅读点击开始选择选择分支展示完成选择回复选中某一项判定结果选择完成无判定完成反馈动画判定完成无动画结束结算反馈结束重开/下一关玩家点击这张表看起来简单但它帮我省掉了后面大量的返工。因为一旦状态定义清楚AI 生成的代码就不会跑偏。2.3 AI 生成代码的边界哪些能信哪些必须自己改这里必须泼一盆冷水。AI 生成的游戏逻辑代码能跑但坑很多。我实测下来AI 在纯逻辑、无副作用的部分表现很好比如状态转移判断、分数计算、关卡数据解析。但一旦涉及微信小游戏的运行时 API比如wx.createCanvas、触摸事件、生命周期AI 给的代码经常是看起来对但跑不起来。原因很简单微信小游戏的 API 更新频繁AI 的训练数据里混着旧版本写法。我踩的第一个坑就是 AI 给的触摸事件绑定方式在新版基础库里已经废弃了报错信息还很隐晦。后来我养成习惯凡是涉及微信 API 的代码一律去官方文档核对AI 只用来生成逻辑骨架。所以我的分工是AI 写逻辑我写胶水。逻辑部分状态机、判定、数据让 AI 生成我再改跟微信运行时打交道的部分渲染、事件、存储我自己写或者至少逐行核对。这个分工让我的返工率大幅下降。3. 微信开发者工具里那些没人告诉你的配置细节3.1 项目初始化选对模板比什么都重要微信开发者工具新建小游戏项目时会让你选模板。我一开始选了个官方示例结果里面塞了一堆我用不上的东西删起来比新建还麻烦。后来我改用空项目从零开始加文件反而清爽。这里有个细节小游戏的目录结构和普通小程序不一样。小游戏没有 WXML/WXSS入口是game.js配置文件是game.json。如果你按小程序的思路去建目录工具会各种报错。我建议第一次做的人先花十分钟把官方文档里小游戏目录结构那一页看完能省掉后面一堆莫名其妙的报错。game.json里我改过的关键配置就两个deviceOrientation设成portrait竖屏showStatusBar设成false不显示状态栏。其他保持默认。别小看这两个竖屏还是横屏直接决定你后面所有坐标计算的方式改晚了要重写布局。3.2 真机调试和发给别人试用的正确姿势开发阶段在模拟器里跑没问题但真机一跑就露馅。我第一次真机调试发现触摸坐标全偏了原因是模拟器和真机的像素比不一样。解决办法是用wx.getSystemInfoSync()拿到pixelRatio所有坐标计算都乘这个系数。这个坑我卡了大半天。至于怎么发给别人试用收集反馈这是热词里很多人问的。微信开发者工具里有个预览功能生成二维码扫码就能在手机上跑。但注意这个二维码只有开发者本人和体验成员能扫。要让别人试用你得在微信公众平台的成员管理里把人加为体验成员上限是 15 个人不同账号类型可能不同以平台实际显示为准。我当时的做法是先加 5 个体验成员发预览二维码让他们玩两天收集反馈。反馈渠道我用的是最土的办法——拉个群让他们直接截图发问题。别搞什么问卷小游戏验证阶段能让人愿意玩两把就不错了问卷没人填。注意预览二维码有有效期过期要重新生成。而且体验成员必须用绑定了微信的账号没绑定的扫了也进不去。3.3 基础库版本一个被严重低估的坑微信小游戏依赖基础库运行不同版本的微信客户端支持的基础库版本不同。我开发时用的是最新基础库本地跑得好好的结果一个体验成员用的是旧版微信直接白屏。解决办法是在game.json里设置minPlatformVersion声明你要求的最低基础库版本。但设太高老用户进不来设太低你用的新 API 又不支持。我的策略是查一下目标用户群体的微信版本分布平台后台有数据取一个覆盖 90% 以上用户的版本作为最低要求。这个坑的教训是本地能跑不等于用户能跑。上线前一定要找几个不同机型、不同微信版本的人实测别只用自己的手机。4. 备案 27 天流程、卡点和我的真实时间线4.1 为什么小游戏也要备案这是很多人没意识到的问题。微信小游戏如果涉及用户交互、内容发布是需要做相关备案的。我一开始以为小游戏不用备案结果提交审核时被打回来要求先完成备案。这一卡就是 27 天。备案的本质是让你的内容主体可追溯。流程上你需要在微信公众平台提交主体信息、内容说明等材料然后等待审核。审核周期官方说法是几个工作日到二十个工作日不等实际我遇到的是 27 天中间还补过一次材料。4.2 我的 27 天时间线拆解我把这 27 天拆开讲让你有个心理预期第 1-3 天准备材料。主体证明、内容说明、功能截图。这里最容易卡的是内容说明要写清楚你的小游戏做什么、有没有用户生成内容、有没有社交功能。我第一版写得太简单被打回。第 4-10 天首次提交等待初审。这期间没有任何反馈就是等。第 11-15 天收到补材料通知。要求补充内容审核机制的说明。我又花了两天写材料重新提交。第 16-27 天二次审核通过。整个过程最折磨人的是没有进度条。你只能等而且不知道卡在哪。我的建议是备案材料一次写全尤其是内容审核机制、用户举报入口这些宁可写详细也别偷懒。补一次材料就是一周起步。4.3 备案期间能做什么别干等27 天不能白等。我在这期间做了几件事一是把玩法又打磨了两轮加了三个关卡二是把代码里的硬编码数据抽成了配置文件方便后面调数值三是找了几个朋友做小范围测试收集了一堆 bug。这里有个经验备案期间不要改主体信息否则可能触发重新审核。玩法、代码随便改但主体相关的别动。我有个朋友就是备案期间改了主体名称结果重新排队多等了两周。5. 上线前的自测清单和几个真实翻车现场5.1 我踩过的三个典型坑第一个坑是音频资源加载。小游戏里音频要用wx.createInnerAudioContext()我一开始把音频文件放在本地结果包体超了。小游戏主包有大小限制音频、图片这些资源要么压缩要么放远程。我最后把音频压到 64kbps图片用 WebP包体才降下来。第二个坑是触摸事件穿透。我的 UI 有层叠的按钮结果点击上层按钮时下层也响应了。原因是触摸事件没有正确拦截。解决办法是在上层按钮的事件处理里return掉或者用wx.onTouchStart时判断点击区域。这个坑很隐蔽因为模拟器里不一定复现真机上才明显。第三个坑是数据存储。我用wx.setStorageSync存玩家进度本地测试没问题。结果有用户反馈进度丢失。排查后发现是存储空间满了setStorageSync静默失败。后来我加了 try-catch并在存储前检查剩余空间。小游戏的本地存储上限不大别存太多东西。5.2 上线前的自测清单我整理了一份自己用的自测清单分享出来检查项检查方法常见问题不同机型适配至少 3 台不同分辨率手机坐标偏移、UI 错位不同微信版本找旧版本微信用户测试白屏、API 不支持弱网环境开飞行模式再恢复资源加载失败无提示存储边界反复存大量数据静默失败、进度丢失音频中断来电、切后台音频不恢复、卡死分享功能实际分享给好友分享卡片无图、链接失效这份清单帮我拦住了至少五个上线后才会暴露的问题。尤其是弱网和音频中断模拟器里根本测不出来。5.3 审核被拒的常见原因我提交审核被拒过一次原因是功能不完整。具体是我有个按钮点了没反应因为那个功能还没做完我忘了隐藏。审核员会实际点你的游戏任何死链、无响应都会被记。其他常见被拒原因内容说明与实际功能不符、有诱导分享、有未声明的用户数据收集。我的建议是提交前自己完整玩一遍把所有按钮都点一遍别留半成品。6. 非游戏开发者做小游戏我的真实体会6.1 AI 能帮你到什么程度不能帮你什么回过头看AI 在这个项目里的作用被我用到了极致但也有明确的边界。它能帮我把想法结构化、生成逻辑代码、解释报错、提供排查思路。但它不能替我做决策——玩法好不好玩、这个坑值不值得填、要不要砍功能这些都得自己判断。我最大的体会是AI 是个极好的副驾驶但你得自己握方向盘。你越清楚自己要什么AI 越有用。你越模糊AI 给你的东西越像正确的废话。6.2 一个人做小游戏最难的不是技术技术上的问题查文档、问 AI、搜社区基本都能解决。真正难的是节奏管理。备案 27 天、审核被拒、真机 bug这些都会消磨你的耐心。我中间有两次想放弃一次是备案补材料一次是音频包体超限。撑下来的方法很土把大目标拆成每天能完成的小任务。今天只解决触摸穿透明天只压音频。完成一个划掉一个看着清单变短就有继续的动力。6.3 给同类开发者的几条实在建议第一先做能跑的最小闭环别一上来就追求完整。我的第一版只有一关但能玩、能分享、能收集反馈这就够了。第二微信 API 相关的代码永远以官方文档为准AI 的话只能参考。我在这上面吃的亏最多。第三备案要趁早。你代码写到一半就可以开始准备备案材料了别等做完才想起来那 27 天足够你把玩法再打磨两轮。第四别怕丑。我的第一版 UI 就是纯色块加文字没有任何美术。但体验成员照样玩得下去因为玩法本身有意思。美术是后面的事验证阶段别在美术上浪费时间。最后分享一个小技巧微信开发者工具的性能面板能看帧率和内存上线前跑一遍如果帧率掉到 30 以下大概率是渲染或逻辑有问题早点优化比上线后被骂强。这个面板很多人不知道但真的有用。