一个人+AI：用Cursor和Codex从零上线微信小游戏的实战复盘

凌晨两点半，电脑屏幕上最后一条编译输出变成了“发布成功”，我盯着那行字愣了好几秒。20天前，我给自己封了四个头衔——策划、程序、美术、运营，听起来像简历里唬人的包装，实际上就是一个人在一台电脑前，用 Cursor 和 Codex 这两款AI编程工具，从零上线了一款微信小游戏。没组队，没外包，没花一分钱做推广，从玩法文档到审核上线全是一个人扛下来的。如果把这段经历浓缩成一句话：不是AI替我写了所有代码，而是AI让我一个人干完了四个人的活。这篇文章我打算把整个过程中的选型逻辑、工具分工、排期节奏和踩过的坑完整捋一遍，尤其是那些让我熬到深夜的报错和审核驳回。如果你也想用AI辅助开发微信小游戏，或者正在纠结“一个人能不能搞定一个完整项目”，这篇应该能帮你在动手前少走不少弯路。

1. 一个人敢接“四个岗位”的底气：选对载体比努力重要

1.1 为什么是微信小游戏，而不是App或者H5

先说结论：微信小游戏这个载体，天然就是为“小团队甚至单人开发者”准备的。我做App的话，光iOS安卓双端适配、真机兼容、性能优化、上架审核这几件事就能耗掉我半个月，而且大概率还要为证书和备案折腾一阵子；做H5虽然门槛低，但用户触达是个大问题，没有分发渠道，做完就是个数字孤岛。微信小游戏把这几个痛点全部绕开了。

微信小游戏自带一整套成熟的用户体系、分享链路和支付/广告组件。登录直接用微信授权，存档可以用微信云开发，分享到群聊和朋友圈是内置能力，激励视频广告位在小游戏后台点几下就能申请下来。这些能力在传统App里对应的是账号系统、后端服务、消息推送、支付SDK——哪一样都不轻松，而小游戏平台已经帮你铺好了路。

再一个关键是“轻”。小游戏对包体、性能、单局时长的天然限制，其实是个筛选器：它逼着你把玩法做简单、做聚焦，不允许你脑门一热铺出一堆大而全的功能。我见过太多独立开发者一上来就想做开放世界、做实时对战，结果半年过去连Demo都跑不流畅。小游戏赛道里活得好的往往是休闲益智类、轻RPG、模拟经营这类规则清晰、单局时间短、天然适合分享传播的玩法。

你可能会问：什么样的游戏适合一个人加AI来做？我的判断标准很朴素——玩法复杂度要有明确天花板，核心循环能在30秒内让玩家看懂，服务器需求能压到最低。拿我自己举例，当时列了三个候选玩法，一个是卡牌构筑，一个是跑酷，一个是轻度的模拟经营。模拟经营和分析决策类玩法对数值平衡要求高，内容消耗极快，一个人做得累死；跑酷虽然看似简单，但在手感调优上是个无底洞。最后选了一个规则简单但上限不低的轻休闲玩法：玩家通过滑动操作让角色通关，关卡之间穿插成长线和随机事件，分享复活是裂变的主要抓手。这类型玩法最契合小游戏生态，也最适合AI辅助开发的节奏。

1.2 二十天倒计时背后的“减法清单”

20天的时间限制，意味着前三天就必须把所有“可做可不做”的东西全部砍掉。我做了一张减法清单，现在回头看，这才是整个项目能按期上线的关键。

坚决砍掉的功能包括：实时对战、好友排行榜实时同步、语音聊天、多语言本地化、账号绑定、复杂的新手引导动画。这些功能每个单独拎出来都能写三天，而且对核心玩法闭环没有本质贡献。比如实时对战听起来很吸引人，但要做帧同步、房间管理、掉线重连，后端复杂度瞬间膨胀，根本不是一个20天项目该碰的东西。同量级的热词里“unity微信小游戏打包”搜索热度那么高，说明很多人卡在技术交付环节，而不是玩法创意上；把精力留给核心玩法，比什么都强。

保留的功能只有四样：核心玩法循环（滑动操作+关卡通关）、本地存档加云存档、分享复活、激励视频广告。确定了MVP清单之后，我把它写成了开发过程的“边界条件”，直接丢给AI工具当约束：“这是本期范围，清单之外的功能不要做，不要主动扩展架构。”这一点非常重要——AI非常容易“自作主张”，它会觉得加入某个设计模式很酷，或者顺手加一个你没要求的编辑器功能。如果你不给它明确边界，它会把你的项目复杂度拖向失控。

我当时的减法清单长这样：

2. Cursor 和 Codex 的分工策略：一个管“手术刀”，一个当“工程队”

2.1 为什么同时用两个AI工具，而不是只用一个

很多人会问：Cursor 和 Codex 不都是AI编程工具吗，选一个不就够了？我的体验是，它们俩的性格完全不同。Cursor 更像是你手里的手术刀——它长在IDE里面，能实时看到报错、上下文感知整个项目，适合逐行精修、改函数、调界面、重构局部逻辑。而 Codex 更像是工程队——它跑在终端里，适合接“把A目录下的所有资产重命名并按规则整理”“把全部硬编码数值抽成配置文件”“跑一遍测试并把失败用例写进日志”这类批量任务。

我给它们的疆界是这样划的：Cursor 负责所有需要“我盯着改”的代码，包括核心玩法脚本、UI交互逻辑、微信SDK调用；Codex 负责所有“我只要结果”的重复劳动，包括依赖安装、构建脚本、资源目录整理、自动化测试和批量生成关卡配置。两者并行，最后用 git 合并。这里有个血泪教训：绝对不要让两个AI同时改同一个文件，它们没有任何协调机制，各改各的会在合并时产生一堆冲突，而且AI很容易在解决冲突时把对方的逻辑清掉。我后期养成了一个习惯，每个人工智能动工之前先给它指定明确的文件路径范围，做完一个再放另一个进场。

2.2 我是怎么把需求翻译给AI听的

把需求讲给AI听，其实和给新同事交底没什么区别。我刚用AI编程时最大的误区是只甩一句话：“做一个关卡选择界面。”AI确实会做出来，但做出来的东西往往边界模糊、缺少细节、架构随意。后来我总结了一套提示词模板，效果稳定得多：

1. 背景：这个项目是什么类型的小游戏，用了什么引擎。
2. 目标：这次要做什么，解决什么问题。
3. 边界：涉及哪些文件/模块，禁止动哪些模块。
4. 验收标准：什么样的输出算完成，用什么命令验证。

一个真实的提示词长这样：

背景：这是一个微信小游戏，使用Unity导出到WebGL平台，现有玩法循环已经跑通。 目标：新增关卡选择界面，显示已解锁的最高关卡数，未解锁关卡显示为锁定状态。 边界： - 只允许修改目录 Assets/Scripts/UI/ 下的文件 - 不得改动 Assets/Scripts/Core/ 下的任何代码 - 不要引入第三方UI库 验收标准： - 运行场景后，点击主菜单的“关卡”按钮能进入关卡选择界面 - 已解锁关卡可点击进入对应关卡，未解锁关卡点击后弹出Toast提示 - 使用微信开发者工具预览时，触摸点击事件正常工作

在 Cursor 里，我依赖三个核心功能。第一个是@Codebase引用，写提示词的时候把@Codebase拉进来，AI 会自动检索整个项目结构，回答更贴合现有代码；第二个是 Agent 模式，它不只是补全代码，而是能自己读文件、改文件、跑命令然后汇报结果；第三个是 Tab 补全，看起来不起眼，但在连续写重复性代码时能让手速翻倍。至于很多人问的“cursor中文怎么设置”，其实在设置里把语言切到中文就行，但我个人建议保留英文界面，因为很多时候 AI 生成的中文注释会和代码风格不太搭，而且英文关键词在搜索报错时更有用。

Codex 的命令行用法要更克制一些。我惯用的姿势是把任务描述写在一个文本文件里，然后跑：

codex exec "读取 docs/todo.md，逐项完成任务，每完成一项在文件末尾标记完成状态"

这样做的好处是 AI 不会因为终端里的历史对话太杂而理解偏，所有指令都是一次性的、可追溯的。Codex 在处理依赖问题、脚本自动化、文件批量重命名这类任务上表现得特别稳定，尤其是在无人值守的场景下，让它自己去干活，你过一会儿回来看结果就行。

2.3 让两个AI“接力”的最佳实践

AI编程工具用多了之后，我越来越觉得它们像是“能力很强但记性很差的新人”。它们的强项是单点任务的执行力极强，弱点是上下文窗口有限，一长串任务积累下来就容易“忘事”或者犯低级错误。热词里有个典型的报错：error running remote compact task: codex ran out of room in the model's context window——翻译过来就是上下文爆了，模型的空间装不下这么多内容了。这个问题几乎每个重度用户都会遇到，解法不是硬扛，而是拆分任务。

我后来的工作习惯是这样：一个会话只做一件事，任务做到一半如果需要继续，先让AI输出一份“当前状态摘要”，存成一个临时文件，下次开新会话时让AI先读那个文件再接着干。这样既绕开了上下文长度限制，又不会丢失进度。打个比方，这就好比你让一个实习生干活，与其让它把100个步骤全记在脑子里，不如让它每一步做完都在便签上记一句，最后你只需要看便签就能知道发生了什么。

另外还有一个特别有效的习惯：让AI每次改完代码，输出两行“变更摘要”，说明改了哪几个文件、改了什么东西、为什么改。一开始我也嫌麻烦，后来发现这个摘要太有用了——因为AI改崩代码的时候，你靠它的摘要能迅速判断是哪个文件出的问题，git diff 都不用逐行看了。带AI写代码，本质上就是带实习生：你给它明确任务、限制边界、要求它汇报，它就能扛起远超一个人力的产出。

3. 四个岗位压缩成一条流水线：我每天的真实工作流

3.1 策划岗：玩法文档先过AI这关

在我的工作流里，策划岗不是最先出图的，而是最先出文字的。我先用文档描述完整玩法，然后把它当成“需求评审材料”喂给AI。最核心的用法是让AI扮演不同角色来“评审”我的方案：让AI扮演玩家，去看新手引导会不会让人困惑；让AI扮演制作人，去判断功能范围会不会失控；让AI扮演数值策划，去检查成长曲线的合理性。

数值推演这一步，AI帮了大忙。我当时做了一张关卡数值表，包含每关怪物的血量、攻击力、金币掉落和道具产出。按照传统做法，我得手动建一个Excel模型慢慢调，但我在提示词里直接写：“当前玩家的基础攻击力是10，每秒攻击一次，怪物血量公式是100乘以关卡数的1.2次方，金币掉落是5加关卡数乘以2，帮我生成100关的数值表，并标记出在第几关会出现玩家击杀怪物时间超过30秒的卡点。”Codex 把答案整理成一张CSV给了我，标注了第37关开始怪物血量明显膨胀，建议把攻击力的成长曲线改成指数型。这种模拟推演，放在以前至少得花一整个晚上，现在20分钟内就能跑完。

3.2 程序岗：从 Demo 到能上线的代码是怎么长出来的

程序岗是AI投入占比最大的环节。我的技术栈是 Unity 加微信小游戏适配方案，通过 WebGL 模板导出微信小游戏工程，再用微信开发者工具打开调试。之所以选 Unity 而不是原生开发，是因为Unity的组件化架构和资源管线更适合AI生成代码——AI特别擅长生成 C# 脚本，而在原始JS里手搓图形引擎属于给自己找不痛快。

代码的组织上，我把它拆成三个核心模块。游戏主循环负责角色移动、碰撞检测和状态流转；UI模块负责所有界面的显示和交互（主菜单、关卡选择、结算、分享弹窗）；数据模块负责存档读写和云函数通信。每个模块用独立的 C# 脚本文件管理，这样既方便我逐个审阅AI生成的代码，也方便AI精准定位问题。一个特别有用的技巧是：写代码的时候让AI给每个公共方法都加上注释说明参数含义和返回值，这样后面让AI修bug时，它自己能快速理解自己的代码，不用我把整个文件塞进上下文。

小游戏平台特有的适配问题需要专门留意。触摸事件和鼠标事件不完全等价，Unity默认的鼠标点击事件在真机上会失灵，所以所有关键交互都要绑定Input.touch或者用统一的输入管理组件；屏幕适配不能只做横屏或竖屏的简单拉伸，要处理不同宽高比的锚点；初始包体必须控制在非常小的体积，这里我会把大部分美术资源放到远程加载。程序岗最容易犯的错是贪多，我给自己定的规矩是：先跑通一个最小闭环，哪怕画面丑一点——一个能跳的小人、一个能碰到的金币、一个能触发的分享按钮，这个闭环通了再往上面加玩法。

3.3 美术岗：没有美术怎么办

美术是个人开发者最容易破防的环节。我的解法是三个词：风格克制、程序生成、资源复用。我做的是扁平几何风格，所有角色和场景元素都用基本的矩形、圆形、三角形组合出来，再统一一套高饱和度的调色板。这种风格做出来的游戏画面干净统一，而且AI生成的素材风格一致性极强，不会出现“前两关像A游戏，后两关像B游戏”的割裂感。

用AI生成素材时，我通常会让它输出透明背景的PNG，并且控制素材尺寸和留白，然后批量导入Unity做成图集。这里有个小坑：AI生成的图片有时候自带一些莫名其妙的噪点，直接放进游戏里会导致包体变大，如果是2D素材一定记得在导入设置里把压缩格式选成适合WebGL的格式，否则真机加载会卡成幻灯片。场景背景我用程序化生成的方式在代码里动态绘制，既省资源又保证风格统一。音频方面，音效来自公开免费音效库，BGM用的是程序化生成的一段循环旋律，再在代码里控制音量淡入淡出。外部公开资源的使用要留意授权协议，尽量选择CC0或MIT协议的素材，免得后面被要求下架。

3.4 运营/后端岗：微信云开发的胜利

一个20天项目如果还要自己买服务器、配域名、做备案，基本宣告失败。微信云开发（CloudBase）帮我省掉了全部后端基础设施。排行榜和云存档各写一个云函数，数据库用云开发自带的文档型数据库，前端通过微信SDK直接调用，根本不用关心服务器运维。整个数据层加起来，代码量不超过200行，而且全程不需要我申请任何服务器资源。

激励视频广告是个人开发者最直接的变现手段。在小游戏后台申请广告位、拿到adUnitId之后，在代码里调用wx.createRewardedVideoAd接口就行。我的设计是：玩家看广告可以复活一次，或者获得双倍金币，这两个场景对广告时长的接受度最高。还有一个容易被忽略的收入来源是“格子广告”或“Banner”，但小游戏里弹窗广告对留存影响很大，个人项目宁可少赚点，保持体验清爽，把留存和口碑先做起来。

微信小游戏的著作权登记问题，我确认过平台流程：上线本身并不强制要求先提交著作权登记证书，个人开发者可以在微信公众平台上走正常的备案和审核流程。但如果你后续想申请“创意小游戏”标识，或者要跟发行商谈独家代理，对方通常都会要求提供软著证明。我的建议是别被这个名字卡住开发节奏，游戏研发完成后用空闲时间把材料一起办了就行。

4. 20天排期与每个阶段的关键里程碑

4.1 第一周：从想法到可玩Demo（Day 1-7）

前三天的任务是“做决定”而不是“写代码”。玩法定稿、美术风格定调、技术选型、搭好Unity工程、跑通微信小游戏官方示例。这三天我基本都在跟AI一起打磨玩法文档和数值模型，因为这些东西一旦定了，后面的开发就很难回头改。

第4到5天，我不再纠结玩法完整性，直接把核心玩法做成一个“能跑、能死、能重开”的Demo。画面用最简单的色块代替，所有美术资源都是占位图，代码逻辑也只保留最核心的移动碰撞和关卡切换。这个阶段最重要的是验证手感：滑动操作的灵敏度、角色移动的加速度、碰撞检测的判定范围。手感不对，玩法再有意思都留不住人。

第6到7天，我把Demo发给了几个朋友试玩，然后仔细观察他们玩的时候的表情和操作。这里有一个特别重要的经验：不要问“你觉得好玩吗”，而要问“你刚才在哪里卡住了”和“你第二次打开游戏是因为什么”。反馈收集完之后，我把所有劝退点列成一个清单，按严重程度排序，能在一小时内改完的立刻改完，改不了的直接砍掉——还没上线，谁也不确定某个设计一定成立，快速验证比自我感觉良好重要得多。

4.2 第二周：内容填充与打磨（Day 8-14）

第二周的重心从“能不能玩”变成“有没有内容”。我让 Codex 批量生成了100关的关卡配置JSON，每个关卡包含地形布局、敌人分布、金币位置和通关条件，然后我写了几个测试脚本逐关跑平衡性，把那些“玩家无论如何都过不去”和“过于简单导致三秒通关”的关卡手动调整。

这个阶段我把占位图全部替换成正式素材，统一了调色板和描边线条宽度。音效和动效的补充也在这个阶段完成，但场面上我会刻意做“节制”——动效过多在小游戏真机上会造成掉帧，尤其是低端安卓手机，所以几乎所有的粒子效果都被简化成了缩放动画。

第14天是一个严格的checkpoint：游戏必须能完整通关，100关从第一关到最后一关不能有中途崩溃或卡死的现象。达不到这个标准，后面的提交审核和广告接入就无从谈起。为了守住这个节点，我甚至做了取舍：把100关的内容砍到了80关，留出时间专心打磨手感。后来证明这个决定是对的——玩家根本不会在意关卡数量是80还是100，但一定会注意到操作卡顿和加载缓慢。

4.3 最后冲刺：审核、合规、上线（Day 15-20）

最后五天，整个节奏变成了“测试、修复、测试、修复”。我用微信开发者工具的真机预览功能在几台不同价位的安卓和iOS设备上反复测试，重点盯三类问题：启动崩溃、内存溢出、UI错位。每修完一个bug，我会把报错日志和修复代码重新喂给AI，让它判断有没有连带风险——这一点对赶进度来说特别关键，因为很多bug是“按下葫芦浮起瓢”，修完一个又冒出一个，AI能帮你快速定位回归测试的范围。

第17天，我把隐私保护指引、用户协议、未成年人保护相关的平台配置全部完成。这一步千万别偷懒，微信审核对隐私指引的检查越来越严格，很多开发者头几次被拒都是因为“未在后台配置隐私保护指引”或“代码中未调用平台要求的隐私授权接口”。

第18天正式提交审核前，我自己用审核人员的视角把游戏过了一遍：类目选的是休闲益智，截图和图标用的是正式版本画面，游戏介绍里没有夸大宣传，也不涉及任何敏感内容。审核结果出来后，平台提了两个修改意见，一个是某个道具图标和内置表情包过于相似，另一个是支付相关提示文案需要调整。这些都是纯手工改的小问题，当天改完重新提交，第20天上午就收到了通过通知。

5. 踩坑实录：这些报错我花了最多时间

5.1 Cursor账号的设备数量限制

开发到第6天的时候，我想从台式机切到笔记本继续写代码，结果登录时直接弹提示：too many computers used within the last 24 hours for the same cursor account——24小时内使用的设备数量超出了账号限制。我当时愣了一下，因为所谓“多设备”其实都是我一个人在用，只是频繁切换而已。这个限制的逻辑是防止多人共享账号，所以它不管你是不是真人，只看设备活跃数量。

排查下来，这个限制是按24小时窗口滚动的，超了就锁，只能等窗口自然重置。处理方式也很直接：把Cursor固定在一台主力开发机上，别在多个设备之间来回切；如果确实需要换机器，先在一台设备上退出登录并停用，过一段时间再登录新设备。这件事给我的启发是，AI工具账号和设备绑定策略各不相同，开工之前最好先看清楚平台规则，不然做到一半被锁账号，心态真的会崩。

5.2 Codex模型不支持与配置姿势

有一次我更新了Codex版本，然后执行任务时突然报错：the 'gpt-5.6-sol' model is not supported when using codex with a chatgpt account。意思是当前账号绑定方式不支持配置里指定的那个模型名。这个问题本质上是模型名、账号权限和客户端版本不匹配。

定位过程其实不难。先查看Codex的配置文件，看模型字段填的是什么：codex config或直接打开~/.codex/config.toml，然后把模型名改成当前账号/计划支持的稳定版本模型，再同步更新Codex到最新版。改完之后，任务就能正常跑了。这里有个通用经验：AI编程工具的配置模型名不是越新越好，稳定性优先；如果遇到“model is not supported”这类错误，第一反应先查版本和配置文件的映射关系，不要盲目换更贵的模型。

5.3 上下文爆满：codex ran out of room

这个报错在长任务场景下特别容易出现：error running remote compact task: codex ran out of room in the model's context window。字面意思是模型上下文窗口满了，AI没法继续处理任务。我第一次遇到时已经让Codex连续干了两个小时的活儿，它一直在改各种文件、输出日志和解释，结果在最后一步突然报这个错，连前面干完的活都差点找不回来。

根本原因还是任务链条太长，累积的token数量超出了模型窗口。解决办法分三步：第一步，把大任务拆成小任务，单个任务控制在“改3到5个文件”以内；第二步，明确要求AI每次只输出“变更摘要”而不是整段代码，摘要内容就够下一次分析用了；第三步，如果任务实在拆不开，就开新会话，让AI先读上次生成的摘要文件再继续。这套方法用到现在，我再也没有因为上下文限制而丢进度。

5.4 Unity/团结引擎打包微信小游戏的WebGL模板配置

搜索“unity微信小游戏打包”的人特别多，说明这个环节卡过不少人。我的经验是：Unity导出的WebGL项目不能直接在微信开发者工具里跑，必须使用微信小游戏专用的适配方案。具体来说，要安装微信小游戏适配插件，然后在Build Settings里选择WebGL平台，Player Settings里的WebGL模板要选成“微信小游戏”专用模板，而不是Unity默认模板。用团结引擎的话，对微信小游戏的支持更顺滑，很多配置都被内置了，但模板选错的问题依然存在。

导出完成之后，会生成一个微信小游戏工程目录，用微信开发者工具打开这个目录，而不是打开Unity工程。很多人卡在这一步，是因为一直在浏览器里预览WebGL版本，结果发现微信的JSBridge接口在浏览器里根本调不通——这是预期内的事情，小游戏必须在微信环境里跑。

首包体积是另一个容易踩的坑。微信小游戏对初始包体有严格限制，超过一定体积会导致首屏加载极慢。我的做法是：所有图片和音频素材压到WebGL支持的格式，关卡配置和数值表全部放到远程服务器上，通过云开发存储动态拉取；首包只保留引擎核心和第一关的少量资源，后面几关的素材在玩家玩到对应关卡时才实时加载。这样首包从最初的十几兆降到了几兆，加载体验完全上了一个台阶。

5.5 多个AI工具客户端并存时的本地服务冲突

我在用一些工具来集中管理多个AI客户端的配置凭证时，踩过一次“切换后任务跑不起来”的坑。现象是：配置切换完成后，Codex任务一开始就报错，提示本地服务连接失败。这种问题大多不是AI本身坏了，而是本地端口或工作目录被另一个实例占用，旧的关联进程没有完全退出。

排查链路是这样：先看报错里提示的端口号，用网络工具检查端口占用情况；然后找到占用进程并结束，重启切换工具的关联服务；最后删除临时缓存文件，重新发起任务。解决之后我在流程上也做了调整：切换配置前先退出所有正在运行的客户端进程，切换完再启动，不要图省事在服务运行的热状态下直接切换。这类本地服务问题，本质上跟“多个浏览器同时抢一个摄像头”是同一类问题，资源独占，谁先抢到谁说了算。

5.6 微信小游戏审核遇到的问题

审核环节，我第一版提交被驳回了。问题并不出在代码，而是后台配置：我没有在后台填写隐私保护指引，而且代码里没有调用平台要求的隐私授权接口。这听起来很基础，但真到提交的时候特别容易忙中出错。修改方式是：在微信公众平台的相应入口里配置隐私保护指引，说明游戏会收集哪些信息、用来做什么，然后在代码里加上隐私授权的调用逻辑，再重新提交。

类目选择也值得多说一句。同一个游戏，选不同类目，审核的严格程度和需要的材料会不一样。休闲益智类目是最常见的游戏类目，门槛相对清晰；如果涉及随机抽取类玩法，通常需要额外做概率公示，避免被判定为“赌博诱导”。我在早期设计阶段刻意规避了这类玩法，就是为了减少审核变量。

最后聊两句

20天结束之后，我脑子里最深刻的感受不是“AI太厉害了”，而是“限制真的能逼出创造力”。没有团队，所以每一行代码都必须有存在的理由；没有美术，所以风格必须简化到几何图形也能撑住；没有专职测试，所以每修一个bug都要连带追一遍边界情况。AI在这中间的角色不是“替我飞”，而是“让我落地”——它把重复劳动、信息检索、原型验证这些耗时的环节压缩了，让我能把精力放在真正的决策上。

如果你也想试试这条路，我的建议是：给AI立规矩，让它输出变更摘要；把任务拆到最小可验证的粒度；每个新功能都先做最丑但能跑的最小闭环。最后分享一个小技巧：每次让AI改完代码，强制它在文件头部加一行注释，写上这次改动的原因和日期，这样即使过了很久再回来维护，你和AI都能一眼看出当初为什么这么写。等你的小游戏上线之后，你可能会发现，最难的不是写代码，而是决定不写什么。