---
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 = 上传云端
```

不要为了显得专业而使用抽象词。重点是让用户能继续推进项目。