微信小游戏/小程序 AI 开发保姆级教程：从需求拆解到云托管上线的完整工作流

一、先把问题定义清楚：AI 能做什么，不能做什么

原始分享里提到”一个周末写出 12 款小游戏 + 一个云托管后端”，这件事能成立的真实原因不是模型”一键生成游戏”，而是 开发流程被拆成了模型擅长的若干环节 ：

• 需求 → 结构化玩法规格（数值、状态机、胜负条件）
• 规格 → 可运行代码骨架（入口、主循环、渲染、触摸、存档）
• 报错栈 → 定位到具体文件与行，给出修复补丁
• 后端需求 → 路由、鉴权、容器配置、部署命令

而下面这些环节 必须由工具链完成，模型无法代替 ：在微信开发者工具里编译预览、真机扫码调试、提交审核、云托管控制台构建镜像、配置环境变量与数据库。所以正确的心智模型是： 模型产出内容与补丁，IDE / 终端 / 控制台负责执行与验证 。涉及渲染、文件产出、部署的动作，都需要在具备代码执行能力的 Agent 环境或本地开发环境中落地。

二、路线选择：小游戏还是小程序

这一步选错，后面全白做。两者的技术栈、审核路径完全不同。

维度	微信小游戏	微信小程序
渲染	wx.createCanvas() + WebGL/Canvas 2D	WXML/WXSS 组件 + 逻辑层
代码组织	纯 JS 工程，无 DOM、无 window	页面四件套 + 自定义组件
典型框架	Cocos Creator、Laya、原生 Canvas	原生、TDesign、Taro、uni-app
后端接入	wx.cloud.callContainer / wx.request	同左
类目与资质	属”游戏”类目，涉及版号/备案等要求，需以微信官方最新政策为准	按服务类目提交对应资质，路径相对轻
适合练手	休闲玩法（躲避、消除、跑酷）	工具类、内容类、表单类

建议 ：如果是个人练手且想快速跑通全链路，先做小程序或”休闲玩法小游戏”的本地跑通，再处理类目资质。资质问题不要问模型要结论，直接查微信官方文档，模型给的信息可能滞后。

三、整体工作流：五个阶段与分工

阶段	你负责	AI 负责	产出物	验证方式
1 需求拆解	说清玩法与手感	输出玩法规格、状态机、数值表、文件树	spec.md	人工评审规格
2 骨架与玩法	建工程、装依赖	生成入口、主循环、渲染、触摸、存档代码	可运行工程	开发者工具编译通过
3 调试排错	复制报错、真机复现	定位原因、给最小修复补丁	修复后的代码	真机预览通过
4 后端与联调	建云托管服务、配环境变量	生成 Dockerfile、路由、鉴权、调用代码	可调用的 API	callContainer 返回 200
5 批量复用	定模板与配置规范	参数化改造、批量生成变体	N 款游戏	逐款冒烟测试

四、阶段 1：需求拆解与技术方案定稿

这一步的产出质量决定后面所有代码的质量。 不要让模型直接写代码 ，先让它把模糊想法变成可实现的规格。

可直接复制的 Prompt：

【任务目标】
把下面的游戏想法拆解为可直接进入编码的技术规格，不要写实现代码。
【输入信息】
- 玩法描述：竖屏单手操作，玩家控制底部挡板左右移动接住下落方块，
  接到加分、漏接扣 1 点生命，3 点生命耗尽结束；每 100 分下落速度提升一档。
- 目标平台：微信小游戏（原生 Canvas，无 Cocos）
- 目标用户：微信内休闲玩家，单局时长 60~120 秒
- 约束：主包体积控制在 2MB 内；不做联网对战；需要本地最高分存档
【执行要求】
1. 输出玩法规格：核心循环、操作映射、状态机（至少包含 ready/playing/paused/over 四态及迁移条件）
2. 输出数值表：挡板宽度与速度、方块尺寸与生成间隔、初速与加速曲线、生命值、计分规则
3. 输出文件树：区分入口层、核心循环层、渲染层、实体层、配置层，并说明每层职责边界
4. 指出 3 个最容易出错的实现点（例如 dt 异常、分辨率适配、触摸坐标偏移），只描述风险不写代码
5. 明确列出哪些能力需要额外接入（存档、排行榜、后端），以及各自的最小实现路径
【预期输出】
Markdown 格式，分「玩法规格 / 数值表 / 文件树 / 风险点 / 外部依赖」五节，
数值表用表格，所有数值给出取值理由，不要出现"根据情况调整"这类空话。

拿到规格后，人工做两件事：确认手感参数是否合理，确认文件树的分层是否够薄。 分层过厚是小游戏项目最常见的自找麻烦 ——超过 4 层，改一个数值要跳三个文件。

五、阶段 2：项目骨架与核心玩法代码

小游戏工程的最小入口长这样（原生 JS，无构建）：

// game.json
{
  "deviceOrientation": "portrait",
  "showStatusBar": false,
  "networkTimeout": { "request": 10000 },
  "subpackages": [
    { "name": "pkgPlay", "root": "subpackages/play/" }
  ]
}

主循环骨架建议一次生成到位，后续每款游戏只替换配置层：

// js/main.js —— 通用主循环，多游戏复用
const info = wx.getWindowInfo ? wx.getWindowInfo() : wx.getSystemInfoSync()
const canvas = wx.createCanvas()
const ctx = canvas.getContext('2d')
const DPR = info.pixelRatio || 1
const W = info.windowWidth
const H = info.windowHeight
canvas.width = W * DPR
canvas.height = H * DPR
ctx.scale(DPR, DPR)          // 之后一律用逻辑像素绘制，避免高分屏模糊
const CFG = require('./config')   // 每款游戏唯一需要改的文件
const S = {
  scene: 'ready',                                   // ready | playing | over
  score: 0,
  best: wx.getStorageSync('best_' + CFG.gameId) || 0,
  entities: [],
  last: 0
}
function reset() {
  S.score = 0
  S.entities = []
  S.scene = 'playing'
}
function update(dt) {
  if (S.scene !== 'playing') return
  // 实体推进、碰撞、生成逻辑
}
function draw() {
  ctx.clearRect(0, 0, W, H)
  // 背景、实体、UI 绘制
}
function loop(now) {
  // 关键：dt 必须裁剪上限，否则切后台返回后实体瞬移穿墙
  const dt = Math.min((now - S.last) / 1000, 0.05)
  S.last = now
  update(dt)
  draw()
  requestAnimationFrame(loop)
}
wx.onTouchStart((e) => {
  const t = e.touches && e.touches
  if (!t) return
  if (S.scene === 'ready' || S.scene === 'over') return reset()
  // 把 t.clientX / t.clientY 交给玩法层
})
wx.onShow(() => { S.last = Date.now() })   // 回前台重置时间基准
wx.onHide(() => { S.scene = 'paused' })
S.last = Date.now()
loop(S.last)

生成代码时的 Prompt 要点（比”帮我写个打砖块游戏”有效得多）：

【任务目标】按已确认的规格实现「核心玩法层」，只输出代码，不要解释性散文。
【输入信息】附上 spec.md 全文 + 上面的 main.js 骨架 + config.js 现有内容
【执行要求】
1. 严格使用微信小游戏 API：wx.createCanvas / wx.onTouchStart / wx.createInnerAudioContext，
   禁止出现 document、window、localStorage、HTMLCanvasElement 等 H5 写法
2. 所有可变数值集中到 config.js，玩法层不得出现魔法数字
3. update(dt) 必须是纯逻辑，不含绘制；draw() 不得修改游戏状态
4. 碰撞检测用 AABB，坐标统一为逻辑像素
5. 每个函数上方写一行注释说明职责，不写"这里实现了xxx"这类废话
【预期输出】
按文件分块的代码块，块前标注文件路径；最后列出「需要我在开发者工具中手动验证的点」清单。

为什么强调”禁止 H5 写法” ：这是 AI 生成小游戏代码最高频的失败模式。模型训练语料里 Canvas 游戏绝大多数是浏览器版本，不加约束就会写出 document.getElementById('canvas')，在开发者工具里直接报 document is not defined。

六、阶段 3：调试与 Bug 修复

排错的关键是 给模型足够的信息，而不是描述感受 。有效输入 = 完整报错栈 + 相关文件代码 + 复现步骤 + 已排除的可能。

高频问题与处理方向：

现象	常见根因	处理方向
document is not defined	混入了 H5/DOM 写法	全量替换为 wx.createCanvas()
首帧后画面静止	requestAnimationFrame 未在全局作用域调用，或 loop 未启动	检查入口是否真正执行到 loop()
切后台回来方块瞬移	dt 未裁剪上限	Math.min(dt, 0.05) + onShow 重置时间基准
高分屏画面模糊	未按 pixelRatio 放大画布	canvas.width = W * DPR + ctx.scale
触摸位置偏移	用了 pageX/pageY 或忘记减 canvas 偏移	统一用 touches.clientX/clientY
模拟器正常、真机白屏	分包未声明、用了真机不支持的语法特性	检查 game.json 分包与基础库版本
主包体积超限	音频/图片打进主包	大资源移入分包或改走 CDN

修复 Prompt：

【任务目标】定位并修复下面的运行时报错，输出最小改动补丁。
【输入信息】
- 完整报错：粘贴开发者工具 Console 全文（含堆栈）
- 复现步骤：1... 2... 3...
- 相关代码：粘贴报错文件全文 + main.js
- 已排除：已确认 config.js 数值正常；已确认基础库版本 3.5.0
【执行要求】
1. 先给结论：根因是什么，为什么会产生这个报错（3 句以内）
2. 再给补丁：只输出需要改动的代码片段，用 diff 或"文件路径 + 完整函数"形式
3. 说明改动的副作用：是否影响其他调用方
4. 如果根因无法从现有信息确定，明确列出还需要哪两项信息，不要猜
【预期输出】结论 → 补丁 → 副作用 → 待补信息（无则写"无"）

第 4 条很重要。允许模型说”信息不足”，比让它编一个看似合理的根因更省时间。

七、阶段 4：云托管后端从零到联调

小游戏后端通常是三件事： 登录换 openid、存档/排行榜读写、可能的道具校验 。微信云托管的价值在于前端可以用 wx.cloud.callContainer 走内网直连， 不需要配置 request 合法域名、不需要备案公网域名 ，联调成本显著低于自建服务器。

后端最小工程：

# Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
ENV NODE_ENV=production
EXPOSE 80
CMD ["node", "server.js"]

// container.config.json（云托管服务配置）
{
  "containerPort": 80,
  "minNum": 0,
  "maxNum": 3,
  "cpu": 0.5,
  "mem": 1,
  "policyType": "cpu",
  "policyThreshold": 60,
  "customLogs": "stdout"
}

// server.js
const express = require('express')
const app = express()
app.use(express.json())
const { WX_APPID, WX_SECRET } = process.env   // 密钥只走环境变量，绝不进代码库
app.post('/api/login', async (req, res) => {
  const { code } = req.body || {}
  if (!code) return res.status(400).json({ error: 'code_required' })
  const url = 'https://api.weixin.qq.com/sns/jscode2session'
    + `?appid=${WX_APPID}&secret=${WX_SECRET}`
    + `&js_code=${code}&grant_type=authorization_code`
  const data = await (await fetch(url)).json()
  if (data.errcode) return res.status(401).json({ error: data.errmsg })
  // 生产环境：session_key 存服务端，下发自有 token（如 JWT），不要直接返回 openid
  res.json({ token: issueToken(data.openid) })
})
app.get('/api/leaderboard', async (req, res) => {
  // 从 MySQL / Redis / 云开发数据库读取榜单
  res.json({ list: [] })
})
app.listen(process.env.PORT || 80, '0.0.0.0')

前端调用：

wx.cloud.init({ env: 'prod-xxxxxxxx', traceUser: true })
async function login() {
  const { code } = await wx.login()
  const res = await wx.cloud.callContainer({
    config: { env: 'prod-xxxxxxxx' },
    path: '/api/login',
    method: 'POST',
    header: {
      'X-WX-SERVICE': 'game-api',              // 必须与服务名完全一致
      'content-type': 'application/json'
    },
    data: { code }
  })
  if (res.statusCode !== 200) throw new Error('login failed: ' + res.statusCode)
  wx.setStorageSync('token', res.data.token)
}

部署步骤（控制台侧，模型只能给命令，执行由你完成）：

1. 代码推到 Git 仓库，云托管新建服务并关联仓库
2. 配置环境变量 WX_APPID、WX_SECRET（在控制台”环境变量”里填，不进镜像）
3. 首次构建镜像并部署，观察日志输出是否为 listening on 80
4. 在小游戏后台/云开发控制台确认调用权限，前端 callContainer 联调
5. 需要持久化时再挂载 MySQL 或 Redis，并在代码里加连接重试

后端 Prompt：

【任务目标】为微信小游戏生成云托管后端的最小可用工程。
【输入信息】
- 运行环境：微信云托管，Node 20，单服务，端口 80
- 需要接口：登录换 token、最高分上报、Top100 榜单查询
- 存储：暂用云开发数据库，后续可换 MySQL
- 安全要求：密钥走环境变量；不下发 openid；接口需校验 token
【执行要求】
1. 输出 package.json / Dockerfile / container.config.json / server.js 四个文件完整内容
2. 所有外部输入做校验，返回统一结构 { code, message, data }
3. 加上基础的错误中间件与请求日志（stdout）
4. 列出必须在控制台配置的环境变量清单，以及本地调试用的 .env 示例（不含真实值）
5. 指出这套实现在什么并发量级下需要改造，改造点是什么
【预期输出】按文件分块的代码 + 环境变量清单 + 扩容改造提示

八、阶段 5：把 1 款变成 12 款的复用策略

批量产出不靠”再生成 11 次”，靠 模板 + 配置 。把玩法差异全部收敛到配置层，主循环、渲染管线、UI 组件、登录与存档逻辑保持唯一实现。

推荐目录结构：

/                  入口层：game.js
/js/core/          主循环、渲染器、输入、存档（跨游戏共用，不修改）
/js/games/         各款玩法的 update/draw 实现
/js/config/        每款游戏的数值配置
/subpackages/      体积较大的玩法或资源分包

复用时的 Prompt：

【任务目标】把现有单游戏工程改造成支持多款玩法的模板化工程。
【输入信息】粘贴当前完整文件树 + core 层全部代码 + 一款游戏的 config
【执行要求】
1. 抽出 core 层与玩法层的边界，玩法层只暴露 init/update/draw/onTouch 四个接口
2. 设计 config schema（含 gameId、初始数值、资源路径、存档 key 前缀），给出 TypeScript 类型定义
3. 给出「新增一款游戏」的最小步骤清单，不超过 5 步
4. 指出当前代码中阻碍模板化的硬编码位置，逐个给出替换方案
5. 不要改动 core 层的公开方法签名，避免影响已完成的玩法
【预期输出】改造后的文件树 + 关键接口代码 + 新增游戏步骤清单 + 硬编码清单

长上下文在这里的价值 ：一个 12 款游戏的工程通常有 30~60 个文件。1M tokens 上下文意味着可以把 core 层、全部 config、以及若干玩法实现一次性交给模型，让它做跨文件的一致性检查——命名是否统一、存档 key 是否冲突、API 约定是否漂移。这类全局性问题，短上下文模型只能看到局部，很难发现。

九、上线前检查清单

功能与体验

• 四态（ready/playing/paused/over）迁移无死角，反复开始/结束不泄漏实体
• 切后台再回前台，时间基准已重置，无瞬移
• 最高分存档在杀掉进程后仍能读回

• [ ] 主流机型（含刘海屏、小屏）布局不错位

  性能与体积

• 主包体积在限额内，大资源已分包或走 CDN
• 单帧逻辑耗时留有余量，对象池已复用的地方没有频繁 new

• [ ] 音频在 onHide 时暂停，避免后台继续播放

  后端与安全

• 密钥只在环境变量，代码库与镜像中无明文
• 接口做了 token 校验与入参校验，榜单写入有频率限制

• [ ] 云托管日志能正常输出，冷启动时间在可接受范围

  合规

• 类目与资质按微信官方最新要求核对（游戏类目涉及版号/备案，务必以官方文档为准）
• 隐私协议、用户信息授权流程齐备

十、关键步骤回顾

1. 先定路线 ：小游戏还是小程序，类目资质先查清。
2. 先出规格再写码 ：用结构化 Prompt 把玩法变成状态机 + 数值表 + 文件树。
3. 约束死 API 边界 ：明确禁止 H5/DOM 写法，数值全部收敛到配置层。
4. 排错给全信息 ：报错栈 + 代码 + 复现步骤 + 已排除项，并允许模型回答”信息不足”。
5. 后端走云托管 ：callContainer 内网直连省掉域名备案，密钥只进环境变量。
6. 模板化再批量 ：core 层唯一实现，玩法差异全部配置化。
7. 执行与验证靠工具链 ：编译、真机、构建、部署在开发者工具与控制台完成，模型只产出内容与补丁。

如果你手上正好有一个想做的小游戏，最快的验证方式是把第三节的需求拆解 Prompt 直接贴进 ERNIE 5.5 Flash Preview 在线体验，看它输出的规格是否达到”可以直接开工”的颗粒度——这一步的效果，基本决定了后面整条工作流的顺畅程度。准备把这套流程接入自己的工程或 CI 时，可以前往 百度智能云千帆模型详情页 查看模型能力说明与接入方式。