最近几个月我一直在折腾用 WorkBuddy 做微信小程序这件事从最开始对着空白项目发呆到最终把一个小程序商城真的提交审核、成功发布上线中间踩的坑比想象中多得多。网上讲单点技术的文章很多但很少有一篇能完整回答用 AI 工具从零做小程序到底能不能直接上线微信这篇就把我的完整路径写出来包括账号怎么配、Prompt 怎么写、登录和支付怎么接、审核被拒怎么处理以及那些只有真正走到上线那一步才会遇到的坑。如果你准备用 WorkBuddy或者其他 AI 编程工具做小程序希望这篇能帮你少走至少一星期的弯路。1. 项目规划先搞清楚 WorkBuddy 能帮你省掉哪些事1.1 传统小程序开发卡在哪做过小程序的人都知道它的技术栈并不复杂——WXML 写结构、WXSS 写样式、JS 写逻辑、JSON 做配置再加上微信提供的各种 API单个页面的开发难度比 Web 还低一点。但真做一个完整项目工作量全藏在细节里登录态要处理、手机号授权要配、购物车要管理状态、订单状态要流转、支付要对接签名和回调还有不同机型的导航栏适配。这些逻辑单个拎出来都不难堆在一起就变成了一座山。传统做法是一个前端至少排两周开发再加一周联调和提审碰上需求临时调整周期轻松翻倍。另一个痛点是环境配置。很多刚接触小程序的人光是搞明白 AppID、AppSecret、服务器域名、业务域名这几个概念就要花上小半天。更不用说很多人并没有现成的后端服务为了一个小程序还得去租服务器、备案域名、写接口还没开始写页面人先被环境吓退了。1.2 WorkBuddy 的AI 脚手架 人工验收定位WorkBuddy 这类 AI 编程工具本质上解决的是代码生成效率和项目脚手架搭建两个问题。你可以把它理解成一个不会累、知道很多最佳实践、但需要你盯着的程序员。它可以根据你的描述生成小程序前端代码、云函数、数据库集合设计甚至帮你把测试数据准备好。但我的实测体验是它不可能一句话生成一个完美上线的小程序更合理的用法是AI 脚手架 人工验收。具体来说我的工作流是这样的。先自己把需求拆成模块比如首页、商品列表、详情、购物车、订单、登录、支付然后针对每个模块给 WorkBuddy 下指令让它输出完整可运行的代码拿到代码后在微信开发者工具里跑起来逐项验收有问题再让它改而不是自己从头写。这样做的好处是页面骨架和重复劳动基本被 AI 吃掉而我只需要把精力放在业务逻辑、边界条件和微信生态的特殊规则上。1.3 交付物定义这一版做到什么程度做项目最忌讳一开始就想要一个大而全的东西。我给自己定的范围是一款单商家的小程序商城功能边界是商品展示首页轮播、金刚区、商品列表、详情、购物车、登录授权、手机号绑定、提交订单、微信支付、订单列表和简单管理。明确不做多商家入驻、不做分销裂变、不做复杂的推荐算法。先让一个最小可用版本能跑通上线再考虑加东西。这也是我给所有准备用 AI 做小程序的朋友的第一条建议把能上线而不是功能多当成第一目标。2. 环境准备账号、工具与目录骨架一次配齐2.1 注册小程序账号与 AppID个人和企业差别很大在写第一行代码之前先去微信公众平台注册小程序账号。这一步值得多说两句因为主体类型直接决定了你能做什么、不能做什么。个人主体注册快只要身份证就能搞定适合做内容展示、工具类小程序但不能开通微信支付也不能做电商、直播、社交等需要资质的类目。企业主体需要营业执照、对公账户验证流程会慢一些但它能开通微信支付、能选更多类目是做一个正规商城的前提。我的建议是只要你的目标是做带交易的小程序直接走企业主体同时把微信支付商户号一并购了。别等代码写完了才去申请商户号那中间几个工作日的审核等待会让你非常被动。注册完成后在小程序后台的开发管理里能看到 AppID 和 AppSecret。AppID 相当于小程序的身份证前端要用AppSecret 是后台密钥只能放在服务端或者云函数里千万别写进前端代码后面我会细说这个坑。2.2 搭建本地开发环境微信开发者工具与 WorkBuddy 配合开发小程序必须要装微信开发者工具这是绕不开的。它能打开项目、编译预览、真机调试、上传代码所有工作流都在这上面完成。安装之后有个细节很多人会忽略在设置-安全设置里开启服务端口否则某些外部工具的调试能力会受限。另外开发阶段可以在详情-本地设置里勾选不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书这样本地调试时可以直接请求测试接口不用为临时的 IP 地址频繁配置域名。但记住这个选项只是开发阶段的便利上线前必须关掉并配置真实域名。WorkBuddy 和微信开发者工具的关系是互补的WorkBuddy 负责生成和修改代码微信开发者工具负责运行和验证。我通常先在 WorkBuddy 里建立项目工作区把小程序源码目录挂进去让它直接读写文件改完代码后切到微信开发者工具刷新编译看效果再反馈给它继续改。这个循环跑顺之后开发效率非常可观。2.3 项目目录结构少走弯路的文件规划原生小程序的项目结构看起来自由但规划不好后面会非常乱。我用的是这套目录WorkBuddy 生成代码时我也会要求它按这个结构输出project/ ├── app.js # 全局逻辑启动时处理登录态 ├── app.json # 全局配置页面路径、窗口、tabBar ├── app.wxss # 全局样式 ├── pages/ # 页面 │ ├── index/ # 首页 │ ├── list/ # 商品列表 │ ├── detail/ # 商品详情 │ ├── cart/ # 购物车 │ ├── order/ # 订单确认 │ ├── orderList/ # 订单列表 │ └── mine/ # 个人中心 ├── components/ # 自定义组件 ├── utils/ # 工具函数如请求封装、时间格式化 ├── services/ # 接口层统一管理 API └── store/ # 全局状态管理在 app.json 里第一项 pages 数组中的第一个页面就是小程序启动后的首页。这个顺序要一开始就定好不然后面调整启动页很绕。pages/ 下每个页面必须有 .js、.wxml、.wxss、.json 四个文件缺一个编译就报错。很多第一次接触小程序的人会漏掉页面的 .json 文件结果编译直接失败这个在 AI 生成代码时也容易出问题验收时要重点检查。3. AI 实操用 WorkBuddy 生成可运行的小程序核心功能3.1 给 WorkBuddy 下达需求Prompt 要像需求文档很多人用 AI 写代码第一次就丢一句给我做一个商城小程序然后期待得到一个完美的项目——现实会给你一记响亮的耳光。WorkBuddy 的能力上限是被你的表达方式决定的。我后来的 Prompt 模板基本固定成这样我要用微信小程序原生语法开发一个单商家商城这是第 N 个模块。请生成 pages/detail 下的四个文件js/wxml/wxss/json。功能要求 1. 顶部轮播图展示商品图片 2. 展示商品名称、价格、库存 3. SKU 选择组件支持规格切换 4. 底部两个按钮加入购物车、立即购买 5. 加入购物车调用 services/cart.js 中的 addToCart 方法该方法通过 wx.request 请求 https://api.example.com/cart/add使用 POST 方法请求体字段为 goodsId、skuId、quantity需要携带 token 请求头 6. 页面的 .js 文件里要处理好加载态和错误提示用 wx.showToast 提示 7. 不要使用第三方 UI 库样式用 flex 布局风格简洁。你会发现这个 Prompt 里包含了页面路径、文件列表、功能点、接口协议甚至交互细节。写得越具体AI 生成的代码就越接近可运行状态。如果需求没有那么清晰可以先让 WorkBuddy 给出一版功能脑图和接口设计草案确认后再让它写代码。这一步属于磨刀不误砍柴工。还有一个小技巧要求 WorkBuddy 在生成代码时附带一份改动清单列出它改了哪些文件、新增了哪些接口、你认为需要人工重点检查什么。这样你在 code review 时不用把每个文件从头读一遍直接看清单和关键 diff 就行。3.2 页面级开发首页、列表页、详情页的生成与验收我让 WorkBuddy 按页面逐一生成而不是一次性生成整个项目这样每一轮的产物都是可运行、可验证的。首页是用户第一眼看到的东西我的要求是顶部搜索栏 轮播图 金刚区几个图标入口 推荐商品列表。数据来源统一走 services 层的请求函数组件之间不直接耦合。轮播图用 swiper 组件在数据未返回之前先显示占位图避免视觉抖动。商品列表页要处理两个高频交互下拉刷新和触底加载。微信提供的 onPullDownRefresh 和 onReachBottom 可以直接用。WorkBuddy 第一次生成的分页逻辑通常会漏掉加载中和没有更多了两个状态这个我几乎每次都要手动补。你也可以直接要求它把分页状态机写好page、pageSize、hasMore、loading 四个变量所有请求都先检查 loading 再发起避免重复请求。详情页是整个商城里交互最复杂的页SKU 选择尤其容易翻车。我在让 WorkBuddy 写详情页时会明确告诉它 SKU 的数据结构比如 colors 数组和 sizes 数组以及每个组合对应的库存量。它生成的选择逻辑我会重点测三件事当前组合是否有效库存大于 0 才能点确认切换规格后价格是否联动重复点击同一规格是否正确处理。这些边界逻辑 AI 容易写得笼统必须靠人工测。3.3 登录与手机号授权新版接口少踩解密坑小程序的登录流程和普通网站很不一样。核心机制是 wx.login() 获取一个临时 code把它发给后端后端拿着 code 加上 AppSecret 去微信接口换用户的 openid 和 session_key。openid 是用户在微信维度下的唯一标识session_key 是会话密钥。这个流程不建议自己手搓太容易出错。登录时的隐私授权处理也要特别注意。现在的微信版本里获取手机号推荐使用新版接口直接在页面放一个 button设置 open-typegetPhoneNumber用户点击授权后会在回调里返回一个 phoneCode。把这个 phoneCode 发给后端后端再调微信接口换取真实手机号整个过程你根本不需要自己解密。很多老教程还在教怎么处理 encryptedData 和 iv 解密那套方案在新版接口下已经没必要了反而容易踩解密失败的坑。还有一个容易被驳回的点是隐私协议。在小程序后台的设置-服务内容声明-用户隐私保护指引里要明确声明你收集了手机号、地址等信息并说明用途。如果你的前端代码里有获取手机号和收货地址的逻辑但隐私指引里没有对应声明审核基本必被拒。WorkBuddy 能帮你写代码但隐私声明的文案和后台配置必须自己根据实际业务去填。3.4 数据层选型云开发还是自建后端小程序后端方案我对比了两个方向各有适用场景。云开发是腾讯提供的一体化方案它包含云函数、云数据库、云存储可以理解成把后端和数据库都托管在了微信生态内部。好处非常直接不用买服务器、不用备案域名、不用手动配置 HTTPS 证书页面里可以直接用 wx.cloud 来调数据库和云函数。对于个人开发者、小团队、快速验证想法的项目这是目前成本最低的路径。登录时也可以直接用云开发自带的匿名登录或开放能力省掉自己维护会话体系的工作。自建后端则适合你已经有了现成的服务端团队或 API或者小程序只是整个业务的一部分后续还打算做 App、H5需要一套接口多端复用。这种情况下后端走自己的服务器小程序只做前端展示只是必须在微信公众平台配置 request 合法域名而且该域名必须 HTTPS、ICP 备案、TLS 版本符合要求。给一个直接的判断标准没有后端团队、着急上线、预算有限选云开发已有 API 体系或者业务需要多端复用选自建后端。WorkBuddy 对两种方案都能生成代码但注意它在生成云函数时默认会帮你写好 require Bound 之类的依赖如果在本地跑提示找不到模块通常是因为云函数需要在云端安装依赖本地需要先 npm install 一下。3.5 购物车与订单状态管理细节购物车是另一个容易写乱的地方。表面看就是一个数组但牵扯到全选、单选、数量增减、价格合计、库存校验和登录态绑定状态一旦散落在各个页面里改起来非常痛。我让 WorkBuddy 生成一个购物车管理模块长期存放购物车数据所有页面操作都通过这个模块统一读和写。这样加购、选中、结算这几个动作的 hook 都是同一套数据不容易出现两个页面状态不同步的问题。订单流程我定义成购物车结算 - 创建订单 - 微信支付 - 支付回调 - 更新订单状态。这里有一个常见的坑创建订单和后端扣减库存需要做原子操作如果只是先创建订单再慢慢减库存高并发下会超卖。WorkBuddy 生成的云函数或后端代码里我专门要求加事务控制——下单和扣库存必须在同一个事务里完成。后端拿到支付回调后再确认更新订单编号的支付状态。4. 上线前避坑从真机调试到微信支付4.1 自定义导航栏高度计算不同机型不错位很多电商小程序不用微信默认的顶部导航栏而是自己写一个自定义导航栏更好地搭配品牌设计。这时候就碰到了一个让无数新手头疼的问题顶部导航栏高度到底是多少直接说结论。微信文档和社区里的说法通常是 iOS 是 44px、Android 是 48px但这只是导航栏内容的建议高度实际情况比这个复杂——不同机型状态栏高度不同刘海屏和非刘海屏差异很大。如果只写死一个高度结果就是部分机型上导航栏和胶囊按钮错位、标题被遮挡或者整体布局顶到状态栏上。正确做法是运行时动态获取。用 wx.getMenuButtonBoundingClientRect() 拿到右上角胶囊按钮的位置和尺寸再用 wx.getWindowInfo() 拿到状态栏高度导航栏高度就按照状态栏高度 胶囊按钮高度 上下各留一定间距来计算。下面是我一直用的一套计算逻辑你可以直接抄走// utils/navigation.js function getNavigationBarHeight() { const windowInfo wx.getWindowInfo() const menuButton wx.getMenuButtonBoundingClientRect() // 胶囊按钮顶部到状态栏底部的距离通常可作为导航栏的上下间距参考 const navBarPadding (menuButton.top - windowInfo.statusBarHeight) * 2 const navBarHeight windowInfo.statusBarHeight menuButton.height navBarPadding return { statusBarHeight: windowInfo.statusBarHeight, menuButton: menuButton, navBarHeight: navBarHeight } }在页面的 onLoad 里调用这个函数把算出来的高度设置到 data 里再绑定到自定义导航栏的样式上。这样 iPhone 和 Android 上都能对齐胶囊按钮不用再为每个机型手工调。4.2 网络请求与 HTTPS 合法域名上线前最后一道闸前面提过开发阶段可以勾选不校验合法域名但这只是权宜之计。上线后小程序运行在一个白名单机制里所有 wx.request 的 URL域名必须在微信公众平台开发管理-服务器域名里配置过而且必须是 HTTPS、ICP 备案的域名。第一次提审前务必把测试接口的 IP 或临时域名全部换成正事可用的正式域名。一个很容易被忽略的细节是小程序的域名校验是针对具体域名的不是 IP也不能用带端口的形式。如果你的后端 API 路径是 https://api.example.com:8080即使域名本身合法带端口的地址依然会被拦。我吃过这个亏后来统一让后端把接口跑在 443 端口上。真机调试阶段如果遇到请求失败第一反应不要去看代码而是先在开发者工具的 Network 面板里看请求状态。既然是调试用 Charles 这类代理工具抓包看请求头和返回体也是常规操作能快速定位是签名问题、参数问题还是后端返回了异常。注意抓包只用于调试自己小程序的请求不要用它去获取用户敏感数据。4.3 微信支付接入企业主体与签名流程微信支付是小程序商城最核心也最麻烦的一环。首先明确一个前提支付能力只对企业主体开放个人主体的小程序无法开通微信支付。这是硬性规定不要试图绕过没有合法路径可走。支付的流程可以概括为四步。第一步后端调用微信支付的下单接口生成一个 prepay_id同时把订单金额、商品描述、回调地址这些参数准备好。第二步后端对 prepay_id、appId、timeStamp、nonceStr、package 等参数按微信要求的规则做二次签名返回给小程序端。第三步小程序端调用 wx.requestPayment把签名参数传进去拉起用户支付。第四步支付结果由后端接收微信的异步回调通知校验签名后更新订单状态。这里最容易出错的两件事签名方式和回调验签。微信支付要求用商户密钥 MD5 或 HMAC-SHA256 对参数字典序拼接后的字符串做签名参数名大小写、顺序错一个就报签名错误。回调通知微信可能重发多次后端必须做幂等处理比如在订单表里加一个支付状态字段重复回调时判断状态忽略即可。WorkBuddy 可以帮你生成一版支付代码但这两个点我建议你逐行确认最好对照微信支付官方文档核对一遍。开发时可以先开通微信支付的沙箱环境来测试流程但沙箱和真实支付的差别不小尤其是签名密钥和回调地址。我最终还是用了一笔 0.01 元的真实支付完成了全流程验证再把这个订单标记为测试订单从后台处理掉。花钱买个确定值得。4.4 真机调试开发工具能跑不等于真机没问题开发者工具里的模拟器和真机有差异这个差异在你上线前一定会以某种方式暴露出来。我第一次提交体验版后在真机上打开首页接口直接报错原因就是我在开发阶段一直勾着不校验合法域名开发者工具里一切正常真机上的白名单校验却毫不留情。此后我把局域网调试地址换成了正式域名才恢复正常。真机调试时建议重点看几类问题。一类是样式border-radius 在部分安卓上显示异常、固定定位被软键盘顶起、iPhone 底部 safe-area 遮挡按钮这些只有真机才能暴露。处理底部安全区可以用 env(safe-area-inset-bottom) 给固定按钮加 padding现在的小程序基础库也支持在样式里写 safe-area-inset-bottom 变量。另一类是性能首屏图片是否过大、是否存在 setData 频繁更新大数组导致页面卡顿建议开启开发者工具的性能面板跑一遍图片用压缩图大列表用分包或虚拟列表方案。体验版的内测也很重要。把体验版二维码发给几个不同手机型号的人让他们在不同网络环境下点一遍核心流程登录、加购、下单、支付、查看订单。这一步能帮你发现大量你自己试不出来的问题。5. 提交审核与发布从体验版到正式上线5.1 上传代码、体验版与版本管理当开发告一段落在微信开发者工具里点击右上角的上传填好版本号和备注代码就进入微信公众平台后台。上传的代码默认是开发版你需要在后台版本管理里把它设为体验版生成体验版二维码给团队成员和测试用户使用。版本管理这件事强烈建议从一开始就配合 Git 来做。WorkBuddy 每轮修改合入前我都在本地先 diff 一遍确认改动是预期的再 commit 到主干。微信后台的版本列表只适合做发布层面的管理代码层面的历史回溯还是得靠 Git。一个标准的流程是git 分支开发 - 本地验收 - 合入主干 - 上传为体验版 - 内测 - 提审。如果提审版本出问题还能回到上一个 Git tag 重新上传而不是在微信后台里翻版本找不回代码。5.2 审核被拒的高频原因与自查清单小程序审核是很多人的心理阴影但仔细分析拒审理由大部分是可以提前规避的。我统计了自己两轮提审的驳回理由再加平时社区里看到的情况高频原因大致有这几类类目与资质不符。比如做了一个商城但选择的类目是工具或者营业执照经营范围里没有零售审核就会要求补充相应资质。商城通常选电商平台或商家自营选哪个要看你的实际经营模式不要编造。功能与描述不一致。提交审核时填写的服务介绍写的是 A点开小程序却是 B 或还在开发中必然被拒。首页绝对不能是开发中或者一堆测试数据。隐私保护指引缺失。后台收集手机号、收货地址、位置信息但用户隐私保护指引里没有声明属于合规问题。虚拟支付问题。iOS 端虚拟商品会员、币、课程不能走微信支付如果你是做虚拟商品的要么下架该类商品要么用 iOS 的虚拟支付规则处理否则会被拒。诱导分享或诱导关注。页面里出现分享得优惠关注公众号领红包这类强诱导文案属于违规。我总结了一张自检清单类目和资质是否匹配用户协议、隐私协议是否完整所有页面是否真实可用无测试数据支付按钮是否为正式状态是否存在通过字样诱导行为分享功能文案是否合规。每一项核完再提交被拒概率会大幅下降。5.3 分阶段发布与应急回滚提审通过后不要直接全量发布。微信后台支持分阶段发布可以按比例逐步放量比如先发 10% 的用户观察线上反馈再逐步提高到 50%、100%。对于没有大流量验证过的产品分阶段发布几乎是成本最低的保险。线上如果出问题最紧急的操作不是立刻改代码而是在后台把当前线上版本切换回上一个稳定版本或者直接暂停服务。等修复后的版本提审通过后再重新发布。说句实话小程序线上出问题的概率比你想的高特别是支付回调、登录态失效这种偶发问题所以我后来一直保留着最后一版稳定版本的可回退状态宁可先回滚再修复也不让用户在坏版本上继续操作。6. 常见问题排查实录与 AI 开发经验沉淀6.1 高频编译与运行问题速查把我在整个过程中遇到过的典型问题整理成了一张表排查时都是先对症状再定位原因效率很高。症状撤回原因处理方法编译报错找不到 app.json项目目录选错或 pages 首个文件缺失确认项目根目录app.json 必须在根目录WXML 标签未闭合AI 生成模板时标签配对错误用开发者工具的编译错误定位行号检查最外层标签页面样式不生效.wxss 文件名与页面名不一致页面文件四个必须同名wx.request fail域名不在合法列表或协议非 HTTPS后台配置合法域名必须 HTTPS 且无端口真机无法登录开发者工具勾选了不校验合法域名换成正式域名后在真机测试getPhoneNumber fail: no permission隐私保护指引未配置或基础库版本过低后台配置隐私声明升级基础库版本云函数调用超时默认超时时间太短或依赖未安装在云函数配置里调大超时重新上传依赖支付签名错误参数拼接顺序或大小写错误对照商户文档逐项核对打印参数串检查导航栏错位高度写死未适配状态栏用 getMenuButtonBoundingClientRect 动态计算审核被拒类目不符或模块未完成按自检清单逐项核对后再提审这张表里我特别想强调基础库版本这一项。很多新接口比如新版 getPhoneNumber需要一定的基础库版本才支持但真正运行的端上有用户的微信版本参差不齐调用新接口前建议先做能力检测不支持的给降级方案不要让用户在老版本微信上直接打不开功能。6.2 WorkBuddy 产出代码的二次审查重点AI 生成的代码我的原则是可以信任但必须验证。每一轮生成后我会重点审查四个地方。第一硬编码和密钥。AppSecret、商户号、私钥这类信息绝不能出现在前端代码或公共库里。AI 有时会把测试用的密钥直接写进页面文件里这种问题只能靠审查发现。云函数里需要密钥时放到云开发的环境变量里配置。第二异步逻辑和生命周期。AI 生成的代码容易出现 onLoad 里发起请求还没等返回就跳转页面的情况setData 回调里再拿 data 用也会踩到异步坑。我会重点检查每个请求的 then/catch 路径是否完整业务逻辑是否在数据就绪后才执行。第三接口协议是否真实存在。AI 有时候会自己合理推导一个接口比如它认为有个 /api/sku 方法于是代码里就调了。这个接口在你的后端里并不存在。所以每次让它生成页面时我都要求它只准调用我提供的 services 层方法禁止自行发明 API。第四第三方依赖。WorkBuddy 有时为了省事会引一些开源库如果是为了 UI 快速成型还好但要警惕未维护的库或和基础库冲突的库。能用原生能力解决的尽量别加依赖小程序包体积每大 1KB加载都会慢一点。6.3 把 AI 开发工作流固化下来项目下线后我复盘过一个问题同样是 AI 开发为什么前两周效率平平后期越来越快答案是流程固化了。我现在把每一类开发任务沉淀成模板——小程序页面生成模板、云函数模板、支付流程模板、审核自查模板。每个模板里包含我要给 WorkBuddy 的标准需求上下文、要遵守的目录规范、接口协议约定以及完成后的人工验收清单。下一次做新小程序我不需要从零写需求直接套用模板再修改业务差异部分效率是第一次的三到四倍。还有一个小习惯每解决一个坑我都会把问题描述、原因、解决方案写回给 WorkBuddy 的项目记忆区让它后续生成代码时主动避开。你可能会觉得 AI 记不住这些但实测下来有了历史上下文之后它再生成的代码在导航栏适配、支付签名、合法域名这些环节上主动正确率明显提升。AI 开发的本质是人和工具的协作工具越了解你踩过的坑后续就越省心。我个人在实际操作中的体会是WorkBuddy 这类工具真正的价值不是把程序员变成甩手掌柜而是把从 0 到 1的时间压缩到极致。真正考验人的其实是从 1 到上线的这一段。微信支付、隐私协议、类目审核、真机适配这些事 AI 能帮你生成代码和文档但最终理解和审核它们的人是你。想做小程序的人不用等自己完全学会再动手先把一个最小模块跑起来让 AI 帮你把这扇门推开剩下的路走一遍就熟了。
最近几个月我一直在折腾用 WorkBuddy 做微信小程序这件事从最开始对着空白项目发呆到最终把一个小程序商城真的提交审核、成功发布上线中间踩的坑比想象中多得多。网上讲单点技术的文章很多但很少有一篇能完整回答用 AI 工具从零做小程序到底能不能直接上线微信这篇就把我的完整路径写出来包括账号怎么配、Prompt 怎么写、登录和支付怎么接、审核被拒怎么处理以及那些只有真正走到上线那一步才会遇到的坑。如果你准备用 WorkBuddy或者其他 AI 编程工具做小程序希望这篇能帮你少走至少一星期的弯路。1. 项目规划先搞清楚 WorkBuddy 能帮你省掉哪些事1.1 传统小程序开发卡在哪做过小程序的人都知道它的技术栈并不复杂——WXML 写结构、WXSS 写样式、JS 写逻辑、JSON 做配置再加上微信提供的各种 API单个页面的开发难度比 Web 还低一点。但真做一个完整项目工作量全藏在细节里登录态要处理、手机号授权要配、购物车要管理状态、订单状态要流转、支付要对接签名和回调还有不同机型的导航栏适配。这些逻辑单个拎出来都不难堆在一起就变成了一座山。传统做法是一个前端至少排两周开发再加一周联调和提审碰上需求临时调整周期轻松翻倍。另一个痛点是环境配置。很多刚接触小程序的人光是搞明白 AppID、AppSecret、服务器域名、业务域名这几个概念就要花上小半天。更不用说很多人并没有现成的后端服务为了一个小程序还得去租服务器、备案域名、写接口还没开始写页面人先被环境吓退了。1.2 WorkBuddy 的AI 脚手架 人工验收定位WorkBuddy 这类 AI 编程工具本质上解决的是代码生成效率和项目脚手架搭建两个问题。你可以把它理解成一个不会累、知道很多最佳实践、但需要你盯着的程序员。它可以根据你的描述生成小程序前端代码、云函数、数据库集合设计甚至帮你把测试数据准备好。但我的实测体验是它不可能一句话生成一个完美上线的小程序更合理的用法是AI 脚手架 人工验收。具体来说我的工作流是这样的。先自己把需求拆成模块比如首页、商品列表、详情、购物车、订单、登录、支付然后针对每个模块给 WorkBuddy 下指令让它输出完整可运行的代码拿到代码后在微信开发者工具里跑起来逐项验收有问题再让它改而不是自己从头写。这样做的好处是页面骨架和重复劳动基本被 AI 吃掉而我只需要把精力放在业务逻辑、边界条件和微信生态的特殊规则上。1.3 交付物定义这一版做到什么程度做项目最忌讳一开始就想要一个大而全的东西。我给自己定的范围是一款单商家的小程序商城功能边界是商品展示首页轮播、金刚区、商品列表、详情、购物车、登录授权、手机号绑定、提交订单、微信支付、订单列表和简单管理。明确不做多商家入驻、不做分销裂变、不做复杂的推荐算法。先让一个最小可用版本能跑通上线再考虑加东西。这也是我给所有准备用 AI 做小程序的朋友的第一条建议把能上线而不是功能多当成第一目标。2. 环境准备账号、工具与目录骨架一次配齐2.1 注册小程序账号与 AppID个人和企业差别很大在写第一行代码之前先去微信公众平台注册小程序账号。这一步值得多说两句因为主体类型直接决定了你能做什么、不能做什么。个人主体注册快只要身份证就能搞定适合做内容展示、工具类小程序但不能开通微信支付也不能做电商、直播、社交等需要资质的类目。企业主体需要营业执照、对公账户验证流程会慢一些但它能开通微信支付、能选更多类目是做一个正规商城的前提。我的建议是只要你的目标是做带交易的小程序直接走企业主体同时把微信支付商户号一并购了。别等代码写完了才去申请商户号那中间几个工作日的审核等待会让你非常被动。注册完成后在小程序后台的开发管理里能看到 AppID 和 AppSecret。AppID 相当于小程序的身份证前端要用AppSecret 是后台密钥只能放在服务端或者云函数里千万别写进前端代码后面我会细说这个坑。2.2 搭建本地开发环境微信开发者工具与 WorkBuddy 配合开发小程序必须要装微信开发者工具这是绕不开的。它能打开项目、编译预览、真机调试、上传代码所有工作流都在这上面完成。安装之后有个细节很多人会忽略在设置-安全设置里开启服务端口否则某些外部工具的调试能力会受限。另外开发阶段可以在详情-本地设置里勾选不校验合法域名、web-view业务域名、TLS 版本以及 HTTPS 证书这样本地调试时可以直接请求测试接口不用为临时的 IP 地址频繁配置域名。但记住这个选项只是开发阶段的便利上线前必须关掉并配置真实域名。WorkBuddy 和微信开发者工具的关系是互补的WorkBuddy 负责生成和修改代码微信开发者工具负责运行和验证。我通常先在 WorkBuddy 里建立项目工作区把小程序源码目录挂进去让它直接读写文件改完代码后切到微信开发者工具刷新编译看效果再反馈给它继续改。这个循环跑顺之后开发效率非常可观。2.3 项目目录结构少走弯路的文件规划原生小程序的项目结构看起来自由但规划不好后面会非常乱。我用的是这套目录WorkBuddy 生成代码时我也会要求它按这个结构输出project/ ├── app.js # 全局逻辑启动时处理登录态 ├── app.json # 全局配置页面路径、窗口、tabBar ├── app.wxss # 全局样式 ├── pages/ # 页面 │ ├── index/ # 首页 │ ├── list/ # 商品列表 │ ├── detail/ # 商品详情 │ ├── cart/ # 购物车 │ ├── order/ # 订单确认 │ ├── orderList/ # 订单列表 │ └── mine/ # 个人中心 ├── components/ # 自定义组件 ├── utils/ # 工具函数如请求封装、时间格式化 ├── services/ # 接口层统一管理 API └── store/ # 全局状态管理在 app.json 里第一项 pages 数组中的第一个页面就是小程序启动后的首页。这个顺序要一开始就定好不然后面调整启动页很绕。pages/ 下每个页面必须有 .js、.wxml、.wxss、.json 四个文件缺一个编译就报错。很多第一次接触小程序的人会漏掉页面的 .json 文件结果编译直接失败这个在 AI 生成代码时也容易出问题验收时要重点检查。3. AI 实操用 WorkBuddy 生成可运行的小程序核心功能3.1 给 WorkBuddy 下达需求Prompt 要像需求文档很多人用 AI 写代码第一次就丢一句给我做一个商城小程序然后期待得到一个完美的项目——现实会给你一记响亮的耳光。WorkBuddy 的能力上限是被你的表达方式决定的。我后来的 Prompt 模板基本固定成这样我要用微信小程序原生语法开发一个单商家商城这是第 N 个模块。请生成 pages/detail 下的四个文件js/wxml/wxss/json。功能要求 1. 顶部轮播图展示商品图片 2. 展示商品名称、价格、库存 3. SKU 选择组件支持规格切换 4. 底部两个按钮加入购物车、立即购买 5. 加入购物车调用 services/cart.js 中的 addToCart 方法该方法通过 wx.request 请求 https://api.example.com/cart/add使用 POST 方法请求体字段为 goodsId、skuId、quantity需要携带 token 请求头 6. 页面的 .js 文件里要处理好加载态和错误提示用 wx.showToast 提示 7. 不要使用第三方 UI 库样式用 flex 布局风格简洁。你会发现这个 Prompt 里包含了页面路径、文件列表、功能点、接口协议甚至交互细节。写得越具体AI 生成的代码就越接近可运行状态。如果需求没有那么清晰可以先让 WorkBuddy 给出一版功能脑图和接口设计草案确认后再让它写代码。这一步属于磨刀不误砍柴工。还有一个小技巧要求 WorkBuddy 在生成代码时附带一份改动清单列出它改了哪些文件、新增了哪些接口、你认为需要人工重点检查什么。这样你在 code review 时不用把每个文件从头读一遍直接看清单和关键 diff 就行。3.2 页面级开发首页、列表页、详情页的生成与验收我让 WorkBuddy 按页面逐一生成而不是一次性生成整个项目这样每一轮的产物都是可运行、可验证的。首页是用户第一眼看到的东西我的要求是顶部搜索栏 轮播图 金刚区几个图标入口 推荐商品列表。数据来源统一走 services 层的请求函数组件之间不直接耦合。轮播图用 swiper 组件在数据未返回之前先显示占位图避免视觉抖动。商品列表页要处理两个高频交互下拉刷新和触底加载。微信提供的 onPullDownRefresh 和 onReachBottom 可以直接用。WorkBuddy 第一次生成的分页逻辑通常会漏掉加载中和没有更多了两个状态这个我几乎每次都要手动补。你也可以直接要求它把分页状态机写好page、pageSize、hasMore、loading 四个变量所有请求都先检查 loading 再发起避免重复请求。详情页是整个商城里交互最复杂的页SKU 选择尤其容易翻车。我在让 WorkBuddy 写详情页时会明确告诉它 SKU 的数据结构比如 colors 数组和 sizes 数组以及每个组合对应的库存量。它生成的选择逻辑我会重点测三件事当前组合是否有效库存大于 0 才能点确认切换规格后价格是否联动重复点击同一规格是否正确处理。这些边界逻辑 AI 容易写得笼统必须靠人工测。3.3 登录与手机号授权新版接口少踩解密坑小程序的登录流程和普通网站很不一样。核心机制是 wx.login() 获取一个临时 code把它发给后端后端拿着 code 加上 AppSecret 去微信接口换用户的 openid 和 session_key。openid 是用户在微信维度下的唯一标识session_key 是会话密钥。这个流程不建议自己手搓太容易出错。登录时的隐私授权处理也要特别注意。现在的微信版本里获取手机号推荐使用新版接口直接在页面放一个 button设置 open-typegetPhoneNumber用户点击授权后会在回调里返回一个 phoneCode。把这个 phoneCode 发给后端后端再调微信接口换取真实手机号整个过程你根本不需要自己解密。很多老教程还在教怎么处理 encryptedData 和 iv 解密那套方案在新版接口下已经没必要了反而容易踩解密失败的坑。还有一个容易被驳回的点是隐私协议。在小程序后台的设置-服务内容声明-用户隐私保护指引里要明确声明你收集了手机号、地址等信息并说明用途。如果你的前端代码里有获取手机号和收货地址的逻辑但隐私指引里没有对应声明审核基本必被拒。WorkBuddy 能帮你写代码但隐私声明的文案和后台配置必须自己根据实际业务去填。3.4 数据层选型云开发还是自建后端小程序后端方案我对比了两个方向各有适用场景。云开发是腾讯提供的一体化方案它包含云函数、云数据库、云存储可以理解成把后端和数据库都托管在了微信生态内部。好处非常直接不用买服务器、不用备案域名、不用手动配置 HTTPS 证书页面里可以直接用 wx.cloud 来调数据库和云函数。对于个人开发者、小团队、快速验证想法的项目这是目前成本最低的路径。登录时也可以直接用云开发自带的匿名登录或开放能力省掉自己维护会话体系的工作。自建后端则适合你已经有了现成的服务端团队或 API或者小程序只是整个业务的一部分后续还打算做 App、H5需要一套接口多端复用。这种情况下后端走自己的服务器小程序只做前端展示只是必须在微信公众平台配置 request 合法域名而且该域名必须 HTTPS、ICP 备案、TLS 版本符合要求。给一个直接的判断标准没有后端团队、着急上线、预算有限选云开发已有 API 体系或者业务需要多端复用选自建后端。WorkBuddy 对两种方案都能生成代码但注意它在生成云函数时默认会帮你写好 require Bound 之类的依赖如果在本地跑提示找不到模块通常是因为云函数需要在云端安装依赖本地需要先 npm install 一下。3.5 购物车与订单状态管理细节购物车是另一个容易写乱的地方。表面看就是一个数组但牵扯到全选、单选、数量增减、价格合计、库存校验和登录态绑定状态一旦散落在各个页面里改起来非常痛。我让 WorkBuddy 生成一个购物车管理模块长期存放购物车数据所有页面操作都通过这个模块统一读和写。这样加购、选中、结算这几个动作的 hook 都是同一套数据不容易出现两个页面状态不同步的问题。订单流程我定义成购物车结算 - 创建订单 - 微信支付 - 支付回调 - 更新订单状态。这里有一个常见的坑创建订单和后端扣减库存需要做原子操作如果只是先创建订单再慢慢减库存高并发下会超卖。WorkBuddy 生成的云函数或后端代码里我专门要求加事务控制——下单和扣库存必须在同一个事务里完成。后端拿到支付回调后再确认更新订单编号的支付状态。4. 上线前避坑从真机调试到微信支付4.1 自定义导航栏高度计算不同机型不错位很多电商小程序不用微信默认的顶部导航栏而是自己写一个自定义导航栏更好地搭配品牌设计。这时候就碰到了一个让无数新手头疼的问题顶部导航栏高度到底是多少直接说结论。微信文档和社区里的说法通常是 iOS 是 44px、Android 是 48px但这只是导航栏内容的建议高度实际情况比这个复杂——不同机型状态栏高度不同刘海屏和非刘海屏差异很大。如果只写死一个高度结果就是部分机型上导航栏和胶囊按钮错位、标题被遮挡或者整体布局顶到状态栏上。正确做法是运行时动态获取。用 wx.getMenuButtonBoundingClientRect() 拿到右上角胶囊按钮的位置和尺寸再用 wx.getWindowInfo() 拿到状态栏高度导航栏高度就按照状态栏高度 胶囊按钮高度 上下各留一定间距来计算。下面是我一直用的一套计算逻辑你可以直接抄走// utils/navigation.js function getNavigationBarHeight() { const windowInfo wx.getWindowInfo() const menuButton wx.getMenuButtonBoundingClientRect() // 胶囊按钮顶部到状态栏底部的距离通常可作为导航栏的上下间距参考 const navBarPadding (menuButton.top - windowInfo.statusBarHeight) * 2 const navBarHeight windowInfo.statusBarHeight menuButton.height navBarPadding return { statusBarHeight: windowInfo.statusBarHeight, menuButton: menuButton, navBarHeight: navBarHeight } }在页面的 onLoad 里调用这个函数把算出来的高度设置到 data 里再绑定到自定义导航栏的样式上。这样 iPhone 和 Android 上都能对齐胶囊按钮不用再为每个机型手工调。4.2 网络请求与 HTTPS 合法域名上线前最后一道闸前面提过开发阶段可以勾选不校验合法域名但这只是权宜之计。上线后小程序运行在一个白名单机制里所有 wx.request 的 URL域名必须在微信公众平台开发管理-服务器域名里配置过而且必须是 HTTPS、ICP 备案的域名。第一次提审前务必把测试接口的 IP 或临时域名全部换成正事可用的正式域名。一个很容易被忽略的细节是小程序的域名校验是针对具体域名的不是 IP也不能用带端口的形式。如果你的后端 API 路径是 https://api.example.com:8080即使域名本身合法带端口的地址依然会被拦。我吃过这个亏后来统一让后端把接口跑在 443 端口上。真机调试阶段如果遇到请求失败第一反应不要去看代码而是先在开发者工具的 Network 面板里看请求状态。既然是调试用 Charles 这类代理工具抓包看请求头和返回体也是常规操作能快速定位是签名问题、参数问题还是后端返回了异常。注意抓包只用于调试自己小程序的请求不要用它去获取用户敏感数据。4.3 微信支付接入企业主体与签名流程微信支付是小程序商城最核心也最麻烦的一环。首先明确一个前提支付能力只对企业主体开放个人主体的小程序无法开通微信支付。这是硬性规定不要试图绕过没有合法路径可走。支付的流程可以概括为四步。第一步后端调用微信支付的下单接口生成一个 prepay_id同时把订单金额、商品描述、回调地址这些参数准备好。第二步后端对 prepay_id、appId、timeStamp、nonceStr、package 等参数按微信要求的规则做二次签名返回给小程序端。第三步小程序端调用 wx.requestPayment把签名参数传进去拉起用户支付。第四步支付结果由后端接收微信的异步回调通知校验签名后更新订单状态。这里最容易出错的两件事签名方式和回调验签。微信支付要求用商户密钥 MD5 或 HMAC-SHA256 对参数字典序拼接后的字符串做签名参数名大小写、顺序错一个就报签名错误。回调通知微信可能重发多次后端必须做幂等处理比如在订单表里加一个支付状态字段重复回调时判断状态忽略即可。WorkBuddy 可以帮你生成一版支付代码但这两个点我建议你逐行确认最好对照微信支付官方文档核对一遍。开发时可以先开通微信支付的沙箱环境来测试流程但沙箱和真实支付的差别不小尤其是签名密钥和回调地址。我最终还是用了一笔 0.01 元的真实支付完成了全流程验证再把这个订单标记为测试订单从后台处理掉。花钱买个确定值得。4.4 真机调试开发工具能跑不等于真机没问题开发者工具里的模拟器和真机有差异这个差异在你上线前一定会以某种方式暴露出来。我第一次提交体验版后在真机上打开首页接口直接报错原因就是我在开发阶段一直勾着不校验合法域名开发者工具里一切正常真机上的白名单校验却毫不留情。此后我把局域网调试地址换成了正式域名才恢复正常。真机调试时建议重点看几类问题。一类是样式border-radius 在部分安卓上显示异常、固定定位被软键盘顶起、iPhone 底部 safe-area 遮挡按钮这些只有真机才能暴露。处理底部安全区可以用 env(safe-area-inset-bottom) 给固定按钮加 padding现在的小程序基础库也支持在样式里写 safe-area-inset-bottom 变量。另一类是性能首屏图片是否过大、是否存在 setData 频繁更新大数组导致页面卡顿建议开启开发者工具的性能面板跑一遍图片用压缩图大列表用分包或虚拟列表方案。体验版的内测也很重要。把体验版二维码发给几个不同手机型号的人让他们在不同网络环境下点一遍核心流程登录、加购、下单、支付、查看订单。这一步能帮你发现大量你自己试不出来的问题。5. 提交审核与发布从体验版到正式上线5.1 上传代码、体验版与版本管理当开发告一段落在微信开发者工具里点击右上角的上传填好版本号和备注代码就进入微信公众平台后台。上传的代码默认是开发版你需要在后台版本管理里把它设为体验版生成体验版二维码给团队成员和测试用户使用。版本管理这件事强烈建议从一开始就配合 Git 来做。WorkBuddy 每轮修改合入前我都在本地先 diff 一遍确认改动是预期的再 commit 到主干。微信后台的版本列表只适合做发布层面的管理代码层面的历史回溯还是得靠 Git。一个标准的流程是git 分支开发 - 本地验收 - 合入主干 - 上传为体验版 - 内测 - 提审。如果提审版本出问题还能回到上一个 Git tag 重新上传而不是在微信后台里翻版本找不回代码。5.2 审核被拒的高频原因与自查清单小程序审核是很多人的心理阴影但仔细分析拒审理由大部分是可以提前规避的。我统计了自己两轮提审的驳回理由再加平时社区里看到的情况高频原因大致有这几类类目与资质不符。比如做了一个商城但选择的类目是工具或者营业执照经营范围里没有零售审核就会要求补充相应资质。商城通常选电商平台或商家自营选哪个要看你的实际经营模式不要编造。功能与描述不一致。提交审核时填写的服务介绍写的是 A点开小程序却是 B 或还在开发中必然被拒。首页绝对不能是开发中或者一堆测试数据。隐私保护指引缺失。后台收集手机号、收货地址、位置信息但用户隐私保护指引里没有声明属于合规问题。虚拟支付问题。iOS 端虚拟商品会员、币、课程不能走微信支付如果你是做虚拟商品的要么下架该类商品要么用 iOS 的虚拟支付规则处理否则会被拒。诱导分享或诱导关注。页面里出现分享得优惠关注公众号领红包这类强诱导文案属于违规。我总结了一张自检清单类目和资质是否匹配用户协议、隐私协议是否完整所有页面是否真实可用无测试数据支付按钮是否为正式状态是否存在通过字样诱导行为分享功能文案是否合规。每一项核完再提交被拒概率会大幅下降。5.3 分阶段发布与应急回滚提审通过后不要直接全量发布。微信后台支持分阶段发布可以按比例逐步放量比如先发 10% 的用户观察线上反馈再逐步提高到 50%、100%。对于没有大流量验证过的产品分阶段发布几乎是成本最低的保险。线上如果出问题最紧急的操作不是立刻改代码而是在后台把当前线上版本切换回上一个稳定版本或者直接暂停服务。等修复后的版本提审通过后再重新发布。说句实话小程序线上出问题的概率比你想的高特别是支付回调、登录态失效这种偶发问题所以我后来一直保留着最后一版稳定版本的可回退状态宁可先回滚再修复也不让用户在坏版本上继续操作。6. 常见问题排查实录与 AI 开发经验沉淀6.1 高频编译与运行问题速查把我在整个过程中遇到过的典型问题整理成了一张表排查时都是先对症状再定位原因效率很高。症状撤回原因处理方法编译报错找不到 app.json项目目录选错或 pages 首个文件缺失确认项目根目录app.json 必须在根目录WXML 标签未闭合AI 生成模板时标签配对错误用开发者工具的编译错误定位行号检查最外层标签页面样式不生效.wxss 文件名与页面名不一致页面文件四个必须同名wx.request fail域名不在合法列表或协议非 HTTPS后台配置合法域名必须 HTTPS 且无端口真机无法登录开发者工具勾选了不校验合法域名换成正式域名后在真机测试getPhoneNumber fail: no permission隐私保护指引未配置或基础库版本过低后台配置隐私声明升级基础库版本云函数调用超时默认超时时间太短或依赖未安装在云函数配置里调大超时重新上传依赖支付签名错误参数拼接顺序或大小写错误对照商户文档逐项核对打印参数串检查导航栏错位高度写死未适配状态栏用 getMenuButtonBoundingClientRect 动态计算审核被拒类目不符或模块未完成按自检清单逐项核对后再提审这张表里我特别想强调基础库版本这一项。很多新接口比如新版 getPhoneNumber需要一定的基础库版本才支持但真正运行的端上有用户的微信版本参差不齐调用新接口前建议先做能力检测不支持的给降级方案不要让用户在老版本微信上直接打不开功能。6.2 WorkBuddy 产出代码的二次审查重点AI 生成的代码我的原则是可以信任但必须验证。每一轮生成后我会重点审查四个地方。第一硬编码和密钥。AppSecret、商户号、私钥这类信息绝不能出现在前端代码或公共库里。AI 有时会把测试用的密钥直接写进页面文件里这种问题只能靠审查发现。云函数里需要密钥时放到云开发的环境变量里配置。第二异步逻辑和生命周期。AI 生成的代码容易出现 onLoad 里发起请求还没等返回就跳转页面的情况setData 回调里再拿 data 用也会踩到异步坑。我会重点检查每个请求的 then/catch 路径是否完整业务逻辑是否在数据就绪后才执行。第三接口协议是否真实存在。AI 有时候会自己合理推导一个接口比如它认为有个 /api/sku 方法于是代码里就调了。这个接口在你的后端里并不存在。所以每次让它生成页面时我都要求它只准调用我提供的 services 层方法禁止自行发明 API。第四第三方依赖。WorkBuddy 有时为了省事会引一些开源库如果是为了 UI 快速成型还好但要警惕未维护的库或和基础库冲突的库。能用原生能力解决的尽量别加依赖小程序包体积每大 1KB加载都会慢一点。6.3 把 AI 开发工作流固化下来项目下线后我复盘过一个问题同样是 AI 开发为什么前两周效率平平后期越来越快答案是流程固化了。我现在把每一类开发任务沉淀成模板——小程序页面生成模板、云函数模板、支付流程模板、审核自查模板。每个模板里包含我要给 WorkBuddy 的标准需求上下文、要遵守的目录规范、接口协议约定以及完成后的人工验收清单。下一次做新小程序我不需要从零写需求直接套用模板再修改业务差异部分效率是第一次的三到四倍。还有一个小习惯每解决一个坑我都会把问题描述、原因、解决方案写回给 WorkBuddy 的项目记忆区让它后续生成代码时主动避开。你可能会觉得 AI 记不住这些但实测下来有了历史上下文之后它再生成的代码在导航栏适配、支付签名、合法域名这些环节上主动正确率明显提升。AI 开发的本质是人和工具的协作工具越了解你踩过的坑后续就越省心。我个人在实际操作中的体会是WorkBuddy 这类工具真正的价值不是把程序员变成甩手掌柜而是把从 0 到 1的时间压缩到极致。真正考验人的其实是从 1 到上线的这一段。微信支付、隐私协议、类目审核、真机适配这些事 AI 能帮你生成代码和文档但最终理解和审核它们的人是你。想做小程序的人不用等自己完全学会再动手先把一个最小模块跑起来让 AI 帮你把这扇门推开剩下的路走一遍就熟了。
