我承认当这个项目真正提审通过的那一刻我自己都有点恍惚。从立项到拿到线上版本掐指一算刚好20天团队成员那一栏只有我的名字但活儿却实打实是四个人干的产品、客户端开发、UI设计、测试。一个人干四个岗位放在五年前想都不敢想但这次我真用Cursor和Codex这对组合扛下来了。我知道很多人看到这类标题的第一反应是标题党或者幸存者偏差。确实AI编程工具火是火但真正用它们完整落地上线一个产品的人并不多。这篇文章不打算吹什么AI取代程序员的论调我只想把我这20天里每天怎么安排、Cursor和Codex到底拆开来干什么活儿、微信小游戏打包时那些绕不过去的坑一件一件讲清楚。无论你是独立开发者、小团队的技术负责人还是准备尝试AI辅助开发的新人这篇内容应该都能给你一个相对完整的参照系。1. 这20天的底气为什么小体量游戏敢押注AI工具链先交代一下背景。这个项目是一款休闲益智类的微信小游戏玩法不复杂核心机制大概半小时就能讲清楚但美术表现、关卡节奏、性能适配这些活儿一样都不能少。选择微信小游戏作为目标平台本身就是经过考量的不需要用户下载安装扫码即玩天然适合社交裂变而Unity配合团结引擎导出WebGL是目前比较成熟的技术路线。很多人问我为什么一个人还敢接这种全栈全岗的活儿我的判断依据其实就三点。第一项目体量足够小。这个小游戏没有服务端所有关卡数据全部本地化不需要账号系统不需要支付连排行榜都砍了。它就是一个纯粹的单机体验这对一个人来说意味着没有运维压力、没有并发问题、没有数据一致性要处理。第二玩法逻辑足够独立。游戏内所有系统都可以拆成独立的模块关卡配置、计分规则、动画控制、音效管理。这些模块之间耦合度低特别适合让AI分模块生成然后我统一串接出了问题也容易定位。第三Unity生态足够成熟。微信小游戏对Unity的支持已经有几年了网上关于打包、适配、优化的方案一大堆遇到问题搜得到答案。最坏情况下我还可以手动改导出的JavaScript模板代码来兜底这说明技术风险是可控的。至于工具选型为什么是Cursor加Codex而不是别的Cursor的强项是交互式编程它像一个真正坐在你旁边看你写代码的结对伙伴适合处理需要上下文连续理解的逻辑开发Codex则更适合当一个不需要休息的代码苦力把一些定义清晰、重复性高、边界明确的任务扔给它它在后台批量跑我同时去干别的活儿。两个人的节奏不一样搭配起来正好覆盖了开发的两类典型工作。这里我想多说一句不要指望AI全程自动写游戏。这个项目里AI直接产出的代码占比大概在六到七成剩下三四成仍然需要我手动去调整、串联和修补。原因很简单小游戏是个整体工程AI擅长的是局部实现而模块之间的胶水代码、全局状态管理、资源加载时序这些只可意会的东西AI暂时还理解不了。把预期放对工具才能发挥出真正的杠杆作用。2. 20天时间线四个岗位的真实工作量分布我见过不少独立开发者的计划表最常见的问题是把所有时间都堆在开发上结果产品定义不清、测试缺失、上线前手忙脚乱。这次的20天我在排期上其实非常刻意地做了分配。整体节奏大致如下时间段阶段主要工作对应岗位第1-3天需求收敛与原型验证核心玩法定义、UI草图、交互流程产品 设计第4-6天技术验证Unity导出WebGL、微信开发者工具跑通最小Demo开发第7-14天核心开发玩法逻辑批量生成、关卡配置、动效接入开发第15-18天内容铺量与打磨关卡扩充、数值调整、音效、UI细节设计 开发第19-20天打包上线微信提审、真机适配、修复反馈测试 开发这张表看着简单但每个阶段背后的取舍其实很有意思。第1到3天是产品阶段。我给自己定的规矩是这两天不写一行代码只写需求文档和画线框图。一个人最大的敌人不是效率低而是想法太多。我一开始列了十几个玩法方向到最后只保留了核心玩法、三个道具、一套计分规则其余的全部砍掉。砍需求的判断标准就一条如果我一个人20天做不出来那再好玩的点子也不要。Cursor在这个阶段帮了我一个忙——我让它基于我的玩法描述生成了一份交互流程图和状态机描述这让我在后续写代码时有了清晰的参照。第4到6天是技术验证阶段。这一阶段决定了整个项目可行还是不可行。我做的第一个技术验证是最小可玩Demo一个方块在屏幕上移动并碰到目标点得分。这个Demo虽然简陋但它跑通了完整链路——Unity里写脚本、导出WebGL、微信开发者工具加载运行、触摸事件响应。我记得第一次在微信开发者工具里看到那个方块能跟着点击移动的时候悬着的心才放下来。这一步最大的价值是把We bGL导出这事在微信环境里到底行不行这个最大不确定性提前消灭了。第7到14天是核心开发阶段。这是整个项目最长的阶段也是Cursor和Codex效率发挥最明显的阶段。我会在下一节详细展开工具分工这里说说整体安排每天早上我会先把当天的功能模块拆解成任务清单定义清楚输入输出然后开始用Cursor逐个实现下午把一些已经定义清晰的批量任务丢给Codex后台执行我自己同时处理关卡数据和美术调研。每天晚上固定抽一段时间做编译和冒烟测试保证第二天的起点是干净的。第15到18天是铺量与打磨阶段。核心逻辑跑通之后最消耗精力的其实是内容量。一个小游戏如果只有三关玩家五分钟就腻了。我利用配置化的思路让AI根据我给出的难度曲线批量生成关卡数据再手动抽查调整。UI动效、音效反馈、结算界面这些细节也是在这几天集中处理的。说句实在话这个阶段工作量大而且琐碎但恰恰是AI工具让内容铺量这件事从不可能变成了可能——换作手写这些重复性的关卡配置和UI状态代码至少要多花一周。第19到20天是上线冲刺阶段。提审之前做了一轮完整的真机测试用微信开发者工具的真机调试功能扫了大概四台不同型号的手机发现并修复了启动图和屏幕适配的若干问题然后提交审核。微信小游戏的审核效率比我预想的快不少中间被打回一次是因为缺少软件著作权证明补上之后第二天就过了。这里顺便提一句很多第一次做微信小游戏的人都会问现在还需要软件著作权登记么我的实际经历是提审时会用到。这件事务必提前规划别等审核打回来了再去办流程需要时间会拖慢你的上线节奏。3. Cursor和Codex的正确分工一个写新代码一个当苦力这一节是整个项目最核心的方法论。很多人用AI编程工具效率低根本原因是把Cursor和Codex当成了同一个东西来用或者只盯着其中一个用到死。实际上这俩工具的工作方式完全不同用对场景一天的产出能差出一倍以上。Cursor我用来做所有需要理解上下文的开发。比如核心玩法的状态机、道具和计分之间的联动逻辑、UI面板的交互流程这些任务的共同特点是需要在原有代码的基础上做修改需要考虑多处调用关系需要不断试错调整。Cursor的编辑器集成本身就是为了这种交互方式设计的我在代码里选中一段直接告诉它我要改成什么行为它就能给出具体的diff我可以边看边审边改一个功能两三轮对话基本就稳了。我在这20天里的标准流程是这样的先把整体需求拆成若干个独立的小功能每个小功能自己新建一个脚本文件然后新建一个Composer会话把需求描述清楚把相关的数据结构贴进去让Cursor生成初版我review之后再让它修改。整个过程像极了带一个水平不错但偶尔犯糊涂的实习生你交代得越清楚产出的代码越靠谱。Codex我用来做所有边界明确但量大的苦力活。它不像Cursor那样给你一个交互界面而是一个命令行工具你在终端里给它一个任务描述它就在后台自己去读代码、写代码、跑测试然后给你一个结果。这个放后台跑的特性太关键了。举个例子我们有几十个关卡每一关的障碍物摆放逻辑都类似。我用Cursor把第一关的完整实现写好、测通之后接下来的关卡就交给Codex去批量生成。给它一条指令读取第一关的数据结构和摆放逻辑按照我给出的难度曲线生成第2到第20关的配置数据并保证障碍物不重叠然后我就可以去干别的任务。它处理完会回来报告结果我再抽查一下特定几关的数据是否合理。这中间我遇到过Codex非常典型的一个报错热词里也有人在问codex ran out of room in the models context。这个报错的本质是Codex在跑一个长任务时积累的代码内容超出了模型上下文窗口的容量通俗讲就是它记不住了。遇到这种情况我摸索出来的处理方式是把一个复杂任务拆成几个更小的子任务分多次跑每次任务开始时重新给它明确的文件路径和需要读的代码片段不要让它在一轮对话里自己翻太多东西。把这个习惯养成之后这个报错基本很少再出现。另外一个常见的坑是关于Codex账号登录和模型支持的。很多人在配置阶段会遇到一个类似这样的报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account。这个报错一般发生在Codex CLI的版本和ChatGPT账号绑定的模型权限不匹配的时候。我当时的处理办法是升级Codex到最新版本换用推荐搭配的模型问题就解决了。如果你用的是第三方中转配置还要检查一下后端接口是否支持你指定的模型名很多时候打不开登录失败都是这类配置问题。再分享一下我管理Codex任务的一些实操习惯。我准备了一个项目根目录下的tasks文件夹里面每个任务一个Markdown文件写清楚任务目标、涉及文件、完成标准和验收方式。每次启动Codex只让它读一个任务文件做完一个再开下一个。这看起来有点笨但实际上大幅减少了AI迷路的概率也让上下文保持在可控范围内。4. 微信小游戏打包Unity和团结引擎的WebGL模板深坑交代清楚工具分工之后来说说这个项目里最让人头疼的技术环节——把Unity项目打包成微信小游戏。这中间有一个热搜词特别准确避坑指南团结引擎打包微信小游戏时如何正确配置WebGL模板。我严重怀疑这位朋友也经历过我踩过的坑。先说技术选型。Unity官方对微信小游戏的支持是通过官方插件或团结引擎Unity中国版实现的。我用的是团结引擎它对微信小游戏那条导出链路的支持比原版Unity更顺手尤其是自动处理了一些环境适配的问题。但即便这样WebGL模板仍然是第一个坑。坑一默认模板直接导出会白屏或异常。Unity导出WebGL时会生成一套围绕UnityLoader的加载逻辑但微信小游戏运行环境跟普通浏览器不完全一样它没有完整的DOM和BOM默认的加载模板在普通浏览器里管用到微信里就失灵了。正确做法是在Project Settings里给Build指定用于微信小游戏的专用模板或者在团结引擎的导出选项中直接选择对应的微信小游戏模板配置。这里必须强调项目里如果有自定义的index.html一定要确认它兼容微信小游戏的环境我见过很多白屏问题都是自定义模板导致的。坑二首包体积4MB限制。微信小游戏对主包有严格的体积限制Unity导出的WebGL默认包体是比较大的尤其是带了不少美术资源之后轻松就能超过4MB。我的处理思路是三个字拆、压、异步。拆指的是拆分包把启动时用不到的关卡、音频和UI素材全部丢到子包或者远程资源主包只保留启动场景和核心逻辑。压指的是压缩策略。WebGL导出时要选择合适的压缩方式我用的是Brotli压缩压缩率相对更高启动时解压耗时也可以接受。异步指的是资源加载方式不在启动时一股脑加载所有内容而是按需加载。配合微信的加载进度条提示用户感觉不到明显的等待焦虑。坑三屏幕适配和刘海屏。Unity的Canvas默认适配逻辑在普通手机浏览器上问题不大但在微信里跑会遇到微信自带的导航栏、胶囊按钮和刘海屏安全区。这里需要做两件事一是拿到微信的安全区数据wx.getSystemInfoSync()里的safeArea把核心操作区限制在安全区范围内避免游戏按钮被刘海遮挡二是在Unity的Game视图里测试多分辨率比例。我在这上面吃过大亏——有一款机型上关卡重开按钮正好被微信胶囊挡住真机测试才发现返工了一下午。坑四触摸事件兼容。浏览器里的鼠标事件和微信小游戏的触摸事件不完全一致。如果你的游戏逻辑直接写了Input.GetMouseButtonDown在真机上会发现在部分机型上点击不够灵敏或者无法触发。团结引擎的适配层一般会做转换但如果某些逻辑绕过了引擎的输入模块就需要你自己处理。我后来统一封装了一个点击工具类底层同时监听鼠标事件和触摸事件所有UI按钮都走这个工具类才彻底解决了这个问题。坑五音频格式与播放策略。微信小游戏环境下Unity原生支持的音频加载方式不能直接用需要走微信的音频接口。而且微信对音频文件的大小和格式也有要求我当时把所有的背景音乐统一转成了压缩后体积较小的格式音效则拆零散文件加载避免一次性加载过多音频导致内存暴涨。这几轮坑走下来我最大的体会是打包阶段一定要用真机测试来验证不要相信模拟器更不要相信我能正常跑所以应该没问题这个错觉。微信小游戏的运行环境和桌面浏览器差异巨大很多问题只在真机上浮出水面。从第15天开始我几乎每天都会拿一台测试机跑一遍完整流程记录启动时间、内存占用、关卡跳转是否有卡顿走到后面心里才有底。5. 一个人如何同时扮演产品、设计、开发、测试最后聊聊软件以外的部分——一个人怎么在四个岗位之间快速切换而且不把项目搞乱。产品视角上我给自己定的铁律是每天只准提一个新需求或者砍掉一个旧需求。人的意志力是有限资源如果白天开发的时候脑子里还在纠结某个功能要不要上晚上还要上线前临时加需求项目必然失控。我在需求文档里把所有功能按优先级分了三档P0是核心体验没有就不上线P1是体验增强有条件下就做P2是脑洞想法这个版本全都砍掉。事实证明P2里的好几个设想后来看确实不适合第一版。砍需求不丢人丢人的是憋了一个月做出来的东西不像个完整产品。设计视角上我坦白讲美术不是我的强项所以我选择了更适合一个人作战的素材方案。我用了AI生成加统一调色滤镜的方式做了一套风格一致的UI素材再配合Unity自带的UI系统。这里分享一个实际经验AI生成的素材一定要统一处理不能东一张西一张直接贴上去风格不一致会让整个游戏显得廉价。我的做法是生成阶段就让AI严格遵循同一个风格描述做完之后再在Photoshop里统一加一遍滤镜和描边这样至少能让整体视觉像出自同一人之手。测试视角上没有QA只能把AI拿来当测试外援。我让Codex根据核心玩法的状态机写了一批单元测试和边界测试用例每天跑一遍回归确保核心逻辑没有被改动破坏。真正的人工测试我放在每天晚上的固定时段用一张Excel表记录测试路径启动、首页、开始游戏、游戏结束、重开、关卡切换、音效开关、前后台切换等每完成一项就更新状态。这样至少能保证每次改动之后核心路径不会出大问题。角色切换的节奏管理也很重要我给自己设计了一个简单的上下半场制度上午精神最好用来做最重要最有创造性的开发任务这时候我是工程师下午精神回落用来处理批量任务和内容铺量这时候我让Cursor和Codex多干活我做审核者晚上则是产品测试时间回顾当天进展、跑测试、修bug、调整第二天的任务清单。四个岗位不需要平均分时间而是按照精力曲线去分配效率确实高了不少。还有一个小技巧值得分享每天收工时我会写一个简短的当日记录只写三件事——今天完成了什么、明天要做什么、当前最担心什么问题。这15分钟的成本换来的好处是巨大的它能保证你第二天醒来打开编辑器时知道自己该从哪里继续不用花半小时回忆昨天的状态。这20天跑下来我对一个人做一款小游戏这件事有了更现实的判断。AI工具链确实把一些原本需要多人配合才能完成的工序压缩到了个体可以承担的范围但它并没有消除产品本身的复杂度它只是把复杂度转移到了人的判断力、决策力和执行力上。如果你问我现在再让我做一次会不会更快我想会的但前提依然是把需求砍到足够小把工具分工理清楚把验证节奏控制好。这几个基本功群里的任何工具都替代不了但它们能让你一个人跑得比以前更远。