凌晨两点半电脑屏幕上最后一条编译输出变成了“发布成功”我盯着那行字愣了好几秒。20天前我给自己封了四个头衔——策划、程序、美术、运营听起来像简历里唬人的包装实际上就是一个人在一台电脑前用 Cursor 和 Codex 这两款AI编程工具从零上线了一款微信小游戏。没组队没外包没花一分钱做推广从玩法文档到审核上线全是一个人扛下来的。如果把这段经历浓缩成一句话不是AI替我写了所有代码而是AI让我一个人干完了四个人的活。这篇文章我打算把整个过程中的选型逻辑、工具分工、排期节奏和踩过的坑完整捋一遍尤其是那些让我熬到深夜的报错和审核驳回。如果你也想用AI辅助开发微信小游戏或者正在纠结“一个人能不能搞定一个完整项目”这篇应该能帮你在动手前少走不少弯路。1. 一个人敢接“四个岗位”的底气选对载体比努力重要1.1 为什么是微信小游戏而不是App或者H5先说结论微信小游戏这个载体天然就是为“小团队甚至单人开发者”准备的。我做App的话光iOS安卓双端适配、真机兼容、性能优化、上架审核这几件事就能耗掉我半个月而且大概率还要为证书和备案折腾一阵子做H5虽然门槛低但用户触达是个大问题没有分发渠道做完就是个数字孤岛。微信小游戏把这几个痛点全部绕开了。微信小游戏自带一整套成熟的用户体系、分享链路和支付/广告组件。登录直接用微信授权存档可以用微信云开发分享到群聊和朋友圈是内置能力激励视频广告位在小游戏后台点几下就能申请下来。这些能力在传统App里对应的是账号系统、后端服务、消息推送、支付SDK——哪一样都不轻松而小游戏平台已经帮你铺好了路。再一个关键是“轻”。小游戏对包体、性能、单局时长的天然限制其实是个筛选器它逼着你把玩法做简单、做聚焦不允许你脑门一热铺出一堆大而全的功能。我见过太多独立开发者一上来就想做开放世界、做实时对战结果半年过去连Demo都跑不流畅。小游戏赛道里活得好的往往是休闲益智类、轻RPG、模拟经营这类规则清晰、单局时间短、天然适合分享传播的玩法。你可能会问什么样的游戏适合一个人加AI来做我的判断标准很朴素——玩法复杂度要有明确天花板核心循环能在30秒内让玩家看懂服务器需求能压到最低。拿我自己举例当时列了三个候选玩法一个是卡牌构筑一个是跑酷一个是轻度的模拟经营。模拟经营和分析决策类玩法对数值平衡要求高内容消耗极快一个人做得累死跑酷虽然看似简单但在手感调优上是个无底洞。最后选了一个规则简单但上限不低的轻休闲玩法玩家通过滑动操作让角色通关关卡之间穿插成长线和随机事件分享复活是裂变的主要抓手。这类型玩法最契合小游戏生态也最适合AI辅助开发的节奏。1.2 二十天倒计时背后的“减法清单”20天的时间限制意味着前三天就必须把所有“可做可不做”的东西全部砍掉。我做了一张减法清单现在回头看这才是整个项目能按期上线的关键。坚决砍掉的功能包括实时对战、好友排行榜实时同步、语音聊天、多语言本地化、账号绑定、复杂的新手引导动画。这些功能每个单独拎出来都能写三天而且对核心玩法闭环没有本质贡献。比如实时对战听起来很吸引人但要做帧同步、房间管理、掉线重连后端复杂度瞬间膨胀根本不是一个20天项目该碰的东西。同量级的热词里“unity微信小游戏打包”搜索热度那么高说明很多人卡在技术交付环节而不是玩法创意上把精力留给核心玩法比什么都强。保留的功能只有四样核心玩法循环滑动操作关卡通关、本地存档加云存档、分享复活、激励视频广告。确定了MVP清单之后我把它写成了开发过程的“边界条件”直接丢给AI工具当约束“这是本期范围清单之外的功能不要做不要主动扩展架构。”这一点非常重要——AI非常容易“自作主张”它会觉得加入某个设计模式很酷或者顺手加一个你没要求的编辑器功能。如果你不给它明确边界它会把你的项目复杂度拖向失控。我当时的减法清单长这样优先级功能项状态原因P0核心玩法循环保留没有它游戏不成立P0本地存档 云存档保留玩家流失后能回来P0分享复活保留裂变的核心入口P1激励视频广告保留个人开发者的主要收入来源P1极简排行榜异步保留云函数每次读库成本可忽略P2实时对战砍掉后端复杂度爆炸P2语音聊天砍掉需要资质和审核风险P2多语言砍掉中文市场先跑通P3复杂新手引导砍掉首局10秒内能用直觉玩2. Cursor 和 Codex 的分工策略一个管“手术刀”一个当“工程队”2.1 为什么同时用两个AI工具而不是只用一个很多人会问Cursor 和 Codex 不都是AI编程工具吗选一个不就够了我的体验是它们俩的性格完全不同。Cursor 更像是你手里的手术刀——它长在IDE里面能实时看到报错、上下文感知整个项目适合逐行精修、改函数、调界面、重构局部逻辑。而 Codex 更像是工程队——它跑在终端里适合接“把A目录下的所有资产重命名并按规则整理”“把全部硬编码数值抽成配置文件”“跑一遍测试并把失败用例写进日志”这类批量任务。我给它们的疆界是这样划的Cursor 负责所有需要“我盯着改”的代码包括核心玩法脚本、UI交互逻辑、微信SDK调用Codex 负责所有“我只要结果”的重复劳动包括依赖安装、构建脚本、资源目录整理、自动化测试和批量生成关卡配置。两者并行最后用 git 合并。这里有个血泪教训绝对不要让两个AI同时改同一个文件它们没有任何协调机制各改各的会在合并时产生一堆冲突而且AI很容易在解决冲突时把对方的逻辑清掉。我后期养成了一个习惯每个人工智能动工之前先给它指定明确的文件路径范围做完一个再放另一个进场。2.2 我是怎么把需求翻译给AI听的把需求讲给AI听其实和给新同事交底没什么区别。我刚用AI编程时最大的误区是只甩一句话“做一个关卡选择界面。”AI确实会做出来但做出来的东西往往边界模糊、缺少细节、架构随意。后来我总结了一套提示词模板效果稳定得多背景这个项目是什么类型的小游戏用了什么引擎。目标这次要做什么解决什么问题。边界涉及哪些文件/模块禁止动哪些模块。验收标准什么样的输出算完成用什么命令验证。一个真实的提示词长这样背景这是一个微信小游戏使用Unity导出到WebGL平台现有玩法循环已经跑通。 目标新增关卡选择界面显示已解锁的最高关卡数未解锁关卡显示为锁定状态。 边界 - 只允许修改目录 Assets/Scripts/UI/ 下的文件 - 不得改动 Assets/Scripts/Core/ 下的任何代码 - 不要引入第三方UI库 验收标准 - 运行场景后点击主菜单的“关卡”按钮能进入关卡选择界面 - 已解锁关卡可点击进入对应关卡未解锁关卡点击后弹出Toast提示 - 使用微信开发者工具预览时触摸点击事件正常工作在 Cursor 里我依赖三个核心功能。第一个是Codebase引用写提示词的时候把Codebase拉进来AI 会自动检索整个项目结构回答更贴合现有代码第二个是 Agent 模式它不只是补全代码而是能自己读文件、改文件、跑命令然后汇报结果第三个是 Tab 补全看起来不起眼但在连续写重复性代码时能让手速翻倍。至于很多人问的“cursor中文怎么设置”其实在设置里把语言切到中文就行但我个人建议保留英文界面因为很多时候 AI 生成的中文注释会和代码风格不太搭而且英文关键词在搜索报错时更有用。Codex 的命令行用法要更克制一些。我惯用的姿势是把任务描述写在一个文本文件里然后跑codex exec 读取 docs/todo.md逐项完成任务每完成一项在文件末尾标记完成状态这样做的好处是 AI 不会因为终端里的历史对话太杂而理解偏所有指令都是一次性的、可追溯的。Codex 在处理依赖问题、脚本自动化、文件批量重命名这类任务上表现得特别稳定尤其是在无人值守的场景下让它自己去干活你过一会儿回来看结果就行。2.3 让两个AI“接力”的最佳实践AI编程工具用多了之后我越来越觉得它们像是“能力很强但记性很差的新人”。它们的强项是单点任务的执行力极强弱点是上下文窗口有限一长串任务积累下来就容易“忘事”或者犯低级错误。热词里有个典型的报错error running remote compact task: codex ran out of room in the models context window——翻译过来就是上下文爆了模型的空间装不下这么多内容了。这个问题几乎每个重度用户都会遇到解法不是硬扛而是拆分任务。我后来的工作习惯是这样一个会话只做一件事任务做到一半如果需要继续先让AI输出一份“当前状态摘要”存成一个临时文件下次开新会话时让AI先读那个文件再接着干。这样既绕开了上下文长度限制又不会丢失进度。打个比方这就好比你让一个实习生干活与其让它把100个步骤全记在脑子里不如让它每一步做完都在便签上记一句最后你只需要看便签就能知道发生了什么。另外还有一个特别有效的习惯让AI每次改完代码输出两行“变更摘要”说明改了哪几个文件、改了什么东西、为什么改。一开始我也嫌麻烦后来发现这个摘要太有用了——因为AI改崩代码的时候你靠它的摘要能迅速判断是哪个文件出的问题git diff 都不用逐行看了。带AI写代码本质上就是带实习生你给它明确任务、限制边界、要求它汇报它就能扛起远超一个人力的产出。3. 四个岗位压缩成一条流水线我每天的真实工作流3.1 策划岗玩法文档先过AI这关在我的工作流里策划岗不是最先出图的而是最先出文字的。我先用文档描述完整玩法然后把它当成“需求评审材料”喂给AI。最核心的用法是让AI扮演不同角色来“评审”我的方案让AI扮演玩家去看新手引导会不会让人困惑让AI扮演制作人去判断功能范围会不会失控让AI扮演数值策划去检查成长曲线的合理性。数值推演这一步AI帮了大忙。我当时做了一张关卡数值表包含每关怪物的血量、攻击力、金币掉落和道具产出。按照传统做法我得手动建一个Excel模型慢慢调但我在提示词里直接写“当前玩家的基础攻击力是10每秒攻击一次怪物血量公式是100乘以关卡数的1.2次方金币掉落是5加关卡数乘以2帮我生成100关的数值表并标记出在第几关会出现玩家击杀怪物时间超过30秒的卡点。”Codex 把答案整理成一张CSV给了我标注了第37关开始怪物血量明显膨胀建议把攻击力的成长曲线改成指数型。这种模拟推演放在以前至少得花一整个晚上现在20分钟内就能跑完。3.2 程序岗从 Demo 到能上线的代码是怎么长出来的程序岗是AI投入占比最大的环节。我的技术栈是 Unity 加微信小游戏适配方案通过 WebGL 模板导出微信小游戏工程再用微信开发者工具打开调试。之所以选 Unity 而不是原生开发是因为Unity的组件化架构和资源管线更适合AI生成代码——AI特别擅长生成 C# 脚本而在原始JS里手搓图形引擎属于给自己找不痛快。代码的组织上我把它拆成三个核心模块。游戏主循环负责角色移动、碰撞检测和状态流转UI模块负责所有界面的显示和交互主菜单、关卡选择、结算、分享弹窗数据模块负责存档读写和云函数通信。每个模块用独立的 C# 脚本文件管理这样既方便我逐个审阅AI生成的代码也方便AI精准定位问题。一个特别有用的技巧是写代码的时候让AI给每个公共方法都加上注释说明参数含义和返回值这样后面让AI修bug时它自己能快速理解自己的代码不用我把整个文件塞进上下文。小游戏平台特有的适配问题需要专门留意。触摸事件和鼠标事件不完全等价Unity默认的鼠标点击事件在真机上会失灵所以所有关键交互都要绑定Input.touch或者用统一的输入管理组件屏幕适配不能只做横屏或竖屏的简单拉伸要处理不同宽高比的锚点初始包体必须控制在非常小的体积这里我会把大部分美术资源放到远程加载。程序岗最容易犯的错是贪多我给自己定的规矩是先跑通一个最小闭环哪怕画面丑一点——一个能跳的小人、一个能碰到的金币、一个能触发的分享按钮这个闭环通了再往上面加玩法。3.3 美术岗没有美术怎么办美术是个人开发者最容易破防的环节。我的解法是三个词风格克制、程序生成、资源复用。我做的是扁平几何风格所有角色和场景元素都用基本的矩形、圆形、三角形组合出来再统一一套高饱和度的调色板。这种风格做出来的游戏画面干净统一而且AI生成的素材风格一致性极强不会出现“前两关像A游戏后两关像B游戏”的割裂感。用AI生成素材时我通常会让它输出透明背景的PNG并且控制素材尺寸和留白然后批量导入Unity做成图集。这里有个小坑AI生成的图片有时候自带一些莫名其妙的噪点直接放进游戏里会导致包体变大如果是2D素材一定记得在导入设置里把压缩格式选成适合WebGL的格式否则真机加载会卡成幻灯片。场景背景我用程序化生成的方式在代码里动态绘制既省资源又保证风格统一。音频方面音效来自公开免费音效库BGM用的是程序化生成的一段循环旋律再在代码里控制音量淡入淡出。外部公开资源的使用要留意授权协议尽量选择CC0或MIT协议的素材免得后面被要求下架。3.4 运营/后端岗微信云开发的胜利一个20天项目如果还要自己买服务器、配域名、做备案基本宣告失败。微信云开发CloudBase帮我省掉了全部后端基础设施。排行榜和云存档各写一个云函数数据库用云开发自带的文档型数据库前端通过微信SDK直接调用根本不用关心服务器运维。整个数据层加起来代码量不超过200行而且全程不需要我申请任何服务器资源。激励视频广告是个人开发者最直接的变现手段。在小游戏后台申请广告位、拿到adUnitId之后在代码里调用wx.createRewardedVideoAd接口就行。我的设计是玩家看广告可以复活一次或者获得双倍金币这两个场景对广告时长的接受度最高。还有一个容易被忽略的收入来源是“格子广告”或“Banner”但小游戏里弹窗广告对留存影响很大个人项目宁可少赚点保持体验清爽把留存和口碑先做起来。微信小游戏的著作权登记问题我确认过平台流程上线本身并不强制要求先提交著作权登记证书个人开发者可以在微信公众平台上走正常的备案和审核流程。但如果你后续想申请“创意小游戏”标识或者要跟发行商谈独家代理对方通常都会要求提供软著证明。我的建议是别被这个名字卡住开发节奏游戏研发完成后用空闲时间把材料一起办了就行。4. 20天排期与每个阶段的关键里程碑4.1 第一周从想法到可玩DemoDay 1-7前三天的任务是“做决定”而不是“写代码”。玩法定稿、美术风格定调、技术选型、搭好Unity工程、跑通微信小游戏官方示例。这三天我基本都在跟AI一起打磨玩法文档和数值模型因为这些东西一旦定了后面的开发就很难回头改。第4到5天我不再纠结玩法完整性直接把核心玩法做成一个“能跑、能死、能重开”的Demo。画面用最简单的色块代替所有美术资源都是占位图代码逻辑也只保留最核心的移动碰撞和关卡切换。这个阶段最重要的是验证手感滑动操作的灵敏度、角色移动的加速度、碰撞检测的判定范围。手感不对玩法再有意思都留不住人。第6到7天我把Demo发给了几个朋友试玩然后仔细观察他们玩的时候的表情和操作。这里有一个特别重要的经验不要问“你觉得好玩吗”而要问“你刚才在哪里卡住了”和“你第二次打开游戏是因为什么”。反馈收集完之后我把所有劝退点列成一个清单按严重程度排序能在一小时内改完的立刻改完改不了的直接砍掉——还没上线谁也不确定某个设计一定成立快速验证比自我感觉良好重要得多。4.2 第二周内容填充与打磨Day 8-14第二周的重心从“能不能玩”变成“有没有内容”。我让 Codex 批量生成了100关的关卡配置JSON每个关卡包含地形布局、敌人分布、金币位置和通关条件然后我写了几个测试脚本逐关跑平衡性把那些“玩家无论如何都过不去”和“过于简单导致三秒通关”的关卡手动调整。这个阶段我把占位图全部替换成正式素材统一了调色板和描边线条宽度。音效和动效的补充也在这个阶段完成但场面上我会刻意做“节制”——动效过多在小游戏真机上会造成掉帧尤其是低端安卓手机所以几乎所有的粒子效果都被简化成了缩放动画。第14天是一个严格的checkpoint游戏必须能完整通关100关从第一关到最后一关不能有中途崩溃或卡死的现象。达不到这个标准后面的提交审核和广告接入就无从谈起。为了守住这个节点我甚至做了取舍把100关的内容砍到了80关留出时间专心打磨手感。后来证明这个决定是对的——玩家根本不会在意关卡数量是80还是100但一定会注意到操作卡顿和加载缓慢。4.3 最后冲刺审核、合规、上线Day 15-20最后五天整个节奏变成了“测试、修复、测试、修复”。我用微信开发者工具的真机预览功能在几台不同价位的安卓和iOS设备上反复测试重点盯三类问题启动崩溃、内存溢出、UI错位。每修完一个bug我会把报错日志和修复代码重新喂给AI让它判断有没有连带风险——这一点对赶进度来说特别关键因为很多bug是“按下葫芦浮起瓢”修完一个又冒出一个AI能帮你快速定位回归测试的范围。第17天我把隐私保护指引、用户协议、未成年人保护相关的平台配置全部完成。这一步千万别偷懒微信审核对隐私指引的检查越来越严格很多开发者头几次被拒都是因为“未在后台配置隐私保护指引”或“代码中未调用平台要求的隐私授权接口”。第18天正式提交审核前我自己用审核人员的视角把游戏过了一遍类目选的是休闲益智截图和图标用的是正式版本画面游戏介绍里没有夸大宣传也不涉及任何敏感内容。审核结果出来后平台提了两个修改意见一个是某个道具图标和内置表情包过于相似另一个是支付相关提示文案需要调整。这些都是纯手工改的小问题当天改完重新提交第20天上午就收到了通过通知。5. 踩坑实录这些报错我花了最多时间5.1 Cursor账号的设备数量限制开发到第6天的时候我想从台式机切到笔记本继续写代码结果登录时直接弹提示too many computers used within the last 24 hours for the same cursor account——24小时内使用的设备数量超出了账号限制。我当时愣了一下因为所谓“多设备”其实都是我一个人在用只是频繁切换而已。这个限制的逻辑是防止多人共享账号所以它不管你是不是真人只看设备活跃数量。排查下来这个限制是按24小时窗口滚动的超了就锁只能等窗口自然重置。处理方式也很直接把Cursor固定在一台主力开发机上别在多个设备之间来回切如果确实需要换机器先在一台设备上退出登录并停用过一段时间再登录新设备。这件事给我的启发是AI工具账号和设备绑定策略各不相同开工之前最好先看清楚平台规则不然做到一半被锁账号心态真的会崩。5.2 Codex模型不支持与配置姿势有一次我更新了Codex版本然后执行任务时突然报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account。意思是当前账号绑定方式不支持配置里指定的那个模型名。这个问题本质上是模型名、账号权限和客户端版本不匹配。定位过程其实不难。先查看Codex的配置文件看模型字段填的是什么codex config或直接打开~/.codex/config.toml然后把模型名改成当前账号/计划支持的稳定版本模型再同步更新Codex到最新版。改完之后任务就能正常跑了。这里有个通用经验AI编程工具的配置模型名不是越新越好稳定性优先如果遇到“model is not supported”这类错误第一反应先查版本和配置文件的映射关系不要盲目换更贵的模型。5.3 上下文爆满codex ran out of room这个报错在长任务场景下特别容易出现error running remote compact task: codex ran out of room in the models context window。字面意思是模型上下文窗口满了AI没法继续处理任务。我第一次遇到时已经让Codex连续干了两个小时的活儿它一直在改各种文件、输出日志和解释结果在最后一步突然报这个错连前面干完的活都差点找不回来。根本原因还是任务链条太长累积的token数量超出了模型窗口。解决办法分三步第一步把大任务拆成小任务单个任务控制在“改3到5个文件”以内第二步明确要求AI每次只输出“变更摘要”而不是整段代码摘要内容就够下一次分析用了第三步如果任务实在拆不开就开新会话让AI先读上次生成的摘要文件再继续。这套方法用到现在我再也没有因为上下文限制而丢进度。5.4 Unity/团结引擎打包微信小游戏的WebGL模板配置搜索“unity微信小游戏打包”的人特别多说明这个环节卡过不少人。我的经验是Unity导出的WebGL项目不能直接在微信开发者工具里跑必须使用微信小游戏专用的适配方案。具体来说要安装微信小游戏适配插件然后在Build Settings里选择WebGL平台Player Settings里的WebGL模板要选成“微信小游戏”专用模板而不是Unity默认模板。用团结引擎的话对微信小游戏的支持更顺滑很多配置都被内置了但模板选错的问题依然存在。导出完成之后会生成一个微信小游戏工程目录用微信开发者工具打开这个目录而不是打开Unity工程。很多人卡在这一步是因为一直在浏览器里预览WebGL版本结果发现微信的JSBridge接口在浏览器里根本调不通——这是预期内的事情小游戏必须在微信环境里跑。首包体积是另一个容易踩的坑。微信小游戏对初始包体有严格限制超过一定体积会导致首屏加载极慢。我的做法是所有图片和音频素材压到WebGL支持的格式关卡配置和数值表全部放到远程服务器上通过云开发存储动态拉取首包只保留引擎核心和第一关的少量资源后面几关的素材在玩家玩到对应关卡时才实时加载。这样首包从最初的十几兆降到了几兆加载体验完全上了一个台阶。5.5 多个AI工具客户端并存时的本地服务冲突我在用一些工具来集中管理多个AI客户端的配置凭证时踩过一次“切换后任务跑不起来”的坑。现象是配置切换完成后Codex任务一开始就报错提示本地服务连接失败。这种问题大多不是AI本身坏了而是本地端口或工作目录被另一个实例占用旧的关联进程没有完全退出。排查链路是这样先看报错里提示的端口号用网络工具检查端口占用情况然后找到占用进程并结束重启切换工具的关联服务最后删除临时缓存文件重新发起任务。解决之后我在流程上也做了调整切换配置前先退出所有正在运行的客户端进程切换完再启动不要图省事在服务运行的热状态下直接切换。这类本地服务问题本质上跟“多个浏览器同时抢一个摄像头”是同一类问题资源独占谁先抢到谁说了算。5.6 微信小游戏审核遇到的问题审核环节我第一版提交被驳回了。问题并不出在代码而是后台配置我没有在后台填写隐私保护指引而且代码里没有调用平台要求的隐私授权接口。这听起来很基础但真到提交的时候特别容易忙中出错。修改方式是在微信公众平台的相应入口里配置隐私保护指引说明游戏会收集哪些信息、用来做什么然后在代码里加上隐私授权的调用逻辑再重新提交。类目选择也值得多说一句。同一个游戏选不同类目审核的严格程度和需要的材料会不一样。休闲益智类目是最常见的游戏类目门槛相对清晰如果涉及随机抽取类玩法通常需要额外做概率公示避免被判定为“赌博诱导”。我在早期设计阶段刻意规避了这类玩法就是为了减少审核变量。最后聊两句20天结束之后我脑子里最深刻的感受不是“AI太厉害了”而是“限制真的能逼出创造力”。没有团队所以每一行代码都必须有存在的理由没有美术所以风格必须简化到几何图形也能撑住没有专职测试所以每修一个bug都要连带追一遍边界情况。AI在这中间的角色不是“替我飞”而是“让我落地”——它把重复劳动、信息检索、原型验证这些耗时的环节压缩了让我能把精力放在真正的决策上。如果你也想试试这条路我的建议是给AI立规矩让它输出变更摘要把任务拆到最小可验证的粒度每个新功能都先做最丑但能跑的最小闭环。最后分享一个小技巧每次让AI改完代码强制它在文件头部加一行注释写上这次改动的原因和日期这样即使过了很久再回来维护你和AI都能一眼看出当初为什么这么写。等你的小游戏上线之后你可能会发现最难的不是写代码而是决定不写什么。