这不是一篇"看我做了什么"的秀，而是一套你今天就能用的方法论。我会把 5 天开发一款倒水排序小游戏过程中踩的每个坑、写过的每条 prompt、犯过的每个错误，都拆解成你可以直接复制的经验。
这篇文章能给你什么？
如果你是程序员，想用 AI 辅助开发微信小游戏（或任何 Canvas 2D 游戏），读完这篇你能得到：
- 一套 spec.md 模板，让 AI 一次理解你想要什么
- 4 个层级的 prompt 写法，从低效到高效的对比
- 3 套 bug 报告模板，让视觉 bug 不再反复出现
- 多模型协作工作流，用视觉大模型帮你"翻译"设计意图
- 一个可复用的零引擎架构，14 个文件搞定完整游戏
- 真实的踩坑记录，帮你绕过我走过的弯路
背景：我用 Claude Code 花了 5 天做了一款微信原生 Canvas 2D 小游戏——「碰个瓶」（水排序解谜），117 条对话，14 个 JS 文件，零第三方引擎。以下所有 prompt 示例和踩坑记录都来自真实对话。
第一课：写 spec 还是直接开干？
结论先行：花 30% 时间写 spec，节省 70% 的返工时间。
很多人上来就跟 AI 说"帮我做个倒水游戏"——别这么干。AI 会按自己的理解去实现，结果大概率不是你想要的。你会陷入"改了这里坏了那里"的无限循环。
你的 spec.md 应该包含什么？
以下是我用过的 6 个模块，按重要性排序。前 3 个必写，后 3 个推荐写：
模块 1：技术边界（必写）
告诉 AI 什么能用、什么不能用。不写这个，AI 可能给你引入 Phaser、Three.js，然后你发现微信包体超了 4MB。
## 1. 项目概述
- **平台**：微信小游戏（原生 Canvas 2D API）
- **技术约束**：禁止使用 Phaser、Cocos、LayaBox 等任何第三方引擎
- **包体限制**：4MB 以内
模块 2：游戏规则（必写）
每条规则单独列出，覆盖所有边界条件。不要怕啰嗦——AI 理解自然语言的边界条件比理解模糊描述强得多。
## 2. 游戏机制
- 瓶子容量：固定 4 层
- 倒水源：只能从瓶子最顶部倒出
- 倒入条件：目标瓶为空 OR 顶部颜色相同
- 倒水量：k = min(源瓶顶部连续同色层数, 目标瓶剩余空间)
- 胜利条件：所有非空瓶子均为纯色
对比效果：有这段 spec，Claude Code 一次就写对了完整的倒水规则引擎、Undo 栈和胜负判定逻辑。没有的话，你至少要来回 5 轮才能把边界条件改对。
模块 3：视觉参数（最核心！）
这是我最重要的经验：视觉描述必须数字化。 不要说"好看的渐变"，说 rgba(255,255,255,0.35)。不要说"流畅的动画"，说 300ms, Back.Out 缓动。
## 3. 视觉规格
### 液体渲染
- 横向渐变：light(0~0.3) → base(0.5) → dark(0.8~1.0)
- 左侧高光条：宽 8px，白色 opacity 0.25
- 右侧暗边：宽 5px，rgba(0,0,0,0.12)
- 液面弧度：椭圆高度 7px，opacity 1.0
### 倒水动画时序
| 阶段 | 时间 | 缓动 |
|--------|-----------|------------|
| 预备 | 0ms | — |
| 倾斜 | 0-300ms | Back.Out |
| 水流 | 200-800ms | — |
| 回正 | 800-1000ms| Quad.Out |
模块 4-6：数据结构 / 资源分工表 / 验收标准
## 5. 数据结构
type Color = 'yellow' | 'orange' | 'blue' | ...
bottles: Color[][] // 二维数组，每个子数组从底到顶
history: Color[][][] // Undo 栈，每步深拷贝
## 6. 资源清单
【AI生成】bg_wall.png 750×1334 背景
Prompt: "Mobile game background, cozy drink shop..."
【代码绘制】液体/水流/粒子 Canvas 动态渲染
## 9. 验收标准
P0: 核心玩法可运行，无闪退
P1: 倒水动画含倾斜+水流+弹性增长，≥50fps
P2: 主题包装完整
spec 的核心原则：改了代码就改 spec
这是我给 Claude Code 对话窗口起的名字——"记得后面每次更改逻辑都需要同步更新 spec.md 内容"。
spec 是"单一事实来源"。如果代码和 spec 不一致，AI 下次参考 spec 时就会引入矛盾。每次让 Claude Code 改逻辑，同时让它更新 spec.md。
第二课：跟 AI 说话的正确姿势
这是我 5 天里最大的成长——学会了怎么写 prompt 效率能差 10 倍。
同一个需求的 4 种写法对比
我拿"让液体看起来有立体感"这个需求，展示真实迭代过程：
Level 1 — 我最初的写法（迭代了 5+ 轮没搞定）：
我想要把瓶子中水看上去更立体点
AI 理解"立体"可以是加阴影、加渐变、加 3D 透视、加光照……它不知道你具体要哪个。
Level 2 — 稍好：
液体需要横向渐变，左亮右暗，模拟圆柱体积感
方向对了，但 AI 需要猜渐变比例、透明度、宽度——仍需 2-3 轮微调。
Level 3 — 推荐写法（基本一次过）：
横向渐变: light(0~0.3) → base(0.5) → dark(0.8~1.0)
左侧高光条 8px 白色 opacity 0.25
右侧暗边 5px rgba(0,0,0,0.12)
Level 4 — 当你想一步到位时：
渲染顺序: ①背面玻璃底色(rgba(255,255,255,0.22~0.35))
→ ②液体层(横向渐变+椭圆液面)
→ ③前面玻璃高光(左10px白opacity0.35 + 描边内3.5px白外1.5px深)
你可以直接用的 Prompt 模板
我总结出视觉类 prompt 最高效的"三段式"结构：
# 角色
你是资深的微信小游戏前端开发 + 休闲游戏美术工程师，
擅长用 Canvas 2D 实现伪 3D（2.5D 等距视角）的卡通渲染效果。
# 视觉规格（全部用数字）
- 瓶身: 宽110px 高264px, 椭圆比0.27
- 瓶颈: 瓶身宽的60%, 凸缘65%
- 各段高度: 凸缘5% / 瓶颈4% / 肩部6% / 瓶身85%
- 玻璃: 填充rgba(255,255,255,0.15), 描边2-3px白色
- 高光: 左侧纵向条 宽8%瓶宽, opacity 0.6
# 交付格式
1. 先输出视觉分析（3-5条）
2. 文件结构
3. 完整代码（BottleRenderer 类 + draw() 方法）
4. 调优清单（至少5条）
为什么要写"交付格式"？ 因为不写的话，AI 可能给你一段不完整的代码片段，你还得再来一轮说"请给完整代码"。提前约定好格式，一次拿到想要的输出。
绝招：让 AI 教你写 Prompt
这是我的一个意外发现——当你不知道怎么描述一个视觉效果时，可以直接问 AI：
如果要实现给的图片样的效果（有阴影、有立体感），
我该如何给提示词和组织语言呢？
AI 会告诉你应该描述哪些维度（光源方向、透明度、渐变方式、阴影参数），然后你用这些维度去写具体的 prompt。等于让 AI 教你怎么跟 AI 说话。
第三课：多模型协作——让大模型帮你"翻译"视觉意图
这是我整个开发过程中最提效的一个发现：不要只用一个模型，用多个模型各司其职。
核心痛点：你看得到差距，但说不出来
你打开竞品游戏截了个图，又打开自己的游戏截了个图。你能看到差距——人家的瓶子有玻璃质感，你的像塑料桶。但你不知道怎么用技术语言描述这个差距。
如果你直接跟 Claude Code 说"把瓶子做得像参考图一样好看"——它无法"看"图片（CLI 模式下），就算能看，它也不知道你觉得哪里差。
解决方案：视觉大模型做"翻译官"
工作流是这样的：
Step 1: 你截两张图（竞品效果 + 当前效果）
↓ 贴图 + 描述差异点
Step 2: 发给视觉大模型（Opus 4.7 / GPT-5.5 等）
它能"看懂"图片，输出精确的技术参数
↓ 拿到 prompt（可微调）
Step 3: 把 prompt 喂给 Claude Code
Claude Code 按参数写代码
↓
Step 4: 运行 → 看效果 → 满意就下一个，不满意回 Step 1
真实案例：瓶子玻璃质感的实现
Step 1 — 你发给视觉大模型的内容：
[贴两张截图]
左图是 Ball Sort Puzzle 的瓶子效果（参考），右图是我当前的效果。
差异点：
1. 参考图的瓶子有玻璃通透感，我的像实心塑料
2. 参考图液体有圆柱立体感（左亮右暗），我的是纯色块
3. 参考图瓶底有椭圆投影，我的没有阴影
请输出一份 Canvas 2D 渲染参数，包含具体的 rgba 值、
像素尺寸、渐变方向和渲染层级顺序，
让开发工具可以直接实现这个效果。
Step 2 — 视觉大模型输出的 Prompt（节选）：
渲染顺序（从后到前）：
① 背面玻璃底色：线性渐变 rgba(255,255,255,0.22) → rgba(255,255,255,0.35)
② 液体层：
- 横向渐变 light(0~0.3) → base(0.5) → dark(0.8~1.0)
- 左侧高光条 8px 白色 opacity 0.25
- 液面椭圆 height=7px
③ 前面玻璃高光：
- 左侧纵向高光 10px 白色 opacity 0.35
- 右侧弱反光 4px opacity 0.08
- 瓶肩弧形反射线
④ 描边：内层白色 3.5px + 外层深色 1.5px
⑤ 地面投影：椭圆 blur=12 rgba(0,0,0,0.3) 偏移(4,8)
Step 3 — 你微调后喂给 Claude Code：
你可能觉得 opacity 0.35 太亮了，改成 0.25。或者觉得描边 3.5px 太粗，改成 2px。微调后直接发给 Claude Code，它拿到精确参数就能一次实现。
为什么这样做效率最高？
因为每个模型做它最擅长的事：
| 模型 | 擅长的事 | 不擅长的事 |
|---|---|---|
| 视觉大模型（Opus 4.7/GPT-5.5） | 看图 → 输出技术描述 | 不能直接改你的代码 |
| Claude Code（Opus 编码模式） | 理解文字 → 修改代码 | CLI 模式下不能看截图 |
| 你 | 判断效果好不好 | 写不出精确的 rgba 参数 |
三者组合形成了完整的闭环：你用眼睛判断，视觉大模型用理解力翻译，Claude Code 用编码力实现。
你可以直接用的"翻译"提示词模板
发给视觉大模型时，用这个模板最高效：
[贴截图A: 参考效果] [贴截图B: 当前效果]
## 差异点
1. [你看到的第一个差距]
2. [你看到的第二个差距]
3. [你看到的第三个差距]
## 需要你输出
请分析两图的视觉差异，输出一份可以直接让
Canvas 2D 开发工程师实现的技术参数，包含：
- 具体的 rgba 颜色值和透明度
- 像素级的尺寸参数
- 渲染层级顺序（从后往前）
- 渐变方向和关键点位置
- 阴影/高光/描边的具体参数
关键：描述差异点是你要做的事。 你不需要知道怎么修，但你需要指出哪里不对。大模型看了图 + 你的描述，就能精确输出修复方案。
第四课：视觉 Bug 修不好？你的问题报告写错了
这是我踩的最大的坑——一个"液体没贴底"的 bug 修了 4 次，每次都回来。
为什么会修了又回来？
因为我一开始的 bug 报告是这样的：
瓶子最下面应该要充满液体
AI 不知道"没充满"差了多少，不知道是哪个坐标算错了，只能猜着改。改了一处可能影响另一处，于是 bug 反复出现。
正确的做法：数据驱动修 Bug
我后来总结出的"三步修 Bug 法"：
Step 1：让 AI 先加 debug 日志（不是直接修！）
请在 drawLiquids 函数开头添加以下日志：
console.log('瓶底Y:', bodyBottom);
console.log('液体区起始Y:', liquidAreaTop);
liquids.forEach((l, i) => {
console.log(`第${i}层 bottomY:`, bodyBottom - i * layerH);
});
Step 2：运行后，把真实数据贴给 AI
模拟器输出：
瓶底Y: 264
液体区起始Y: 39.6
第0层 bottomY: 220 ← 瓶底264但液体只到220，差了44px！
Step 3：给 AI 根因分析 + 精确修复指令
根因：layerH = bodyH / 4 计算错误
bodyH 包含了瓶颈+肩部高度，但液体不进入瓶颈区域
❌ 当前: this.layerH = this.H / this.maxLayers
✅ 修改为: this.layerH = (this.bodyBot - this.shoulderBot) / this.maxLayers
这次一轮搞定，再没复现。
3 套可复用的 Bug 报告模板
模板 A：视觉对比型（适合布局/定位问题）
## 问题
❌ 当前: 液体浮在瓶子中间
✅ 期望: 液体紧贴瓶底
## ASCII 对比
错误: 正确:
│ ▓▓▓ │ │ │
│ │ │ ▓▓▓ │
╰─────╯ ╰─────╯
模板 B：数据驱动型（适合坐标/尺寸计算问题）
## 请先加 debug 日志
console.log('瓶底Y:', bodyBottom);
console.log('第0层Y:', layerBottomY);
## 模拟器实际输出
瓶底Y: 264, 第0层Y: 220 ← 差了44px!
## 根因 + 修复
layerH 计算包含了瓶颈高度，应只计算液体可用区域
模板 C：优先级标签型（适合多个问题同时存在）
## 🔴 P0 关键：液体未贴底（必须修）
## 🟠 P1 重要：层间分隔线太粗 2.5px→1.5px
## 🟢 P2 优化：瓶肩弧度可更圆润
## 验收标准
- [ ] 4层液体贴紧瓶底，无空隙
- [ ] 分隔线清晰但不突兀
一个血泪教训：不要暴力全删
我有一次对瓶身白色描边太粗感到烦躁，写了这样的 prompt：
把代码里所有 ctx.strokeStyle = 'rgba(255, 255, 255 开头的
代码全部注释掉或删除
结果：描边是没了，但空瓶子也看不见了，布局全乱了，又花了 3 轮修副作用。
正确做法：先让 AI 列出所有 stroke 调用的位置，然后只改目标位置的参数（0.8 → 0.25），不删除。
第五课：零引擎架构——你可以直接拿去用
做微信小游戏不需要引擎。Canvas 2D 足够简单，而且微信包体限 4MB，引入 Phaser/Cocos 直接超标。
14 个文件的架构
这套架构可以直接复用到你的项目：
你的小游戏/
├── game.js # 入口 (~100行)
├── spec.md # 设计规格
├── js/
│ ├── base/ # ← 这4个文件每个游戏都一样
│ │ ├── sceneManager.js # 场景管理器
│ │ └── tween.js # 补间动画引擎
│ ├── data/
│ │ ├── config.js # 全局参数(一处修改)
│ │ └── levels.js # 关卡数据
│ ├── objects/
│ │ ├── bottle.js # 游戏对象
│ │ └── particle.js # 粒子系统
│ ├── scenes/
│ │ ├── gameScene.js # 核心场景(主战场)
│ │ └── resultScene.js # 结算场景
│ └── utils/
│ ├── audio.js # 音频(wx.createInnerAudioContext)
│ ├── imageManager.js # 图片预加载
│ ├── renderer.js # 渲染工具
│ └── storage.js # 存储(wx.setStorageSync)
├── images/ # AI生成的美术资源
└── audio/ # 音效
让 Claude Code 一次生成基础设施
你可以用一条 prompt 让 AI 生成上面 js/base/ 里的所有基础文件：
帮我搭建一个微信小游戏的基础框架：
1. game.js 入口：Canvas 2D + HiDPI适配 + 设计分辨率750×1334 + requestAnimationFrame主循环
2. SceneManager：register(name, scene) / switchTo(name, params) / 输入事件分发
3. Tween 引擎：支持 linear/quadOut/backOut/elasticOut/bounceOut 缓动函数
4. ImageManager：preload([paths]) 批量预加载 + get(path) 获取
5. Audio：基于 wx.createInnerAudioContext 的音频管理器
6. Storage：wx.setStorageSync/getStorageSync 的简单封装
技术约束：纯 Canvas 2D，禁止第三方引擎，每个模块一个文件
这套基础设施我做了 10+ 款小游戏，每次都是让 AI 基于这个模板一次生成，然后只改游戏逻辑部分。
关键设计原则：参数集中到 config.js
// config.js — 所有可调参数集中在这里
const CONFIG = {
colors: {
yellow: { base: '#FFD426', light: '#FFE566', dark: '#E6B800' },
// ...
},
bottle: { width: 110, height: 264, maxLayers: 4 },
anim: {
pourTiltDuration: 150, // 倾斜耗时
pourTiltAngle: -Math.PI * 0.55, // 倾斜角度
streamWidth: 10, // 水流宽度
},
};
好处：调参数不用翻代码逻辑。跟 AI 说"把倾斜角度改成 100 度"，它只改 config.js 一行。
第六课：Claude Code 擅长逻辑，但游戏更需要美术和动效
这是我开发过程中最深的一个体会：Claude Code 是代码逻辑的天才，但游戏的灵魂在美术和动效——而这恰恰是纯代码 AI 的短板。
Claude Code 能一次搞定的事
倒水逻辑引擎、Undo/Redo 栈、关卡数据生成、缓动函数库、微信 API 封装——这些纯逻辑的东西，Claude Code 基本一条 prompt 就写对了。规则明确、边界清晰的任务，它比人快 10 倍。
但游戏不只是逻辑
一个水排序游戏，逻辑可能只占 20% 的工作量。剩下 80% 是什么？
- 瓶子要看起来像透明玻璃，不是塑料杯
- 液体要有左亮右暗的渐变，像真实的圆柱体
- 倒水要有弧线水流 + 溅射水花 + 液面弹性上升
- 盖塞要有咔嗒音效 + 手机震动的仪式感
- 背景、袋子、按钮需要精致的美术素材
- 通关页面需要烟花动效 + 成就数据展示
这些东西，Claude Code 写出来的代码逻辑可能是对的，但视觉效果对不对、动画节奏好不好，它自己看不到。CLI 模式下没有眼睛，它只能靠你的反馈来迭代。
解决方案：AI 素材生成 + 多模型协作
我的做法是把美术和动效拆成两条线并行推进：
静态美术 → AI 图片生成工具搞定。 背景图、购物袋、瓶塞、通关页面背景——这些不需要动态变化的素材，用 AI 图片生成（Midjourney / 豆包等）直接出图，效果比自己画好得多。我这个游戏里 20+ 张美术素材全部是 AI 生成的。
动态效果 → Claude Code 写代码 + 视觉大模型翻译。 液体渐变、水流动画、粒子特效这些必须用代码实现的效果，我用视觉大模型（能看图的 AI）帮我把「我觉得不好看」翻译成精确的参数，再喂给 Claude Code 去改代码。
spec 中提前标记分工：
【AI生成】bg_wall.png — 用 AI 图片工具生成
【AI生成】bag_*.png — 8个颜色的购物袋
【代码绘制】液体/水流/粒子 — Claude Code 用 Canvas API 实现
这样 Claude Code 写代码时，对 AI 生成的图片预留 drawImage 接口 + 纯色占位。美术素材什么时候到位，什么时候替换进去，互不耽误。
核心认知：Claude Code 是最强的「代码手」，但做游戏你还需要「美术眼」。AI 图片生成工具就是你的美术团队，视觉大模型就是你的「设计→代码」翻译官。三者组合，才是一个人做出精致游戏的完整工具链。
第七课：人和 AI 各做什么最高效？
5 天下来，我发现了清晰的效率分界线。
AI 一次搞定的事（你别自己写）
| 事项 | 一条 prompt 搞定 |
|---|---|
| 倒水逻辑引擎 | "按 spec 第 2 节实现倒水规则" |
| Undo/Redo 栈 | "每步保存 bottles 深拷贝" |
| 关卡数据生成 | "生成 10 关数据，3色→7色递增难度" |
| Tween 动画引擎 | "实现 7 种缓动函数" |
| 微信 API 封装 | "封装 storage/audio/ad 模块" |
必须靠人迭代的事（别指望一次过）
| 事项 | 为什么 |
|---|---|
| 2.5D 瓶子外观 | 迭代了 15 轮，AI 无法"看到"效果 |
| 动画节奏感 | 2.7s→2s→1.5s，必须人眼判断 |
| 配色微调 | rgba 的最后一位差 0.1 效果完全不同 |
| 功能取舍 | "去掉加瓶子按钮"——AI 不会替你做产品决策 |
人机并行工作流
这是效率最高的模式——AI 写代码的同时，你去用 Midjourney 生图：
spec 中标记资源分工:
【AI生成】bg_wall.png — Claude Code 在代码中预留 drawImage + 占位色块
【代码绘制】液体渲染 — Claude Code 用 Canvas API 实现
你的流程：
1. Claude Code 写代码（用色块占位 AI 图片位置）
2. 你同时用 Midjourney 生成背景/图标
3. 把 PNG 放进 images/ 目录 → 自动替换占位 → 完成
代码中预留接口长这样：
// 如果有 AI 生成的背景图就用，没有就用纯色占位
const bgImg = ImageManager.get('images/bg_wall.png');
if (bgImg) {
ctx.drawImage(bgImg, 0, 0, 750, 1334);
} else {
ctx.fillStyle = '#1a1a3e'; // 占位纯色
ctx.fillRect(0, 0, 750, 1334);
}
这意味着你的游戏在没有任何美术资源的情况下就能跑通逻辑。 美术是最后才替换进去的。
第八课：我踩过的坑，帮你绕过去
坑 1：别用 AI 生图做动态元素
我最初尝试用 Midjourney 生成瓶子图片（静态 PNG），然后发现：
- 不同图的光影角度不一致
- 瓶子倾斜时 PNG 无法跟着变形
- 选中态高光无法动态叠加
- 每次修改需要重新生图
Day 2 的关键决策：放弃 AI 瓶子图，全部改为 Canvas 代码绘制。
规律：
- 静态不变的东西 → AI 生图（背景、图标、按钮）
- 需要交互/动画的东西 → Canvas 代码绘制（液体、粒子、水流）
坑 2：倒水动画从"瞬移"到"丝滑"的 7 轮打磨
这是真实的迭代过程，每轮的 prompt 和结果：
| 轮 | prompt 关键句 | 结果 |
|---|---|---|
| 1 | "实现基本倒水动画" | 液体瞬间转移，毫无体验 |
| 2 | "加入瓶子抛物线飞行路径" | 有了飞行感，但没有倾斜 |
| 3 | "参考 Ball Sort Puzzle，倾斜 100°" | 倾斜了但没有水流效果 |
| 4 | "加贝塞尔曲线水流" | 水流弯弯曲曲不自然 |
| 5 | "水流改为 L 形直角路径" | 自然了！但 2.7 秒太慢 |
| 6 | "整个过程控制在 2 秒内" | 节奏对了 |
| 7 | "A 瓶子的水位需要随倾斜角度变化" | 完美 |
经验：动画类需求不可能一步到位，但每轮 prompt 要聚焦一个问题。不要一次提 5 个修改——AI 会把其中 3 个弄对、2 个弄错，然后你分不清哪些是新 bug。
坑 3：微信包体 4MB 超限
加入 20+ 张 AI 生成的 PNG 后：
Error: source size 5428KB exceed max limit 4MB
解决方案：
- 压缩图片（TinyPNG）
- 小图标合并成 spritesheet
- 能用代码画的就别用图片（比如渐变背景）
坑 4：Claude Code 上下文耗尽
长时间迭代视觉效果后，上下文窗口用完了。用 /compact 压缩上下文继续开发：
/compact
Claude Code 会自动总结之前的对话，保留关键上下文继续工作。我 5 天开发只用了 5 个会话，关键信息始终连贯。
第九课：Claude Code 的进阶用法
1. Plan Mode —— 大改之前先出方案
当你要做复杂重构（比如整个瓶子渲染引擎升级），不要直接让 AI 改代码。用 Plan Mode：
# 在对话中自然触发 Plan Mode
"我想升级瓶子渲染引擎，从简单圆角矩形改为 2.5D 玻璃质感，
请先出一个改造方案，列出要改哪些文件、影响范围"
Claude Code 会进入计划模式，列出：
- 需要修改的文件和行号
- 每个修改的具体内容
- 可能的风险点
你确认后它才开始改。这避免了"AI 改了 5 个文件但有 2 个改错了"的灾难。
2. 对话窗口命名 —— 固化项目级规则
我给对话窗口起名叫"记得后面每次更改逻辑都需要同步更新 spec.md 内容"。
这不只是备忘——它会作为上下文一直提醒 Claude Code。你可以用类似的方式固化项目规则：
- "所有颜色值统一走 config.js 不要硬编码"
- "新增功能前先更新 spec.md"
- "Canvas 绑定设计分辨率 750x1334"
3. 角色设定 —— 在关键时刻激活专业知识
不需要每条 prompt 都写角色设定，但在遇到专业问题时加上会显著提升效果：
# 角色
你是资深的微信小游戏前端开发 + 休闲游戏美术工程师，
擅长用 Canvas / SVG / CSS 实现伪 3D（2.5D 等距视角）的卡通渲染效果
我是在迭代了 20+ 轮瓶子 3D 效果后才加上这个角色设定的——加上之后效果明显提升。AI 开始主动考虑光影、玻璃折射、椭圆投影等专业细节。
快速行动清单
如果你今天就想开始用 Claude Code 做小游戏，按这个顺序走：
第 0 步：选型
- 2D 休闲游戏 → 微信原生 Canvas 2D（零引擎）
- 3D 或复杂 2D → Cocos Creator（但要注意包体大小）
第 1 步：写 spec.md（花半天）
- 用本文的 6 模块模板
- 视觉参数精确到 px / rgba / ms / 缓动函数
- 标记每个资源的实现方式：【AI生成】或【代码绘制】
第 2 步：生成基础架构（一条 prompt）
- SceneManager + Tween + ImageManager + Audio + Storage
- 告诉 AI "技术约束：微信原生 Canvas 2D，禁止第三方引擎"
第 3 步：实现核心逻辑（1-2 天）
- 让 AI "按 spec 第 2 节实现"
- 用纯色矩形占位所有美术资源
- 确保逻辑跑通——先能玩，再好看
第 4 步：视觉打磨（2-3 天，最耗时）
- 用"三段式"prompt 模板：角色 + 参数 + 交付格式
- bug 用"数据驱动修复法"：加日志 → 贴数据 → 给修复指令
- 同步用 Midjourney 生成静态美术资源
第 5 步：接入音效 + 广告 + 上线
wx.createInnerAudioContext音效wx.createRewardedVideoAd激励广告wx.setStorageSync本地存档
最终成果：5 天的 Vibecoding 做出了什么？
这就是 5 天 Vibecoding 的最终效果：
- 2.5D 玻璃瓶：带通透玻璃质感、高光、瓶盖、椭圆投影
- 7 种彩色液体：横向渐变 + 椭圆液面 + 层间分隔线，有真实的圆柱立体感
- 丝滑倒水动画：拾起 → 飞行 → 倾斜 → 水流 → 液面弹性上升 → 回正，全程 2 秒
- 完整功能：Undo / Shuffle / 音效 / 本地存档 / 微信分享
来玩一下？
微信搜索小游戏 「碰个瓶」 就能体验这个纯 Vibecoding 的作品。如果搜不到，说明还在审核中，敬请期待。
如果你觉得手感不错——这里面的每一行代码都是 Claude Code 写的，每一个视觉细节都是人和 AI 迭代出来的。
你也可以做到。 用这篇文章里的方法论，选一个你喜欢的小游戏类型，从写 spec.md 开始。
真实数据
| 指标 | 数据 |
|---|---|
| 开发周期 | 5 天 |
| 对话会话 | 5 个 |
| 用户消息 | ~117 条 |
| 源文件 | 14 个 JS 文件 |
| spec.md | 227 行 |
| 视觉迭代最多 | 瓶子 3D 外观 15+ 轮 |
| 动画迭代最多 | 倒水动画 7 轮 |
| 最顽固的 bug | 液体贴底问题 4 次复现 |
| AI 生成图片 | 20+ 张 |
最后
Vibecoding 的本质不是"让 AI 写代码"——而是把你变成一个有 AI 助手的全栈团队。
你是产品经理（写 spec）+ 美术总监（审视觉）+ QA（报 bug）。 AI 是前端工程师 + 动画师 + 平台适配专家。 视觉大模型是你的"技术翻译官"——帮你把"我觉得不好看"转化成精确的 rgba 参数。
你不需要会写 Canvas 渲染代码，但你需要会说"左侧高光条 8px 白色 opacity 0.25"。
Prompt 写得好不好，决定了你是跟 AI 协作还是跟 AI 吵架。
如果这篇文章对你有帮助：
- 来玩玩成品 —— 微信搜「碰个瓶」，感受一下 Vibecoding 的实际效果（如果搜不到说明还在审核中）
- 动手试试 —— 选一个你喜欢的游戏类型，从写 spec.md 开始
- 分享给朋友 —— 让更多程序员知道这套方法论
逐光·AI实战手记
