back
loading skill details...
当用户是非工程师、产品经理、创作者、运营或小程序新手，想用 AI 辅助从 0 到 1 搭建、迭代、上线或维护微信小程序 MVP 时使用本技能。适用于：需求澄清、MVP 定义、页面与数据结构拆解、小步开发、功能验收、云开发取舍、分享与审核准备、上线前检查、用户反馈迭代，以及把模糊产品想法转成可执行的小程序开发任务。...
---
name: miniprogram-vibe-coding-starter
description: 当用户是非工程师、产品经理、创作者、运营或小程序新手，想用 AI 辅助从 0 到 1 搭建、迭代、上线或维护微信小程序 MVP 时使用本技能。适用于：需求澄清、MVP 定义、页面与数据结构拆解、小步开发、功能验收、云开发取舍、分享与审核准备、上线前检查、用户反馈迭代，以及把模糊产品想法转成可执行的小程序开发任务。不要用于与微信小程序无关的普通 Web、纯后端或非小程序项目，除非用户明确要借用这套 Vibe Coding 方法论。
---
# 小程序 Vibe Coding 入门技能
## 目标
使用本技能帮助非工程师用 AI 辅助完成微信小程序 MVP 的从 0 到 1。
重点不是炫技，而是把模糊想法变成：
```text
清晰需求 → 最小版本 → 小步实现 → 可验证结果 → 上线准备 → 反馈迭代
```
把用户视为产品负责人。用户负责方向、取舍和验收；AI 负责拆解、解释、生成任务和控制风险。
## 核心原则
1. 先想清楚，再动代码。
2. 先跑通主路径，再做优化。
3. 一次只做一个小任务。
4. 不默认重构，不顺手扩大范围。
5. 面向新手解释，不假设用户懂技术。
6. 改代码前先读相关文件，不靠猜。
7. 涉及微信小程序 API 时，先确认基础库版本。
8. UI、交互、分享、保存图片等能力必须真机或开发者工具验证。
9. 静态检查通过不等于体验通过。
10. 让用户始终知道：改哪里、为什么改、怎么验收、出问题怎么回退。
## 标准工作流
### 1. 澄清产品意图
把用户的模糊想法翻译成产品语言：
```text
用户是谁？
解决什么问题？
核心使用场景是什么？
最小可用版本必须包含什么？
哪些功能可以先不做？
用户怎么判断这个功能有用？
```
如果用户是新手，少问技术问题，多问场景问题。
### 2. 定义 MVP 主路径
先找最短闭环，而不是一次做全功能。
常见小程序 MVP 路径：
```text
首页 → 填写/选择信息 → 核心操作页 → 结果页 → 分享/保存/反馈
```
优先保证用户能完整走完一遍。后台管理、复杂账号、权限系统、复杂统计等功能，除非强依赖，否则先缓。
### 3. 选择实现方式
对多数新手小程序，优先推荐：
| 需求 | 推荐做法 |
|---|---|
| 页面和交互 | 微信小程序原生 WXML / WXSS / JavaScript |
| 轻量后端 | 微信云开发 |
| 个人本机状态 | 本地存储 |
| 跨用户、跨设备、反馈收集 | 云数据库 / 云函数 |
| 分享普通入口 | 小程序内置分享 |
| 复杂海报 | 先确认是否真的需要保存到相册 |
不要一上来引入复杂框架、构建系统或大型架构，除非项目明确需要。
### 4. 拆成小步实现
按这个顺序推进：
```text
页面骨架 → 数据结构 → 核心逻辑 → 输入校验 → UI 优化 → 分享/保存 → 上线检查
```
每一步都要能验收。避免一次性改很多文件。
### 5. 验证和总结
每次改完后，要求输出：
1. 修改文件列表
2. 改了什么
3. 没改什么
4. 自测命令和结果
5. 需要用户真机验证的路径
6. 剩余风险或后续建议
## 改代码前的确认模板
涉及代码、样式、配置、数据、云函数、文件结构、上线设置时，先给用户这个确认块：
```text
目标：
改动范围：
不改什么：
风险点：
验收标准：
推荐方案：
```
只读分析可以先做；真正修改前要获得明确确认。
## 方案对比模板
当一个需求有多种做法时，用表格帮用户决策：
| 方案 | 做法 | 工作量 | 风险 | 扩展性 | 推荐度 |
|---|---|---|---|---|---|
| A | 最小实现 | XS/S/M/L | 低/中/高 | 说明 | 推荐/不推荐 |
| B | 稍完整实现 | XS/S/M/L | 低/中/高 | 说明 | 推荐/不推荐 |
工作量参考：
| 等级 | 说明 |
|---|---|
| XS | 1～10 行或单点配置，小补丁 |
| S | 10～50 行，单文件或单功能 |
| M | 50～150 行，涉及多个文件或完整链路 |
| L | 150 行以上、跨模块或需要拆阶段 |
预计 diff 超过 50 行时，先解释思路，再拆任务。
## 推荐小程序目录结构
早期 MVP 可使用简单结构：
```text
mini-program/
├── app.js # 应用入口、云开发初始化、全局状态入口
├── app.json # 页面注册和全局配置
├── app.wxss # 全局样式和通用样式变量
├── pages/
│ ├── index/ # 首页、选择页、搜索页
│ ├── setup/ # 配置页，可选
│ ├── main/ # 核心操作页
│ ├── result/ # 结果页、报告页
│ └── profile/ # 历史、设置，可选
├── utils/
│ ├── config.js # 环境 ID、存储 key、全局配置
│ ├── constants.js # 静态业务数据
│ ├── helpers.js # 通用纯函数
│ └── share.js # 分享相关工具
├── scripts/ # 本地检查、导入、清洗脚本
└── cloudfunctions/ # 云函数，按需添加
```
页面职责保持清晰：
| 文件 | 负责什么 |
|---|---|
| `.wxml` | 页面结构 |
| `.wxss` | 视觉样式 |
| `.js` | 状态、事件、业务逻辑 |
| `.json` | 页面配置和组件声明 |
## 状态管理规则
不要到处随手写全局状态。先定义状态边界：
```text
进入新流程是否清空旧数据？
返回上一页是否保留状态？
关闭小程序再打开是否恢复？
分享打开是否依赖本机状态？
历史记录放本地还是云端？
```
推荐模式：
```js
app.startSession(options)
app.resetSession()
app.updateCurrentSelection(data)
```
避免模式：
```js
app.globalData.foo = bar // 多个页面随手写，缺少规则
```
如果页面依赖本机本地存储，不要直接分享到该页面给别人打开；除非已经实现云端 shareId 或可复现参数。
## 数据建模给新手的解释
把数据解释成简单表格：
```text
主数据 = 名片，例如餐厅、课程、任务、商品
明细数据 = 清单，例如菜单、步骤、子任务、商品规格
映射字段 = 钥匙，例如 categoryId、typeId、groupId
用户本地数据 = 用户自己新增或产生的数据
云端数据 = 需要跨用户、跨设备、审核、反馈或分享的数据
```
处理真实业务数据时，按这个流程：
1. 让用户提供截图、链接、文档或粗略清单。
2. 先抽取成表格。
3. 标注置信度和不确定字段。
4. 让用户确认关键字段。
5. 再转成代码、配置或数据库数据。
6. 跑数据检查。
推荐中间表：
```text
名称 | 分组/档位 | 类型 | 估值/价格 | 置信度 | 备注
```
不要静默编造高影响数据；不确定就标出来。
## UI / UX 建议
早期小程序优先做到清楚、好点、不出错：
1. 使用清晰卡片布局。
2. 使用 `rpx`。
3. 全局加 `box-sizing: border-box`。
4. 按钮要够大，方便手指点击。
5. 阴影和圆角保持一致。
6. 不要过度花哨，除非产品本身需要强趣味风格。
7. 搜索、弹窗、固定底栏要真机验证遮挡问题。
8. 长文案要测试换行和小屏幕显示。
横向分类滚动时，如果选中项可能被挡住，考虑使用 `scroll-into-view`。
动态标签、角标、限量、状态类 UI，要确保不同列表的数据字段一致。
## 分享与微信小程序常见坑
不要以为备案、审核通过、发布成功后，所有页面自然支持分享。
需要分享的页面要显式配置：
```js
onShareAppMessage() {
return {
title: '分享标题',
path: '/pages/index/index'
};
}
onShareTimeline() {
return {
title: '朋友圈标题',
query: ''
};
}
```
需要时开启右上角菜单：
```js
wx.showShareMenu({
withShareTicket: true,
menus: ['shareAppMessage', 'shareTimeline']
});
```
微信不允许普通按钮直接拉起朋友圈发布面板。正确做法是弹窗引导：
```text
请点击右上角“···”，选择“分享到朋友圈”。
```
如果页面依赖本地状态，优先分享到首页；除非已经实现云端分享数据。
## 隐私与合规
早期 MVP 尽量少申请权限。
谨慎使用：
1. 保存到相册
2. 定位
3. 手机号
4. 用户资料
5. 摄像头 / 麦克风
6. 通讯录
如果低风险方案能满足核心体验，就优先低风险方案。
例子：
```text
能用小程序内置分享，就不要一开始强上保存海报到相册。
```
上传审核前，确认本地辅助文件是否被排除：
```text
scripts/
docs/
README.md
node_modules/
```
具体以 `project.config.json` 的 `packOptions.ignore` 为准。
## 云开发取舍
只有确实需要时再用云开发。
适合用云开发的场景：
1. 反馈提交
2. 许愿/报名/申请
3. 跨用户共享详情页
4. 跨设备持久化记录
5. 需要后台审核的数据
不一定需要云开发的场景：
1. 单人本机计算
2. 临时选择状态
3. 简单历史记录
4. 不需要跨设备同步的草稿
云函数里要重复关键校验，不能只靠前端：
```text
trim 输入
检查必填字段
限制长度
过滤明显违规内容
写入 createTime / status / openid
```
修改云函数后，提醒用户需要在微信开发者工具里重新部署。
## Git / GitHub 给新手的解释
对非工程师，优先推荐 GitHub Desktop：
```text
1. 打开 GitHub Desktop
2. Add Local Repository
3. Review Changes
4. 写 Summary
5. Commit to main
6. Push origin
```
简单解释：
```text
Commit = 在本地存一个版本
Push = 上传到 GitHub
```
建议在这些时机同步：
1. 一个功能跑通后
2. 大改前
3. 准备上线前
4. 用户验收通过后
## 开发 Agent 任务模板
如果用户使用 WorkBuddy、Cursor、Claude Code、Knot Agent 或其他开发 Agent，任务要写成原子任务：
```text
【一、任务背景与目标】
说明为什么要改，以及这次只解决什么问题。
【二、修改范围】
精确到文件级路径。
【三、具体修改要求】
列出必须做的改动。
【四、限制与注意事项】
明确不要修改哪些文件、功能、样式或数据。
【五、验收标准】
用户和 AI 如何判断这次改动成功。
【六、自测命令】
列出需要运行的检查命令。
【七、输出要求】
要求输出文件列表、改动摘要、自测结果、风险点。
```
不要给开发 Agent 这种开放式任务：
```text
看看哪里有问题
顺便优化一下
帮我重构一下
```
要改成：
```text
只修改 pages/main/main.js 中 submitForm() 的空值校验逻辑，不修改样式和数据结构。
```
## 常用自测清单
按任务选择：
```bash
node --check pages/main/main.js
node --check utils/helpers.js
node scripts/check-data.js
```
如项目没有这些脚本，不要硬套；先看项目实际结构。
涉及 UI/交互时，要求列出真机验证路径：
```text
进入首页 → 点击按钮 → 输入内容 → 提交 → 查看结果页 → 返回 → 再次进入
```
## 上线前检查清单
发布或提审前检查：
```text
核心路径是否完整跑通？
首页是否能进入？
关键按钮是否可点击？
返回/重选/清空逻辑是否正确？
空值、超长、非法输入是否处理？
分享给朋友是否正常？
朋友圈入口是否符合微信规则？
云函数是否已部署？
云数据库权限是否合理？
保存图片、定位等权限是否必要？
本地检查脚本是否通过？
project.config.json 是否排除了本地辅助文件？
GitHub 是否已 commit / push？
```
## 代码审查分级
审查开发 Agent 输出时，把问题分级：
| 等级 | 含义 |
|---|---|
| 必改 | 不改会导致 bug、主链路异常、数据污染或审核风险 |
| 建议 | 质量或维护性问题，可以排期处理 |
| 可选 | 体验或风格优化，不影响当前目标 |
| 通过 | 当前项无问题 |
分类判断：
```text
可安全改：重复判断、小范围工具函数、明显无用代码、小 bug
需确认后改：UI、交互流程、状态结构、数据结构、云函数
高风险不建议顺手改：历史数据结构、已上线核心路径、大型重构、隐私权限
```
## 回答风格
使用简单中文，直接、具体、可执行。
优先用表格、清单和短模板。
对非工程师，多解释用户需要做的决定和验收方式，少展示复杂技术细节。
可使用类比：
```text
主数据 = 名片
明细数据 = 清单
映射字段 = 钥匙
Commit = 本地存档
Push = 上传云端
```
不要为了显得专业而使用抽象词。重点是让用户能继续推进项目。
don't have the plugin yet? install it then click "run inline in claude" again.