做微信小程序这件事我前后拖了快两年。网页版的2048小游戏早写好了朋友一直说“包一层壳就能上微信”真动手才发现完全不是那么回事——小程序的运行机制、发布审核、登录授权每一环都跟网页开发隔着一条河。最近总算用WorkBuddy把这个工程从网页重构成了小程序从生成代码到提交审核前后花了一个周末。如果你也打算用AI工具做微信小程序这篇应该能帮你少踩几个坑至少不用像我一样在“为什么手机号授权不弹窗”这种问题上耗掉半天。先说结论AI工具写小程序难点根本不在“写代码”而在“平台上下文”。WorkBuddy这类带工作台概念的工具比我之前用过的通用AI助手强在它能理解微信小程序这个特定场景——知道WXML不是HTML知道app.json是干嘛的知道wx.login和getPhoneNumber该怎么用。这篇就把我用WorkBuddy从零搭一个小程序并跑通上线全流程的实操过程拆开讲顺带把上线前那些容易卡住的细节都捋一遍。1. 为什么我用 WorkBuddy 而不直接手写或找通用AI帮手1.1 小程序开发和普通网页开发从根上就不一样很多人以为小程序就是“把网页塞进微信里”这是最大的误区。微信小程序虽然表面上是前端技术但架构上跟传统网页几乎完全不同。网页跑在浏览器里DOM是开放的你想怎么操作就怎么操作。小程序是双线程模型逻辑层跑在JavaScript引擎里渲染层跑在WebView里两层之间靠setData通信。意味着你不能直接操作DOM不能随便用window、document那一套浏览器API也不能用jQuery这类依赖DOM的库。我最初把网页版2048直接丢进小程序开发者工具白屏控制台报了一堆“wx is not defined”“document is not defined”的错误——这就是不了解架构差异的代价。还有样式。小程序用WXSS虽然有rpx这种适配单位很好用但选择器支持有限不支持通配符*不支持很多伪类。写惯了CSS的人上手WXSS容易在“为什么这个样式没生效”上怀疑人生。我周围不少朋友第一个小程序项目死在“写完代码跑不起来”这个阶段其实大概率就是被这套隐性规则绊住了。1.2 WorkBuddy 解决的是“平台上下文”问题用通用AI写小程序代码经常遇到一种尴尬它生成的代码语法完全正确但用在微信环境里就是不行。比如它可能生成document.getElementById来操作节点可能用localStorage而不是wx.setStorageSync甚至可能用ES6模块的原生import而不做构建处理。代码本身没错错在“不懂微信的规矩”。WorkBuddy不一样的地方在于它天然带工作台和项目上下文概念。我不用每次对话都重复说“这是微信小程序项目请使用WXML/WXSS图标用iconfont数据存储用wx.setStorageSync”——你只要把项目结构在工作台里搭好它就知道在什么语境下工作。这就像同一个熟练工和刚毕业的学生学生有知识但不了解你们公司的规矩熟手一看项目结构就知道该怎么落地。我用它的实际感受是生成的代码基本都在正确的“轨道”上——页面注册到app.json里组件用微信原生组件API调用用wx对象下对应的方法。虽然偶尔也有瑕疵但不会出现“压根不能跑”的根源性错误。这个“上下文能力”对于微信小程序开发尤其重要因为小程序框架里约定大于配置的东西太多了目录结构、页面注册、生命周期、API命名全部都有既定规范。2. 动手之前搞懂微信小程序的4个关键机制2.1 双线程模型为什么你不能像网页那样操作DOM小程序的逻辑层和渲染层是分离的。逻辑层负责业务逻辑、数据处理渲染层负责UI展示。两层之间通过setData建立桥梁逻辑层数据一变setData告诉渲染层“这部分变了”渲染层才去更新视图。这套模型带来两个直接影响。第一你不能在逻辑层里直接访问页面DOM元素所有界面更新都得走数据驱动。拿2048来说游戏格子里的数字变化不是“找到某个DOM节点改它的innerText”而是修改data里的二维数组然后WXML模板里用wx:for去渲染这个数组。第二setData是异步的而且每次setData都涉及两层之间的通信频繁、大数据量的setData会直接导致页面卡顿。我优化2048手感时把所有格子更新合并成一次setData而不是每次移动都触发多次更新这个改动对性能影响非常明显。2.2 app.json 全局配置小程序的立身之本小程序不像网页那样靠URL路由找页面所有页面必须在app.json里注册。pages数组的第一项就是首页。窗口样式、导航栏、tabBar、插件、权限申请全部在这个文件里声明。这里有个很坑的细节如果页面文件存在但忘了在app.json里注册开发者工具会报错“page not found”。我遇到过两次一次是WorkBuddy生成了新页面但更新配置时漏了一次是我自己手动加了目录但没注册。这个问题排查起来特别容易忽略因为报错提示不算明显看到“not found”先怀疑路径写错了其实多半是没注册。另外微信小程序的导航栏是原生的不能在WXML里随便改变。想自定义导航栏需要在app.json里把window的navigationStyle设为custom但设置了之后你就得自己处理状态栏高度、胶囊按钮位置不然刘海屏上你的导航栏会跟胶囊按钮重叠。这个后面在第4章详细讲。2.3 微信登录与手机号能力用户体系的入口小程序拿用户信息的核心流程是wx.login获取临时code把code发给后端后端用code去微信的code2Session接口换openid和session_key。很多新手以为wx.login返回的code就是用户身份可以直接用实际上code五分钟过期、只能用一次而且必须由后端配合调用微信接口才能换取真正的用户身份。手机号授权是另一回事。不能直接在代码里调用API拿手机号必须用button组件加上open-typegetPhoneNumber用户在界面上主动点击授权然后微信返回一个加密数据code或encryptedData由后端解密获取真实手机号。这个设计是为了合规用户体验上就是“必须用户点了才算”。我见过很多AI生成的登录代码在这一点上是错的——以为跟网页端一样调个接口就能拿到用户信息。这也是我推荐用WorkBuddy这类懂平台规则工具的原因它生成的button代码会带正确的open-type而不是自己瞎写一个获取手机号的函数。2.4 本地缓存与存储轻量数据的正确姿势小程序的本地存储API是wx.setStorageSync / wx.getStorageSync跟浏览器的localStorage非常像但有几个区别单个key限制1MB整体没有明确上限但超过一定量会有性能问题存储是持久化的卸载小程序才清除同一台手机上不同小程序的数据互不隔离按AppID区分但同AppID下所有用户数据都在一起。2048这种游戏排行榜、音效设置、最佳成绩这种轻量数据用wx.setStorageSync完全够了。我一开始犯过把整个棋盘状态都存进Storage的错后来发现每次移动都写Storage频繁IO导致卡顿明显改成“仅退出时存一次”就稳定多了。存储不是不能用而是要控制频率和粒度。3. 实操用 WorkBuddy 从零搭2048小程序并跑通上线3.1 第一步让 WorkBuddy 生成标准小程序工程骨架我用的方法是先建好工作台项目然后在项目说明里写清楚自己要什么一个微信小程序版本的2048游戏页面包括游戏主页、规则页用原生小程序框架不用第三方UI库支持滑动操作有本地排行榜。WorkBuddy生成的工程结构大概是这样的2048-miniprogram/ ├── app.js ├── app.json ├── app.wxss ├── sitemap.json ├── project.config.json └── pages/ ├── index/ │ ├── index.wxml │ ├── index.wxss │ ├── index.js │ └── index.json └── rules/ ├── rules.wxml ├── rules.wxss ├── rules.js └── rules.json这里面每个文件都有明确职责。拿到这个骨架之后先别急着改代码打开app.json确认页面注册、窗口样式、sitemap配置这三项是否符合预期。sitemap.json用于配置小程序页面是否被微信索引新项目默认全部允许就行。project.config.json是开发者工具的项目配置文件里面包含appid、项目名称、编译设置等。我建议生成之后立刻手动检查这个文件特别是appid那一项。开发者工具导入项目时如果appid不对很多API用不了——尤其是手机号授权这类能力测试号根本无法完整验证。3.2 第二步实现游戏逻辑与页面渲染2048的核心逻辑是棋盘操作数组的移动、合并、随机生成新方块、判断游戏结束。这部分逻辑跟平台无关WorkBuddy生成得很干脆直接放到index.js里作为普通函数就行。页面渲染部分就考验平台适配了。棋盘是一个4x4的二维数组WXML里用wx:for嵌套渲染view classboard view classrow wx:for{{board}} wx:for-itemrow wx:keyindex view classcell wx:for{{row}} wx:for-itemcell wx:keyindex text classcell-text value-{{cell}}{{cell}}/text /view /view /viewWXSS方面棋盘格用rpx单位适配不同屏幕宽度16个格子的宽高都设为固定的比例加一些背景色区分不同数值的方块。滑动操作可以用touchstart和touchend来监听通过比较起始坐标和结束坐标的差值判断方向。这里有个细节touch事件拿到的坐标是px需要换算成逻辑方向不用精确判断距离只需比较x轴和y轴位移绝对值大小就能确定是左右滑还是上下滑。游戏核心逻辑写完之后我做了个关键优化把2048状态机整理成纯函数不依赖任何小程序API。这样做有两个好处一是WorkBuddy后续提优化方案时不会被平台API干扰二是逻辑可以脱离开发者工具单独做单元测试。小程序开发者工具虽然自带调试器但复杂逻辑先在Node环境跑通效率高得多。3.3 第三步接入微信能力——登录、授权与数据回传2048其实不需要登录也能玩但我为了验证“小程序上线全流程”还是加了一个可选的微信登录。按钮放在规则页用户主动点击后触发wx.loginwx.login({ success: (res) { if (res.code) { // 把 code 传给后端后端调用 code2Session 换取 openid that.setData({ loginCode: res.code }); } } });如果要拿手机号前端代码就是一行button配置button open-typegetPhoneNumber bindgetphonenumberonGetPhoneNumber 获取手机号 /button这里我要强调手机号不是在前端“拿到的”前端只是拿到一个加密数据必须后端配合解密。很多人写到这里就断了——拿到用户手机号了然后呢你得自己建后端接口、处理解密逻辑、关联用户体系。WorkBuddy能做的是把前后端交互的代码框架生成好但真的做一个生产级后端你还需要做token签发、会话管理、数据库设计这些不是一个AI工具能全包圆的。这次实战我选择了最简方案不接自建后端先做纯本地版本。登录状态用一个全局变量标记手机号授权先打通前端流程后端业务我单独用微信云开发处理。微信云开发可以免鉴权直接获取openid对个人开发者非常友好一步就能把一个“只有前端”的小程序升级成“有后端”的小程序而且不用买服务器、不用备案。云开发的获取openid方式也很简单在云函数里通过cloud.getWXContext()就能拿到OPENID。前端只需调用wx.cloud.callFunction一个完整的用户体系就起来了。个人开发者做小程序我强烈建议优先考虑云开发可以少掉一半运维工作量。3.4 第四步从开发者工具到真机再到提交审核开发者工具里跑通之后我按这个顺序做了上线前验证先用“预览”功能生成一个体验版二维码手机扫码在真机上玩几局重点看滑动灵敏度、性能表现和是否闪退。这里要特别提醒开发者工具里的模拟器和真机不是一回事微信WebView在不同iOS/Android版本上的表现差异不小尤其是CSS兼容和内存占用。2048这种小游戏对性能要求不高但如果是复杂页面建议至少在一台旧安卓、一台iPhone上验证。确认没问题后在开发者工具里点“上传”代码会打包到微信后台然后在微信公众平台mp.weixin.qq.com里把刚上传的版本设为体验版再提交审核。审核一般1-2个工作日个人主体的小游戏类目会稍微慢一点。我提交了两次第一次被拒是因为页面里没有明显的“用户协议和隐私政策”入口第二次就通过了。现在平台对合规要求很严格哪怕是个人小游戏隐私相关的文案也得提前准备好。上线之后还有一个容易忽略的点正式版的AppID和你开发时用的测试AppID是不同的。如果你用测试号开发上线前必须把project.config.json里的appid改成正式AppID重新编译、重新上传。这个步骤漏掉会出现“本地一切正常线上全挂”的经典事故。4. 我踩过的坑常见问题与排查实录4.1 手机号授权弹窗为什么不出现这个坑我折腾了大半天。代码写法完全正确button带了open-typegetPhoneNumber但点击之后什么反应都没有既不弹授权窗口也不触发回调。排查过程是这样的先确认基础库版本手机号授权需要基础库2.21.2以上调试器里看版本没问题再确认开发者工具模式测试号有些能力受限换成正式AppID重新编译最后发现问题是button内部嵌套了一层view微信对这个有严格限制button内不能再嵌套别的可点击组件。AI生成的代码里button内部经常会被包一层view来做样式——这就是典型的“代码正确但不符合平台规则”。还好WorkBuddy能识别这类问题我把它当成“代码审查员”帮我跑了一遍wxml规范检查。如果手写代码建议遇到这种问题时先查微信官方文档的组件开放能力说明。4.2 真机白屏或样式错乱模拟器里却是好的第一次真机预览时模拟器里完美的棋盘在真机上裂开了——格子不对齐、背景色缺失、数字错位。仔细排查发现是WXSS的兼容性问题。我在棋盘的样式里用了CSS Grid布局。开发者工具内置的WebView版本比较高Grid支持的很好但部分真机的WebView版本较老Grid布局支持不完整直接导致渲染崩了。换成Flexbox重写棋盘布局之后问题消失。这个经验很重要小程序WXSS的兼容性边界比你想象的低能用Flexbox解决的就别用Grid能用基础属性解决的就别用高级特性。样式类问题的排查手段有两个。一是用开发者工具的“真机调试”功能可以看到真机上的渲染结果和控制台报错二是用Charles抓包看资源加载是否异常。这里多说一句小程序里用到了网络图片、字体文件这些外部资源真机上加载不到也会表现为白屏。排查时先看是不是资源问题通常是0%的。4.3 本地排行榜数据丢失重启小程序就清零排行榜数据我存在wx.setStorageSync里模拟器玩的时候一切正常但真机上杀进程重启之后排行榜不见了。排查发现是并发问题的坑我在onHide生命周期里写Storage但在onShow里读取排行榜。当用户快速切换前后台时onHide和onShow的执行顺序在某些情况下会出现竞态导致读取的时候数据还没写完。解决方案很粗暴但也有效所有Storage写入都走同一个函数串行执行避免多个异步操作同时触发写操作。另外iOS上小程序的Storage在内存压力过大时确实可能被系统清掉一部分所以重要数据尽量在关键节点主动落盘不要只依赖退出时保存。4.4 自定义导航栏在不同机型上的高度适配我为了追求游戏页面的沉浸感把导航栏设成了custom。问题来了iPhone X以上机型有刘海安全区域跟普通安卓完全不同小程序右上角有胶囊按钮这是系统级的你拿不到它的DOM只能通过API获取它的位置。微信提供了wx.getMenuButtonBoundingClientRect()这个接口能拿到胶囊按钮的位置信息包括它的top、right、width、height。自定义导航栏的高度标准算法是状态栏高度 胶囊按钮的top到状态栏底部的距离 胶囊按钮高度 胶囊按钮距底部距离。我把这段逻辑封装成一个工具函数在app启动时计算一次存到globalData里所有自定义导航的页面直接用这个值。这个坑属于典型的“不踩一次永远不知道为什么别人都写这段代码”的坑。如果你不做自定义导航栏完全不用关心一旦做了这段适配逻辑必须写对否则在全面屏手机上你的导航栏会和胶囊按钮重叠丑且难用。5. 用 WorkBuddy 提效的几个实战心得5.1 把需求写进“项目说明书”而不是零散对话WorkBuddy的工作台模式最大的好处是可以建一个项目级别的说明文档相当于给AI一个“小程序的契约”。我的做法是在项目根目录维护一份README里面写清楚这个项目的技术栈、目录约定、页面清单、数据存储方案、UI风格偏好。每次让AI改代码之前先让它读一遍README再动手改。这个习惯的价值在于你不需要反复提醒AI“这是微信小程序不是网页”它每次改代码都会自动遵循既定约定。就像带实习生最省力的方式不是每次纠正而是给他一份团队规范文档他在规范下工作。5.2 用 Skill 沉淀常见操作流程WorkBuddy有Skill的概念就是把一个常见的操作流程固化下来做成可复用的指令。比如我写了一个小程序发版Skill更新版本号、修改project.config.json、检查sitemap、执行上传命令、整理发布说明。每次发版只需要调用这个SkillAI会按固定顺序执行不会漏步骤。我强烈建议把“微信小程序从改代码到发体验版的流程”固化成Skill。这个流程步骤多、重复性高、容易遗漏正好是Skill发挥价值的地方。实测下来固化之后我发一个体验版的平均时间缩短了一半而且不会出现“忘了改版本号”这种低级失误。5.3 抓包和日志分开看问题边界更清晰调试网络请求时我习惯用Charles抓包看小程序发出的HTTP请求再用开发者工具的Console看逻辑层日志。两者结合能快速定位问题出在“前端没发对请求”还是“后端返回了异常数据”。有一次手机号登录接口一直报错Console里没有任何异常Charles里看到接口返回了401。问题很快就定位到了后端token过期而不是前端代码的问题。如果你只依赖开发者工具的Network面板某些微信内部的请求比如登录接口的code换token过程可能看不太清Charles在这种场景确实更从容。只要你的小程序请求走的是普通HTTPS协议Charles就能抓到明文请求这对排查接口联调问题帮助巨大。抓自己开发的小程序的包是再正常不过的调试手段。唯一要注意的是小程序要求所有请求域名必须配置到后台白名单里本地调试时也需要注意这个点否则真机上所有请求都会被拦截。结尾这次用WorkBuddy把网页版2048搬上微信小程序从项目搭建到审核通过前后花了一个周末。对比几年前手写小程序的经历最大的感受是AI工具确实把“工程搭建”和“代码生成”这两大块的效率拉高了但它改变不了一个事实微信小程序的平台规则还是得你自己懂审核规范还是得你自己维护上线的整个流程还是得你自己走通。如果你正准备做自己的第一个小程序我的建议是别一上来就挑战商城、社媒那类大项目先拿一个迷你小游戏跑通“开发–预览–上传–审核–上线”的完整闭环。这个闭环跑通之后你会发现后面做任何小程序都是重复这个框架而你已经有了一套顺手的工作流。另外一个小技巧用WorkBuddy生成代码之后就养成分步提交的习惯每完成一个小功能就让AI在项目说明里更新一下“当前已完成功能”这样整个开发过程里项目的状态是清晰的不会改到后面连自己都忘了哪块做到哪一步了。别嫌这一步啰嗦真到上线前排查问题时这份记录能帮你省下整整一晚上的时间。