上周一个小游戏在微信上过审朋友看到后台数据后第一句话是美术谁画的程序外包了我说都是我一个人搞的用Cursor和Codex扛完整个流程前后20天。他满脸不信但这事确实是我最近做得最值的一笔时间投资。今天不聊空话就把我一个人是怎么用这两款工具把策划、程序、美术、测试四个岗位的活儿全部消化掉的原原本本拆给你看。如果你也是一个人想上微信小游戏或者在小团队里被当成“全干工程师”用这篇应该能给你一套可复制的流程。我的经验是一个人干四个岗位不是不可能关键是你愿不愿意把工作拆成AI能理解、能接管、能批量处理的任务。底下所有内容都来自真实项目不是什么理论推演。1. 一人分饰四角的可行性关键是把工作拆成AI能咽下的粒度1.1 我如何拆解策划、程序、美术、测试的日常工作很多人一听“一个人干四个岗位”第一反应是这得加班到死。其实不是。四个岗位的工作里有大量内容属于“可并行”和“可被工具接管”。我在立项第一天就干了一件事把所有工作列成清单挨个打标签标注是“AI能直接做”“AI辅助做”还是“必须人工做”。策划这块核心是玩法规则、数值表、关卡配置。玩法规则必须自己拍板AI给不了创意但AI能帮你把“跳跃收集时间限制”这种玩法翻译成一份结构化的规则文档。数值表更是Codex的强项给它一个Excel模板和几条公式它就能把几十关的掉落概率、分数曲线全部生成出来。这样我就从“设计者”变成了“审核者”。程序是最适合AI代劳的部分。UI界面、角色控制、计分逻辑、动画状态机、音频管理、数据存储这些模块之间边界清晰正是Cursor和Codex最擅长的活儿。我只需要先定义好接口和数据流剩下的大段代码可以直接让Codex批量生成。美术听起来最难但其实小游戏的美术需求比大多数人想象中低。一个跳跃类游戏核心素材就是背景、平台、角色、UI图标。我用的方案是Unity Asset Store免费素材打底 统一配色 程序化生成几何图形。真正需要“画”的东西很少AI帮不上手绘的忙但它能帮你裁图、改色、批量调整导入设置。测试也同理。功能用例、边界条件、兼容性清单这些都可以让Codex按模板生成人工只需要在真机上跑一遍确认。所以我的判断是真正不能替代的只有“拍板”和“验收”其余都可以尽量拆分给工具。1.2 为什么选 Cursor Codex而不是只用其中一个有人会问Cursor本身就有AI补全和对话功能为什么还要再上一个Codex我用下来的体感是它们俩的定位完全不同。Cursor更像一个“副驾驶”你开着车它帮你看着路况、提醒你转弯Codex更像一个“远程实习生”你把任务文档丢给它它在后台吭哧吭哧给你写出一批文件来。为了让你更直观地理解我把它们的差异整理成了表格维度CursorCodex工作形态集成开发环境里的AI助手命令行 / API调用的自动代理适合任务写函数、改Bug、解释报错、重构生成多个文件、批量调整、跨模块搬运交互方式边写边提示人机共同编辑直接给任务描述等它交付结果对人的依赖每个改动都需要你确认需要你把任务拆到足够细但可以在后台跑典型场景“帮我看看这个空引用是怎么来的”“帮我按这个JSON结构生成所有配置解析类”学习成本低会IDE基本操作就能上手中需要习惯写结构化任务指令我在实际项目里的用法是Cursor负责“人在回路”的交互式开发我一边看代码一边让它改Codex负责那些“我不想一行行写”的批量活。比如项目中期需要为所有UI控件装配背景资源这种纯粹重复、量又大的工作用Cursor一个个点击改太慢了直接列好规则丢给Codex它一次性处理完我再抽查。如果你只用一个当然也能跑但效率会差很多。单打独斗的核心思路是尽量让“并行”发生Cursor在我看代码的时候等着提问Codex在后台批量跑任务两边不冲突。2. 前五天从0到Demo我搭了一条自动化编码流水线2.1 先砍玩法只留一个核心操作立项第一天我没急着开Unity而是花了一个小时做减法。我想做的是一款“跳跃收集类”小游戏这个品类有很多成熟产品可以参考风险低玩家上手快。但即便这样我也把玩法砍到了只剩一个核心操作点击屏幕或按空格跳跃踩中发光的平台获取分数连续踩中会有连击加成。这种极简设计不是为了无聊而是为了一个人能撑得住。玩法越复杂策划文案越长程序模块越多美术素材量越大测试用例指数级上升。核心规则只有一条我写的需求文档一页A4纸就能装下Codex理解起来也不容易出偏差。等你拿到反馈想加系统后续版本再迭代完全来得及。我把所有数值都做成了配置表用JSON文件存放。平台出现间隔、移动速度、分数奖励曲线、连击时间窗口全在配置表里。这样做的原因是我能让Codex只写一套万能解析逻辑后续调平衡只改配置不碰代码。2.2 用Cursor初始化Unity工程和微信小游戏转换链我的技术栈是Unity 2022.3 LTS。选这个版本不是因为它最新而是因为它对微信小游戏的支持最稳定。微信小游戏的环境本质上是WebViewUnity项目要通过导出WebGL再转成小游戏能识别的包。因此初始化工程时就要把整条转换链搭对不然到后期再回头改代价翻倍。这里有个细节很多人容易忽略微信小游戏适配需要安装官方提供的Unity适配插件不同Unity版本对应不同插件版本直接装最新版有时候会报不兼容。所以我在创建工程后的第一件事就是按Unity版本号去挑对应的适配插件把WebGL导出模板装好。Cursor在这个阶段做的事主要是帮我解读安装日志。我遇到过插件导入后菜单栏不出现的怪问题直接把控制台报错贴给Cursor它分析是插件和Unity版本缓存冲突我照着清理了ProjectSettings下的临时配置再重启就正常了。如果你也会一点技术只是懒得翻文档把这个报错解释工具用好玩游戏能省很多时间。顺便提一句Cursor是支持中文界面的如果你和我一样英文菜单看着慢半拍按CtrlShiftP搜索“Display Language”选Install the Chinese Language Pack重启后就变中文了。这事不起眼但“看得顺眼”在做项目时很重要。在Build Settings里我选择WebGL平台Scripting Backend选IL2CPP然后按插件要求把压缩格式、异常选项都调成推荐值。第一次打包耗时比较长但我把它当作一次环境验证打包成功后再加业务代码后续迭代就快了。2.3 给Codex派活的正确姿势很多人用AI编码工具觉得“生成的代码用不了”八成是任务描述不够清晰。我后来总结出一个给Codex派活的模板包含五要素项目背景、文件路径、接口依赖、边界条件、交付格式。第一次用完整模板生成的代码基本都能直接编译过。举个例子在写主角控制时我给Codex的任务是这样描述的你现在是一名Unity开发工程师。 项目位于D:/MyGame使用Unity 2022.3.21f1脚本后端IL2CPP面向微信小游戏。 请创建PlayerController.cs要求 - 控制角色左右移动键盘A/D移动端触控拖拽 - 跳跃点击屏幕或空格只允许二段跳 - 落地后自动触发Run动画空中触发Jump动画 - 使用CharacterController组件不要用Rigidbody - 所有参数速度、跳跃力、二段跳倍数用可序列化字段暴露到Inspector - 输出完整可编译的代码关键步骤写注释。这里面的重点是“面向微信小游戏”和“不要用Rigidbody”。如果不写这些Codex可能会给你生成普通PC端游戏的控制代码或者用物理组件导致后面适配小游戏时性能出问题。任务描述越细返工越少。第一天到第三天我用这个方法让Codex写完了PlayerController、ObstacleSpawner、ScoreManager、AudioManager、UIManager五个核心模块。Day 4开始把它们接进场景Day 5已经能在Unity编辑器里跑通完整的一局游戏。3. 中间十天美术、UI、音频和排行榜——最耗人力的部分怎么扛3.1 没有美术功底我用统一配色和免费素材做出风格一致的界面小游戏最容易被玩家吐槽的就是画面。但我不是美术也没钱外包所以我的策略是“别追求惊艳追求统一”。用一句话说让所有素材看起来属于同一个世界比单个素材多好看重要得多。我在Unity商店里花了一个下午淘免费素材。要的是呼吸灯式的发光平台、简洁的背景纹理、基本形状的装饰物。挑完素材后我用同一种色板重新给所有素材调色保证饱和度、明度一致。UI元素更简单全部用Unity UGUI自带的Image和纯色背景边框用九宫格拉伸按钮做轻微圆角处理。很多独立开发者会忘记音频。没有背景音和音效游戏会显得很干但自己录制又容易糙。我从免费音效站找了几段CC0授权的点击音、跳跃音、得分音再用Audacity做了统一响度处理。背景音乐找了一段循环时长30秒的轻快电子乐音量压在-18dB不抢戏。这些事看着琐碎但流程化以后耗时并不夸张。真正费时间的其实是“导入设置”纹理压缩格式、Mipmap开关、音频加载类型。我让Codex生成了一份“素材导入规范”Markdown文档之后所有素材按规范手动导入就不再纠结了。3.2 好友排行榜的开放数据域一个人也能搞定微信小游戏的好友排行榜是个很大的吸引力但也劝退了不少独立开发者。原因是它涉及“开放数据域”一个和主域逻辑隔离的特殊环境。简单解释主域是你游戏正常运行的JS/C#环境开放数据域是只能访问好友关系链数据的封闭环境它俩不能直接互相调用只能通过微信提供的消息接口通信。我是在项目第6天开始做排行榜的。先到微信公众平台申请好友关系链权限这个需要符合类目要求个人主体的小游戏通常可以申请但要在提审时说明用途。然后把开放数据域当成一个小型Canvas应用单独开发不能用主域的Unity渲染只能自己用Canvas画排行榜。具体流程是主域通过wx.getFriendCloudStorage拉取好友分数数据然后把消息发给开放数据域开放数据域收到消息后在Canvas上绘制列表。回头看我让Codex帮我生成了主域的调用代码骨架以及开放域的绘制逻辑但真正让它跑通还是得理解这套数据流。我的建议是别只看代码先把下面这个流程画在纸上玩家在自己手机上登录授权好友关系游戏结束时上传自己的分数排行榜界面打开时主域从微信关系链读取好友分数把分数数据整理成消息传给开放数据域开放数据域用Canvas绘制排名这五步里最容易出错的是第三步因为分数上传需要先在你的小游戏后端或微信云开发里做一个存储接口。我图省事直接用了微信云开发配合云函数省掉了自己买服务器的环节。这块如果自己从零搞第6天肯定搞不完但用Codex生成云函数模板再按需求改改一天半左右就能通。3.3 低端机适配和包体控制我的测试机里有台红米老机型性能非常差。游戏如果在这台机器上能稳定跑大部分用户就都没问题。所以在中间十天里我专门留出两天做适配优化。首先是屏幕适配。用的Canvas ScalerUI缩放模式设为“按屏幕宽度适配”这样不同比例的手机都能保证核心操作区域完整。但刘海屏需要在顶部留安全距离微信小游戏里可以通过安全区API获取顶部高度然后动态调整UI位置。其次是包体控制。微信小游戏首包限制非常严格一不小心就超了。我的做法是所有UI图集打成一个图集背景音乐和音效全部用压缩格式Shader只用最简单的不受光shader能不用实时阴影就不用。最后首包压在了3.5MB左右留出余量。如果你有额外关卡资源一定要放在子包里用wx.loadSubpackage按需加载。我当时把三个奖励关卡放进了子包玩家玩到对应进度时才下载既不卡启动又能降低首包体积。4. 最后五天从“能玩”到“能上线”微信审核和兼容性的临门一脚4.1 微信开发者工具和真机调试里的高频坑代码在Unity编辑器里跑得好好的不代表转成微信小游戏也能跑。我最后五天几乎天天泡在微信开发者工具里踩了三个最典型的坑。第一个坑是网络请求的合法域名。小游戏里如果请求自己的服务器或云开发接口需要在微信公众平台配置合法域名开发阶段虽然可以勾选“不校验合法域名”但提审版本必须关闭这个选项否则正式环境请求全挂。我第一次上传时忘了配置排行榜数据一片空白查了半天才发现是域名白名单问题。第二个坑是本地缓存。Unity PlayerPrefs在小游戏环境里的行为跟本地不同我原本只缓存玩家分数和设置结果偶尔出现数据丢失。后来改用微信小游戏自己的storage接口通过桥接层封装成统一方法这才稳下来。第三个坑是首屏白屏时间。微信小游戏启动时要加载Unity WebGL的WASM文件如果处理不好玩家要盯着白屏两三秒。我做了两件事启动场景尽可能简单只放一个Loading界面开启微信小游戏插件推荐的“代码分包预下载”配置让核心逻辑在启动阶段并行加载。真机调试时还有一个容易被忽略的细节开发者工具里的表现和真机有差异。比如字体渲染、SafeArea判断、WebGL纹理上限都会不一样。我每天固定花一个小时用真机把主要流程点一遍发现问题直接记在手机备忘录里晚上统一修。4.2 提审材料准备Codex能帮忙但别全交给它微信小游戏提审不止上传代码包还需要填写一堆材料。包括游戏名称、简介、类目、截图、隐私保护指引、版号信息非游戏类目可能不强制但涉及虚拟支付会有额外限制。我第一次提交时心态很乐观结果因为类目选错被驳回一次。这里Codex确实帮了大忙。我让Codex根据我的玩法描述和功能清单生成了一份提审材料草稿包含简介、截图说明、玩法说明、隐私用途表格。因为Codex比我更擅长把功能翻译成“平台方爱看的合规语言”省去不少整理时间。但我必须强调AI生成的提审材料一定要人工审。因为它不会知道你的实际数据存储逻辑也不会知道你接了哪些第三方SDK。尤其隐私保护指引必须按你代码里真实用到的权限来填少填一项或被抽查到轻则驳回重则下架。我最后花了一个小时逐字核对所有权限和接口才点击提交。4.3 灰度发布、埋点和第一版数据闭环提交审核通过以后我没有直接全量发布而是先做了灰度发布。微信后台可以设灰度比例我放了5%的用户进来用来验证崩溃率和关键流程通过率。同时我在游戏里埋了几个关键事件启动完成、成功进入第一局、结束一局、触发分享、点击排行榜。每个事件上报到微信数据分析后台。埋点这件事看起来不性感但对独立开发者极其重要。没有数据你会沦为自己拍脑袋调游戏。我后来靠这些数据发现一个很大的问题第一局退出率接近40%说明新手引导不够清晰。于是第二天就改了一个“高亮光圈引导”的交互退出率降到20%左右。上线不是终点只是另一个起点。我给自己留的计划是每周一个小版本每两周一个玩法更新。而第一版的数据就是后续决策的依据。5. 复盘AI没有让我失业但让我一个人活成了一支队伍5.1 20天时间实际怎么花的很多人听到“20天上线”会觉得夸张我真实的时间分配其实并不紧张。为了让你判断自己的项目能不能照搬我列了一张实际投入表阶段时间对应岗位核心工具玩法设计与需求拆解2天策划文档 Codex工程搭建与核心Demo3天程序Cursor Codex美术、UI、音频5天美术Asset Store 免费音频排行榜与云开发3天程序Codex 微信云开发适配、性能与真机调试3天测试微信开发者工具 真机提审材料准备与审核2天运营Codex 人工核对灰度发布与首个补丁2天运营微信后台 埋点总时长比20天还少一点但我故意留了缓冲因为真机调试和审核等待时间不可控。如果你的项目玩法和我差不多这个时间表可以当参考如果你的玩法复杂一倍时间大概会变成三倍而不是两倍。因为复杂玩法带来的边界条件和素材量是指数级增长的。5.2 哪些环节AI帮了倒忙我不会神话AI工具。这20天里Codex生成的代码大约有30%被我改过或重写过。最典型的一个例子它给我生成的排行榜云函数直接用了普通JSON存储没有考虑微信云开发数据库的权限规则导致真机上所有玩家都能改别人分数。这种逻辑漏洞如果只靠读代码很难发现必须实际跑一遍多用户场景。我自己又花了半天重新设计数据库权限。Cursor也有帮倒忙的时候。它的自动补全有时候会在修改一个类时顺带改动了我根本没让它动的成员变量。尤其Unity的序列化字段一旦被误改场景里的引用全断。所以后来我养成了一个习惯每次Cursor大改完先用版本控制系统看diff确认改动范围再继续。我的建议是不要相信AI说“已完成”。它说“已完成”只代表它没有遇到编译错误不代表逻辑正确。你必须按照玩家的真实路径从头到尾手动过一遍。这个验收环节不能省。5.3 如果你想复刻这个流程记住这三条第一先跑通最小闭环再让AI铺量。不要上来就让AI生成十几个文件先手动或半手动做出一条最简的“开始游戏-操作-结束-展示分数”链路确认全部通了再让Codex批量铺其他模块。这样能避免“生成了几千行代码却跑不起来”的失控感。第二把提示词当成代码仓库来管理。我专门建了一个prompts目录每个模块的任务描述都存成Markdown文件后面项目复用直接改参数。你越积累后面的项目启动越快。第三AI生成的文件必须有人工review机制。哪怕你只是快速扫一遍也要看几个关键点外部调用有没有异常处理、数据库权限是否正确、有没有埋了后门或测试逻辑。单人开发没有第二双眼睛你就把自己当成那个Code Review者。这次项目结束后我最大的体会是一个人干四个岗位靠的不是压榨自己而是把岗位动作标准化让AI处理最耗时间的执行层自己专注于拍板和验收。这种模式不一定适合所有人但如果你能接受“先写清楚需求再放手给工具”它会把你从996式的单打独斗里捞出来。