一人三周用Cursor和Codex开发微信小游戏上线全复盘

20天前我给自己下了一个听起来有点疯的目标一个人在三个星期内用Cursor和Codex这两个AI工具把一个微信小游戏从零做到上线。不是做个Demo而是要过微信审核、能被用户搜到、能玩的那种。更疯狂的是我给自己拆了四个岗位——产品、开发、美术、测试运营一个没少。结果是真的做成了而且踩的坑比想象中多得多。今天这篇不写教程也不吹AI神器就是把这段经历完整复盘一遍给同样想一个人干点东西的朋友做个参考。先交代一下背景我做独立开发有几年了之前也上线过一些小工具但小游戏是第一次。技术栈选的是Unity因为熟悉而且微信小游戏已经有比较成熟的转换插件。AI工具方面主力是Cursor编辑器配合Codex做批处理和自动化任务。20天里我几乎把所有能交给AI的活儿都交给了AI自己只做决策和兜底。这篇文章里你会看到四个岗位具体怎么拆、20天如何排期、微信小游戏打包有哪些隐藏门槛以及AI工具在实际项目中哪些地方靠得住、哪些地方必须人工盯。1. 四个岗位拆解项目还没动手先把“人”的问题解决1.1 一个人为什么还要给自己设四个岗位很多人会问一个人干活直接做不就行了拆岗位不是多此一举吗我之前的做法也是想到什么做什么结果往往是“开发到一半发现玩法不好玩”“测试时才发现安卓机型闪退”“上线前才发现连游戏名字都没想好”。一个人看似自由但实际上如果没有职能边界很容易陷入“什么都做了什么都没做透”的状态。这次我在项目第一天就给自己立了一个规矩哪怕只有一个人也要在产品经理、程序员、美术、测试运营这四个角色之间来回切换。切换的标记是“当前正在思考的问题”如果我在纠结“玩家为什么要玩这个游戏”那现在就是产品经理如果我在修改代码逻辑那现在就是程序员如果我在调UI颜色和图标那现在就是美术如果我在反复点按钮测流程、看数据那现在就是测试运营。角色切换的另外一个好处是能“强制”自己跳出单一视角。AI工具一天能生成几百行代码但生成出来的东西到底有没有用需要站在产品的角度去判断。同样AI能画出手绘风格的图标但如果不符合微信小游戏的UI规范就得让美术角色出来说话。拆岗位的本质是逼自己把“做出来”和“做对”分开。1.2 这次项目里四个岗位的具休范围因为是一个人岗位范围不能像大厂那样画得特别细但必须有明确的产出物。产品岗的产出是一页纸的玩法说明、核心循环图、功能优先级列表。我给自己定的玩法很简单玩家控制一个小球躲避障碍通过收集道具获得高分支持微信好友之间比分数。核心循环就三个动作开始游戏、操作躲避、看到评分结果。其他所有P2功能皮肤、排行榜、成就都放到P2绝不占用前期时间。开发岗的产出是Unity工程、微信小游戏转换后的包体、可运行的代码。这块工作量最大也是Cursor和Codex介入最深的环节。我会让Cursor在编辑器里直接生成Unity C#脚本比如移动控制、碰撞检测、UI事件绑定然后自己review一遍再拖到场景里。Codex则用来处理重复劳动比如批量重命名资源、批量修改Prefab上的脚本参数、给UI按钮生成统一的事件响应代码。美术岗的产出是游戏图标、启动图、背景图、玩法元素的基本视觉。说实话我没有画图能力所以美术这里用了两个工具一是用AI绘图工具生成原始素材二是用Cursor修改Shader或UI样式把风格统一。微信小游戏对素材尺寸有要求图标和启动图必须符合规范这部分不能靠猜否则提审会被打回。测试运营岗的产出是一份测试用例表、一份上线检查清单、以及上线初期的数据监控计划。我会写一个简单的测试脚本用Unity Test Framework跑核心玩法的自动化测试同时每天抽半小时用真机在微信开发者工具里手动点一遍关键流程。运营方面因为还没法做很复杂的埋点就先用微信自带的“小程序数据助手”看基础指标访问人数、点击次数、分享次数、人均时长。1.3 AI怎么压缩每个岗位的时间占比以前做一个完整小游戏至少需要两到三个月这次压缩到20天最重要的原因是把每个岗位的重复劳动都交给了AI。产品岗需求文档用Cursor生成我只需要输入几个关键词它就帮我列出玩法的五个卖点、三个竞品差异点、以及首版功能范围。当然生成的东西不能直接用但至少帮我建立了思考框架。开发岗代码生成和代码修复的效率提升最明显。以前写一个UI面板的交互逻辑要半天现在基本是“说人话——生成代码——复制到工程——调整位置”四步走。美术岗用AI生成贴图后再用Cursor改Shader或贴图调整代码把一个粗糙的AI绘画变成风格统一的游戏素材节省了大量手工PS时间。测试运营岗Cursor可以生成边界条件测试用例Codex还能写脚本模拟点击链路自动把反馈报告输出到文本文件。这些以前要花2小时的工作现在10分钟能搞定。不过必须承认AI压缩的是“执行时间”并没有压缩“决策时间”。玩法好不好、颜色搭不搭、按钮位置合不合理这些还是得人来做。所以我的原则是凡是“能明确描述规则”的任务全部交给AI凡是“需要审美和同理心”的任务自己死磕。2. 工具组合拳Cursor和Codex到底各自承担什么角色2.1 为什么不是纯手写也不是只用一个AI工具在动工之前我就试过把开发流程全丢给Cursor让它直接从零生成一个完整的小游戏。结果发现它生成的代码经常出现“看起来没问题一运行就报错”的情况而且上下文一长它就开始忘记前面的约定甚至会重复生成同名类。后来我又单独试了Codex发现它在命令行里执行批量任务非常利落但你没办法跟它做那种“你一句我一句”的即时修改。所以这次我用的是组合策略Cursor负责编辑器内的探索式编程Codex负责外围的批量任务和自动化脚本。简单比喻一下Cursor是我的结对编程搭档Codex是我的实习生外包团队。2.2 Cursor负责“会话式开发”从需求到代码的快速原型Cursor最擅长的是在一个已有的代码库内部进行局部修改。比如说我在Unity里搭建了一个场景想让小球根据加速度计的数值左右移动。传统做法是先查API文档再写Input.acceleration的封装还要处理平台差异。用Cursor我只需要在对话窗口里输入“帮我写一个Unity C#脚本让对象在移动平台上通过加速度计控制左右移动并保证在微信小游戏环境里正常运行。”它会直接生成脚本甚至帮我加上了#if UNITY_WEBGL这样的平台判断代码。这里有个很关键的细节Cursor生成的代码默认只是“文本”不会自动放进你的工程结构里。你需要新建脚本文件把代码贴进去然后在Unity里编译。如果编译报错把报错信息复制回Cursor它能立刻给出修复建议。这种“编译错误→AI修复→继续编译”的循环是我个人觉得Cursor最有价值的地方比它直接生成一整个游戏框架可靠得多。Cursor的另一个强项是跨文件重构。比如我要把游戏里的“ScoreManager”类改成一个资源加载管理器如果我手工去改可能要搜十几个引用点。用Cursor的编辑功能它能基于语义理解帮你改引用并保留逻辑大大减少了遗漏。2.3 Codex负责“批量执行”改样式、修bug、补测试Codex在我的流程里更像一个“任务调度器”。它可以在终端里接收命令然后基于代码库执行复杂的变更任务。举一个实际的例子项目后期我突然想把所有Button组件的圆角半径从8像素改成12像素同时把全局的字体大小从16像素调到14像素。如果一个一个改100多个UI节点能改到天荒地老。用Codex我写一个简单的任务描述它就能解析所有场景文件批量替换相关的参数。刚开始我不放心先让它跑一个只读扫描命令输出哪些文件会受影响确认没问题后再让它执行。Codex还有一个特别好用的场景是写测试脚本。小游戏开发里很多测试是重复性的比如“模拟点击开始按钮→加载场景→产生分数→弹出结算面板”这条链路。我可以让Codex生成Unity Test Framework的脚本并且在测试里加入异常捕获。然后我用命令行启动测试Codex会读取测试结果如果发现失败它会自动分析日志把可能的原因列出来。这一点帮我省下了大量排查“预期结果”与“实际结果”差异的时间。同时Codex也能快速修复编译错误尤其适合那种错误信息特别长、涉及多个依赖项的报错。你只要把它输出的错误信息完整贴给它它基本能定位到具体文件和行号有时候甚至能直接给出修好的代码块。2.4 两者协作的“交接仪式”很多人用AI工具时是想起来哪个用哪个没有固定的协作流程。我是这样设计的当我在Cursor里写完一段核心逻辑后会把代码提交到本地Git仓库然后写一句提交备注再把“当前代码概况接下去需要做的事”以注释的形式写在一份TASKS.md文件里。Codex在启动时指定的第一个任务就是读取这份TASKS.md接着自动执行里面标记为“待处理”的条目。这样两个工具之间就有了一个简单的交接机制既避免上下文丢失也方便我自己追踪进度。这个“交接仪式”虽然简单但实际上解决了AI工具最大的一个问题——记忆。Cursor和Codex都不是跨会话记忆的但通过一份常驻的文本文件它们能把上一阶段的状态和下一阶段的目标串联起来效率提升非常明显。3. 20天时间线从玩法想法到微信小游戏包体的真实排期3.1 前5天定玩法、搭场景、把核心循环跑通第1天到第2天只做一件事确定玩法并做一版最简可玩原型。我没有花时间去写正式的策划文档而是直接在Cursor里描述玩法和规则让它给我生成一份“玩法计算逻辑”的代码框架。比如小球的速度公式、障碍物的生成频率、判定碰撞的逻辑。虽然代码很粗糙但第2天晚上我就能在Unity编辑器的预览窗口里用键盘控制小球躲避障碍了。第3天到第5天主要优化手感。手感这个东西很玄但本质上就是几个参数小球移动速度、加速度曲线、障碍物的生成间隔、碰撞判定半径。我每天上午用Codex写一点参数调优脚本比如让角色自动跑20次随机分布的测试记录每次碰撞时间。下午根据统计结果调整参数再让Codex重新跑一轮。AI在这里的作用不是替你调出“最佳手感”而是帮你快速验证“手感是否随着参数在变化”真正的判断仍在于我自己的直觉。到第5天结束时核心循环已经完整了点击开始按钮→小球出现→躲避障碍→碰到障碍后显示得分→分享按钮→回到开始菜单。3.2 中间10天美术资源、UI适配、存档与分享功能从第6天开始工作量重心转移到了“让它看起来像个游戏”。我先用AI绘图工具生成了三套风格备选扁平卡通风、霓虹炫彩风、手绘涂鸦风。每套都让Cursor生成截图脚本自动把Unity的Game视图导出成PNG然后我快速对比。最后选定扁平卡通风因为它更适合跑起来流畅而且AI生成的素材一致性最好。选定风格后美术岗正式开始干活。我用AI绘图工具批量生成背景、主角小球、障碍物、道具图标等素材然后用Cursor写了一个资源导入器脚本自动把下载好的PNG文件裁剪到指定尺寸并生成对应的Sprite。这个过程中最大的坑是“资源尺寸不一致导致UI错位”所以我在导入器里加了一层校验如果图片宽高比和预设不一致就改成占位图并输出警告。第8天到第10天接UI面板。Cursor生成了一套通用UI组件脚本包括开始面板、结算面板、排行榜面板。我还用Codex批量给每个按钮添加了点击音效。微信小游戏对音频格式有要求一般用m4a而非mp3我没注意结果打包后声音全部丢失排查了很久才发现是编码问题。这个细节在开发文档里写了但第一次接触的人很容易忽略。第11天到第12天处理存档和分享。微信小游戏的世界里存档主要依赖本地Storage但也要考虑用户换手机的情况所以我加了一个“游客号”逻辑把分数保存到微信开放数据域的KV存储里。分享功能则是通过微信小游戏的分享API生成一张分享图图片上的文案我让Cursor批量生成了20条筛选了5条不那么像“营销号”的再用Codex替换到分享代码里。3.3 最后5天微信环境适配、性能优化、提审准备第15天到第16天我把Unity工程转成微信小游戏。这个过程不是一键完成的需要用到官方提供的“微信小游戏Unity插件”。我不小心用了错误版本的WebGL模板结果转换出来后加载进度条完全不显示游戏的每个场景都要等十几秒。后来我参考了社区里的“团结引擎打包微信小游戏时如何正确配置webgl模板”的避坑指南才重新配好。第17天到第18天进行性能优化。微信小游戏跑在浏览器容器里对初始包体大小很敏感。我首包做了好几次压缩把公开贴图改成压缩格式、把不需要的Shader禁用、把启动场景里的光照烘焙关闭。Codex在这里帮我写了自动检测脚本统计Resource目录里所有资源的引用情况找出“貌似被用到但实际没加载”的资源直接清除。第19天到第20天提交审核。微信小游戏提审前需要准备一些材料比如游戏截图、简介、以及著作权相关文件。我提前一天在微信公众平台查询了最新的规则发现个人主体需要提供计算机软件著作权登记证书的扫描件或者可以提交一份“自主知识产权承诺函”。我选择提交承诺函很快就通过了。提审后等审核结果期间我用真机在微信开发者工具里跑了一遍全流程确保没有“虚拟支付”或“诱导分享”等违规文案。幸运的是第20天晚上审核通过小游戏正式上线。4. 微信小游戏打包与合规最容易被AI忽略的硬骨头4.1 从Unity导出微信小游戏的转换链路很多人在这一步卡住觉得AI工具能帮忙解决。但实际上AI只能帮你处理“转换之后”的代码问题真正的转换链路还是得靠自己理解。简单说一下Unity需要先打包成WebGL版本再用微信小游戏插件把WebGL产物转换为小游戏包体。这个过程中WebGL模板决定了最终小游戏的操作模式和加载行为。我遇到的一个具体问题是默认模板会启用多线程支持但微信小游戏环境对多线程的支持是有限制的。这导致转换后打不开控制台一直报错。后来我改用单线程的WebGL模板并关闭了“增量打包”选项问题才解决。这个教训的核心是遇到报错时先想想是不是模板兼容性问题不要急着让AI改业务代码否则会在错误的楼层里修水管。4.2 WebGL模板配置与首包大小控制首包大小是微信小游戏审核的一项硬指标。如果首包超过4MB加载体验就会很差。其实官方文档写的是“首包不超过4MB小游戏总包不超过20MB”如果你的资源太大就必须拆分成远程资源。我用Codex做了一件事扫描所有由于美术素材“几乎无语”地塞进Resources目录的贴图和音频给它们生成一个清单标注大小和引用情况。然后我决定把背景音乐和几个大贴图放到腾讯云CDN上运行时再通过网络加载。这里又踩了一个坑微信小游戏不允许在程序启动时同步网络加载资源必须走异步接口。所以我把加载逻辑改成了“加载→显示进度条→加载完成→进入游戏”并用了一个异步加载工具类。如果你也用Unity开发微信小游戏记得在构建设置里把“Compress Files”选项开启同时使用“LZ4”压缩。导出后在微信开发者工具里查看包体大小分布哪块占得多就优化哪块。这个步骤不要依赖AI自动完成因为它需要你对工程结构有全局认识。4.3 著作权与版号个人开发者需要知道的底线热词里有人问“微信小游戏现在需要著作权登记么”我的实际经验是如果你的游戏是自研原创的可以提交“计算机软件著作权登记证书”也可以提交“原创声明承诺函”。但这里必须提醒版号是另一个层面的东西目前微信小游戏平台对无需内购的休闲游戏走的是“备案审核”流程不是传统意义上的游戏版号。个人开发者最好在提审前仔细阅读最新的平台规则不要盲目听信攻略。我当时选择直接申请软著因为以后万一想做付费道具或广告变现软著是基础资质。软著申请周期一般在一个月左右但我这个项目只有20天所以我先提交了承诺函把游戏成功上线了。等软著办下来后我再更新主体资质。这个顺序是可操作的但前提是你不要在未获资质的情况下从事商业化运营。说白了人可以先上路但该有的证得陆续补上。提审时还有一个容易被忽略的点隐私协议。虽然休闲游戏不涉及大量用户隐私但微信平台会在审核时检查你是否有“用户隐私保护提示”。我在游戏里加了一个弹窗简要说明我们收集哪些数据比如游戏分数并加了用户同意的按钮。这句话看起来简单但如果没有做审核会被以“隐私不合规”为由驳回。5. 一个人作战的AI翻车现场教训与防坑清单5.1 Cursor提示词泄露与工程安全Cursor确实方便但我在项目第三周时发现了一个安全问题Cursor的云端代码索引功能会把我的工程文件内容发送到服务器。如果你在代码里写了一些敏感信息比如云数据库密码、支付密钥、内测链接那这些信息就等于被“共享”出去了。这不是危言耸听社区里已经出现过“Cursor提示词泄露”的讨论。我采取的措施是在Cursor的配置文件里关闭“云端索引”选项或者只对本地项目开启代码索引。同时所有真实密钥都用环境变量或本地配置文件保存并且在.gitignore里忽略它们。聊天窗口里我也不会粘贴任何完整的密钥字符串而是用占位符代替。对于Codex也是类似的我会在任务提示里提醒它不要读取某个敏感文件。5.2 Codex上下文窗口溢出与任务拆分“error running remote compact task: codex ran out of room in the models context”这个报错我在第11天的时候遇到过一次。当时我让Codex一次性分析“UI管理器、网络管理器、存档管理器”三个模块的代码并生成一份统一的优化建议。结果它直接把上下文窗口塞爆了报错说跑不动了。解决办法并不难就是拆分任务。一次只让它分析一个模块并且指定输出格式先给结论再给建议最后给代码块。与其让它输出一个“大而全”的报告不如让它分三次输出三个小报告我再自己汇总。这个经验也适用于Cursor对话轮次太多个别功能就会变“笨”及时开启新对话并引用关键代码片段效果反而更稳定。5.3 让AI生成的代码可维护命名、注释、模块化AI生成代码有一个通病能用但很难改。因为它的训练数据来自海量开源项目常常会生成一些“名字叫A、实际做B”的函数比如上一次生成的UpdateScore()里除了更新分数还偷偷修改了UI文本、检查了游戏结束条件甚至触发了一次音效播放。这种“副作用”刚开始没问题但后期想加新功能时你会完全摸不着头脑。我的对策是在Cursor提示词里明确要求“每个函数只做一件事不允许产生额外副作用函数名要清晰类名要用业务术语”。如果还是生成了一坨我会手动抽方法把副作用拆开。另外我还让Codex精读过我的TASKS.md并在里面维护一份“代码风格指南”内容只有几句话使用PascalCase、禁止全局静态状态、所有数值参数必须定义常量、每个公开方法必须有XML注释。这样两个AI工具在处理代码时就有了统一的约束。5.4 AI的“幻觉”与无效修改AI有时会一本正经地给你一个不存在的API比如Unity根本没有GameObject.ChangeLayer()这个方法但Cursor会生成一个调用它的代码。遇到这种情况最好的验证方式就是编译。所以我的工作流里永远会有一个“编译检查”步骤只要AI改完代码我第一时间按CtrlShiftB或点击编译按钮看是否报错。Codex也出现过“无效修改”的问题它说它改了配置但实际内容没变。后来我发现是因为它默认使用了“只读模式”需要显式开启“写操作”权限。这个细节非常关键很多人在执行Codex任务时发现“什么都没发生”就是因为忘了给它写入权限。6. 上线后24小时一个人怎么干运营的活6.1 数据埋点与用户反馈入口小游戏虽然上线了但真正的工作才刚刚开始。我在上线的当天就在微信公众平台里面配置好了“微信小程序数据助手”这样可以实时看访问人数、点击次数、分享次数、人均时长。但是光看这些还不够我还在游戏里埋了一个“反馈”按钮玩家可以直接在游戏中提交建议和问题。由于没有后端服务我让反馈内容通过微信小游戏的云开发能力存入云数据库然后我每天早上看一眼。为了鼓励用户反馈我在结算页面设计了“遇到bug点这里报告”的小按钮玩家点击后会弹出一个对话框可以输入文字。虽然很简单但上线第一天就收到了7条反馈其中有一条是“在iPhoneX上按钮位置偏下”这个信息对我接下来的适配优化非常有价值。6.2 社交裂变与分享设计微信小游戏最核心的运营动作就是“让用户愿意分享”。我在游戏里设置了两个分享触发点一是游戏结束后的“炫耀一下”按钮二是达到个人最佳分数时的自动弹窗。为了让分享更有吸引力我用Cursor生成了一套分享图模板把当前分数、角色造型、以及“你能超过我吗”这些文案动态绘制到Canvas上再以图片形式给用户分享。第一天的数据证明这个设计是有效的约18%的玩家点击了分享按钮。但还有82%的人没有分享所以我准备在下个版本里增加“分享奖励”分享后获得一个小道具。这个功能对代码结构的要求不高但会影响游戏平衡性我正在权衡。6.3 以天为单位的快速迭代计划上线后第三天我收到微信后台的一条审核提醒说游戏内某处文案涉及“推荐”两个字有诱导嫌疑。我赶紧让Cursor搜索所有UI文本把“推荐”改成了“看看”。这类小修改基本上每天都会发生所以我的计划是每天下午集中处理用户反馈和平台提示晚上用Codex跑一遍自动化测试确保第二天早上出新版本。一个人运营的节奏必须以“天”为单位不能以太长周期为单位。因为你的上下文有限时间也有限。AI在这时候的用处不是“创造新功能”而是帮我快速定位问题。比如用户反馈“安卓手机卡顿”我让Codex分析性能面板发现是某个Shader的matcap计算在低端机上的开销太大第二天直接把那个Shader换成普通Unlit问题就解决了。这20天走下来我最深的感受是AI不会替你站在用户的立场上考虑“这个游戏到底有没有意思”但它能帮你在想到一个点后以最快速度把它变成可见的、可体验的东西。一个人做四个岗位不是神话只要你懂得把重复劳动交给工具把审美和决策留给自己20天上一款微信小游戏是完全能复制的路径。如果你也正打算一个人动手希望这篇复盘能帮你少踩几个我踩过的坑尤其是WebGL模板和著作权提交那两步提前准备好真的能省出两三天时间。