为什么我决定用 AI 开发小游戏
去年年底，我突然想起一个念想：做个微信小游戏。不是为了赚钱，就是想看看能不能在一个周末内从零到上线。
传统路线是什么？学微信小游戏 API、配置开发环境、手写 Canvas 绘制逻辑、调试兼容性问题……这套下来没个一两周根本搞不定。但我手里有 Cursor + Claude Code，何不试试让 AI 来做这件事？
结果出乎意料——3 天从 Prompt 到微信审核通过。这篇文章就是完整的实战记录。
第一步：设计游戏机制（最关键的 Prompt）
我没有直接甩代码需求，而是先花了半小时设计游戏。选了个简单但有趣的方向：2048 风格的数字合并游戏。
为什么选这个？
- 逻辑清晰：滑动合并相同数字
- 胜负条件明确：达到 2048 或无法继续
- 微信小游戏友好：不需要复杂的网络交互
- 容易扩展：后续可加排行榜、分享功能
然后我写了这个 Prompt（这是关键）：
我要开发一个微信小游戏，基于 2048 的玩法。
游戏规则：
1. 4x4 网格，每个格子可以放数字
2. 初始状态：随机两个格子出现 2 或 4
3. 玩家滑动屏幕（上下左右），相同数字向滑动方向合并，合并后数字翻倍
4. 每次滑动后，随机位置出现新的 2 或 4
5. 当无法继续滑动时游戏结束
6. 目标：达到 2048 获胜
技术要求：
- 使用微信小游戏 Canvas API
- 支持触摸事件（上下左右滑动）
- 显示当前分数和最高分（本地存储）
- 游戏结束后显示重新开始按钮
- 适配不同屏幕尺寸
代码结构：
- game.js：游戏逻辑（网格管理、合并算法、分数计算）
- render.js：Canvas 绘制（网格、数字、UI）
- input.js：触摸事件处理
- main.js：入口和初始化
请生成完整的可运行代码。
这个 Prompt 的关键是：明确的规则 + 清晰的技术要求 + 代码结构建议。Claude Code 拿到这个，直接生成了 80% 可用的代码。
第二步：Cursor 中的代码生成与迭代
我在 Cursor 中打开了微信小游戏项目模板，然后：
-
创建 game.js：粘贴上面的 Prompt，Claude Code 生成了完整的游戏逻辑
- 网格初始化
- 滑动合并算法
- 分数计算
- 胜负判定
-
创建 render.js：让 Claude Code 根据游戏逻辑生成 Canvas 绘制代码
- 网格背景
- 数字渲染（不同数字不同颜色）
- 分数显示
- 游戏结束界面
-
创建 input.js：处理触摸事件
- 识别滑动方向
- 防止误触（设置最小滑动距离）
- 调用游戏逻辑
-
创建 main.js：整合所有模块
第一次生成的代码能跑，但有问题：
- 合并算法有 bug（同一行多个相同数字合并时顺序错误）
- Canvas 绘制性能差（每帧重绘整个网格）
- 触摸事件响应延迟
我用 Claude Code 的 @codebase 功能让它看到整个项目，然后逐个修复：
@codebase 中的合并算法有问题。
当一行有 [2, 2, 2, 4] 时，向右滑动应该得到 [0, 2, 4, 4]，
但现在得到的是 [0, 0, 4, 8]。
问题在哪里？怎么修复？
Claude Code 立即定位到问题（合并后没有重新检查相邻元素），给出了修复方案。
性能优化也是这样：
Canvas 绘制太慢了，每帧都在重绘。
能不能只重绘变化的格子？
它建议用脏矩形（dirty rectangle）技术，只重绘有变化的区域。代码改了不到 20 行，帧率从 30fps 提升到 60fps。
第三步：本地测试与踩坑
代码写完后，我在微信开发者工具中测试。这里踩了几个坑：
坑 1：触摸事件坐标映射
微信小游戏的触摸坐标是相对于 Canvas 的，但我一开始用的是相对于屏幕的。结果滑动识别完全错乱。
我问 Claude Code：
touchstart 事件的 touches[0].clientX 和 Canvas 坐标系的关系是什么？
怎么正确转换？
它给出了标准答案：需要减去 Canvas 的 getBoundingClientRect() 偏移量。
坑 2：本地存储 API 不同
浏览器用 localStorage，微信小游戏用 wx.getStorage / wx.setStorage（异步）。我的代码一开始用的是同步 API，导致最高分保存失败。
Claude Code 帮我改成了异步版本，并加了错误处理。
坑 3：屏幕适配
iPhone 和 Android 的屏幕尺寸差异大。我让 Claude Code 生成了自适应代码：
const screenWidth = wx.getSystemInfoSync().screenWidth;
const screenHeight = wx.getSystemInfoSync().screenHeight;
const gridSize = Math.min(screenWidth, screenHeight) * 0.9;
这样在任何设备上都能正常显示。
第四步：优化用户体验
代码能跑了，但游戏体验还差点意思。我加了几个细节：
- 动画效果：数字合并时有缩放动画，新出现的数字有淡入效果
- 音效：合并时有"嘟"的声音（用 wx.playSound）
- 分享功能：游戏结束后可以分享到微信群
- 排行榜：用微信云开发存储最高分
这些都是让 Claude Code 根据现有代码逐个加的。每次我只需要说"加个合并动画"，它就能理解上下文，生成符合现有代码风格的新功能。
第五步：微信开放平台审核
代码完成后，我在微信开放平台提交了审核。这里有几个要点：
1. 游戏描述要清楚
微信审核团队会玩你的游戏。我的描述是：
一个经典的数字合并游戏。滑动屏幕合并相同的数字，达到 2048 即可获胜。支持本地最高分记录。
简洁、准确，没有夸大其词。
2. 隐私政策
微信要求声明你收集了什么数据。我的游戏只存储本地最高分，所以隐私政策很简单：
本游戏仅在本地存储您的最高分数，不收集任何个人信息。
3. 内容合规
确保游戏内容没有违规内容。数字游戏肯定没问题，但如果是其他类型的游戏要特别注意。
审核结果：一次通过。从提交到上线只花了 6 小时。
第六步：上线后的数据
游戏上线后，我用微信云开发的数据分析看了一下数据：
- 首日用户：127 人（主要是我分享给朋友的）
- 平均游戏时长：8 分钟
- 完成率（达到 2048）：23%
- 重玩率：42%
这个数据对一个个人小游戏来说还不错。说明游戏的可玩性还可以。
用 AI 开发小游戏的核心经验
1. Prompt 是一切的基础
好的 Prompt 能让 Claude Code 一次生成 80% 的可用代码。差的 Prompt 会导致反复修改。我花在 Prompt 上的时间（30 分钟）省了我后续 5 小时的调试时间。
2. @codebase 是你的超级武器
不要让 Claude Code 在真空中工作。用 @codebase 让它看到整个项目，它能理解上下文，生成的代码风格一致，集成度高。
3. 小步快走，不要一次性要求完美
我没有一开始就要求"完美的游戏"，而是先要求"能跑的游戏"，然后逐步加功能、优化性能、改进体验。这样每一步都能快速验证，发现问题也容易定位。
4. 人工审查是必须的
AI 生成的代码有时候逻辑对但性能差，有时候功能完整但边界情况处理不周。我每次都会自己跑一遍、测一遍，找到问题后让 Claude Code 修复。
5. 微信小游戏的坑要提前知道
触摸事件、本地存储、屏幕适配……这些微信特有的 API 和限制，最好在 Prompt 中就提到。这样 Claude Code 能从一开始就避免这些坑。
成本核算
这个项目用了多少 Claude Code 的 token？
- 初始代码生成：约 15,000 tokens
- 调试和优化：约 8,000 tokens
- 功能扩展：约 6,000 tokens
- 总计：约 29,000 tokens
按 Claude 3.5 Sonnet 的价格（$3/100K input tokens），成本不到 1 块钱。
如果我自己手写这个游戏，保守估计需要 20 小时。按我的时薪，成本是 1000+ 块。
ROI：1000 倍。
总结
用 AI 开发微信小游戏不是科幻，而是现实。关键是：
- 设计好游戏机制（30 分钟）
- 写好 Prompt（30 分钟）
- 让 Claude Code 生成代码（1 小时）
- 自己测试和修复（2 小时）
- 提交审核（6 小时等待）
总耗时：3 天，成本：不到 1 块钱。
下一步我想试试用 AI 开发一个稍微复杂点的游戏——比如塔防或卡牌游戏。如果这个也能成功，我可能会考虑做成一个系列。
如果你也想试试，我的建议是：别想太复杂，从 2048 这样的简单游戏开始。一旦你体验到 AI 编程的威力，你会发现很多"不可能"的事其实只需要一个好 Prompt。