1. 先说结论一个人怎么撑起四个岗位过去20天我基本是一个人同时扛了策划、程序、美术、测试四个岗位用CursorCodex这套AI编码组合从零做出来了一款可以提交审核的微信小游戏。说出来有点像是朋友圈标题党但确确实实是这个流程玩法我用Cursor帮我整理成需求文档前端逻辑和打包脚本主要靠Cursor边聊边改批量重构、迁移、代码审查这类杂活交给Codex在后端跑最后再用Unity的团结引擎打包成微信小游戏工程提交到微信开发者工具。这篇文章不是纯炫耀也不是工具软文而是把这20天怎么排兵布阵、哪些环节能省时间、哪些坑差点让我放弃全部复盘一遍。适合三类人看一是想尝试个人开发微信小游戏但不知道怎么起步的新手二是已经在用AI写代码、但还停留在“聊天生成代码”阶段、没有形成工作流的开发者三是想做独立小项目、又没预算组团队的产品/设计同学。看完你至少能少走一半弯路。先交代一下背景我本身不是游戏行业从业者日常工作是偏前端和工具链的懂一点Unity但很久没碰了。这次的目标非常明确20天内上一款微信小游戏不追求大制作只求“玩法能闭环、包能发出去、审核能过”。在这种限制下选对AI工具、压对人效比写代码本身重要得多。1.1 这4个岗位到底是怎么分工的很多人一听说“一个人做游戏”就以为要包揽所有杂活其实不是。我的做法是先把工作切成四个角色再用AI工具把每个角色的动作标准化让它们至少在效率上接近一个真实团队策划我负责定方向Cursor负责把方向拆成可执行的功能列表、关卡配置和数值表。比如“做一个合成类休闲小游戏”它会进一步帮你拆出合成规则、计分方式、道具类型、难度曲线。程序代码主体都是AI生成的但架构是我定的。我会先画清楚模块边界再让Cursor在边界内写具体函数避免AI一股脑把所有逻辑塞到一个文件里。美术一个人不可能在20天内手绘全套美术资源。我选择的是“程序化生成低多边形风格”用代码生成占位素材再请AI帮忙批量调整配色和形状参数保证整体风格统一。测试测试部分最容易被独立开发者忽略。我的做法是让Codex批量生成测试用例用脚本验证核心玩法逻辑最后再发体验版给几个朋友实测按反馈清单修问题。这样分工之后我每天的核心工作从“写代码”变成了“做决策”确定优先级、验收AI的输出、平衡质量和进度。真正的开发强度其实没那么夸张每天大概4到6小时有效工作时间。1.2 20天时间线是怎么排出来的很多人做个人项目失败不是因为能力不够而是因为在前期策划和工具调试上拖了太久。我的20天排期很硬而且每个阶段设置了明确的验收标准第1到3天完成玩法原型只要能跑就行不关心画质。第4到7天把核心玩法用真实美术资源替换同时把游戏循环跑通。第8到12天补齐关卡、数值、音效和设置页把整体体验打磨到“能给别人玩”的程度。第13到15天打包到微信小游戏处理Unity到小游戏的兼容问题。第16到18天测试、修Bug、做性能优化。第19到20天提交审核准备软著材料。实际执行时当然不会这么顺比如第7天就发现合成的特效在手机上卡得没法看第15天又因为WebGL模板配置错误浪费了整整一个下午。但因为有排期我知道这些偏差是不能接受的必须当天解决或者快速绕过而不是无限期打磨。2. 工具链选型Cursor和Codex到底谁适合干什么先说结论Cursor和Codex不是替代关系更像是“编辑器和流水线工人”的关系。Cursor适合坐在电脑前一边看代码一边交互式修改它的优势是理解上下文、实时补全、能精确改文件Codex适合挂一批任务让它自己跑特别是批量处理、代码迁移、测试生成这类不需要频繁人盯着的活。两款工具配合起来才有一点“一个人干四个岗”的意思。2.1 Cursor负责什么Cursor对我来说就是主力编辑器整个项目有一半以上的时间都待在里面。它最核心的价值是“对话式编程”你可以直接选中一段代码让它重构可以新建文件让它按照项目现有风格生成甚至在报错时把错误信息贴给它它会结合上下文直接给出修改建议。它的正确用法不是“帮我写个游戏”而是把任务缩小到可执行的粒度。比如我会这样说“当前项目是Unity C#脚本请为合成逻辑写一个‘可以合并的物体标记’接口包含id、等级、可合成目标这三个属性并给出空实现。”这种指令它完成得又快又稳。还有一点很关键Cursor支持项目级别的规则文件比如.cursorrules。我会在里面写清楚项目的技术栈、命名规范、目录结构以及“不要使用第三方付费插件、不要修改核心数据模型”这类约束。有了规则文件它生成出来的代码会明显更一致少很多“花式踩坑”。2.2 Codex负责什么Codex我主要把它当“哑巴劳模”用它擅长一次性处理大批量任务适合那种“让AI自己跑我过一会儿来看结果”的场景。比如项目做了中期之后我发现很多脚本里存在重复的UI刷新逻辑人工改太花时间就让Codex扫描所有包含特定模式的文件统一替换成公共方法。Codex还特别适合写测试。游戏项目里最繁琐的就是边界测试什么“格子里已经有一个同等级物体”“玩家金币不足但是有使用道具的按钮”“服务器排行榜返回空数据”之类的情况手工测试很难覆盖全。我直接让Codex根据核心类的公开方法生成一组单元测试用脚本跑一遍把失败用例喂回去再修效率高得惊人。不过Codex也有它的毛病它不会主动问你需求只会按字面意思执行。如果你给的指令含糊它会给你一个看起来完整但其实没满足要求的实现。所以我的习惯是先让Cursor把需求讨论清楚生成一份详细的功能描述再让Codex照着功能描述拆分任务绝不直接甩一句话让Codex“随便优化一下”。2.3 模型选择与成本控制Cursor和Codex底层都支持不同模型。实际使用中我的经验是分场景选日常对话和简单生成不需要上最贵的模型普通模型就够响应快、成本低。整体架构设计、复杂重构、Bug排查可以用强一点的模型因为这类任务一旦判断错误返工成本很高。Codex跑批量任务稳定优先我更关心它能不能按格式输出而不是它有多“聪明”。成本上只要把任务拆分合理20天下来花费并不夸张。个人开发者的核心成本其实是时间不是API费用。相比于请一个外包程序员或者美术这套AI组合的成本几乎可以忽略。2.4 我的实际协作工作流最终沉淀下来的流程是这样每天开工先花15分钟写一个PLAN.md把当天的任务拆成“完成标准”和“验收方式”然后把PLAN.md交给Codex执行其中机械的部分比如“为所有UI界面加上返回按钮”“把所有字符串统一放进配置表”我自己则在Cursor里处理那些需要做决策的部分比如某个玩法手感不对、某个界面布局不协调。这种并行模式最大的好处是我不容易被AI的节奏拖走。AI写代码速度很快但如果你一直在旁边看着它写你的时间也会被吃掉。只有把重复劳动全部丢给后台自己专注在真正需要判断的地方才能发挥出“一个人顶四岗”的效率。3. 从0到1做小游戏项目设计与开发3.1 玩法选型为什么选择“合成类”第一次做微信小游戏玩法选型真的能决定生死。我的标准有三个开发成本低、生命周期长、容易做出即时反馈。最后选了“合成类”具体玩法是屏幕上有一个网格玩家把同等级的小元素拖到一起合成更高级的元素等级越高得分越高还附带收集图鉴、每日任务、分享奖励这些轻社交功能。为什么合成类比动作类、射击类更适合一个人做因为它的核心逻辑是“判断合并”没有复杂的物理引擎没有密集的帧同步也不需要高帧率的动画表现。程序部分主要就是数组和列表操作边界情况容易梳理。美术上只要做几种基础元素的形状和配色高级元素可以通过颜色渐变和尺寸缩放生成不需要逐帧手绘。这让AI编程工具的发挥空间非常大因为它生成的代码不容易踩到复杂的性能坑。选型时也考虑过“答题闯关”“模拟经营”等方向但都因为内容量太大被否掉了。答题类需要大量题库题目质量人工审核成本高模拟经营虽然吸金能力强但底层系统太多20天根本做不完。所以如果你也想用AI快速做一款小游戏我的建议是规则能写满一页A4纸以内核心循环不超过三个操作越简单越好。3.2 架构怎么定才能不失控AI写的代码最大的隐藏风险不是“不会写”而是“无意识地堆叠复杂度”。如果你不给它约束它会在一个文件里写两千行还边写边改最终你根本无法维护。我一开始就定了几条硬性规则按功能拆目录比如Core核心玩法、UI界面、Data配置表、Audio音效、Utils工具类。核心玩法的数据模型要独立于表现层UI可以随时替换但数据模型不能随便改。禁止在多个脚本里重复定义常量所有数值必须进配置表。每个脚本控制在300行以内超了就说明职责不单一优先重构。刚开始让Cursor写代码时它总喜欢把“创建格子”“检查是否可合并”“更新得分”塞进同一个方法里。我就用需求文档跟它说明边界GameBoard只负责格子状态MergeChecker只负责判断是否能合并ScoreManager只负责计分UI层只负责监听这些模块的状态变化。拆分后好处立刻显现后面修Bug时我能很快定位问题Codex做批量重构时也不会误伤核心逻辑。3.3 美术素材怎么“空手”搞定这是很多个人开发者最怕的环节。我没有美术功底也没有预算买图库所以从第一天就决定走“低多边形程序化配色”路线。具体做法是用代码生成基础形状比如圆形、三角形、多边形再通过Shader或材质参数控制颜色和发光的深浅。不同等级的合成元素用色相区分1级是浅蓝2级是青色3级是绿色这样玩家看起来会觉得是同一套体系。背景、图标、按钮这类资源我找了CC0协议下的免费素材再让Cursor帮我写一个批处理脚本把素材统一缩放、替换颜色、生成不同分辨率的图片。这样做的好处是版权干净也省去了大量人工修图时间。需要特别提醒的是不管用AI生图工具还是免费素材网站都要看清楚授权协议尤其是“可商用”和“不可商用”的区别不然上线后被投诉就麻烦了。音效方面我用的是程序化合成音效比如点击音、合并音、升级音都是通过修改频率和波形生成的。虽然听起来不算精致但和整体风格是一致的也避免了版权问题。3.4 策划数值和关卡设计也要数据化策划看起来是“拍脑袋”但实际做起来全是数据活。我的做法是先定义好公式比如“合成高一级元素得分 基础分 x 等级系数 x 随机加成”再让Cursor根据公式生成一张关卡配置表。每个关卡包含目标分数、可用步数、初始元素数量、特殊道具出现概率这一大堆参数如果手工填不仅累还很难调平衡。这里必须要说AI能帮你生成数值表但不会帮你判断“哪个数值好玩”。我自己的方法是每天花20分钟手动体验一把当前版本记录“第几关开始感觉无聊”“第几关开始劝退”然后把反馈写进Bug单让Cursor帮我调整配置。数值这玩意只有真实玩家能给你答案AI只是加速实验过程。3.5 测试用自动化用例把核心逻辑焊死小游戏上线前最害怕的是什么不是Bug多而是每次修完一个Bug又冒出三个新Bug。为了防住这种情况我让Codex给核心玩法逻辑写了很细致的单元测试。比如“连续合成两次会不会触发重复奖励”“目标分数达到后是否立即进入结算”“重新开始时分数和步数是否重置”这些用例覆盖了大部分回归风险。测试通过之后我还做了几件事在微信开发者工具里调出真机预览让朋友用不同型号手机扫码玩录制了几段操作录像回放时观察UI是否错位、点击是否有延迟。游戏这种东西代码层面没问题不代表体验没问题真机帧率和触摸响应才是最真实的反馈。4. Unity打包微信小游戏最容易翻车的环节这一节可能是很多Unity开发者真正想看的内容。说句实话开发和玩法设计阶段虽然也累但对AI工具来说都算顺手真正让我差点崩溃的是“把Unity做的游戏装进微信小游戏”这个环节。缺一个配置、选错一个模板都会导致黑屏、加载失败、按钮点不了。4.1 用团结引擎还是Unity国际版微信小游戏不是单纯跑WebGL它是一套基于浏览器内核的运行时需要把Unity工程转换成一个“小游戏工程”。Unity国际版要装一个微信官方提供的“微信小游戏适配插件Mini Game Support”构建出WebGL包后再转换成小游戏格式而团结引擎Unity中国版则内置了微信小游戏的构建支持流程会顺很多。我实际用的是团结引擎主要原因是它对微信小游戏的适配处理得更省心。你不用自己琢磨“构建目标切WebGL后到底要下载哪几个模块”它在新项目模板里已经帮你把微信小游戏支持的包准备好了。如果你坚持用Unity国际版也可以但一定要在Unity Hub里确认安装好了WebGL Build Support并且去微信小游戏官方文档下载适配插件。给新手一个非常具体的建议第一遍打包前先把项目里所有中文路径、特殊字符、空格都检查一遍因为很多打包失败和资源加载不到的问题根源都是路径不干净。第二遍打包前再确认你的Unity版本和插件版本是官方文档里互相兼容的版本版本不匹配会出现各种莫名其妙的问题。4.2 WebGL模板配置避坑团结引擎打包微信小游戏时有一个细节叫“WebGL模板”。在Player Settings里你可以选择默认模板、Minimal模板或者微信小游戏专用模板。这个选项如果你不主动改很容易就用了默认模板结果构建出来后在微信开发者工具里一片白屏控制台报错还指向一些看不懂的.js文件。正常的做法是在Player Settings的“Resolution and Presentation”里把WebGL模板选成WeChat Game模板。不同版本名字可能不太一样有的叫“微信小游戏”有的叫“MiniGame”总之不要选“Default”或“Minimal”。选错模板的典型表现是构建成功但真机运行没有任何画面或者在微信工具里提示缺少game.js、game.json。还要注意Player Settings里的“Compression Format”选项。我试过选Brotli导致有些低端安卓手机加载后无法解码。最稳妥的方案是用Disable压缩或改用LZ4等跑通全流程后再回去做体积优化。这些都不是高深的技术问题但踩一次坑就是一下午提前按这个清单检查能省太多时间。4.3 微信开发者工具怎么对接Unity/团结引擎打包完成后会输出一个目录里面包含小游戏需要的game.js、game.json、project.config.json等文件。这时候打开微信开发者工具选择“导入项目”目录指向打包产物填好小程序的AppID就能看到一个可以模拟运行的小游戏工程。关于AppID我强烈建议你一开始就在微信公众平台注册一个小游戏账号而不是用测试号。测试号虽然能跑但不能上传代码、不能发布到了提审阶段还得重新配白白浪费半天。注册小游戏账号时主体类型选个人就行后面做软著时也只要个人身份。开发者工具里第一次运行小游戏常见问题有三个一是域名校验开发阶段可以在“详情-本地设置”里勾选“不校验合法域名”但要注意这只是本地调试用的正式上线前必须把网络请求都换成HTTPS并在小程序后台配置request合法域名二是缓存问题改完代码要点击“编译”而不是直接刷新三是用户授权弹窗如果游戏需要获取头像昵称记得要使用微信官方推荐的“头像昵称填写能力”不能直接wx.getUserInfo了。4.4 包体大小和首屏加载优化微信小游戏主包有4MB的限制超过之后要走分包加载个人开发者能不碰分包就不碰。我做的时候严格控制资源体积所有图片都用压缩过的PNG或者WebP纹理集最多两张2048音频全部转成压缩格式并把采样率降到22050代码里用到的所有美术资源只保留实际使用到的不把废弃素材放进Assets目录。首屏加载的优化逻辑也很简单优先展示一个加载界面后台加载核心场景不要在启动时实例化所有UI。因为微信小游戏是在网页容器里跑的首包越大、初始化对象越多首屏等待就越久用户很容易直接流失。我让Cursor把启动过程改成了“加载进度条 分帧初始化”先显示主菜单再预加载游戏场景这一步实测能把首屏从3秒以上压到1秒多一点。最后一点经验如果发现手机上发热明显或者卡顿先看是不是美术资源的Drawn Call太多。小游戏的渲染开销和Unity原生项目不一样很多为PC做的Shader和光照效果在手机上非常吃性能。最粗暴有效的办法是减少透明物体、合并网格、关闭实时阴影和反射探针。性能优化没有捷径只能用真机Profiler一帧一帧地看。5. 上线前的最后几步软著、提审和运营心态游戏做完了、打包打好了很多人以为下一步就是“点击发布”。实际上微信小游戏提审比小程序严格得多尤其是“著作权证明”这一关没准备的话审核会被打回。我在第19天才开始处理软著差点就翻车这里必须提醒大家早点准备。5.1 微信小游戏现在需要著作权登记吗需要。微信小游戏提审时会要求你提供软件著作权证明。这里的“软件著作权”指的就是《计算机软件著作权登记证书》也就是大家常说的“软著”。前几年还能用“电子版权认证”代替但现在提审审核更规范原则上都要软著如果你没有平台会明确提示你补充资质材料。软著申请可以自己在中国版权保护中心官网提交也可以找代理机构代办。个人开发者自己申请完全可行只是周期长一些所以要提前规划。如果哪天看到有人宣传“一键代办软著当天出证”一定要留个心眼那种往往是用加急通道或者不规范的代理服务费用高、风险也不小。顺便多说一句如果你打算在小游戏里开通虚拟支付、卖道具或者充值会员除了软著之外可能还涉及其他资质要求。个人开发者选择“广告变现”是目前最稳妥的路径不需要引入复杂资质微信广告组件直接接入就能用。提审前最好把微信小游戏平台的官方规则从头到尾看一遍别等被打回才去补。5.2 软著申请流程和时间线自己申请软著的大致流程是这样登录中国版权保护中心官网注册账号并实名认证在“计算机软件著作权登记申请”里填写软件名称、版本号、开发完成日期、软件分类等信息上传源代码文档和软件说明书提交后等待审核。源代码文档有格式要求一般要提交前、后各连续30页代码每页不少于50行如果代码总量不够就全部提交。软件说明书则要写清楚软件的功能和操作方式最好配上截图。这些材料不复杂但要花时间整理如果代码是AI生成的也没关系著作权归申请人所有只要你保留好开发过程记录。时间线上普通申请从提交到拿到证书快则一个月慢则两三个月。如果游戏急着上线可以考虑“加急办理”不过需要额外费用。最稳妥的做法是“先申请软著再做游戏”因为软著和游戏内容绑定程度不高可以先根据玩法描述申请表拿到证书后再开发上线时直接用。我这次就是因为游戏做完才开始申请导致提审推迟建议你们完全反过来。5.3 版本提审要注意什么提审时除了软著还需要准备一个比较完整的“游戏介绍”和“免责声明”。微信平台很看重内容安全如果游戏里有用户生成内容比如玩家昵称、留言板、排行榜昵称一定要有内容审核机制否则审核会以“具有内容风险”为由打回。提审前把测试账号和通关方法写上给审核员一条顺畅的体验路径。很多人会在“审核备注”里什么都不写结果审核员不知道怎么进入核心玩法只能瞎点几秒就退出然后以“体验不佳”驳回。我的做法是写清楚如何开始游戏、第几关会出现关键功能、如何触发合成和结算尽量让审核员在30秒内体会到游戏的完整循环。审核被驳回也不用慌微信的驳回原因一般写得很具体。按驳回意见逐条修改重新上传代码再提审就行。我见过很多开发者在被驳回后疯狂找“内部渠道”其实没必要把规则读清楚后自己改顺利通过只是时间问题。6. 这20天踩过的坑高频问题速查最后这部分我把这20天里实际遇到的、几乎每个AI编程玩家都会碰到的问题整理成一个速查表。不是从文档里抄的是我和Cursor、Codex、微信开发者工具三方面“斗智斗勇”换来的经验。6.1 Cursor提示“too many computers used within the last 24 hours”这个问题我在项目做到第三天就遇到了当时吓一跳以为是账号被盗。实际上这是Cursor账号的安全策略它检测到同一账号在24小时内登录过太多设备就会触发临时锁定。我因为白天在公司电脑、晚上在家电脑、睡前还用笔记本接力触发了这个限制。解决方法是登录Cursor官网的账号后台找到“设备管理”或“安全设置”手动删除不再使用的设备然后回到编辑器重新登录。如果后台没有这个入口那就只能等24小时自动解锁。经验教训是小项目尽量固定一台主力机器不要多设备频繁切换如果确实需要换设备尽量先退出旧设备再登录新设备别让账号同时在线。6.2 Codex提示“The gpt-5.6-sol model is not supported when using codex with a ChatGPT account”这个问题通常出现在用ChatGPT账号登录Codex时。Codex命令行工具会让用户选择模型但并不是所有模型都对所有账号类型开放如果用ChatGPT普通账号却选择了某个比较新的模型就会报这个错。我当时一度以为是软件坏了反复重装都没用最后才发现是模型选择的问题。一个稳妥的做法是先用配置里列出的默认支持模型跑不要手动切换到不熟悉的模型名如果项目必须用特定模型优先考虑使用官方API Key来认证而不是通过ChatGPT账号登录。这里还有一个规律模型名称更新很快网上教程里提到的模型可能已经下线或改名为新的型号遇到“not supported”时先去官方文档看看当前支持的模型列表。6.3 Codex执行大型任务时提示“ran out of room in the models context”Codex跑批量任务时如果一次塞给它的文件太多、指令太长它就容易报“上下文空间不足”。这不是Bug而是模型的上下文窗口有限。我第一次让Codex“扫描全项目并统一优化代码”结果运行到一半就红了原因是我把所有源码路径都贴在指令里了。解决思路是把大任务切成小块每次只让它处理一个目录、一类文件或者只做一种修改。修改某个公共接口时告诉它只查看被该接口引用的文件不要全项目扫描。我还会在项目根目录放一个索引文件说明每个模块的职责这样Codex能更快找对文件减少无效的上下文消耗。6.4 CC Switch本地转发报错怎么排查很多人在配置AI工具时会装一些“本地转发”或者“服务增强”类的辅助工具比如CC Switch。这类工具的本意是方便切换模型或管理后端服务但同时也容易引入“local proxy failed while handling codex endpoint”之类的报错。这个报错看起来很吓人其实大概率不是AI工具本身的问题而是辅助工具没跑通。我的排查顺序是先关闭所有辅助工具回到AI工具最基础的官方命令行模式确认官方功能本身能正常使用然后再重新启动辅助工具看报错是否复现。如果复现就去检查辅助工具的日志看它提示的本地端口是否真的被进程监听是不是有杀毒软件拦截了相关进程或者配置文件里的地址写错了。这类报错的本质是“路由不匹配”和你的代码项目没有任何关系别浪费时间改代码。6.5 小心“提示词泄露”和敏感信息外泄网上经常有“一句话套出Cursor系统提示词”的玩法我不建议去试但这件事本身值得警惕AI工具会把你项目里的内容一起带入模型上下文如果你在代码、文档或者注释里写了密钥、数据库连接串、手机号、内部业务信息它们就可能被AI读取并出现在生成结果里。我在项目初期就把所有敏感配置抽到环境变量和本地配置文件里代码仓库中只保留占位符。.cursorrules里只写技术规范不写公司名、不写业务敏感逻辑。别小看这一点一旦中招轻则泄露代码结构重则把用户数据交出去这在个人项目里是毁灭性的。6.6 其它小问题汇总除了上面几个大坑还有一些小问题虽然不致命但会反复消耗时间Unity构建时“Assets路径有中文或空格”导致打包失败处理方式是建一个纯英文路径的工程微信开发者工具打开项目提示“appid不存在”检查是否在小游戏后台正确创建了账号小游戏首次启动黑屏多半是首包太大或WebGL模板选错分享功能无法使用检查是否在微信公众平台配置了分享参数。我把这些问题列成了一张表贴在我的项目文档里后面如果再遇到直接查表就能解决问题典型原因解决方式Cursor多设备登录被锁24小时内多设备切换后台清理设备或等待解锁Codex模型不支持账号类型与模型不匹配切换到默认模型或使用API KeyCodex上下文溢出单次任务太大拆分任务、减少传入文件CC Switch转发报错辅助服务没跑通先关辅助工具验证基础功能小游戏黑屏WebGL模板或压缩格式配置错换成微信模板调整压缩方式包体超过4MB图片音频未压缩压缩资源、使用分包这20天下来我最真实的体会是一个人做一款小游戏真正稀缺的不是技术能力而是“在错误方向上及时止损”的能力。Cursor和Codex帮我省掉的是编码和测试的体力活但方向判断、玩法手感、审核合规这些事AI替代不了。如果你也正准备用AI做一个自己的小游戏我的建议是先想清楚做什么、给谁玩、怎么过审再打开编辑器。方向上别贪大时间上用排期倒逼AI工具只负责加速你的执行力不会替你做产品决策。最后再分享一个很实用的小技巧把所有AI工具生成的代码每天做一次版本提交提交信息里写清楚是“人改的”还是“AI改的”。这看起来是个很小的习惯但当你需要回滚、排查线上问题、复盘这20天的工作时间分配时会发现这些记录比任何复盘笔记都管用。AI写代码已经不是什么新鲜事真正拉开差距的永远是你怎么用它的判断力。 一个人用AI工具20天开发微信小游戏：从零到提审的全流程复盘
1. 先说结论一个人怎么撑起四个岗位过去20天我基本是一个人同时扛了策划、程序、美术、测试四个岗位用CursorCodex这套AI编码组合从零做出来了一款可以提交审核的微信小游戏。说出来有点像是朋友圈标题党但确确实实是这个流程玩法我用Cursor帮我整理成需求文档前端逻辑和打包脚本主要靠Cursor边聊边改批量重构、迁移、代码审查这类杂活交给Codex在后端跑最后再用Unity的团结引擎打包成微信小游戏工程提交到微信开发者工具。这篇文章不是纯炫耀也不是工具软文而是把这20天怎么排兵布阵、哪些环节能省时间、哪些坑差点让我放弃全部复盘一遍。适合三类人看一是想尝试个人开发微信小游戏但不知道怎么起步的新手二是已经在用AI写代码、但还停留在“聊天生成代码”阶段、没有形成工作流的开发者三是想做独立小项目、又没预算组团队的产品/设计同学。看完你至少能少走一半弯路。先交代一下背景我本身不是游戏行业从业者日常工作是偏前端和工具链的懂一点Unity但很久没碰了。这次的目标非常明确20天内上一款微信小游戏不追求大制作只求“玩法能闭环、包能发出去、审核能过”。在这种限制下选对AI工具、压对人效比写代码本身重要得多。1.1 这4个岗位到底是怎么分工的很多人一听说“一个人做游戏”就以为要包揽所有杂活其实不是。我的做法是先把工作切成四个角色再用AI工具把每个角色的动作标准化让它们至少在效率上接近一个真实团队策划我负责定方向Cursor负责把方向拆成可执行的功能列表、关卡配置和数值表。比如“做一个合成类休闲小游戏”它会进一步帮你拆出合成规则、计分方式、道具类型、难度曲线。程序代码主体都是AI生成的但架构是我定的。我会先画清楚模块边界再让Cursor在边界内写具体函数避免AI一股脑把所有逻辑塞到一个文件里。美术一个人不可能在20天内手绘全套美术资源。我选择的是“程序化生成低多边形风格”用代码生成占位素材再请AI帮忙批量调整配色和形状参数保证整体风格统一。测试测试部分最容易被独立开发者忽略。我的做法是让Codex批量生成测试用例用脚本验证核心玩法逻辑最后再发体验版给几个朋友实测按反馈清单修问题。这样分工之后我每天的核心工作从“写代码”变成了“做决策”确定优先级、验收AI的输出、平衡质量和进度。真正的开发强度其实没那么夸张每天大概4到6小时有效工作时间。1.2 20天时间线是怎么排出来的很多人做个人项目失败不是因为能力不够而是因为在前期策划和工具调试上拖了太久。我的20天排期很硬而且每个阶段设置了明确的验收标准第1到3天完成玩法原型只要能跑就行不关心画质。第4到7天把核心玩法用真实美术资源替换同时把游戏循环跑通。第8到12天补齐关卡、数值、音效和设置页把整体体验打磨到“能给别人玩”的程度。第13到15天打包到微信小游戏处理Unity到小游戏的兼容问题。第16到18天测试、修Bug、做性能优化。第19到20天提交审核准备软著材料。实际执行时当然不会这么顺比如第7天就发现合成的特效在手机上卡得没法看第15天又因为WebGL模板配置错误浪费了整整一个下午。但因为有排期我知道这些偏差是不能接受的必须当天解决或者快速绕过而不是无限期打磨。2. 工具链选型Cursor和Codex到底谁适合干什么先说结论Cursor和Codex不是替代关系更像是“编辑器和流水线工人”的关系。Cursor适合坐在电脑前一边看代码一边交互式修改它的优势是理解上下文、实时补全、能精确改文件Codex适合挂一批任务让它自己跑特别是批量处理、代码迁移、测试生成这类不需要频繁人盯着的活。两款工具配合起来才有一点“一个人干四个岗”的意思。2.1 Cursor负责什么Cursor对我来说就是主力编辑器整个项目有一半以上的时间都待在里面。它最核心的价值是“对话式编程”你可以直接选中一段代码让它重构可以新建文件让它按照项目现有风格生成甚至在报错时把错误信息贴给它它会结合上下文直接给出修改建议。它的正确用法不是“帮我写个游戏”而是把任务缩小到可执行的粒度。比如我会这样说“当前项目是Unity C#脚本请为合成逻辑写一个‘可以合并的物体标记’接口包含id、等级、可合成目标这三个属性并给出空实现。”这种指令它完成得又快又稳。还有一点很关键Cursor支持项目级别的规则文件比如.cursorrules。我会在里面写清楚项目的技术栈、命名规范、目录结构以及“不要使用第三方付费插件、不要修改核心数据模型”这类约束。有了规则文件它生成出来的代码会明显更一致少很多“花式踩坑”。2.2 Codex负责什么Codex我主要把它当“哑巴劳模”用它擅长一次性处理大批量任务适合那种“让AI自己跑我过一会儿来看结果”的场景。比如项目做了中期之后我发现很多脚本里存在重复的UI刷新逻辑人工改太花时间就让Codex扫描所有包含特定模式的文件统一替换成公共方法。Codex还特别适合写测试。游戏项目里最繁琐的就是边界测试什么“格子里已经有一个同等级物体”“玩家金币不足但是有使用道具的按钮”“服务器排行榜返回空数据”之类的情况手工测试很难覆盖全。我直接让Codex根据核心类的公开方法生成一组单元测试用脚本跑一遍把失败用例喂回去再修效率高得惊人。不过Codex也有它的毛病它不会主动问你需求只会按字面意思执行。如果你给的指令含糊它会给你一个看起来完整但其实没满足要求的实现。所以我的习惯是先让Cursor把需求讨论清楚生成一份详细的功能描述再让Codex照着功能描述拆分任务绝不直接甩一句话让Codex“随便优化一下”。2.3 模型选择与成本控制Cursor和Codex底层都支持不同模型。实际使用中我的经验是分场景选日常对话和简单生成不需要上最贵的模型普通模型就够响应快、成本低。整体架构设计、复杂重构、Bug排查可以用强一点的模型因为这类任务一旦判断错误返工成本很高。Codex跑批量任务稳定优先我更关心它能不能按格式输出而不是它有多“聪明”。成本上只要把任务拆分合理20天下来花费并不夸张。个人开发者的核心成本其实是时间不是API费用。相比于请一个外包程序员或者美术这套AI组合的成本几乎可以忽略。2.4 我的实际协作工作流最终沉淀下来的流程是这样每天开工先花15分钟写一个PLAN.md把当天的任务拆成“完成标准”和“验收方式”然后把PLAN.md交给Codex执行其中机械的部分比如“为所有UI界面加上返回按钮”“把所有字符串统一放进配置表”我自己则在Cursor里处理那些需要做决策的部分比如某个玩法手感不对、某个界面布局不协调。这种并行模式最大的好处是我不容易被AI的节奏拖走。AI写代码速度很快但如果你一直在旁边看着它写你的时间也会被吃掉。只有把重复劳动全部丢给后台自己专注在真正需要判断的地方才能发挥出“一个人顶四岗”的效率。3. 从0到1做小游戏项目设计与开发3.1 玩法选型为什么选择“合成类”第一次做微信小游戏玩法选型真的能决定生死。我的标准有三个开发成本低、生命周期长、容易做出即时反馈。最后选了“合成类”具体玩法是屏幕上有一个网格玩家把同等级的小元素拖到一起合成更高级的元素等级越高得分越高还附带收集图鉴、每日任务、分享奖励这些轻社交功能。为什么合成类比动作类、射击类更适合一个人做因为它的核心逻辑是“判断合并”没有复杂的物理引擎没有密集的帧同步也不需要高帧率的动画表现。程序部分主要就是数组和列表操作边界情况容易梳理。美术上只要做几种基础元素的形状和配色高级元素可以通过颜色渐变和尺寸缩放生成不需要逐帧手绘。这让AI编程工具的发挥空间非常大因为它生成的代码不容易踩到复杂的性能坑。选型时也考虑过“答题闯关”“模拟经营”等方向但都因为内容量太大被否掉了。答题类需要大量题库题目质量人工审核成本高模拟经营虽然吸金能力强但底层系统太多20天根本做不完。所以如果你也想用AI快速做一款小游戏我的建议是规则能写满一页A4纸以内核心循环不超过三个操作越简单越好。3.2 架构怎么定才能不失控AI写的代码最大的隐藏风险不是“不会写”而是“无意识地堆叠复杂度”。如果你不给它约束它会在一个文件里写两千行还边写边改最终你根本无法维护。我一开始就定了几条硬性规则按功能拆目录比如Core核心玩法、UI界面、Data配置表、Audio音效、Utils工具类。核心玩法的数据模型要独立于表现层UI可以随时替换但数据模型不能随便改。禁止在多个脚本里重复定义常量所有数值必须进配置表。每个脚本控制在300行以内超了就说明职责不单一优先重构。刚开始让Cursor写代码时它总喜欢把“创建格子”“检查是否可合并”“更新得分”塞进同一个方法里。我就用需求文档跟它说明边界GameBoard只负责格子状态MergeChecker只负责判断是否能合并ScoreManager只负责计分UI层只负责监听这些模块的状态变化。拆分后好处立刻显现后面修Bug时我能很快定位问题Codex做批量重构时也不会误伤核心逻辑。3.3 美术素材怎么“空手”搞定这是很多个人开发者最怕的环节。我没有美术功底也没有预算买图库所以从第一天就决定走“低多边形程序化配色”路线。具体做法是用代码生成基础形状比如圆形、三角形、多边形再通过Shader或材质参数控制颜色和发光的深浅。不同等级的合成元素用色相区分1级是浅蓝2级是青色3级是绿色这样玩家看起来会觉得是同一套体系。背景、图标、按钮这类资源我找了CC0协议下的免费素材再让Cursor帮我写一个批处理脚本把素材统一缩放、替换颜色、生成不同分辨率的图片。这样做的好处是版权干净也省去了大量人工修图时间。需要特别提醒的是不管用AI生图工具还是免费素材网站都要看清楚授权协议尤其是“可商用”和“不可商用”的区别不然上线后被投诉就麻烦了。音效方面我用的是程序化合成音效比如点击音、合并音、升级音都是通过修改频率和波形生成的。虽然听起来不算精致但和整体风格是一致的也避免了版权问题。3.4 策划数值和关卡设计也要数据化策划看起来是“拍脑袋”但实际做起来全是数据活。我的做法是先定义好公式比如“合成高一级元素得分 基础分 x 等级系数 x 随机加成”再让Cursor根据公式生成一张关卡配置表。每个关卡包含目标分数、可用步数、初始元素数量、特殊道具出现概率这一大堆参数如果手工填不仅累还很难调平衡。这里必须要说AI能帮你生成数值表但不会帮你判断“哪个数值好玩”。我自己的方法是每天花20分钟手动体验一把当前版本记录“第几关开始感觉无聊”“第几关开始劝退”然后把反馈写进Bug单让Cursor帮我调整配置。数值这玩意只有真实玩家能给你答案AI只是加速实验过程。3.5 测试用自动化用例把核心逻辑焊死小游戏上线前最害怕的是什么不是Bug多而是每次修完一个Bug又冒出三个新Bug。为了防住这种情况我让Codex给核心玩法逻辑写了很细致的单元测试。比如“连续合成两次会不会触发重复奖励”“目标分数达到后是否立即进入结算”“重新开始时分数和步数是否重置”这些用例覆盖了大部分回归风险。测试通过之后我还做了几件事在微信开发者工具里调出真机预览让朋友用不同型号手机扫码玩录制了几段操作录像回放时观察UI是否错位、点击是否有延迟。游戏这种东西代码层面没问题不代表体验没问题真机帧率和触摸响应才是最真实的反馈。4. Unity打包微信小游戏最容易翻车的环节这一节可能是很多Unity开发者真正想看的内容。说句实话开发和玩法设计阶段虽然也累但对AI工具来说都算顺手真正让我差点崩溃的是“把Unity做的游戏装进微信小游戏”这个环节。缺一个配置、选错一个模板都会导致黑屏、加载失败、按钮点不了。4.1 用团结引擎还是Unity国际版微信小游戏不是单纯跑WebGL它是一套基于浏览器内核的运行时需要把Unity工程转换成一个“小游戏工程”。Unity国际版要装一个微信官方提供的“微信小游戏适配插件Mini Game Support”构建出WebGL包后再转换成小游戏格式而团结引擎Unity中国版则内置了微信小游戏的构建支持流程会顺很多。我实际用的是团结引擎主要原因是它对微信小游戏的适配处理得更省心。你不用自己琢磨“构建目标切WebGL后到底要下载哪几个模块”它在新项目模板里已经帮你把微信小游戏支持的包准备好了。如果你坚持用Unity国际版也可以但一定要在Unity Hub里确认安装好了WebGL Build Support并且去微信小游戏官方文档下载适配插件。给新手一个非常具体的建议第一遍打包前先把项目里所有中文路径、特殊字符、空格都检查一遍因为很多打包失败和资源加载不到的问题根源都是路径不干净。第二遍打包前再确认你的Unity版本和插件版本是官方文档里互相兼容的版本版本不匹配会出现各种莫名其妙的问题。4.2 WebGL模板配置避坑团结引擎打包微信小游戏时有一个细节叫“WebGL模板”。在Player Settings里你可以选择默认模板、Minimal模板或者微信小游戏专用模板。这个选项如果你不主动改很容易就用了默认模板结果构建出来后在微信开发者工具里一片白屏控制台报错还指向一些看不懂的.js文件。正常的做法是在Player Settings的“Resolution and Presentation”里把WebGL模板选成WeChat Game模板。不同版本名字可能不太一样有的叫“微信小游戏”有的叫“MiniGame”总之不要选“Default”或“Minimal”。选错模板的典型表现是构建成功但真机运行没有任何画面或者在微信工具里提示缺少game.js、game.json。还要注意Player Settings里的“Compression Format”选项。我试过选Brotli导致有些低端安卓手机加载后无法解码。最稳妥的方案是用Disable压缩或改用LZ4等跑通全流程后再回去做体积优化。这些都不是高深的技术问题但踩一次坑就是一下午提前按这个清单检查能省太多时间。4.3 微信开发者工具怎么对接Unity/团结引擎打包完成后会输出一个目录里面包含小游戏需要的game.js、game.json、project.config.json等文件。这时候打开微信开发者工具选择“导入项目”目录指向打包产物填好小程序的AppID就能看到一个可以模拟运行的小游戏工程。关于AppID我强烈建议你一开始就在微信公众平台注册一个小游戏账号而不是用测试号。测试号虽然能跑但不能上传代码、不能发布到了提审阶段还得重新配白白浪费半天。注册小游戏账号时主体类型选个人就行后面做软著时也只要个人身份。开发者工具里第一次运行小游戏常见问题有三个一是域名校验开发阶段可以在“详情-本地设置”里勾选“不校验合法域名”但要注意这只是本地调试用的正式上线前必须把网络请求都换成HTTPS并在小程序后台配置request合法域名二是缓存问题改完代码要点击“编译”而不是直接刷新三是用户授权弹窗如果游戏需要获取头像昵称记得要使用微信官方推荐的“头像昵称填写能力”不能直接wx.getUserInfo了。4.4 包体大小和首屏加载优化微信小游戏主包有4MB的限制超过之后要走分包加载个人开发者能不碰分包就不碰。我做的时候严格控制资源体积所有图片都用压缩过的PNG或者WebP纹理集最多两张2048音频全部转成压缩格式并把采样率降到22050代码里用到的所有美术资源只保留实际使用到的不把废弃素材放进Assets目录。首屏加载的优化逻辑也很简单优先展示一个加载界面后台加载核心场景不要在启动时实例化所有UI。因为微信小游戏是在网页容器里跑的首包越大、初始化对象越多首屏等待就越久用户很容易直接流失。我让Cursor把启动过程改成了“加载进度条 分帧初始化”先显示主菜单再预加载游戏场景这一步实测能把首屏从3秒以上压到1秒多一点。最后一点经验如果发现手机上发热明显或者卡顿先看是不是美术资源的Drawn Call太多。小游戏的渲染开销和Unity原生项目不一样很多为PC做的Shader和光照效果在手机上非常吃性能。最粗暴有效的办法是减少透明物体、合并网格、关闭实时阴影和反射探针。性能优化没有捷径只能用真机Profiler一帧一帧地看。5. 上线前的最后几步软著、提审和运营心态游戏做完了、打包打好了很多人以为下一步就是“点击发布”。实际上微信小游戏提审比小程序严格得多尤其是“著作权证明”这一关没准备的话审核会被打回。我在第19天才开始处理软著差点就翻车这里必须提醒大家早点准备。5.1 微信小游戏现在需要著作权登记吗需要。微信小游戏提审时会要求你提供软件著作权证明。这里的“软件著作权”指的就是《计算机软件著作权登记证书》也就是大家常说的“软著”。前几年还能用“电子版权认证”代替但现在提审审核更规范原则上都要软著如果你没有平台会明确提示你补充资质材料。软著申请可以自己在中国版权保护中心官网提交也可以找代理机构代办。个人开发者自己申请完全可行只是周期长一些所以要提前规划。如果哪天看到有人宣传“一键代办软著当天出证”一定要留个心眼那种往往是用加急通道或者不规范的代理服务费用高、风险也不小。顺便多说一句如果你打算在小游戏里开通虚拟支付、卖道具或者充值会员除了软著之外可能还涉及其他资质要求。个人开发者选择“广告变现”是目前最稳妥的路径不需要引入复杂资质微信广告组件直接接入就能用。提审前最好把微信小游戏平台的官方规则从头到尾看一遍别等被打回才去补。5.2 软著申请流程和时间线自己申请软著的大致流程是这样登录中国版权保护中心官网注册账号并实名认证在“计算机软件著作权登记申请”里填写软件名称、版本号、开发完成日期、软件分类等信息上传源代码文档和软件说明书提交后等待审核。源代码文档有格式要求一般要提交前、后各连续30页代码每页不少于50行如果代码总量不够就全部提交。软件说明书则要写清楚软件的功能和操作方式最好配上截图。这些材料不复杂但要花时间整理如果代码是AI生成的也没关系著作权归申请人所有只要你保留好开发过程记录。时间线上普通申请从提交到拿到证书快则一个月慢则两三个月。如果游戏急着上线可以考虑“加急办理”不过需要额外费用。最稳妥的做法是“先申请软著再做游戏”因为软著和游戏内容绑定程度不高可以先根据玩法描述申请表拿到证书后再开发上线时直接用。我这次就是因为游戏做完才开始申请导致提审推迟建议你们完全反过来。5.3 版本提审要注意什么提审时除了软著还需要准备一个比较完整的“游戏介绍”和“免责声明”。微信平台很看重内容安全如果游戏里有用户生成内容比如玩家昵称、留言板、排行榜昵称一定要有内容审核机制否则审核会以“具有内容风险”为由打回。提审前把测试账号和通关方法写上给审核员一条顺畅的体验路径。很多人会在“审核备注”里什么都不写结果审核员不知道怎么进入核心玩法只能瞎点几秒就退出然后以“体验不佳”驳回。我的做法是写清楚如何开始游戏、第几关会出现关键功能、如何触发合成和结算尽量让审核员在30秒内体会到游戏的完整循环。审核被驳回也不用慌微信的驳回原因一般写得很具体。按驳回意见逐条修改重新上传代码再提审就行。我见过很多开发者在被驳回后疯狂找“内部渠道”其实没必要把规则读清楚后自己改顺利通过只是时间问题。6. 这20天踩过的坑高频问题速查最后这部分我把这20天里实际遇到的、几乎每个AI编程玩家都会碰到的问题整理成一个速查表。不是从文档里抄的是我和Cursor、Codex、微信开发者工具三方面“斗智斗勇”换来的经验。6.1 Cursor提示“too many computers used within the last 24 hours”这个问题我在项目做到第三天就遇到了当时吓一跳以为是账号被盗。实际上这是Cursor账号的安全策略它检测到同一账号在24小时内登录过太多设备就会触发临时锁定。我因为白天在公司电脑、晚上在家电脑、睡前还用笔记本接力触发了这个限制。解决方法是登录Cursor官网的账号后台找到“设备管理”或“安全设置”手动删除不再使用的设备然后回到编辑器重新登录。如果后台没有这个入口那就只能等24小时自动解锁。经验教训是小项目尽量固定一台主力机器不要多设备频繁切换如果确实需要换设备尽量先退出旧设备再登录新设备别让账号同时在线。6.2 Codex提示“The gpt-5.6-sol model is not supported when using codex with a ChatGPT account”这个问题通常出现在用ChatGPT账号登录Codex时。Codex命令行工具会让用户选择模型但并不是所有模型都对所有账号类型开放如果用ChatGPT普通账号却选择了某个比较新的模型就会报这个错。我当时一度以为是软件坏了反复重装都没用最后才发现是模型选择的问题。一个稳妥的做法是先用配置里列出的默认支持模型跑不要手动切换到不熟悉的模型名如果项目必须用特定模型优先考虑使用官方API Key来认证而不是通过ChatGPT账号登录。这里还有一个规律模型名称更新很快网上教程里提到的模型可能已经下线或改名为新的型号遇到“not supported”时先去官方文档看看当前支持的模型列表。6.3 Codex执行大型任务时提示“ran out of room in the models context”Codex跑批量任务时如果一次塞给它的文件太多、指令太长它就容易报“上下文空间不足”。这不是Bug而是模型的上下文窗口有限。我第一次让Codex“扫描全项目并统一优化代码”结果运行到一半就红了原因是我把所有源码路径都贴在指令里了。解决思路是把大任务切成小块每次只让它处理一个目录、一类文件或者只做一种修改。修改某个公共接口时告诉它只查看被该接口引用的文件不要全项目扫描。我还会在项目根目录放一个索引文件说明每个模块的职责这样Codex能更快找对文件减少无效的上下文消耗。6.4 CC Switch本地转发报错怎么排查很多人在配置AI工具时会装一些“本地转发”或者“服务增强”类的辅助工具比如CC Switch。这类工具的本意是方便切换模型或管理后端服务但同时也容易引入“local proxy failed while handling codex endpoint”之类的报错。这个报错看起来很吓人其实大概率不是AI工具本身的问题而是辅助工具没跑通。我的排查顺序是先关闭所有辅助工具回到AI工具最基础的官方命令行模式确认官方功能本身能正常使用然后再重新启动辅助工具看报错是否复现。如果复现就去检查辅助工具的日志看它提示的本地端口是否真的被进程监听是不是有杀毒软件拦截了相关进程或者配置文件里的地址写错了。这类报错的本质是“路由不匹配”和你的代码项目没有任何关系别浪费时间改代码。6.5 小心“提示词泄露”和敏感信息外泄网上经常有“一句话套出Cursor系统提示词”的玩法我不建议去试但这件事本身值得警惕AI工具会把你项目里的内容一起带入模型上下文如果你在代码、文档或者注释里写了密钥、数据库连接串、手机号、内部业务信息它们就可能被AI读取并出现在生成结果里。我在项目初期就把所有敏感配置抽到环境变量和本地配置文件里代码仓库中只保留占位符。.cursorrules里只写技术规范不写公司名、不写业务敏感逻辑。别小看这一点一旦中招轻则泄露代码结构重则把用户数据交出去这在个人项目里是毁灭性的。6.6 其它小问题汇总除了上面几个大坑还有一些小问题虽然不致命但会反复消耗时间Unity构建时“Assets路径有中文或空格”导致打包失败处理方式是建一个纯英文路径的工程微信开发者工具打开项目提示“appid不存在”检查是否在小游戏后台正确创建了账号小游戏首次启动黑屏多半是首包太大或WebGL模板选错分享功能无法使用检查是否在微信公众平台配置了分享参数。我把这些问题列成了一张表贴在我的项目文档里后面如果再遇到直接查表就能解决问题典型原因解决方式Cursor多设备登录被锁24小时内多设备切换后台清理设备或等待解锁Codex模型不支持账号类型与模型不匹配切换到默认模型或使用API KeyCodex上下文溢出单次任务太大拆分任务、减少传入文件CC Switch转发报错辅助服务没跑通先关辅助工具验证基础功能小游戏黑屏WebGL模板或压缩格式配置错换成微信模板调整压缩方式包体超过4MB图片音频未压缩压缩资源、使用分包这20天下来我最真实的体会是一个人做一款小游戏真正稀缺的不是技术能力而是“在错误方向上及时止损”的能力。Cursor和Codex帮我省掉的是编码和测试的体力活但方向判断、玩法手感、审核合规这些事AI替代不了。如果你也正准备用AI做一个自己的小游戏我的建议是先想清楚做什么、给谁玩、怎么过审再打开编辑器。方向上别贪大时间上用排期倒逼AI工具只负责加速你的执行力不会替你做产品决策。最后再分享一个很实用的小技巧把所有AI工具生成的代码每天做一次版本提交提交信息里写清楚是“人改的”还是“AI改的”。这看起来是个很小的习惯但当你需要回滚、排查线上问题、复盘这20天的工作时间分配时会发现这些记录比任何复盘笔记都管用。AI写代码已经不是什么新鲜事真正拉开差距的永远是你怎么用它的判断力。