先说结论我一个写文案出身、连 Unity 都没装过的人用 AI 聊天的方式在白天上班、晚上带娃的间隙里做了一款能通过微信审核并上线的微信小游戏。从正式动工到 MVP 可用大概花了两周从提交备案到备案通过整整 27 天。这中间踩的坑比大部分教程里写的都多也比“AI 替你写代码”这句话轻描淡写得残酷得多。如果你和我一样不是游戏开发者甚至不是程序员但对微信小游戏这个方向有想法想借 AI 把门槛压下来这篇文章就是给你写的。我会把从立项、用 AI 聊出 MVP、准备备案材料、反复被驳回到最终上线的全过程拆开讲包括每一次因为什么被拒、AI 在哪些地方胡说八道、以及教程不会明说的隐藏规则。先交代一下我的背景方便你对照参考我熟悉产品逻辑和文案写过一点 SQL但没写过正经代码对 Canvas、碰撞检测、渲染管线这些概念只停留在“听说过”的层面。我的全部开发能力几乎都建立在和 AI 的对话之上。所以这篇实录不会跟你讲算法复杂度也不会教你重构代码它讲的是一套“非开发者如何用对了方法让 AI 替你把事办了”的完整路径。1. 起点选择与目标定义我凭什么敢碰微信小游戏1.1 为什么不是 App不是抖音小游戏而是微信小游戏很多人听到“做游戏”第一反应是 Steam 或 App Store但对我这种没有团队、没有资金背景的个体来说那两条路从第一天起就是死路。我花了一周时间对比了几个方向最后选择微信小游戏核心考虑是三点用户不用额外下载点开就能玩传播路径最短微信开放个人开发者主体允许个人注册和提审小游戏包体小、逻辑相对简单非常适合 AI 辅助开发。具体对比逻辑见下表方向流量获取开发门槛个人开发者友好度我的判断App需要应用商店曝光获客成本高高需要原生或跨端开发一般审核严格、物料多不选抖音小游戏平台流量大但分发给个人较小中等有类似的小游戏生态中等爆款需要内容运营能力暂缓微信小游戏社交裂变强群聊和好友路径天然低Canvas JS 即可起步高明确支持个人主体选定我当时的判断依据是微信小游戏看似竞争激烈但休闲小游戏的用户基数摆在那里只要玩法清晰、体验流畅小而美的项目依然有机会。这个赛道对个人开发者唯一的真实门槛是“完成上线流程”而流程本身是可以通过准备和踩坑学会的。1.2 什么才是真的 MVP先把验收标准定好第一次接触“AI 编程”的人最容易犯的错是上来就对 AI 说“帮我做一个游戏”。这句话约等于没有需求。AI 会给你一个看似完整、实际跑不动的代码堆然后你陷入“不知道哪里错了、怎么问都说不清”的泥潭。我给自己定的 MVP 是玩家能进入游戏并且不需要任何说明就明白核心玩法核心循环完整开始游戏 → 操作角色 → 获得结算 → 可以重新开始不设置账号体系不收集任何个人信息能在微信开发者工具中正常跑通使用 Canvas 2D 渲染不依赖任何第三方库和游戏引擎。这些边界条件非常重要因为它们直接决定了 AI 对话的失控概率。你把边界说得越清楚AI 给出的代码越收敛边界模糊AI 就会自作主张帮你引入 npm 包、帮你加数据库、帮你写一堆你用不上的功能。1.3 为什么 AI 是这个方案的最优解而不是“学习编程”这里我得说点反直觉的经验。作为非开发者我最大的优势恰恰是“不会写代码”。原因很简单AI 生成代码有很强的不确定性它会给出“能跑”但不一定“优雅”的写法。如果你懂编程你会忍不住想重构、想优化、想自己改但我不懂所以我只会做一件事复制、运行、报错、把报错信息贴回给 AI。这种笨办法在 MVP 阶段反而非常高效。AI 对我起到了三个作用翻译官把我用大白话描述的玩法翻译成 Canvas 绘制指令调试助手我只需要把截图或报错日志粘回去它就能定位问题私人讲师每当遇到“相对坐标”“碰撞检测”这类概念我直接问它它会用类比讲清楚。所以这条路走得通不是因为我聪明而是因为我把自己的位置摆对了AI 是执行者我是验收者AI 负责怎么实现我负责判断结果对不对。2. 把需求“聊”成代码非开发者的 AI 结对流程2.1 工具选型我不需要编辑器我需要一个会聊天的搭档我的软件栈非常朴素一个代码生成能力较强的对话模型 VS Code 微信开发者工具。没有复杂脚手架没有本地环境配置。AI 方面我并没有只押注一个模型。主力模型负责最重的代码生成因为它对长上下文的记忆更好能记得我们前面约定过的文件名和函数名同时我会用另一个模型做交叉验证——同一个问题用两个模型各问一遍如果答案差异很大说明我的需求描述有歧义需要重新表达。VS Code 在我这里只当文件管理器用打开项目文件夹、全局搜索关键词、偶尔根据 AI 的指示把某段代码删掉。微信开发者工具则是真实验收的地方我会在里面编译预览、看报错、切到真机调试。这套组合不需要花钱买额外的 AI 编程插件也不需要背命令。唯一需要养成的习惯是给你的模型“立规矩”。2.2 第一轮对话不是要代码是要它复述需求我在这里做了一件和大多数人不一样的事第一轮对话我不让 AI 写任何功能代码只让它做三件事复述我描述的游戏玩法输出它建议的技术架构列出接下来需要创建的文件清单。我当时给它的提示词大约是你是一位微信小游戏开发者。我的项目是一个休闲益智类小游戏目标用户是普通微信用户只在手机上玩。请遵守以下约束使用 Canvas 2D 渲染不使用任何第三方库和引擎代码按模块拆分每个文件不超过 200 行兼容 iOS 和安卓系统主包大小控制在 4MB 以内所有文案使用简体中文。请先不要写代码复述一遍你对这个游戏玩法的理解然后输出你计划创建的文件清单和每个文件的职责。这轮对话的价值在于AI 的复述就是一面镜子它能让我看出自己到底有没有把需求说清楚。如果它复述的玩法和我想的不一样我可以当场纠正而不是等它写完一千行代码后才发现方向错了。2.3 从玩法描述到可玩原型一次只做一件事过了方案对齐这关我正式进入“一次只做一件事”的迭代节奏第一轮画出背景和玩家角色让玩家可以触摸移动第二轮实现一个敌人从屏幕上方随机生成并下落第三轮实现碰撞检测被碰到则游戏结束第四轮加入计分、开始界面和结束界面第五轮循环完善改掉各种边界 bug。每一次对话我都会限定范围并且只把 AI 的输出放回微信开发者工具里跑能跑才进入下一轮。这里有个重要的原则每轮只让 AI 改一个功能点。如果一次提多个需求AI 很容易改坏某一个原有逻辑而你又因为不懂代码而无法定位是哪段引起的。2.4 一个典型的对话拆解从“接物”到“避炸弹”用我这款小游戏的第一个功能来举例。我的原始描述是我要做一个“接住下落的物品避开炸弹”的小游戏。玩家控制底部的一个篮子用手指滑动控制左右移动。水果和炸弹从屏幕上方随机下落水果接住加 10 分碰到炸弹游戏结束。先实现第一版画出背景、篮子和一个下落的水果篮子可以跟随手指滑动。AI 返回了一段包含 Game 类、Sprite 绘制逻辑和触摸事件绑定的代码。我复制进微信开发者工具第一次编译报错理由是“找不到 createCanvas”。我把报错原文粘回对话它立刻指出微信小游戏环境不能直接使用浏览器 API必须改用wx.createCanvas。这个过程反复发生了很多次而我做的事情只有两件复制代码、粘贴报错。到后来 AI 已经能在代码里自动加注释标注“这一块在真机上可能需要注意什么”这减少了我的很多理解成本。经过大约 5 到 7 轮对话一个可以玩的 MVP 就出现了有开始界面、有计分、有结束结算重开按钮也正常工作。那一刻的成就感说实话比我工作中写完任何一篇爆款文案都强。2.5 非开发者如何管理代码和版本笨办法才是安全的办法不懂 git 的人也要做版本管理否则 AI 改坏代码的瞬间就是你心态崩溃的瞬间。我的做法非常笨但非常可靠每次改动前把整个项目文件夹压缩一份存到网盘每次 AI 生成完代码后要求它附带一段“本次改动说明”解释改了哪些文件、为什么这么改让 AI 直接生成git init、git add .、git commit这些命令我只负责复制执行。很多程序员看到这里会笑但对我这种非开发者来说压缩包就是我的后悔药。有一次 AI 在优化下落速度时把碰撞检测逻辑弄丢了我冷静地把上一个压缩包解压出来覆盖回去再让它基于旧版本重做一次十分钟就恢复了。没有备份那一次我可能就得从零开始。3. 备案 27 天的完整时间线材料、驳回与并行准备3.1 备案前必须先搞定的两件事软著和主体信息微信小游戏上线的硬流程至少包含软著申请、备案和平台内容审核三关。很多教程会把这三件事混为一谈但实际上它们是分开的环节而且软著是最容易被忽略、最拖时间的一个。软著全称是计算机软件著作权登记证书。我去咨询时平台明确要求游戏类小游戏必须提供软著作为版权证明。软著申请需要准备源代码文档、软件说明书、申请表。我用 AI 帮我整理文档格式和源代码排版花了一个周末才提交上去。主体信息则是身份证实名、邮箱、手机号、人脸核验等按微信公众平台的指引走就行大概半天能完成。我的教训是软著一定要在游戏开发启动时就同步申请不要等备案需要了才去办。它虽然是整个流程里“技术含量”最低的环节但因为需要打印邮寄或等待审核周期不可控。我的软著是开发第 8 天就去提交了这个决定后来帮我省了大半个月。3.2 27 天的逐日记录哪几天是真审核哪几天是干等我在备忘录里记下了每一个时间节点整理成下面这张表时间节点说明第 1 天提交备案申请填写主体资料、游戏名称、类目、简介上传软著扫描件第 2 天平台初审驳回理由是“游戏简介描述不清晰”第 3 天修改后重新提交补齐玩法说明和适龄提示第 4 天平台初审通过进入“已受理”状态第 5 天至第 10 天转交通信管理部门审核此阶段无法在线修改信息纯等第 11 天至第 24 天管局审核中期间收到一次短信要求补充联系人信息第 25 天在线补充材料用手机完成人脸核验补充联系邮箱第 26 天状态变为“审核通过”但后台通知文字滞后一天第 27 天正式收到备案号可以进入提审环节这里要提醒一句备案周期和你的注册地有很强的关系我所在地区的流程是 27 天但不同地区从 15 天到 40 天都有可能。不要因为论坛上有人说“两周就过了”就焦虑也不要因为这个数字而盲目乐观。3.3 被驳回的真实原因细节能决定一周的差距整个备案阶段我的申请被驳回过一次平台要求补充说明过一次。把教训写在这里是希望你能绕开游戏名字不能含通用词和绝对化词语。我第一次起的游戏名带了一个流量词直接被驳回。命名尽量用“玩法特征 具象名词”干净中性安全得多。游戏简介必须写清“具体怎么玩”。只写“休闲小游戏”根本不够我后来改成“玩家控制篮子接住水果、躲避炸弹通过连续接取获得更高分数”这种可感知的描述。软著材料必须和游戏实际功能对应。说明书里写到的模块备案审核会抽查如果写得太抽象审核会退回让你补充说明。截图数量宁多勿少。第一次我只上传了一张玩法截图后来补上了开始界面、结算界面和设置界面的截图才顺利进入下一环节。我自己的总结是备案不是技术考试而是材料考试。材料越实、越具体审核越顺利写不清楚、模糊描述就是给自己制造不必要的等待。3.4 备案期间我在做什么最怕“干等”这两个字备案等待期最容易陷入的状态是“反正还没通过什么也做不了”。但这段时间恰恰是打磨游戏的好时机我做完了这些事完善隐私保护指引。虽然 MVP 不收集用户信息但微信平台要求所有小游戏都要配置隐私保护指引并说明是否收集信息补新手引导。我在 MVP 阶段其实没有教学环节趁等待期让 AI 加了一个“滑动手指即可控制”的轻提示写自测报告。这个报告在提交平台审核时会用到内容包括功能清单、玩法说明、是否涉及虚拟支付等每次改动后都做一遍真机回归。开发者工具里正常不代表真机正常我每天都会用安卓和 iOS 各跑一遍。如果你也想走这条路我建议你在备案期间至少把“提审前的准备材料清单”全部列好这样备案号一拿到你当天就能提交平台审核而不是再多等一周。4. 从“能跑”到“能上线”我在包体、适配和审核上栽的跟头4.1 包体从 7MB 瘦到 3.8MBAI 帮我写的代码先超重了微信小游戏主包有大小限制超过会被直接拦截。我第一次提交时就被拦了后台显示主包 7.1MB。原因很典型AI 为了图省事把游戏音效和几张素材图直接转成 base64 字符串硬编码在代码里。这些字符串看起来是一堆乱码但体积非常可观。我当时的解决思路是能靠代码绘制的图形绝不用图片。比如水果、炸弹、背景纹理全部让 AI 用 Canvas 原生绘图 API 实现不加载任何本地图片文件音效压成极低比特率的短音频放到远端服务器玩家首次进入后缓存到本地开启微信开发者工具里的“代码压缩”和“ES6 转 ES5”选项避免导入字体文件全部使用系统默认字体。一通操作下来主包从 7MB 降到了 3.8MB勉强过关。如果你一开始就准备做小游戏建议在需求约束里直接加一条“不使用 base64 内嵌资源所有图形尽量用 Canvas 绘制”这会省掉后面整周的瘦身痛苦。4.2 真机黑屏的排查链路开发者工具说没事真机说有事这是我踩过的最折磨人的坑。开发者工具编译一切正常但到了手机上一片黑屏连调试面板都没有报错。我当时沿着这条链路排查先看 Console 日志确实没有报错说明不是崩溃而是画面没有渲染出来再看入口文件是否执行我在代码里临时加了一条console.log真机上能看到输出怀疑是 ES6 语法兼容性问题。我用了可选链操作符?.在微信开发者工具中能跑但低版本 iOS 的 JavaScript 引擎不识别导致后续代码中断修改做法关闭高版本语法特性改成兼容写法让 AI 把可选的?.替换成传统判断。有时黑屏并不等于代码错而是一个不被支持的新特性导致渲染流程中断。这件事给我的教训是在真机调试阶段把代码往“更笨、更兼容”的方向写总是对的。越华丽的语法在我的基础库版本上越可能是雷。4.3 分享与隐私合规我差点因为“诱导分享”彻底翻车微信小游戏天然带社交属性但分享能力是审核重点关注的对象。我第一次设计的分享机制是“不分享不能继续游戏”审核直接判定为诱导分享拒了。这里必须明确一个区分“不分享就没法玩” 强制分享属于违规“分享后可以获得额外加分” 激励分享相对安全但文案也不能太刺激。我改成“分享给好友后首次获得额外加分”并且把分享按钮做成了游戏内的非必要入口这才过审。另外藏在前面的坑是如果你在小游戏里调用wx.getUserProfile获取头像昵称就必须在隐私保护指引里明确说明收集用途并在登录时弹出授权框。我的 MVP 原本不需要这些信息所以干脆完全不做账号和昵称功能直接从源头避开了最复杂也最容易踩坑的环节。4.4 其他隐蔽但真实存在的小坑音频在 iOS 上默认跟随静音键。用户手机调成静音游戏就没有声音了需要在wx.createInnerAudioContext里设置obeyMuteSwitch: false才能保证游戏音频正常播放小游戏切后台再回来计时逻辑会混乱。需要监听wx.onHide和wx.onShow回到前台时重新同步游戏状态老机型性能不足时下落物体会卡顿。我把屏幕上同时存在的物体数量做了上限控制超出后不生成新的待旧的消失再补位。这些坑单个看都不大但每遇到一个都可能要花一到两个晚上的时间去排查和修复。我建议你在开发早期就把“真机兼容性测试”纳入每天的例行操作不要堆到要提审时才集中处理。5. 关于“复制这套流程”的坦白局5.1 什么类型的小游戏真的适合 AI 来做我复盘之后认为下面这类项目更适合复制我的流程成功率更高游戏机制透明、规则简单比如接物、消除、点击、答题单局时长短不需要存档系统没有复杂的数值成长不需要实时联网对战不存在服务器同步问题画面呈现可以用简单的几何图形和文字代替。反过来以下项目我不建议你用“纯 AI 聊天”的方式去做因为调试成本会远远超出你的承受能力实时多人在线、强物理引擎模拟、3D 渲染、复杂的 Unity 项目或需要大量美术素材的游戏。AI 非常适合当“执行者”但它很难替你做真正的“架构决策”。项目越复杂你越需要懂行才能判断 AI 给的答案是不是在敷衍你。5.2 技术债一定会还我的应对方式AI 生成的代码有一个共性问题没有单元测试、全局变量到处飞、函数职责混乱。这在 MVP 阶段无所谓但当你开始迭代功能时旧代码会成为新功能的负担。我的应对策略是每次只要求 AI 修改一个函数尽量不碰其它代码每完成一个里程碑就做一个压缩备份让 AI 在关键函数里写注释解释输入、输出和边界情况如果一个功能连续改了三轮仍然有问题果断回退到上一个版本换一种思路重新来不要恋战。技术债不是非要还清而是要在你没能力重构的前提下控制它不爆炸。对我这种人来说最有效的方式就是“小步快跑 及时备份 不恋战”。5.3 时间账与心态建设这真的是给你的路吗最后把真实的时间消耗写在结尾希望你做决定前心里有数从零到 MVP我大约用了 3 天碎片时间每天 2 小时左右软著准备和提交周末两天备案等待27 天其中大部分时间是在等待而非劳动提交平台审核被驳回两次重新修改和等待约一周。整个过程从第一步到上线将近一个半月。单纯看开发时间不多但最消耗人的并不是开发而是等待期的未知感。你不知道审核为什么还没过也不知道会不会突然被驳回这种不确定性对我的心理压力远大于写代码本身。但如果你问我还愿不愿意再来一次我的答案是肯定的。因为这一个月让我完整走通了“从想法到上线”的最小闭环而现在这个闭环就静静地躺在我的证书列表里就像一个被打包好的可能性。最后再分享一个我在这个项目里最深的体会AI 不会因为你说“我不会”就放慢速度它会默认你是懂行的。所以你要做的事就是不断反问它“为什么”——为什么这么写为什么不选另一种方案为什么这里要加一个函数。每一步都多问一句这一句一句的问就是非开发者最值钱的开发能力。