| name | vibe-coding-guide |
| description | Use when a user wants to start vibe coding a product but isn't sure how to ask AI the right questions. Guides the user through structured product discovery questions, then generates four output documents: core feature design, user interaction flow, technical architecture, and data storage design. |
| version | 1.0.0 |
| author | Hermes Agent |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"hermes":{"tags":["vibe-coding","product-discovery","architecture","design","onboarding"],"related_skills":["writing-plans"]}} |
Vibe Coding 产品发现指南
概述
这个 Skill 帮助不熟悉 vibe coding 的用户，通过结构化的提问引导他们理清产品思路。AI 会先问几个关键问题来了解产品，然后自动生成四份文档，帮用户从「有个想法」走到「知道怎么让 AI 写代码」。
核心流程：提问 → 理解 → 生成四份文档。
何时使用
- 用户说「我想做一个 App，但不知道怎么跟 AI 描述」
- 用户有一个模糊的产品想法，需要梳理清楚再动手
- 用户想了解 vibe coding 的产品发现流程
- 用户在做分享/教学，演示如何从零开始用 AI 做产品
不要用于：
- 用户已经有了详细 PRD，只是想执行 —— 直接用 writing-plans
- 纯技术调研（无产品层面需求）
工作流程
第一阶段：产品发现提问
在生成任何文档之前，先向用户提出以下问题（一次最多问 2-3 个，分批进行）：
第一轮：产品定位（必问）
- 你要解决什么问题？ — 用户的核心痛点是什么？谁有这个痛点？
- 你的产品叫什么名字？ — 给产品一个临时名称，方便后续引用。
- 目标用户是谁？ — 谁会使用这个产品？他们的技术水平和场景是什么？
第二轮：核心功能（必问）
- 用户用你的产品完成什么任务？ — 描述 1-3 个核心使用场景。
- 有没有竞品？ — 如果有，你的产品有什么不同？如果没有，为什么之前没人做？
- 产品运行在什么平台上？ — Web、iOS、Android、小程序、桌面端？
第三轮：技术偏好（可选，有默认值）
- 有技术栈偏好吗？ — 如果没有偏好，AI 会根据场景推荐最合适的。
- 需要用户账号系统吗？ — 是否需要注册/登录/权限管理？
- 数据需要实时同步还是可以本地存储？ — 影响架构选型。
提问策略
- 每轮只问 2-3 个问题，等用户回答后再继续。
- 用友好的语气提问，避免技术术语（除非用户表现出来是技术人员）。
- 如果用户的回答模糊，追问具体细节，但不要一次性追问太多。
- 用户不需要回答所有问题——根据产品复杂度灵活调整。
第二阶段：生成四份文档
收集到足够信息后，生成以下四份文档。每份文档放在独立文件中。
(a) 产品核心功能设计
文件名：<产品名>-核心功能设计.md
内容要点：
- 产品定位：一句话描述产品是什么
- 目标用户画像：主要用户群体及其特征
- 核心功能列表：按优先级排列（P0/P1/P2）
- 差异化特性：与竞品相比的独特优势
- MVP 范围：第一版必须包含的功能
- 未来迭代方向：后续版本可扩展的功能
(b) 用户核心交互流程
文件名：<产品名>-用户交互流程.md
内容要点：
- 用户旅程地图：从首次接触到完成核心任务的完整流程
- 关键页面/界面清单：列出所有需要的页面
- 核心交互流程图：用 ASCII 或文本描述主要操作路径
- 异常状态处理：空状态、加载中、错误状态、边界情况
- 用户反馈机制：操作确认、错误提示、成功反馈
(c) 技术实现架构
文件名：<产品名>-技术架构.md
内容要点：
- 整体架构图：用 ASCII art 绘制系统架构
- 前端架构：
- 框架选型（React/Vue/Flutter 等）
- 组件树概览
- 状态管理方案
- 路由设计
- 后端架构（如适用）：
- API 设计（RESTful/GraphQL）
- 服务分层（Controller → Service → Repository）
- 中间件/拦截器
- 关键技术决策：为什么选这个技术栈
- 第三方服务集成：需要哪些外部 API/服务
- 部署方案：托管平台、CI/CD 流程
(d) 数据存储架构设计
文件名：<产品名>-数据存储设计.md
内容要点：
- 数据模型总览：列出所有数据实体及其关系
- 详细数据模型：每个实体的字段定义（名称、类型、必填、说明）
- 数据关系图：实体之间的关系（一对多、多对多等）
- 存储方案选择：
- 主数据库选型（PostgreSQL/MySQL/MongoDB/SQLite 等）
- 缓存方案（如需要）
- 文件/对象存储（如图片、附件）
- 索引策略：高频查询的索引设计
- 数据安全：敏感字段加密、备份策略
- 迁移策略：数据库版本管理方案
第三阶段：交付与后续
- 将四份文档保存到用户指定的目录（默认：当前工作目录下的
docs/ 或桌面）。
- 给用户一个简洁的总结：四份文档分别是什么、它们的用途、建议的阅读顺序。
- 提供后续步骤建议：
- 如果想继续：可以用
writing-plans Skill 把 (a) 和 (b) 转成可执行的开发计划
- 如果想调整：随时告诉 AI 哪部分需要修改
- 如果准备好了：告诉 AI 你的技术栈偏好，开始写第一行代码
示例对话流程
用户: 我想做一个记账 App
AI: 好想法！先聊几个问题帮我们理清思路：
1. 你这个记账 App 主要给谁用？是个人记账还是家庭/小团队共享？
2. 你觉得现有记账 App 有什么让你不满意的地方？
用户: 个人用。现有 App 太复杂了，我就想快速记一笔，不需要分类预算那些。
AI: 明白了，核心理念是「极简记录」。再问两个：
1. 你希望怎么输入——手动打字、语音、还是拍照识别账单？
2. 数据你希望只在手机上存着，还是可以云端同步？
用户: 手动打字就行，但要快。先本地存着吧。
AI: 够了。我现在帮你生成四份文档：
- 核心功能设计（极简记账 App 的功能范围）
- 用户交互流程（极致简化的操作路径）
- 技术架构（适合本地存储的技术方案）
- 数据存储设计（轻量级的交易记录模型）
开始生成...
常见陷阱
-
提问太多太密：一次性丢 5+ 个问题会吓跑用户。每轮 2-3 个，分批进行。
-
跳过「为什么」直接进入「怎么做」：如果没有理解用户的核心痛点，生成的设计会偏离方向。第一阶段的目标是理解动机。
-
生成内容过于技术化：如果用户是产品经理或非技术人员，避免出现 PostgreSQL、Kubernetes 等术语。用「数据库」、「部署平台」等通俗表达，在附录中给出技术建议。
-
假设用户知道所有答案：有些问题用户没想清楚很正常。提供一个合理默认值并解释为什么，让用户可以选择接受或修改。
-
文档过长：每份文档控制在可阅读的长度内。目标是清晰有用，不是详尽无遗。MVP 优先。
-
忘记平台差异：Web App、移动 App、小程序的交互模式和技术架构完全不同。第一阶段就要确认平台。
验证清单
