“原来做小游戏不需要会画图，不会写后端，甚至不需要懂得什么是帧率——只需要会问AI。”

去年双十一，我闲得蛋疼，想做一个微信小游戏发朋友圈炫耀。结果一查资料：得学微信小游戏框架（Egret/Laya），得懂TypeScript，还要处理图片资源、音效、后端排名……算了，放弃。

今年年初，我突然意识到：AI 已经能写代码、画图、做策划了。于是我决定用 AI 整条链路跑一个微信小游戏，看看能不能在不写一行手代码的情况下，把游戏做出来、审核通过、还能有点流量。

下面就是我的实录——从选技术栈到上线运营，记录每一步的决策、踩坑、以及最终的成本和收获。如果你也想用 AI 做点有趣的东西，这篇可能比官方文档更有用。

一、技术选型：为什么我放弃了传统小游戏框架，转而拥抱 AI 生成

1.1 传统路线的三座大山

• 技术栈：要学 TypeScript、微信小游戏 API、游戏循环、帧同步……门槛高。
• 资源制作：即使用 AI 生成图片，也得手动裁剪、打包成图集，还要处理不同分辨率适配。
• 后端与运营：排名存储、分享引流、防作弊……这些不是游戏核心，却占了开发时间的 60%。

1.2 AI 链路的核心假设

如果能让 AI 直接输出：

• 可运行的游戏主循环代码（含碰撞、得分、状态机）
• 符合微信小游戏尺寸的素材（角色、背景、按钮）
• 符合规则的游戏描述、页面文案甚至隐私政策

那么，人类只需负责“搭桥”和“质量门”。

我最终选择的技术栈如下：

关键点：我没有使用任何现成的小游戏框架（如 Egret、Laya），全部代码由 AI 生成，仅依赖浏览器原生 Canvas API（微信小游戏其实也是基于 Canvas 的）。

二、从零到可玩原型：三天搞定核心玩法

2.1 定义一个“足够简单但有上头感”的游戏

我最初的想法是做一个“合成类”小游戏（像 2048），但 AI 生成的合成逻辑 bug 特别多。后来转向一个更容易实现的“跑酷躲避”：

• 角色一直向右跑
• 随机生成障碍物（仙人掌、鸟儿）
• 玩家点击屏幕让角色跳跃
• 撞到障碍物游戏结束，显示得分

这个玩法只有三个状态（跑动、跳跃、死亡），碰撞检测简单（矩形相交），非常适合 AI 生成。

2.2 Prompt 工程：让 AI 写出“不跑偏”的游戏主循环

我尝试过直接让 Claude Code 写“一款微信小游戏”，结果得到的是一个只有空白画面的项目。后来我发现，需要把游戏拆解成细粒度的任务，然后用 Skills 一步步引导。

最终使用的 Prompt 模板（保存在 Skills 里）：

你是一个微信小游戏开发专家。请使用 TypeScript 和 Canvas API 实现一个横向跑酷小游戏，要求：
1. 游戏循环使用 requestAnimationFrame
2. 角色为一个 50x50 的红色方块（暂用占位图），能够跳跃（初始速度 -8，重力 0.5）
3. 障碍物从右侧生成，间隔随机（900-1500 px），类型随机（仙人掌/鸟儿）
4. 碰撞检测使用简单的 AABB 矩形相交
5. 得分为 sopravvissuto seconds（保留一位小数）
6. 游戏结束后显示最终得分和重新开始按钮
7. 所有常量请放在文件顶部，便于调试
8. 请确保代码可以直接在微信开发者工具中运行，不依赖任何外部库

有了这个框架 Prompt，我只需要每天给 Claude Code 提供一个细化任务：

• Day 1：实现基本的循环、角色跳跃
• Day 2：添加障碍物生成和碰撞检测
• Day 3：加分、游戏结束 UI 和重置逻辑

每次修改后，我直接将生成的 .ts 文件复制到微信开发者工具，点击编译——奇迹发生了：它真的能跑起来！

2.3 资源生成：从“僵尸方块”到“有灵魂”的角色

最初的角色是红色方块，玩起来毫无乐趣。我于是让 AI 生成角色概念图，然后用生成的图作为占位素材。

Prompt（用于 DALL·E 3）：

A cute dinosaur character for a 2D side-scrolling game, facing right, simple style, transparent background, 128x128 pixels, PNG

生成后我得到一个可爱的小恐龙。同样的方法生成了仙人掌和鸟儿的障碍物，以及一张简单的沙漠背景。

注意：微信小游戏对资源大小有严格限制（单个文件不超过 2MB，总大小不超过 4MB）。我后来发现 AI 生成的图片往往偏大，需要用 Tinypng 无损压缩（这一步目前仍需人工）。

三、踩坑实录：AI 生成代码的三个致命陷阱

3.1 “看起来对，其实错”：碰撞检测的浮点漂移

AI 生成的碰撞检测代码看起来完全正确：

if (dino.x < cactus.x + cactus.width &&
    dino.x + dino.width > cactus.x &&
    dino.y < cactus.y + cactus.height &&
    dino.y + dino.height > cactus.y) {
    // 撞到了
}

但实际运行时，角色经常“明明没碰到却判定为碰撞”。排查后发现是因为：

• AI 没有考虑微信小游戏的坐标系原点在左上角，而 Y 轴向下为正（这其实是标准）
• 但更隐蔽的问题是：角色和障碍物的坐标是浮点数，而在某些帧下，由于跳跃公式产生的小数误差，导致矩形相交提前触发。

解决方案：将所有坐标在碰撞检测前强制取整（Math.floor），或者给矩形留出 1px 的缓冲区。这一步虽然简单，但如果不是亲自调试，很难想到。

3.2 性能杀手：每帧重新生成障碍物数组

早期版本中，AI 为了“简单”，每帧都在更新函数里重新生成整个障碍物数组：

function update() {
    obstacles = generateNewObstacles(); // 每帧分配新数组！
    // ...
}

结果是游戏运行几秒后帧数从 60 掉到 20，尤其是在低端安卓机上更明显。

解决方案：改为对象池（Object Pool）模式——预先生成一定数量的障碍物对象，用完后回收重用。虽然这需要一点额外代码，但把平均帧数稳定在了 58+。

3.3 音效与资源预加载的坑

我想加点跳跃音效和撞击音效，让 AI 生成了如下代码：

const jumpSound = wx.createInnerAudioContext();
jumpSound.src = 'audio/jump.mp3';

乍一看没问题。但实际测试时，第一次跳跃时会卡顿明显——因为音频是在播放时才开始下载和解码。

解决方案：在游戏开始时预加载所有音效（调用 wx.createInnerAudioContext() 并提前设置 src，然后调用 pause() 让它进入就绪状态）。此外，我还发现微信小游戏对音频格式有要求：必须是短小的 MP3 或 OGG，且文件名不能包含特殊字符。

四、成本控制：AI 开发到底省了多少钱？

注：以上成本按北京地区程序员日薪 800 元计算，不包括我的时间成本（毕竟是兴趣驱动）。

如果把我的时间也算进去（当作自由职业者），则：

• 传统模式：我需要投入 80 小时 ≈ 6,400 元（按自由职业日薪 800 元）
• AI 模式：我投入 20 小时 ≈ 1,600 元 + AI API 费用（Claude Pro + Midjourney）约 200 元

实际节省仍然在 50% 以上，并且后期维护成本更低（因为代码更集中，逻辑更清晰）。

五、上线与运营：审核、数据与第二曲线

5.1 微信审核的隐藏规则

提交审核时，我遇到了两次被拒：

1. 第一次：理由是“游戏内容过于简单，缺乏互动性”——其实是因为我在首页没有放明显的“开始游戏”按钮，审核员以为只是一个静态页面。
   • 改法：在游戏未开始前显示一个巨大的“点击开始”按钮，并在规则说明里写明“点击屏幕让恐龙跳跃”。
2. 第二次：理由是“涉及诱导分享”——因为我在游戏结束页放了一个“分享到朋友圈再继续一次”的按钮。
   • 改法：去掉诱导文案，只保留一个纯粹的“重新开始”按钮，分享改为兴趣式（“如果你觉得好玩，可以分享给朋友”）。

经验：微信小游戏审核更看重“是否像一个游戏”而非“是否好玩”。确保有明显的入口、明确的规则和反馈。

5.2 数据运营：从 0 日活到第二天的 83 人

上线后第二天早上我看到后台数据：

• 总启动次数：127
• 日活用户（DAU）：83
• 平均游戏时长：2 分 17 秒
• 次日留存：18%

这个数据对于一个没有任何推广的小游戏来说已经不错了。我后来尝试了两件小事：

1. 在游戏结束页加入了一句“今日最高得分：XXX)（实时拉取后台排名）”——这让玩家有了回来挑战自己的动力。
2. 每周更新一次皮肤（通过 AI 生成新角色）——虽然只换了一张图，但评论区出现了“今天的恐龙好萌！”之类的反馈。

5.3 第二曲线：把小游戏变成技术演示

有趣的是，这款小游戏最终没有靠流量赚到钱（广告收益不到 5 元），但它给我带来了意外的价值：

• 我在技术社区分享了《用 AI 开发微信小游戏的全流程》，吸引了约 2000 次阅读。
• 有人找我定制了类似的“AI 生成游戏”服务（例如年会互动小游戏），单子价格在 3000-5000 元之间。
• 更重要的是，这个项目让我深刻体会到：AI 不是为了取代程序员，而是把我们从重复劳动中解放出来，去做更高层次的设计和决策。

六、给想尝试的你：三条实用建议

1. 先跑通最小可玩原型（MVP），再追求完美

不要一上来就想做出“完美的游戏”。先让一个能跳跃、能撞到东西、能显示分数的原型跑起来，这就已经赢了 80%。其他的（美化、音效、排名）都可以在原型基础上迭加。

2. 把 AI 当成“实习生”，而不是“魔法师”

AI 能生成代码，但需要你：

• 把需求拆解成它能理解的小任务
• 检查它的输出是否真的符合预期（尤其是边界情况）
• 在它卡住时提供更具体的约束或示例

把 AI 看成一个学习能力很强但上下文敏感的实习生：你越清晰地告诉它要什么，它越能交出满意的答卷。

3. 资源压缩和性能调优是必修课

即使 AI 生成的代码和资源看起来完美，也别忘了：

• 用工具（如 Tinypng、SVGO）压缩图片
• 用 Chrome 性能面板检查帧率和内存
• 在真机低端机型上测试（微信开发者工具的性能往往乐观）

这些步骤目前还很难完全交给 AI，但只要形成检查清单，就能避免大多数上线前的意外。

七、结尾：不仅仅是一款小游戏

当我在朋友圈看到第一个不是亲戚的点赞时，我知道这件事已经超越了“做个小游戏玩玩”层面。它证明了一点：在 2026 年，一个没有美工背景、不想学复杂游戏框架的人，完全可以用 AI 工具链从零开始，做出一个有人愿意玩、愿意分享的微信小游戏。

当然，这款游戏不会成为下一个《纪念碑谷》——但它不需要。它只需要完成它被设计出来的使命：让我在无聊的下午找到点乐趣，同时也让我看到了 AI 真正能改变什么：不是取代创造力，而是让更多人能够以最低的门槛去创造。

如果你也有一个被搁置的小点子（不管是游戏、工具还是玩具），也许现在就是时候——打开你的 AI 助手，问它：“能帮我实现这个吗？”

（完）

附录：我使用的关键 Skills 列表（Claude Code）

1. game-loop-basic：基础渲染循环
2. input-handler-wechat：微信触摸事件封装
3. aabb-collision：带容错的 AABB 检测
4. obstacle-pool：障碍物对象池实现
5. score-timer：基于时间的得分计算
6. ui-button-simple：纯 Canvas 绘制的按钮
7. audio-preload-wechat：微信音效预加载封装
8. ranking-leancloud：简单的得分排名（后改为 Supabase） （还有 24 个用于资源生成、Prompt 调试等的 Skills，这里不一一列出）

本文首发于 softon.top，转载请保留版权声明。
文章更新于 2026-06-04，如有疑问或想一起交流 AI 游戏开发，欢迎在评论区留言。