20天前如果有人告诉我一个人能在三周内把产品、开发、设计、测试四个岗位的活儿全干了还要上线一款微信小游戏我肯定觉得这是开玩笑。但现在我可以明确说能而且我刚刚就是这么干完的。这20天里我最大的外挂不是自己多能肝而是把一个叫Cursor的AI代码编辑器和一个叫Codex的编码智能体用到了极致。这篇文章我不打算讲虚的就说说这20天里怎么拆需求、怎么调AI、怎么绕开微信小游戏那些坑以及最终怎么把版本提交上去通过审核。如果你想认真了解用AI编程做一款可上线产品到底靠不靠谱这篇文章应该比你看一百条AI新闻都管用。1. 项目概述一个人怎么顶四个岗位1.1 这是一款什么游戏我做的是款休闲小游戏名字不重要类型就是那种“一局两分钟、排行榜驱动”的消除闯关玩法。核心动作很简单看题、选答案、消除方块难度不高但带点小解谜非常适合微信里碎片化场景。为什么选这个方向因为我要在20天内上线品类的复杂度和开发量必须压到最低但又不能没有任何传播抓手——好友排行榜就是那个抓手。用户玩完一局看到自己排名比朋友高天然想转发朋友点进来又形成新一轮回流。这个逻辑听起来简单实际牵扯到微信号登录、开放数据域、云存储、分享参数传递一堆细节后面我会单独讲。游戏本身是原生Canvas渲染没有用重型引擎代码量被控制得很小核心玩法部分满打满算不到3000行。这3000行里AI写的比例相当高大概七成以上。我负责的是整体架构、玩法定义、参数调整、上架审核这些AI替代不了的事以及给AI当“监工”和“debug员”。1.2 四个岗位的活都摊在谁头上先拆一下这四个岗位到底要做什么。产品岗要出需求文档、定核心玩法、设计关卡难度曲线开发岗要有架构设计、编码、自测设计岗要做界面、图标、音效、动效测试岗要过一遍完整链路还要管提审要用的各种截图、说明、资质材料。一个人干四个岗最大的问题不是时间而是思维切换。写代码的时候你要有工程师逻辑切到界面又得启动审美直觉再切回产品视角得不停问自己“这个功能对用户到底有没有价值”。我的方法是把四条线全部异步化产品需求在最前面一次性定死开发过程里不再改需求设计走“先占位、后美化”的策略前期所有美术都是用形状和系统字体顶上测试则像打补丁一样揉进每天的收尾阶段当天写的代码当天必须能跑。这样做的好处是思维切换的痛苦被控制在每天一到两次而不是每个小时切换一次。1.3 为什么敢用AI这把“外挂”说白了传统模式下一个人四条线20天是绝对不可能达成的。我敢接这个活是因为我清楚Cursor和Codex这类工具已经能把程序员的“体力活”压缩到原来的十分之一。以前写一个排行榜列表可能要反复查文档、调样式、测分页现在让AI基于微信小游戏API写一个能跑的版本十分钟内就能完成初稿。但我必须泼一盆冷水AI不是万能的它最大的产出是“初稿”和“中间态”。它很难在没有明确输入的情况下帮你做产品决策也很难理解微信平台那些隐藏在文档角落的规则。所以“AI外挂”的正确打开方式是——你用架构能力和产品直觉把大方向定好剩下那些重复性、模式化的编码工作放给AI自己只做审稿和修bug。后面这几章我就按这个思路把完整流程摊开讲。2. 工具选型解析Cursor和Codex到底干不干得了活2.1 Cursor坐在副驾驶上的结对编程搭档Cursor本质上是个AI优先的代码编辑器底层是VS Code那一套所以如果你用过VS Code上手零成本。它最常用的几个能力我挨个说。第一是Tab补全不是传统IDE那种关键词补全而是能预测你下一整段逻辑比如你在写一个函数处理排行榜数据它连排序、去重、异常兜底一起给你补出来。第二是CtrlK行内编辑你可以直接框住几行代码用自然语言说“这段逻辑太慢改成二分查找”它当场就改。第三是Composer多文件编辑这个最实用你可以说“帮我新增一个每日签到功能需要新的页面、存储方法和入口按钮”它会一次性修改多个文件。整个项目里我用Cursor最多的是中小粒度的代码生成和重构。写一个工具函数、调一个组件样式、把一段重复逻辑抽取成公共方法——这些事它做得又快又稳。有一点要注意不要把设计得太核心的算法逻辑完全交给它比如消除玩法的匹配算法我是自己先把伪代码写清楚再让Cursor照着实现这样出错的概率会低很多。2.2 Codex能自己跑完整个任务的“实习生”如果说Cursor是坐在副驾的搭档那Codex更像是你招来的一个“远程实习生”——你把任务写清楚它在自己的执行环境里查代码、改文件、跑命令、看报错然后反复修复直到任务完成。它基于OpenAI的编码模型核心能力不是写一段代码而是“完成一个任务”。这有本质区别。举个例子我当时让它干过一件事给项目写一套完整的微信小游戏分享回调逻辑包括原生分享按钮绑定、分享成功后的回调处理、卡片参数校验。这个任务如果我自己写要查文档、试回调、处理各种边界情况起码半天Codex拿到任务后自己翻了项目结构在代码里找入口文件补上了所有缺失的函数最后还跑了一遍node语法检查前后不到20分钟。当然它中间也有懵的时候比如回调参数拿错位置但描述清楚问题后它自己就修正了。Codex的用法和Cursor不太一样它更适合“目标是明确的、步骤是重复的、验证是机器能跑通”的任务。比如批量生成关卡数据、重构接口调用方式、补充单元测试、修复lint报错。这些任务都有一个共同点能不能成跑一下就知道不需要人工判断主观质量。2.3 两个人的分工边界在哪里我在这个项目里形成了比较稳定的分工习惯。Cursor负责“在线实时”的部分写代码时随时提问、即时补全、快速重构。Codex负责“离线独立”的部分给它一个issue描述它自己吭哧吭哧改完然后我来验收。一个像厨师身边的帮厨一个像你能放心派出去买东西的跑腿。二者都有各自的上下文管理问题所以我会在项目根目录写一个CLAUDE.md式的项目说明文档把技术栈、目录结构、编码规范都写清楚这样两个AI工具都能快速理解项目背景生成的代码也更贴题。需要特别强调的是它们都是“高智商但缺常识”的队友。你如果不告诉它微信小游戏有包体限制、渲染性能要求它可能给你生成一个加载1000张图片的设计你不告诉它开放数据域不能操作主域它可能把排行榜代码写进一个没法跑通的上下文。所以给AI写任务书的能力某种意义上比写代码的能力更值钱。3. 技术方案与核心功能实现3.1 技术栈最后为什么没上Unity始终悬在头顶的问题就是技术栈选型。微信小游戏的主流方案有几条路一是纯原生JavaScript/TypeScript直接用微信小游戏API和Canvas做渲染二是用Cocos Creator、LayaBox这类游戏引擎导成微信小游戏三是用Unity通过官方适配方案转成微信小游戏。我最终选了原生TypeScript原因很简单我要在20天内控制变量纯原生方案链路最短、问题的可控性最高。Unity做微信小游戏的最大坑在于“转换”这个环节。Unity本身的渲染管线和微信小游戏运行环境并不天然契合官方适配插件解决了大部分问题但遇到报错时排查链路特别长你得同时懂Unity、WebGL和微信平台三个领域。Cocos是好选择但项目体量还不到需要引擎的程度。对于消除闯关这种轻量玩法原生Canvas加TypeScript完全够用而且代码量小、AI生成的准确率高。后来我复盘这个决定至少帮我省了5天时间。3.2 主循环、关卡和题库怎么用AI快速搭建小游戏本质是一个渲染循环加状态机。我用TypeScript写了一个简单的GameLoop基于requestAnimationFrame每一帧里按状态分发到不同场景首页、游戏页、结算页。这个生命周期很简单但它是所有功能的地基。地基稳了后面AI生成的任何功能代码都能挂到正确的位置上地基如果不稳AI补出来的功能就会变成一堆互相打架的意大利面。关卡和题库是AI最能“批量打工”的地方。我先把关卡规则定义成一个JSON结构比如目标分数、方块颜色数、步数限制、特殊道具出现概率然后让Codex按照这个结构生成几百组合法关卡数据。这里有个关键的工程技巧一定要让AI把“生成器”和“校验器”成对写出来。生成器生成关卡校验器检查这个关卡是否有解、难度是否过高。AI有时候会生成看起来合理实际无解的数据没有校验器的话玩家会卡在某一关直接流失。3.3 好友排行榜最容易绕弯的功能微信小游戏的好友排行榜让我绕了不少弯这里单独拿出来说。首先你要明白一个平台规则主域里拿不到好友关系链数据所有关系链数据的读取和展示都必须在“开放数据域”里进行。开放数据域是一个隔离环境有自己的JS引擎和Canvas主域只能通过wx.getOpenDataContext()拿到它的引用两个域之间通过postMessage通信。具体到排行榜流程是这样的主域用wx.setUserCloudStorage把当前用户的分数写入微信的云端存储然后开放数据域使用wx.getFriendCloudStorage拉取好友分数列表再把这个列表渲染到开放数据域自己的Canvas上最后通过sharedCanvas把画面“贴”到主域的某个位置。听起来简单但实现里有不少细节setUserCloudStorage的key必须固定value是KVDataList数组开放数据域里不能调用wx.request所以所有网络请求都不能放这里。我第一次让AI写排行榜时它直接把渲染逻辑写在了主域Canvas上跑起来什么都显示不了因为API调用在开放数据域外直接拿不到数据。后来我把架构调整成主域负责通知开放数据域“我分数变了”开放数据域负责拉取数据、渲染排行榜再通过postMessage把“排名变化”的结果回传主域。理顺这个边界后AI生成的代码一次就过了。4. 20天实操时间线每一天都没有浪费4.1 冲刺路线图拆解先放一张我在项目启动时画好的时间表虽然中途有调整但大节奏基本没变。前3天是需求与设计期我把产品定义、核心玩法、UI草图、技术选型全部敲定这一阶段不允许任何反复。第4到第7天是核心玩法开发期GameLoop、方块逻辑、关卡系统全部搞定每天结束前必须有一个可以手动跑通的小Demo。第8到第12天是功能完善期把微信登录、排行榜、分享、音效和设置全部接进来。第13到第17天是美术与打磨期替换所有占位美术调整动效手感补齐加载进度和异常态。第18到第20天是提审与上线期准备截图、填写信息、提审、修复反馈最终上线。这个节奏里最反直觉的一点是美术和音效被刻意放到了最后。很多人做小游戏会先堆美术再写代码这是最典型的项目延期原因。我的逻辑是前期所有视觉都用色块和系统字只要布局是对的后面替换素材是纯粹的手工活不涉及任何逻辑改动。这样就算设计审美不合格也完全不阻塞开发进度。4.2 关键节点的产出与验收标准每个阶段我都设了明确的“能跑”标准而不是“差不多写完”。第7天的里程碑是在微信开发者工具里能点完一局完整流程分数能刷新游戏结束能出结算页。第12天的里程碑是真机预览模式下排行榜能拉出好友数据分享卡片能带参数回到指定页面。第17天的里程碑是在低端安卓机上连续跑20分钟不崩溃帧率不低于30FPS首屏加载时间低于3秒。第20天的里程碑就是审核通过。这些验收标准为什么要卡得这么死因为AI生成代码很容易让你产生“进度很快”的错觉。它能快速生成大量代码但代码多不代表产品可用。我每天都要求自己至少跑一遍完整用户路径一旦发现阻塞问题当天必须解决。这样到后期我遇到的大多是“体验优化”类问题而不是“游戏跑不起来”的致命问题。4.3 一个人怎么管理4条线的进度我一个人怎么同时管理产品、开发、设计、测试四条线我靠的不是脑子记而是一个极其朴素的待办池每天开工前花15分钟把当天要做的事按“开发/设计/测试/产品”四个标签列出来做完一条划掉一条。任务粒度控制在两小时以内超过两小时的一律拆开。在AI辅助下大部分编码任务的粒度其实都是半小时级所以这个清单管理起来很轻松。另一个经验是每天给自己留出两小时“零任务时间”完全不做新功能只做三件事——跑已有功能、看有没有过期代码、修昨天AI留下的小尾巴。这两个小时对心态的维稳作用非常大。因为一个人做项目最大的风险不是活多而是不知道还有多少活每天留白能让你随时掌握项目的真实状态而不是跟着AI的产出节奏自嗨。5. 上线流程与审核避坑5.1 账号、类目、备案一个都不能少微信小游戏和个人主体小程序不一样注册小游戏账号前你要先想清楚用个人主体还是企业主体。个人主体能选的类目很有限比如休闲游戏是可以的但涉及虚拟支付、直播、棋牌类基本都向企业开放。我的项目是消除闯关个人主体还够用但要注意个人主体无法开通虚拟支付也就是说你不能在小游戏里卖道具卖皮肤。这也是我做纯休闲玩法、靠激励视频广告变现的原因。账号体系准备起来会碰到一堆材料问题。身份证、手机号、邮箱这些就是基础但真正花时间的是各类资质申请以及按照平台最新要求完成必要的登记流程。我的经验是在项目启动第一天就把账号申请提交上去不要等游戏做完了再注册。因为审核材料本身有等待周期你完全可以一边开发一边等资质下来。5.2 提审前必须自查的三类问题提审是整个流程里主观性最强的一环我总结了三个最容易被打回的类型。第一是功能缺失或异常比如分享按钮点了没反应、排行榜在低版本微信上白屏。第二是内容合规广告位展示不明显、页面里有暗示性文案都很容易被退回。第三是信息完整度截图尺寸不对、隐私协议链接打不开、类目和内容不符都会被直接拒绝。我的自救方式是提前准备一份“自查清单”专门在提审前跑一遍每一页都有至少一张高质量截图、所有外部链接都能正常打开、授权弹窗有明确说明文案、游戏内没有出现“诱导分享”字样的引导语。平台对诱导分享特别敏感即使你只是写了“分享给好友可复活”也可能被判定违规。所以我在游戏里把分享做得非常克制只放一个中性的“分享”按钮不加任何奖励暗示。5.3 线上版本回滚与热更新第一次上线后免不了会收到用户反馈或者平台警告这里要提前想好两个机制代码层面要有热更新能力数据层面要有远程开关。微信小游戏本身支持分包加载和远程资源所以我会把一些非核心配置比如关卡难度参数、广告开关、活动文案放到一个远程JSON里客户端启动时拉取。这样一旦某个配置出问题我不需要发布新版本改远程JSON就能修复大部分线上问题。远程开关的典型用法是“灰度放量”。小游戏审核通过后我不会一次性把所有流量都放开而是先把广告开关关掉观察用户留存和崩溃数据稳定后再通过远程配置把广告打开。这样做一方面保证用户体验另一方面避免新版本一上线就出事故。这个习惯让我后来处理线上问题的时候从容很多因为大部分风险都在下发配置时就被拦截了。6. 常见问题与踩坑实录6.1 Cursor使用上的槽点Cursor最大的槽点大概就是配额。免费版每个月的快速请求次数非常有限用完之后体验会断崖式下降——补全还是能补全但速度明显变慢。如果你准备长期做项目该付费就付费效率换回来的时间远不止那点订阅费。但要注意它的订阅生效机制我研究过C站和其他社区分享的经验订阅通常按自然月计算复购后并不是从当前日期重新开始而是沿用原有周期所以“续杯”之前一定要看清剩余天数别在刚用完的当天充值那样等于只补了几天。另一个经验是上下文管理。Cursor的对话长度越长它对早前指令的遵从度越差。我常用的做法是超过10轮以上的对话就新开一个会话然后手动把关键约定复制进去。这个习惯看似笨拙但能极大提升生成质量。还有一个小技巧不要把密钥、token写到会被AI扫描的文件里AI工具在处理内容时可能把这些信息带进上下文万一提示词泄露出去是很危险的事。6.2 Codex配置和执行的坑Codex这类命令行编码智能体安装本身没什么难度重点在环境配置。它会读取你本地的Node.js环境如果你机器上Node版本太老很多依赖会装不上。我第一次跑的时候就是报了一堆奇怪的语法错误最后发现是Node版本不兼容升级之后立刻就好。配置模型时也要注意不同模型的擅长方向不一样。如果只是写小程序前端逻辑用快速模型就够响应快、成本低但遇到复杂的架构级重构一定要切到推理更强的大模型否则它会在细节里钻牛角尖。Codex执行任务时还有一个老毛病它会在一个错误上反复重试比如某段代码有语法错误它会改来改去还是报同一个错。这时候不要一直让它重试你要做的是把报错信息重新整理给它告诉它“这个错误发生在编译阶段不是运行阶段”它才会跳出来。6.3 AI生成代码的“隐性债务”用AI写代码最大的陷阱是“看起来能跑就算了”。AI擅长生成表面上正确的代码但很多边界情况它根本想不到。举个例子它在处理网络请求时经常不写超时逻辑和重试机制在处理用户输入时很少考虑传null的情况。这些代码在正常路径下完全没问题一旦用户操作到边缘场景就会出现白屏或闪退。我的应对策略是所有网络请求统一封装成公共方法由我在封装层补上超时、重试和错误提示所有用户输入进引擎前先走一个清洗函数。这两个“防御层”是我手写的不允许AI自由发挥。另外AI生成的每一段代码都要做“代码评审”——我所谓评审不是读一遍那么简单而是针对性检查三件事异常分支有没有处理、生命周期有没有释放、性能有没有明显浪费。这个习惯能帮你避免在提审前突然发现一堆低级问题的尴尬。7. 一个人AI开发模式的真正边界到现在为止你可能会觉得一个人用AI做项目非常简单。但我要诚实地说这个模式也有天花板。纯玩法创新很难靠AI做出来因为AI只能组合你给它的输入它不会凭空产生“这个玩法会很爽”的产品直觉。另外当一个项目达到几千行代码以后AI的理解能力会下降它改一个地方可能破坏另一处逻辑这种时候你必须有足够强的架构能力去约束它。把大系统拆成小模块、模块之间定义清晰接口这些活儿AI帮不上太多只能靠你自己。所以我把这个模式定义为“AI放大了一个人的交付能力但没有替代一个人的决策能力”。你在项目里至少要是半个架构师、半个产品经理、半个测试工程师。有了这个底线认知AI才真正能帮你一个人扛起四个岗位。最后分享一个关于时间管理的实战心得20天做完这个项目后我最大的收获不是掌握了多少AI技巧而是学会了“随时能用最简单的方式验证一件事成没成”。每一次让AI干活之前我都会先想清楚验收标准是什么。这个习惯帮我省下了大量“以为做完其实没用”的返工时间。如果你也想一个人挑战这种效率极限不妨从一个小而完整的项目开始先逼自己20天其他事情等真正跑起来以后再说。