一个人20天用AI编程工具从零上线微信小游戏：完整实战拆解

最近我干了件自己以前觉得不可能的事一个人同时顶着产品、前端、后端、美术四个岗位的活儿用了20天把一款微信小游戏从空编辑器做到了正式上线。整个过程主要靠两个AI编程工具撑起来——Cursor负责日常编码和界面调整Codex负责跨文件折腾的重活两者配合下来我每天的有效工作时间大概在4到6小时剩下时间都花在验收、修bug和跟审核斗智斗勇上。这篇文章就把这段经历完整拆开从玩法怎么定、技术怎么选到Cursor和Codex怎么分工、小游戏打包审核有哪些坑一条条讲清楚。无论是想用AI辅助做独立游戏的人还是单纯好奇AI编程工具在真实项目里能顶到什么程度都应该能从中找到点有用的东西。1. 一个人怎么顶四个岗位先把项目想透再做1.1 玩法为什么选“休闲合成”而不是“RPGMMO”我一开始也膨胀过想着一个人用AI做游戏是不是能直接挑战个放置挂机RPG什么背包、装备、技能树AI全能写。但冷静下来算了一笔账就直接放弃了。一个人做游戏最怕的不是代码写不出来而是玩法太复杂导致美术量爆炸、数值平衡失控、测试繁琐最后死在半路上。AI能帮你把代码写得飞快但它不能替你把“这个游戏到底好不好玩”想清楚。所以我最后定的是“休闲合成”品类题材选了个数字合成的小游戏屏幕里不断掉落数字方块相同数字碰撞后合成更大数字合成过程产生分数分数进排行榜。这类玩法的好处是核心循环只有“下落、碰撞、合成、计分”四步代码量天然可控美术上不需要复杂立绘我自己用AI生成了几张背景图和几个简单元素就能撑起来数值上也不涉及装备、属性、暴击这些容易失控的维度一个合成规则表就能写完。对第一次用AI辅助开发游戏的人来说这种“2小时能玩明白”的轻玩法是性价比最高的选择。1.2 技术选型Cocos Creator 比 Unity 更适合这个场景玩法定下来之后最关键的决策就是引擎选型。现在做微信小游戏主流路线无非两条Cocos Creator或者Unity加微信小游戏适配方案。我几乎没犹豫就选了Cocos Creator 3.x原因很现实Cocos对微信小游戏的导出是内置支持的构建面板里直接选“微信小游戏”平台填上APPID点一下就能生成微信开发者工具能打开的项目。整个过程非常顺滑不需要额外装适配插件也不需要折腾WebGL模板。Unity这条路我不是没考虑过身边确实有朋友在用但相关热搜里也常年躺着“unity微信小游戏打包”“团结引擎打包微信小游戏时如何正确配置webgl模板”这类问题说明这条路对新手来说坑不少。一个人只有20天我不愿意把时间赌在构建工具链上。另外Cocos默认使用TypeScript开发而TypeScript在AI训练语料里占比极高Cursor和Codex生成的代码质量相对更稳。事实也证明这个选择是对的我从装好Cocos到首次在微信开发者工具里跑起一个空场景只花了大概半天。1.3 后端微信云开发帮我省掉一个“运维岗”榜单和用户成绩总得有地方存。我一开始想过自己买个云服务器搭个Node后端写接口再维护数据库。后来一算这等于凭空多出一个运维岗位还得处理服务器安全、备份、扩容这些问题明显不划算。于是直接用了微信云开发这是微信小游戏生态里自带的一体化后端方案云函数、云数据库、云存储全都有而且天然和微信登录态打通。云开发最大的好处是省心。用户授权后云函数里直接通过cloud.getWXContext().OPENID就能拿到用户唯一标识不需要自己做token鉴权数据库用JSON结构存记录排行榜一条集合就能搞定静态资源可以放云存储还能走CDN。对一个小游戏来说这种方案从成本、开发效率到稳定性都完全够用。我一个人不在后端上花太多精力就是靠它把“服务端开发”这个岗位的工作量压缩到了极致。2. Cursor Codex 的工作流编排我一天的真实节奏2.1 Cursor 是日常主力写代码、调UI、解bug先聊Cursor。我把它当作整个项目的“日常主力编辑器”每天80%的代码修改都发生在它里面。Cocos Creator内置的代码编辑器只能说够用但一旦牵扯到AI补全、AI对话改代码这种需求就完全不够看了。我的做法是用Cocos创建完项目之后直接把项目根目录用Cursor打开所有脚本都在Cursor里写遇到问题直接在Cursor的对话框里提问。Cursor有几个用法在这一项目里极其高频。一个是CtrlK内联修改比如我在UI里调整一个标签位置选中那行代码告诉它“节点向右偏移48像素”它改完我直接切回Cocos看效果效率非常高。另一个是Agent模式遇到跨文件的需求比如“给所有弹窗都加一个关闭音效”它能自己去项目里找相关组件批量处理。至于网上问得很多的“Cursor怎么设置中文”其实是小事装个中文语言包或者在设置里把locale改成zh-cn就行别在这上面浪费时间。2.2 Codex 是“全能外挂”批量重构、跑测试、跨文件改动如果说Cursor是步兵那Codex就是特种部队。Codex是OpenAI出品的云端开发智能体给它一个任务它会自己在沙箱里克隆代码、修改文件、执行命令、跑测试最后把改动提交出来。我在这个项目里遇到最典型的场景是某个功能在20个文件里都要加参数或者有一批编译报错需要逐个修复这种活儿手工改会疯正好交给Codex。我常用的方式是在命令行里执行codex exec加一段任务描述比如“把项目中所有直接调用wx.getSystemInfoSync()的地方替换成新的封装方法并处理可能的类型错误”然后它就开始工作了。它跑完以后我再在Cursor里打开diff逐块看没问题就合并。这个流程里有个很重要的原则Codex适合“过程明确但步骤繁琐”的任务不适合“我还不知道要怎么做”的任务。另外关于Codex的安装配置我补充一句网上常见的那几个报错比如cc switch local proxy failed多半和本地代理环境配置有关把HTTP_PROXY之类的环境变量清掉再重试就好codex ran out of room in the models context则是任务太大上下文塞满了拆成几个小任务就能解决。2.3 用 .cursorrules AGENTS.md 给AI定规矩想让AI稳定输出高质量代码光靠对话里反复强调背景是不够的。我在项目根目录同时放了两个文件.cursorrules和AGENTS.md。Cursor会自动读取.cursorrulesCodex也会参考项目里的AGENTS.md。这俩文件等于给AI提前“签合同”让它知道这个项目的技术栈是什么、代码结构怎么组织、有哪些禁区不能碰。我写的.cursorrules大致长这样你是一个微信小游戏开发专家。 技术栈Cocos Creator 3.x TypeScript 微信云开发。 项目结构assets/scripts 下按 components/managers/logic 分类。 命名文件用 kebab-case组件类用 PascalCase。 不要修改assets/resources 下的美术资源、temp/ 目录、library/ 目录。 设计分辨率750 * 1334UI单位用px。别小看这几行它的作用是把AI从“什么都能编的通用模型”变成“懂我项目规矩的协作者”。加了.cursorrules之后Cursor生成的代码风格明显统一了很多不会再出现一个文件里混用单引号双引号、类名命名规则前后矛盾这类低级问题。AGENTS.md里我还会额外写清楚“合成逻辑必须在src/logic目录下做成纯函数”“每次改完跑一遍npx tsc --noEmit做类型检查”这种约束能大大减少AI改出“看着能跑但类型全错”的代码。2.4 原子任务拆分把大功能切成AI能执行的小任务这一条是整个工作流里最值钱的经验没有之一任何交给AI的任务都必须拆到“5分钟能完成”的粒度。比如我在开发合成玩法时不直接说“帮我做一个合成小游戏”而是拆成几十个小任务像“给方块节点增加一个merge动画方法”“在ScoreManager里增加addScore方法并同步更新UI”“创建一个LevelConfigJSON包含5个难度档位和对应生成概率”。每个任务就是一个明确的小单元AI执行起来准确率高出了问题也容易定位和回滚。我通常的节奏是晚上把第二天要做的功能拆成10到20个原子任务写进一个todo.md第二天上午把任务逐个丢给Cursor或Codex执行下午集中验收和修bug。这种做法还有一个隐性好处任务粒度越小AII的“自由发挥空间”就越小产出越可控。千万别让AI一口气搭一个完整页面它会给你生成很多花里胡哨但根本不在你预期内的结构到时候删起来都麻烦。3. 从空项目到能玩核心开发环节实操拆解3.1 项目骨架与场景结构我拿到Cocos创建的空项目后第一件事不是写代码而是先把目录结构和场景规划清楚。整个游戏的场景只分了三个Menu主菜单、Game游戏主场景、Result结算场景。菜单负责开始游戏和查看排行游戏场景承载下落、合成和实时分数结算场景展示本局得分和好友榜单。场景越少构建和分包越简单对AI的理解负担也越小。脚本目录我是按组件职责拆的components放具体的节点行为组件比如方块掉落、按钮点击managers放全局管理类GameManager、AudioManager、AdManagerlogic放纯逻辑函数比如合成规则、计分规则、关卡参数utils放工具方法。这个拆分很重要因为它决定了AI改代码时能不能迅速找到目标文件。我在做项目管理时发现只要你的目录结构足够清晰AI的代码定位准确率会高很多因为Agent模式下它会先读目录树再去猜你要改哪结构混乱的话它就只能靠文件名硬猜。3.2 核心玩法实现合成逻辑与控制手感核心玩法的第一件事是把合成规则从游戏场景里抽出来写成独立纯函数。两个相同数字的方块碰撞数字翻倍分数增加这个逻辑本身很简单难点在于“方块什么时候算碰撞”。一开始我试过用Cocos的物理引擎做碰撞检测但物理引擎的调试成本很高方块下落速度稍快就会穿透AI生成的代码在物理参数上经常靠猜调起来很费时间。最后我换成了最土但最稳的方案手动做2D圆碰撞检测每帧遍历相邻方块如果中心距离小于半径和就触发合并。合成规则和计分逻辑单独抽成纯函数之后非常方便测试// assets/scripts/logic/score.ts // 合成规则两个相同数字 n 合成 2n得分是合成后数字的 10 倍 const RULES: Recordnumber, number { 1: 2, 2: 4, 4: 8, 8: 16, 16: 32, 32: 64, 64: 128, }; export function getNextValue(v: number): number { return RULES[v] ?? 0; } export function getMergeScore(v: number): number { return getNextValue(v) * 10; }这段代码就是全游戏的计分核心逻辑简单到一眼能看穿这也意味着出bug的概率极低。我让Codex批量生成了十几个像这样的纯函数模块然后自己逐个review一遍基本不用调试。除了合成逻辑控制手感是另一个重点方块下落不能太快也不能太慢合成时要有轻微的弹跳感。这些细节AI写起来不费劲但需要你反复试玩、给出非常具体的调整指令比如“方块合并后缩放动画改成0.8倍到1.1倍时长0.15秒”AI就能很快改到位。3.3 微信能力接入登录、分享、激励视频、云函数小游戏不是单机游戏想要榜单和社交传播就得接微信能力。登录这块因为用了云开发其实不需要写授权弹窗云函数天然能拿到用户身份。分享功能用wx.shareAppMessage就能把游戏分享给好友我做了个“分享后可获得一次额外开局机会”的机制但这里有个大坑——微信对诱导分享查得很严千万不能写“必须分享才能继续游戏”的强逻辑一定要让用户可拒绝否则审核大概率被拒。激励视频广告是我当时设定的变现方式。在微信公众平台申请广告位拿到adUnitId之后用wx.createRewardedVideoAd就能创建广告实例在用户“本局结束获取双倍积分”的场景调用。接入广告的代码本身不难但我要提醒一个细节广告实例最好是全局单例不要每次点击都重新创建否则会引发加载延迟甚至黑屏。下面是云函数的经典写法用于提交成绩// cloudfunctions/submitScore/index.js const cloud require(wx-server-sdk); cloud.init({ env: cloud.DYNAMIC_CURRENT_ENV }); const db cloud.database(); const scores db.collection(scores); exports.main async (event) { const { OPENID } cloud.getWXContext(); const score Math.max(0, Math.floor(event.score || 0)); const result await scores.add({ data: { openid: OPENID, score, ts: Date.now() } }); return { ok: true, id: result._id }; };这里有个容易被忽略的点云数据库的读写权限必须单独配置。排行榜集合scores需要设置成“所有人可读、仅创建者可写”否则要么排行榜别人看不到要么任何人都能篡改分数。云开发控制台里用一句安全规则就能搞定但如果你忘了配上线后一定会被用户用刷分脚本教做人。3.4 资源加载与包体控制策略资源这块是“一个人做游戏”最容易翻车的地方。我一个人做美术资源自然紧张所以我定了个原则能用代码画的就不用图片能用压缩图的绝不用原图。背景和UI图标用AI生成了几张高质量PNG然后统一用压缩工具压到原来的30%体积音效和背景音乐找的是免费可商用素材全部转成低码率mp3尽量控制在每段几十KB。这里牵扯出微信小游戏一个很重要的限制代码包体积红线。微信小游戏主包大小限制很严格一般要求控制在4MB左右超出就必须分包。我在开发早期就对资源做了严格管控所有非首屏需要的资源一律放云存储等进到对应场景再远程加载。同时还用上了Cocos的“MD5 Cache”配置让资源文件名带哈希值方便CDN缓存。整个开发过程中我每次构建完都会看一眼产物体积一旦接近红线立刻排查是哪个资源拖了后腿。如果开发初期不养成这个习惯等游戏做完了再来压缩资源那简直是一场灾难。4. 打包、审核、上线最容易翻车的最后三公里4.1 Cocos 构建微信小游戏的配置要点游戏开发完不是直接就能在微信里跑中间还有一道构建工序。Cocos Creator这边的操作其实已经非常傻瓜化打开“项目→构建发布”平台选“微信小游戏”填上从微信公众平台拿到的APPID点击构建然后在弹出的目录里找到build/wechatgame用微信开发者工具打开就能预览和上传。但有几个配置项值得单独说。第一起始场景要设对我默认是Menu主菜单如果设错了用户一打开游戏就掉到结算场景审核人员会直接判定为“无法正常体验”。第二要勾选“MD5 Cache”选项这样资源文件名会带哈希避免用户更新版本后因为缓存拿到旧资源。第三如果项目用到了远程资源加载一定要在微信公众平台后台配置好downloadFile合法域名不然真机上资源全部加载失败模拟器里却一切正常这个线上线下差异极其坑人。我第一次提审的时候就栽在这里模拟器完美运行真机却白屏排查了半天才发现是域名没配。4.2 主包体积与分包方案如果你的游戏和我一样是休闲类资源按理不会太夸张但代码逻辑多了以后主包还是容易超限。我最终的主包结构是核心场景、核心逻辑、基础UI资源放主包所有排行榜、设置、帮助等次要页面的资源和代码放进了一个subpackage子包在需要时用wx.loadSubpackage动态加载。分包的操作在Cocos里就是在构建配置里把某些目录标记为“子包”构建后微信开发者工具会识别出来。这里有一个经验分包不要写得太多太碎两三个就够了否则管理成本和加载时序复杂度会让AI也很难维护。另外分享图这种大尺寸图片我根本不会放进代码包直接放到云存储分享的时候用远程URL传进去这样既能省包体又能随时换图不用发版本。4.3 软著、备案、隐私协议上线前必备材料很多人做小游戏只顾着写代码结果卡在提审当天的材料准备上。这里我明确说一句现在上架微信小游戏游戏类目基本都要求提供软件著作权登记证书这是绕不开的。我的软著是提前提交申请的审批周期不短所以在开发前两周就应该先把这件事安排上等游戏写完了证书差不多也下来了。除了软著还有两件事容易忽略。一是小游戏备案这个在微信公众平台后台走流程即可需要准备主体信息、游戏名称、简介等资料审核也需要时间所以要尽快启动。二是隐私保护指引只要你的游戏会获取用户头像、昵称、位置虽然我这游戏只需要头像昵称等信息就必须在后台填写隐私保护指引并在游戏启动时以弹窗或其他合规方式让用户知情确认。很多第一次上架的人会忽略这个审核被拒后一脸懵。4.4 审核被拒的几种典型原因与对策我提审一共被拒了两次一次是白屏问题域名没配好一次是iOS端虚拟支付问题。第二个问题值得重点说微信小游戏在iOS端不能提供任何形式的虚拟支付但我的广告变现不涉及这个问题出在UI上——我游戏里放了一个“去广告永久版”的按钮虽然实际逻辑是隐藏入口但审核人员看到按钮就会认为存在iOS支付风险。最后我直接把整个按钮从iOS端逻辑里移除才顺利过审。审核阶段会遇到的典型问题还有启动没有隐私弹窗、分享机制涉嫌强制诱导、测试账号留白让审核员无法完整体验玩法、版本描述里没有写清楚测试指引等等。针对这些我的对策很简单在提审时填写的“测试说明”里把操作路径写得清清楚楚比如“点击开始→等待方块掉落→相同数字合并→15秒后查看结算”审核人员体验顺畅通过率就高很多。另外要给自己留出至少3天时间专门应对审核反馈不要卡着上线日期截止才提审否则任何一个意外都可能导致延期。5. 常见问题与排查技巧实录5.1 Cursor / Codex 常见报错速查我在整个开发过程中搜集到的AI工具典型报错应该和你在搜索框里看到的那些问题高度重合这里直接给个速查表报错或现象可能原因处理办法codex ran out of room in the models context任务太大上下文塞满把任务拆成更小的原子任务或让Codex先读文件清单再针对性修改the gpt-5.x-sol model is not supported when using codex with a chatgpt account当前账号类型不支持该模型在Codex配置里切换到当前账号可用的模型或改用API Key方式认证cc switch local proxy failed while handling codex endpoint /responses本地代理配置影响请求转发检查HTTP_PROXY/HTTPS_PROXY环境变量临时关闭代理重试Cursor生成的代码风格混乱缺少项目规范约束在根目录创建.cursorrules明确技术栈、命名规则和禁区提示词或密钥泄露风险把敏感信息写进了项目共享文件API Key等敏感配置放环境变量或本地配置文件务必加入.gitignore这些报错里的大多数都不是功能性问题调整配置就能解决别被吓到。最需要警惕的反而是“没有报错但代码写错了”的情况所以每个AI任务完成后的review环节千万不能省。5.2 微信小游戏运行期的典型问题上线后我也遇到了一些运行期问题其中一个和音频格式有关AI生成的音频素材直接丢进项目模拟器正常真机却没声音。查了半天发现是音频格式兼容问题小游戏真机对部分音频编码格式支持有问题最后统一转成标准mp3才解决。所以素材进入项目之前格式和编码一定要统一检查。另一个高频问题是排行榜头像显示不出来。罪魁祸首通常是后台没有配置downloadFile合法域名微信头像URL加载会被拦。你只要在微信公众平台后台把头像域名加进白名单问题立刻消失。还有云函数超时问题默认配置的超时时间可能不够处理大数据量真机上容易表现为排行榜加载失败。我在云开发控制台把相关云函数的超时时间调大后这个问题就稳定了。类似这种“模拟器一切正常、真机就出问题”的现象几乎都是网络请求和域名配置引起的排查时优先往这个方向想。5.3 时间不够时哪些活儿可以“让位”20天时间看着长实际到了提审阶段会感觉什么都不够用。如果让我重新排一次优先级我会把开发顺序调整为核心玩法第一UI和动效第二排行榜和分享第三广告和商业化第四。原因是核心玩法不跑通其他所有功能都是空中楼阁而商业化就算上线当天没接也能在后续版本补上不耽误首发。如果时间极度紧张可以砍掉的功能包括新手引导小游戏玩法简单时根本不需要、设置页音效开关可以暂时不做、复杂的每日任务系统留着做版本更新内容。千万别砍的是分享功能低成本获客核心、隐私弹窗合规硬性要求。我个人的时间分配大致是前3天定玩法搭骨架第4到12天开发核心玩法和UI第13到15天做榜单和分享第16天统一处理素材和音效第17到18天提审第19到20天处理审核反馈和修复问题这个节奏基本可以复刻。写到最后我个人的一点体会是AI编程工具这次给我的核心价值不是“一个人干了四个人的活”这种表面的效率提升而是让我这个对后端、美术、上线流程都不算熟的人也能把一款完整产品推到真实用户面前。工具只是放大器真正决定项目成败的还是玩法方向的判断、任务拆解的颗粒度以及验收标准的严格程度。如果你也打算用Cursor加Codex跑一个完整项目我的建议是别想着一步到位先把最小可玩版本跑通再一步步加功能AI会让这条路走得比你想象中快得多。