1. 项目背景与重做动机
1.1 一个 2048 小程序，为什么值得推倒重来
上一轮交付的产物是一个微信小程序源码工程，压缩包叫2048-小程序.zip。功能层面它没大毛病：4x4 棋盘、滑动合并、分数统计、重新开始，该有的都有。但真正把它丢进微信开发者工具里跑起来，问题就藏不住了——它本质上是一个“网页思维”写出来的东西，只是套了个小程序的壳。
最直观的体感是：页面切换有肉眼可见的白屏，棋盘渲染在低端安卓机上掉帧，登录态和云数据的衔接全靠手写wx.request拼凑，改一个字段要在三四个文件里来回跳。更麻烦的是，它没法像网页那样随手刷新调试，每次改动都得等开发者工具重新编译，一轮下来几分钟就没了。三天工期里，有将近一半时间耗在“改一行、等编译、点半天、发现没生效”这种循环上。
所以这次重做的核心目标不是加功能，而是换一套工作方式：用 Codex 这类 AI 编程助手把重复劳动压下去，把省出来的时间花在真正影响体验的地方——渲染性能、登录链路、云开发数据流。标题里说的“从 3 天到 90 分钟”，指的不是功能缩水，而是同样一个可交付的小程序工程，从零到能跑通核心流程的时间被压缩了一个数量级。
1.2 适合谁参考这套流程
这套东西不是给完全没碰过小程序的人看的。如果你连微信开发者工具都没装过、不知道app.json是干嘛的，建议先去把官方 quickstart 跑一遍再回来。它更适合这几类人：接过外包小程序、被工期压得喘不过气的独立开发者；手里有一堆重复页面要写、想找个靠谱助手分担的团队；以及已经会用 AI 写代码，但总觉得“生成的东西能跑却不敢上线”的中级选手。
我踩过的坑主要集中在三个地方：Codex 生成的代码对小程序特有 API 的理解偏差、云开发环境下的登录态处理、以及miniprogram-automator做自动化验证时的配置细节。下面会把这些一个个拆开讲，包括我最后是怎么绕过去的。
2. 整体思路与工具链选型
2.1 为什么是 Codex 而不是纯手写
先说结论：Codex 在这类项目里的价值，不在于“帮你写完整项目”，而在于“帮你写那些你闭着眼都知道怎么写、但写起来很烦的代码”。2048 的核心逻辑——滑动方向判定、合并规则、新方块生成——这些是算法，值得自己盯着写。但页面结构、样式、云函数模板、登录流程的样板代码，这些是体力活，交给 Codex 完全够用。
我实际的做法是分三层：核心算法手写并加测试，页面与样式用 Codex 生成后微调，云函数与登录链路用 Codex 出初稿再逐行审。这样既保证了关键逻辑的可控性，又把重复劳动压到了最低。实测下来，一个标准页面（wxml + wxss + js + json 四件套）从描述需求到能跑，大概 3 到 5 分钟，比手写快 4 倍以上。
2.2 工具链清单与各自职责
| 工具 | 用途 | 备注 |
|---|---|---|
| 微信开发者工具 | 编译、预览、真机调试 | 稳定版即可，不必追 nightly |
| Codex | 生成页面、云函数、样板代码 | 需要清晰的需求描述 |
| 云开发 | 数据存储、登录态、云函数 | 免服务器，适合小项目 |
| miniprogram-automator | 自动化测试与回归验证 | 配合 Jest 使用 |
| Git | 版本管理 | 每次 Codex 生成后单独提交 |
这里重点说下miniprogram-automator。很多人做小程序不做自动化测试，觉得“点一点就行了”。但当你用 Codex 批量生成页面后，回归成本会陡增——你根本记不住哪个页面改过什么。miniprogram-automator能让你用脚本模拟点击、滑动、断言页面数据，配合 Jest 跑一遍核心流程，几分钟就能确认没改坏东西。这是把“快”变成“可持续的快”的关键。
2.3 云开发 vs 自建后端的选择逻辑
2048 这种小游戏，数据量极小，用户体系也简单，自建后端纯属浪费。云开发的免费额度对这类项目绰绰有余，而且登录态、数据库、云函数是一套打通的，省掉了跨域、鉴权、部署这些破事。唯一要注意的是云函数的冷启动——第一次调用可能慢个一两秒，所以登录这种关键路径要做好 loading 态，别让用户以为卡死了。
3. 核心环节拆解与实操要点
3.1 用 Codex 生成页面的正确姿势
直接跟 Codex 说“帮我写个 2048 小程序”是没用的，它会给你一堆似是而非的代码。有效的做法是把需求拆到“一个文件一个文件”的粒度。比如生成游戏主页面，我会这样描述：
生成一个微信小程序页面，包含 4x4 棋盘、当前分数、最高分、重新开始按钮。棋盘用 view 嵌套实现，每个格子有固定宽高比。样式用 rpx 单位，适配不同屏幕。数据绑定用 data 里的 board 二维数组，每个元素是 0 或 2 的幂次。不要写游戏逻辑，只写结构和样式。
这样出来的 wxml 和 wxss 基本能直接用，js 里只留空的 data 和生命周期函数。游戏逻辑我自己填，因为那部分 Codex 容易写出边界条件错误的代码——比如合并时同一轮不能连续合并两次，这种规则它经常搞混。
3.2 登录链路：手机号获取的坑
微信小程序的登录获取手机号，现在必须用button组件的open-type="getPhoneNumber"，而且要在用户点击后拿到code，再传给后端或云函数去换手机号。这里有个大坑：code只能用一次，且有效期极短。我第一版让 Codex 生成的代码是把code存到 data 里等用户填完昵称再一起提交，结果十次有八次失败。
正确做法是：拿到code立刻调云函数，云函数里用code换phoneNumber，换到之后直接写库并返回登录态。整个过程要在用户点击后的几百毫秒内完成，不能有任何中间等待。云函数里换手机号的接口调用需要access_token，这个 token 要缓存，不能每次现取，否则会触发频率限制。
3.3 渲染性能：为什么你的棋盘会卡
2048 的棋盘渲染，新手最容易犯的错是“每次移动都重新渲染整个棋盘”。4x4 一共 16 个格子，听起来不多，但如果每个格子都用独立的setData更新，16 次调用叠加起来在低端机上就是灾难。正确做法是一次性 setData 整个 board 数组，让小程序自己做 diff。
另一个坑是动画。如果你给每个方块加 CSS transition，移动时的重排会非常耗性能。我的做法是：移动逻辑先算完，直接更新数据，动画只做“新方块出现”和“合并时数字放大”这两个轻量效果。实测下来，这样在千元安卓机上也能稳定 60 帧。
3.4 云函数的数据结构设计
分数和最高分我放在一个users集合里，每个用户一条记录，字段就三个：openid、bestScore、updatedAt。云函数只做两件事：登录时 upsert 用户记录，游戏结束时如果分数超过最高分就更新。这里要注意并发问题——如果用户快速连续提交两次，可能后一次覆盖前一次。我的处理是在云函数里加一个简单的版本号或时间戳比较，只有更新的时间戳才写入。
4. 完整实操流程与关键配置
4.1 从零到能跑的 90 分钟时间线
我把整个过程拆成几个阶段，每个阶段都有明确的产出和验证点：
- 环境准备（10 分钟）：装微信开发者工具、开通云开发环境、建好数据库集合。这一步没什么技术含量，但容易漏——比如云开发环境要选对区域，数据库权限要设成“仅创建者可读写”。
- 项目骨架（15 分钟）：用 Codex 生成
app.json、app.js、app.wxss和首页四件套。重点是app.json里的pages列表和window配置，顶部导航栏高度这种细节让 Codex 按默认来就行，别自己瞎调。 - 游戏核心（25 分钟）：手写棋盘逻辑，包括初始化、滑动、合并、判负。这部分我写了单元测试，用 Jest 跑，确保边界条件正确。
- 登录与云开发（20 分钟）：Codex 生成登录页面和云函数模板，我改手机号获取逻辑和数据库写入。
- 自动化验证（15 分钟）：配置
miniprogram-automator，写三个核心用例：启动后棋盘有 16 个格子、滑动后数据变化、登录按钮可点击。 - 真机调试与收尾（5 分钟）：真机跑一遍，确认没有白屏和报错，提交代码。
4.2 miniprogram-automator 配置实录
这个工具的配置有几个细节容易翻车。首先，它需要开发者工具开启“服务端口”，在设置里勾上“安全设置”里的服务端口选项。然后automator.launch的时候要指定projectPath，路径里不能有中文和空格，否则会报找不到项目。
const automator = require('miniprogram-automator'); async function runTest() { const miniProgram = await automator.launch({ projectPath: '/Users/xxx/2048-miniprogram', port: 9420 }); const page = await miniProgram.reLaunch('/pages/index/index'); await page.waitFor(500); const cells = await page.$$('.cell'); console.log('格子数量:', cells.length); await miniProgram.close(); }实测下来，waitFor的时间不能太短，小程序启动有延迟，500 毫秒是保守值。另外reLaunch比navigateTo更适合测试入口页，因为它会清空页面栈。
4.3 云函数登录的完整代码
云函数这边，我用的是cloud.getWXContext()拿openid，然后用code换手机号。注意code换手机号的接口需要access_token，我用一个简单的内存缓存加定时刷新：
const cloud = require('wx-server-sdk'); cloud.init(); const db = cloud.database(); let cachedToken = null; let tokenExpire = 0; async function getAccessToken() { if (cachedToken && Date.now() < tokenExpire) return cachedToken; const res = await cloud.callFunction({ name: 'getToken' }); cachedToken = res.result.access_token; tokenExpire = Date.now() + 7000 * 1000; return cachedToken; } exports.main = async (event) => { const { code } = event; const token = await getAccessToken(); const phoneRes = await cloud.openapi.phonenumber.getPhoneNumber({ code }); const { openid } = cloud.getWXContext(); await db.collection('users').doc(openid).set({ data: { openid, phone: phoneRes.phoneInfo.phoneNumber, updatedAt: Date.now() } }); return { openid, phone: phoneRes.phoneInfo.phoneNumber }; };这里getToken是另一个云函数，专门负责拿access_token并缓存到数据库或全局变量。别把 token 硬编码，会过期。
5. 常见问题与排查技巧
5.1 Codex 生成代码的典型翻车现场
| 问题现象 | 原因 | 解决 |
|---|---|---|
| 页面白屏，控制台无报错 | Codex 生成的 wxml 用了未注册的组件 | 检查usingComponents |
| 滑动无反应 | 事件绑定写成了bindtouchmove但逻辑没触发 | 改用bindtouchstart+bindtouchend算方向 |
| 云函数调用超时 | 冷启动 + 首次 token 获取慢 | 加 loading，token 预热 |
| 手机号获取失败 | code 被复用或超时 | 拿到 code 立刻调云函数 |
| 真机样式错乱 | 用了 px 而非 rpx | 全局替换为 rpx |
5.2 我踩过的三个大坑
第一个坑是云开发环境初始化。Codex 生成的app.js里cloud.init()没带env参数，在开发者工具里能跑，真机上直接报错。必须显式指定环境 ID，这个 ID 在云开发控制台能看到。
第二个坑是登录态持久化。我一开始把openid存在storage里，但用户换设备就丢了。后来改成每次启动静默登录，用wx.login拿code换openid，不弹授权框，体验好很多。
第三个坑是自动化测试的端口冲突。miniprogram-automator默认端口 9420，如果开发者工具已经开了一个实例，再启动会失败。解决办法是测试前先关掉手动打开的开发者工具，或者换端口。
5.3 性能优化的两个小技巧
棋盘渲染用wx:for的时候，wx:key一定要用唯一值，别用 index。虽然 2048 的格子位置固定，但用 index 做 key 在数据更新时会导致不必要的重渲染。另一个技巧是合并动画用transform: scale()而不是改width/height，前者走 GPU 合成，后者触发重排。
6. 后续可扩展的方向
这套流程跑通之后，扩展起来就很顺了。比如加一个排行榜，只需要在云函数里加一个聚合查询，页面用 Codex 生成一个列表页，半小时能搞定。再比如加音效，用wx.createInnerAudioContext，Codex 能直接生成播放逻辑，你只需要准备音频文件。
我个人在实际操作中的体会是：Codex 这类工具最大的价值不是“替你写代码”，而是“替你写那些你不想写的代码”。把省下来的时间花在架构设计、性能调优和测试上，才是真正的效率提升。至于那些说“AI 写的代码不能上线”的人，大概率是没搞明白怎么把 AI 当成一个需要清晰指令的初级助手来用。你给的需求越具体，它出的活越靠谱。
