一个人用AI工具20天开发微信小游戏：从零到提审的全流程复盘

1. 先说结论：一个人怎么撑起四个岗位

过去20天，我基本是一个人同时扛了策划、程序、美术、测试四个岗位，用Cursor+Codex这套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 model's 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模板选错；分享功能无法使用，检查是否在微信公众平台配置了分享参数。

我把这些问题列成了一张表，贴在我的项目文档里，后面如果再遇到，直接查表就能解决：

这20天下来，我最真实的体会是：一个人做一款小游戏，真正稀缺的不是技术能力，而是“在错误方向上及时止损”的能力。Cursor和Codex帮我省掉的是编码和测试的体力活，但方向判断、玩法手感、审核合规这些事，AI替代不了。如果你也正准备用AI做一个自己的小游戏，我的建议是：先想清楚做什么、给谁玩、怎么过审，再打开编辑器。方向上别贪大，时间上用排期倒逼，AI工具只负责加速你的执行力，不会替你做产品决策。

最后再分享一个很实用的小技巧：把所有AI工具生成的代码，每天做一次版本提交，提交信息里写清楚是“人改的”还是“AI改的”。这看起来是个很小的习惯，但当你需要回滚、排查线上问题、复盘这20天的工作时间分配时，会发现这些记录比任何复盘笔记都管用。AI写代码已经不是什么新鲜事，真正拉开差距的，永远是你怎么用它的判断力。