AI 会员小程序实战
Goal Coding 从 0 到 1 用 AI 做一个能微信支付的 AI 会员小程序，全过程公开
本次教程的目标是一个 AI 会员小程序。用户交年费加入社区，查看推荐资料，报名线下活动，认识新的朋友。
跟传统的 Vibe Coding 开发不同，我们这次是 "Goal Coding"，利用 AI Agent 的目标功能，人类提前准备好详细需求文档，走完必须的流程，不写任何一行代码，剩下全部让 AI 全自动化开发，自动测试直到目标达成。
当然但由于 AI 的局限，我们实际上还是有一些介入调试 bug 的环节。但是，相比传统的教程，我们已经大大大减少了介入的次数。
让我们开始挑战吧！
我们计划实现的功能：
- 手机号登录
- 资料填写和照片
- 推荐资料浏览
- 会员权益和微信支付
- 线下活动报名
- 简单的后台管理功能
第 1 步：准备账号和权限
小程序这件事，真正麻烦的地方不在代码。
代码可以让 Codex 去写，依赖可以让它去装，原型也可以让它先画出来。麻烦的是微信生态里的账号和权限：注册、认证、备案、类目、AppID、CloudBase、微信支付、体验版。
这些地方现在 AI 还搞不定，需要人自己去后台确认。
先准备一小段项目信息：
注册小程序
入口是 微信公众平台。
如果你已经有认证过的公众号，可以在公众号后台的小程序管理里创建小程序，能省一点第一次认证的费用。第二年小程序还是要单独处理，这个以后台提示为准。
几个我实际遇到的点：
- 注册邮箱不能被其他公众号或小程序占用。
- 小程序名称经常被占用，纯英文名称可能会要求商标。
- 如果要接微信支付，个人小程序限制很多，商业项目通常要企业认证。
- 社交、内容、AI、支付相关类目都要认真看材料要求。
- 备案、类目、认证别等代码写完再弄，这些通常要等几天。
如果你的小程序里接了 AI，后面提审时可能还会涉及算法备案、模型合作协议、备案编号这类材料。用国内模型的话，一般可以去模型平台找他们已经备案的材料。
获取 AppID
注册完小程序后，去后台拿 AppID：
小程序后台 -> 账号设置 -> 账号信息这个 AppID 后面要给 Codex，也要关联微信支付商户号。
如果你要接第三方 API，还要配置合法域名：
管理 -> 开发管理 -> 开发设置 -> 服务器域名这里填你自己的接口域名。密钥不要放到小程序前端，能放云函数就放云函数。
开通腾讯云开发 CloudBase
CloudBase 可以从微信开发者工具进入，也可以从腾讯云控制台进入。
开通后，先复制环境 ID：
CloudBase 环境 ID：<你的环境 ID>这次案例用的是 CloudBase SQL。用户、订单、会员、活动这类结构化数据，用 SQL 型数据库更容易管理。
给 Codex 的要求可以写得很短：
后端使用 CloudBase。
数据库使用 CloudBase SQL 型数据库。
不要把核心业务改成文档数据库。如果要让 Codex 调 CloudBase，提前准备这些工具会方便一点：
npm install @cloudbase/cli@latest -g
tcb ai
npx skills add TencentCloudBase/cloudbase-skills
npm i @cloudbase/cloudbase-mcp -g实战里我也遇到过 MCP 没跑通的情况。这个不用太纠结，能用 CLI 把云函数部署上去就行。
配微信开发者工具
你需要去官网下载微信开发者工具，但你并不需要去精通它的操作，你只需要去做必要的设置。
之后我们会让 AI 帮我们完全接管微信开发者工具。
Codex 想自动打开微信开发者工具、看日志、截图验证，需要开发者工具允许命令行访问。
如果命令行提示服务端口没打开，去这里开：
微信开发者工具 -> 设置 -> 安全设置 -> 开启服务端口第一次自动打开项目时，开发者工具可能会弹出信任确认。这里要人工点一次「信任并运行」。
准备微信支付
接入微信支付需要企业账户，如果不准备接入可以跳过
由于小程序需要收会员费，微信支付商户号要提前准备。
大概流程是这样：
- 登录 微信支付商户平台。
- 在产品中心里关联小程序 AppID。
- 回到小程序后台确认待关联商户号。
- 回到 CloudBase 设置里做微信支付授权，有两次授权。
微信支付商户平台 -> 产品中心 -> AppID 账号管理 -> 关联小程序 AppID小程序后台确认路径：
小程序后台 -> 支付与交易 -> 微信支付 -> 待关联商户号 -> 确认CloudBase 授权路径：
CloudBase 控制台 -> 设置 -> 其他设置 -> 微信支付配置 -> JSAPI 授权退款授权路径：
CloudBase 控制台 -> 设置 -> 其他设置 -> 微信支付配置 -> 退款授权
实战里还有一个容易漏掉的点：退款 API 授权不一定会主动弹通知。
你可以去微信支付商户平台这里找：
产品中心 -> 我授权的产品 -> 服务商 API 退款 -> 授权授权后有时要等几分钟，微信支付商家助手才会弹确认。
技术栈选择
我没有直接用微信开发者工具的模板新建。
经过几个小时的调研，发现 Weapp-vite 的开发体验会好很多。它能保留原生小程序写法，又能用 Vite、TypeScript、Tailwind，还能配合工具自动打开开发者工具、看日志、截图。
TDesign 也很关键。小程序里按钮、表单、弹窗、底部导航这些东西，能用成熟组件就别自己造一套。尤其是让 AI 写 UI 的时候，先把组件库限制住，后面会少很多乱七八糟的样式。
TECH STACK
这次我用这套搭配
工程
Weapp-vite
Vite + TypeScript，开发体验好一点
写法
原生小程序
不引入 Taro，少一层多端抽象
组件
TDesign
按钮、表单、弹窗、导航先用成熟组件
样式
Tailwind CSS
让 AI 写样式时更容易收口
后端
CloudBase SQL
云函数、SQL 型数据库、云存储
执行
Codex
装依赖、跑命令、看日志、修 bug
人和 Codex 怎么分工
我一开始也很想把所有步骤都让 AI 来操作，最好是它能使用 computer use 自行操作电脑完成一切。
但微信小程序真的比开发网站麻烦很多。网站项目有时候一段话就能从需求写到部署，小程序这边有大量人工确认：注册、认证、备案、AppID、云环境、支付商户号、开发者工具信任、真机测试。
这次我的分工大概是这样：
第 2 步：初始化项目
新建一个空文件夹，打开 Codex，把下面这段复制进去：
我要做一个微信小程序项目，请你从零帮我创建并初始化。
基础信息：
- 小程序 AppID：<填写你的 AppID>
- 技术栈：Weapp-vite + TDesign Mini Program + Tailwind CSS + CloudBase SQL 型数据库
- 项目类型：微信小程序，AI 会员 + 线下活动 + 资料推荐
执行原则：
1. 先创建 Weapp-vite 项目，优先选择适合微信小程序、TDesign、Tailwind CSS 的模板组合。
2. 脚手架如果提示安装推荐 AI skills，请优先安装。生成的 AGENTS.md 要保留。
3. 后端使用 CloudBase，数据库使用 SQL 型数据库，不要改成文档数据库。
4. 如果 CloudBase MCP、CLI 或微信开发者工具需要登录授权，请明确告诉我需要人工授权的位置，然后继续完成能自动完成的部分。
5. 不要把内部开发说明、任务日志、调试备注写进小程序 UI。
请你自己执行这些命令，不需要让我手敲：
```bash
pnpm create weapp-vite
pnpm i
pnpm dev
pnpm dev --open
wv ide logs --open
pnpm build
wv screenshot --project ./dist/build/mp-weixin --json
```
`wv ide logs --open` 特别有用。它能把微信开发者工具里的 console 日志带回终端，让 AI 根据真实日志修问题。
如果需要 CloudBase 工具链：
```bash
npm install @cloudbase/cli@latest -g
tcb ai
npm i @cloudbase/cloudbase-mcp -g
```
完成后告诉我：
1. 项目结构。
2. 开发服务器状态。
3. 微信开发者工具是否打开。
4. 哪些步骤需要我到微信后台或开发者工具里确认。如果前面还没开启服务端口，去这里处理：
微信开发者工具 -> 设置 -> 安全设置 -> 开启服务端口第一次打开项目时，开发者工具可能会弹出信任确认，点「信任并运行」。
第 3 步：生成需求文档
开一个 Codex 对话，让它先生成需求文档，并把不清楚的地方问出来。
如果不符合你的预期的话，就继续对话直到满意为止
复制下面这段：
下面是一份 AI 交友会员微信小程序原始需求，请输出详细需求文档，不清楚的地方可以先问我。
产品类型：微信小程序，会员 + 线下活动 + 资料推荐。
核心目标：
- 用户可以先简单浏览小程序
- 访问核心功能需要手机号登录
- 用户可以完善资料。
- 用户浏览推荐资料。
- 年费会员解锁详细资料和活动权益。
- 用户报名线下活动。
- 管理员能处理用户、活动、订单和会员状态。第 4 步：做原型图
继续前面的对话
接下来我们根据需求文档来生成原型图。等我们确定好全部的交互之后，我们再去把它实现成真正的小程序。
这里分成两步：
- 第一步是先让 AI 根据需求文档生成多种风格来供挑选。这一步让它生成核心的两三个页面找感觉就可以了。
- 第二步是让 AI 根据你选择的风格生成全部剩余的所有页面。
为了画原型图，我们首先需要安装一个 Skill。
npx skills add anthropics/skills --skill frontend-design
给 Codex 的第 1 段 prompt：生成几个风格供你选择。
基于已经确认的需求，现在先设计小程序 UI 原型，
项目背景：
- AI 会员小程序。
- 核心场景是会员、推荐资料、线下活动报名。
技术栈背景：
- Weapp-vite + TDesign Mini Program + Tailwind CSS。
要求：
- 每个页面都要画出来，不要只画首页。
- 页面状态要完整，包括未登录、非会员、会员、支付成功、报名成功。
- 原型用于确认结构和视觉方向，不代表最终代码要逐像素复刻。
- 不要为了好看堆装饰性边框、图标、阴影。给 Codex 的第 2 段 prompt：生成全部剩余的原型图（如果不符合预期再慢慢调整）
接下来你需要根据我选定的【你选择的风格】以及需求文档，实现全部必须的交互设计图，注意不要遗漏！
包括且不限于：手机号绑定、资料完善、活动报名成功、支付成功、运营管理。
第 5 步：转成真正的小程序
这一轮进入真正实现。我用了 Codex 的目标功能 “goal”。
把前面确认好的需求、页面、技术栈、CloudBase 环境 ID 和支付信息都给 Codex。
记得做两个设置：
- 切换到“完全访问权限”
- 切换到 /目标 模式
基于前几轮确认的需求和 HTML 原型，请你实现完整微信小程序，自动开发自动测试，直到所有功能都能正常运行，验收通过为止。
基础信息：
- 小程序 AppID：<填写你的 AppID>
- CloudBase 环境 ID：<填写你的 CloudBase 环境 ID>
- 微信支付商户号：<填写你的商户号；如果暂不接支付，写「暂不接入」>
- 是否需要微信支付：需要
- 技术栈：Weapp-vite + TDesign Mini Program + Tailwind CSS + CloudBase SQL 型数据库
- 项目类型：微信小程序
UI 实现要求：
1. 组件尽可能使用 TDesign Mini Program 或 Tailwind CSS，不要重复造基础组件。
2. UI 代码要高可维护，抽出可复用组件，不要写重复冗余代码，相同交互和样式要复用。
3. 保持 UI 组件一致性，按钮、卡片、表单、标签、底部导航不要每页一套风格。
4. 注意原型图中，为了演示效果，加上了一些虚拟的小程序边框和按钮，这些不应该出现在最终代码中。
5. 不要把内部开发说明、任务日志、调试备注、内部工程信息写进小程序 UI。
6. 小程序页面要像真实产品，不要出现「这是一个示例页面」「点击这里测试」这类临时文案。
使用 CloudBase SQL 型数据库。
云函数部署可以通过 `tcb fn deploy <functionName> --force --json` 的方式来部署
## 数据说明
最终生成的页面是需要真实可交互的。UI 原型图里头填充了一些假的数据，最终你应该在数据库中填充对应的数据，而不是直接写在代码当中。
## 微信支付接入说明
使用微信云开发接入微信支付，参考微信官方云开发支付文档。
- 本项目走 CloudBase/微信云开发云调用支付。云开发后台先绑定商户号，并授权 JSAPI；
- 小程序端只调用 payment 云函数，传订单类型和业务 ID。云函数用 cloud.getWXContext().OPENID 取当前用户 openid，从数据库读取真实金额，再调用 cloud.cloudPay.unifiedOrder，其中 subMchId=商户号、subAppid=小程序 AppID、subOpenid=当前用户 openid。返回 payment 后前端调用 wx.requestPayment(payment)；最终支付成功以 payCallback 云函数回调更新订单状态为准。真机支付和体验版
支付跑通后，用电脑端小程序调起支付时，需要手机扫码确认。
确认支付成功后，再上传体验版：
微信开发者工具 -> 上传
小程序后台 -> 管理 -> 版本管理 -> 选为体验版
体验版二维码可以发给朋友测试。体验成员需要在小程序后台配置，正式提审前还要补隐私协议、类目材料、支付说明和可能的 AI 相关材料。
这次踩到的坑
小程序前期准备比网站多很多
注册、认证、备案、类目、AppID、CloudBase、支付商户号、支付授权、服务端口、真机测试，这些都要人处理。
AI 可以帮你写步骤，但不能替你通过平台安全确认。
原型图转小程序要加约束
这次 Codex 在原型转小程序时花了不少时间做截图和修 UI。
后面再做，我会在 prompt 里提前写清楚：
- 优先用 TDesign 和 Tailwind。
- 复用组件，不要每页一套样式。
- 原型图只看结构和关键视觉，不要逐像素实现装饰元素。
- 页面要是真实产品状态，不要放假数据糊弄。
支付模式不能让 AI 猜
直连商户和服务商模式字段不同。报错里出现「受理关系不存在」这类信息时，要回到商户平台和 CloudBase 授权关系排查，不要只改前端参数。
MCP 不成功就换 CLI
这次云函数部署时，MCP 没有一次跑通，最后走 CloudBase CLI。
工具只是路径，目标是把函数部署上去、日志能看、支付能回调。
AI 还不能完全托管整个项目
这次主代码环节跑了七八个小时，消耗了不少额度。
最后登录、支付、页面大体可用，但 UI 细节、小 bug、真实运营流程仍然需要人收尾。
我觉得它已经很有潜力了。现在更像一个能长时间执行的工程助手，还不是完全自动交付团队。
如果你也想试，可以先从一个足够小的场景开始：会员报名、活动预约、本地服务、社群工具，都行。
先别把产品想太大。把一个核心动作跑通，比一上来做十几个页面更重要。
这篇文档有问题？