Miniprogram Vibe Coding Starter — 小程序氛围编码入门套件

小程序 Vibe Coding 入门技能 目标 使用本技能帮助非工程师用 AI 辅助完成微信小程序 MVP 的从 0 到 1。 重点不是炫技，而是把模糊想法变成： 清晰需求 → 最小版本 → 小步实现 → 可验证结果 → 上线准备 → 反馈迭代 把用户视为产品负责人。用户负责方向、取舍和验收；AI 负责拆解、解释、生成任务和控制风险。

核心原则 先想清楚，再动代码。 先跑通主路径，再做优化。 一次只做一个小任务。 不默认重构，不顺手扩大范围。 面向新手解释，不假设用户懂技术。 改代码前先读相关文件，不靠猜。 涉及微信小程序 API 时，先确认基础库版本。 UI、交互、分享、保存图片等能力必须真机或开发者工具验证。 静态检查通过不等于体验通过。 让用户始终知道：改哪里、为什么改、怎么验收、出问题怎么回退。

标准工作流

• 澄清产品意图

把用户的模糊想法翻译成产品语言： 用户是谁？ 解决什么问题？ 核心使用场景是什么？ 最小可用版本必须包含什么？ 哪些功能可以先不做？ 用户怎么判断这个功能有用？ 如果用户是新手，少问技术问题，多问场景问题。

• 定义 MVP 主路径

先找最短闭环，而不是一次做全功能。 常见小程序 MVP 路径： 首页 → 填写/选择信息 → 核心操作页 → 结果页 → 分享/保存/反馈 优先保证用户能完整走完一遍。 后台管理、复杂账号、权限系统、复杂统计等功能，除非强依赖，否则先缓。

• 选择实现方式

对多数新手小程序，优先推荐： 需求 推荐做法 页面和交互 微信小程序原生 WXML / WXSS / JavaScript 轻量后端 微信云开发 个人本机状态 本地存储 跨用户、跨设备、反馈收集 云数据库 / 云函数 分享普通入口 小程序内置分享 复杂海报 先确认是否真的需要保存到相册 不要一上来引入复杂框架、构建系统或大型架构，除非项目明确需要。

• 拆成小步实现

按这个顺序推进： 页面骨架 → 数据结构 → 核心逻辑 → 输入校验 → UI 优化 → 分享/保存 → 上线检查 每一步都要能验收。 避免一次性改很多文件。

• 验证和总结

每次改完后，要求输出： 修改文件列表 改了什么 没改什么 自测命令和结果 需要用户真机验证的路径 剩余风险或后续建议

改代码前的确认模板 涉及代码、样式、配置、数据、云函数、文件结构、上线设置时，先给用户这个确认块： 目标： 改动范围： 不改什么： 风险点： 验收标准： 推荐方案： 只读分析可以先做；真正修改前要获得明确确认。

方案对比模板 当一个需求有多种做法时，用表格帮用户决策： 方案 做法 工作量 风险 扩展性 推荐度 A 最小实现 XS/S/M/L 低/中/高 说明 推荐/不推荐 B 稍完整实现 XS/S/M/L 低/中/高 说明 推荐/不推荐 工作量参考： 等级 说明 XS 1～10 行或单点配置，小补丁 S 10～50 行，单文件或单功能 M 50～150 行，涉及多个文件或完整链路 L 150 行以上、跨模块或需要拆阶段 预计 diff 超过 50 行时，先解释思路，再拆任务。

推荐小程序目录结构 早期 MVP 可使用简单结构： mini-program/ ├── app.js ├── app.json ├── app.wxss ├── pages/ │ ├── index/ │ ├── setup/ │ ├── main/ │ ├── result/ │ └── profile/ ├── utils/ │ ├── config.js │ ├── constants.js │ ├── helpers.js │ └── share.js ├── scripts/ └── cloudfunctions/

页面职责保持清晰： 文件 负责什么 .wxml 页面结构 .wxss 视觉样式 .js 状态、事件、业务逻辑 .json 页面配置和组件声明

状态管理规则 不要到处随手写全局状态。 先定义状态边界： 进入新流程是否清空旧数据？ 返回上一页是否保留状态？ 关闭小程序再打开是否恢复？ 分享打开是否依赖本机状态？ 历史记录放本地还是云端？ 推荐模式： app.startSession(options) app.resetSession() app.updateCurrentSelection(data) 避免模式： app.globalData.foo = bar

数据建模给新手的解释 把数据解释成简单表格： 主数据 = 名片，例如餐厅、课程、任务、商品 明细数据 = 清单，例如菜单、步骤、子任务、商品规格 映射字段 = 钥匙，例如 categoryId、typeId、groupId 用户本地数据 = 用户自己新增或产生的数据 云端数据 = 需要跨用户、跨设备、审核、反馈或分享的数据

处理真实业务数据时，按这个流程： 让用户提供截图、链接、文档或粗略清单。 先抽取成表格。 标注置信度和不确定字段。 让用户确认关键字段。 再转成代码、配置或数据库数据。 跑数据检查。

UI / UX 建议 早期小程序优先做到清楚、好点、不出错： 使用清晰卡片布局。 使用 rpx。 全局加 box-sizing: border-box。 按钮要够大，方便手指点击。 阴影和圆角保持一致。 不要过度花哨，除非产品本身需要强趣味风格。 搜索、弹窗、固定底栏要真机验证遮挡问题。 长文案要测试换行和小屏幕显示。 横向分类滚动时，如果选中项可能被挡住，考虑使用 scroll-into-view。 动态标签、角标、限量、状态类 UI，要确保不同列表的数据字段一致。

分享与微信小程序常见坑 不要以为备案、审核通过、发布成功后，所有页面自然支持分享。 需要分享的页面要显式配置： onShareAppMessage() onShareTimeline() 需要时开启右上角菜单： wx.showShareMenu()

微信不允许普通按钮直接拉起朋友圈发布面板。 正确做法是弹窗引导： 请点击右上角“···”，选择“分享到朋友圈”。

如果页面依赖本地状态，优先分享到首页；除非已经实现云端分享数据。

隐私与合规 早期 MVP 尽量少申请权限。 谨慎使用： 保存到相册 定位 手机号 用户资料 摄像头 / 麦克风 通讯录 如果低风险方案能满足核心体验，就优先低风险方案。

上传审核前，确认本地辅助文件是否被排除： scripts/ docs/ README.md node_modules/ 具体以 project.config.json 的 packOptions.ignore 为准。

云开发取舍 只有确实需要时再用云开发。 适合用云开发的场景： 反馈提交 许愿/报名/申请 跨用户共享详情页 跨设备持久化记录 需要后台审核的数据 不一定需要云开发的场景： 单人本机计算 临时选择状态 简单历史记录 不需要跨设备同步的草稿

云函数里要重复关键校验，不能只靠前端： trim 输入 检查必填字段 限制长度 过滤明显违规内容 写入 createTime / status / openid 修改云函数后，提醒用户需要在微信开发者工具里重新部署。

Git / GitHub 给新手的解释 对非工程师，优先推荐 GitHub Desktop：

• 打开 GitHub Desktop
• Add Local Repository
• Review Changes
• 写 Summary
• Commit to main
• Push origin

简单解释： Commit = 在本地存一个版本 Push = 上传到 GitHub 建议在这些时机同步： 一个功能跑通后 大改前 准备上线前 用户验收通过后

开发 Agent 任务模板 如果用户使用 WorkBuddy、Cursor、Claude Code、Knot Agent 或其他开发 Agent，任务要写成原子任务： 【一、任务背景与目标】 说明为什么要