| name | vibe-coding-prd |
|---|---|
| description | 将用户需求、粗糙需求、工程版 PRD、竞品分析、笔记、飞书/Lark 文档链接，整理成可直接发给 Claude Code、Codex 或其他编码 Agent 的精简 Vibe Coding PRD。适用于用户说“帮我写一个用来vibe coding的PRD”、要求生成 coding-ready PRD、希望把杂乱产品资料转成实现说明，或需要在编码前先澄清需求的场景。 |
Vibe Coding PRD
使用本 skill，把杂乱的产品输入整理成一份精简、可编码、Markdown 格式的 PRD，供编码 Agent 使用。输出必须让 Claude Code/Codex 明确知道：要做什么、不做什么、用什么技术栈、有哪些页面/模块，以及如何验收。
硬性规则
- 当关键信息缺失时，不要推断用户真实意图。必须先让用户确认。
- 需要澄清时，优先使用简短选择题。在 Codex Plan 模式下使用
request_user_input；否则用简洁的文本问题询问。 - 所有“待确认内容”“待确认问题”“需用户确认”“未决事项”都必须用选项方式反馈给用户，不要只列开放式问题。每个问题应提供 2-4 个可选项，标出推荐项，并用一句话说明取舍；确实无法枚举时，才允许增加“其他：请补充”。
- 如果用户提供飞书/Lark 文档链接，必须使用飞书/Lark 文档 skill 或可用的 Lark 工具读取内容，再进行总结。
- 去掉编码 Agent 不需要的商业型 PRD 内容：市场背景、商业价值、组织关系、冗长用户调研、不可执行的战略表述。
- 最终 PRD 要精简、面向实现。避免产品黑话和模糊目标。
- 每个功能都必须包含明确的验收标准。不要使用“体验良好”“性能优秀”“页面美观”这类模糊表述。
- 如果用户还没有确认范围、优先级或原型方向，不要直接输出最终 PRD。先输出草案并要求确认。
- 最终交付物必须是一份完整的 Markdown PRD。
输入类型判断
设计 PRD 前，先判断用户输入属于哪一种：
明确需求
- 已经有目标用户、使用场景、痛点和期望产品结果。
- 可以进入功能设计，但最终定稿前仍要确认范围和优先级。
原始工程 PRD
- 看起来像给工程师看的正式 PRD，通常包含背景、目标、商业价值、指标、页面说明，或是飞书/Lark 链接。
- 只提取编码 Agent 需要的信息：用户、流程、模块、页面、数据、逻辑、边界情况、权限、依赖、验收标准。
- 移除商业价值、冗长市场背景、说服型内容和不影响实现的指标。
竞品分析
- 包含竞品案例、截图、功能对比或参考产品。
- 提取可复用的交互模式、功能点、页面结构和实现约束。
- 询问用户哪些竞品功能要照搬、改造或排除。
不清晰/信息不完整
- 缺少用户、场景、痛点、产品形态或目标。
- 设计前先提问澄清。尽量给 3-5 个选项。
澄清问题
当输入不清晰时，只问阻塞继续推进的问题。优先使用这类问题：
输出格式必须是选项题：
## 待确认内容
1. [问题名称]
- A. 选项内容（推荐）：选择后的影响/取舍
- B. 选项内容：选择后的影响/取舍
- C. 选项内容：选择后的影响/取舍
- 其他：请补充
规则：
- 优先给单选题；范围、功能取舍、技术栈可用多选题。
- 每个问题最多 4 个选项，避免让用户重新做长篇判断。
- 必须标注一个推荐选项，除非信息完全不足无法判断。
- 不要输出“请确认是否需要 xxx”这类开放句，改成“A 做 / B 不做 / C 后续做”。
产品形态：
- Web 应用
- 移动端应用
- 浏览器插件
- 内部工具/仪表盘
- AI Agent/工作流
目标用户：
- 内部运营
- 销售/客服
- 产品/市场
- C 端用户
- 其他指定用户
核心目标：
- 降低人工工作量
- 生成内容
- 分析数据
- 管理流程
- 训练/评估用户
MVP 深度：
- 只做演示 Demo
- 可用 MVP
- 偏生产级原型
技术约束：
- 最快实现
- UI 质量优先
- 后端成本最低
- AI 流程较重
- 本地运行/不要后端
工作流程
1. 读取并整理原始资料
- 阅读用户提供的文本、文件、链接、截图和 PRD。
- 对飞书/Lark 链接，如果已配置工具，则通过 Lark 工具读取文档内容；如果访问失败，要求用户导出或粘贴内容。
- 用 3-5 行总结来源资料：
- 要做什么产品
- 谁来使用
- 用在什么场景
- 解决什么问题
- 还缺什么输入
2. 确认需求定义
输出一段简短的需求定义：
## 1. 需求定义
- 目标用户：
- 使用场景：
- 核心痛点：
- 产品形态：
- 核心价值：
- MVP 目标：
如果任意一项未知，先询问用户，不要继续写最终 PRD。
3. 设计功能清单
功能清单必须包含：
- 一级模块
- 二级功能
- 功能描述
- 建议优先级
- MVP 还是后续版本
- 优先级理由
要求用户确认：
- 哪些功能必须做
- 哪些功能现在不做
- 哪些功能属于 MVP
- 是否有交付时间要求
优先级排序依据：
- 是否支撑主流程
- 是否能验证产品核心价值
- 是否能快速开发
- 是否能减少后续返工
- 是否依赖其他模块
4. 推荐技术栈
根据产品大小、复杂度、交付时间和用户技术水平推荐技术栈。
对每个主要模块，用通俗语言解释为什么这样实现：
## 3. 推荐技术栈
- 前端：
- 后端：
- 数据库：
- 登录鉴权：
- 文件存储：
- AI 模型/API：
- 向量数据库/RAG：
- 部署方式：
### 模块与技术映射
| 模块 | 建议实现方式 | 推荐理由 |
|---|---|---|
可使用以下默认建议：
- 小型 Web MVP：Next.js + Tailwind + shadcn/ui
- 简单后端：Next.js API routes 或 Supabase
- 登录/存储/数据库：Supabase
- AI 工作流：OpenAI/Anthropic 兼容 API；如果用户要求国内模型，则推荐国内模型
- RAG 原型：Supabase pgvector、Chroma 或厂商知识库
- 内部仪表盘：Next.js + 表格/表单组件
- 本地原型：Vite/React + 本地 JSON 状态
用直白语言说明取舍，不要过度设计。
5. 设计核心页面原型
只设计框架级原型，不做高保真 UI。
需要包含：
- 核心页面/界面
- 关键布局区域
- 主要按钮/操作
- 重要状态：空状态、加载中、成功、失败
- 页面之间如何跳转
最终定稿前，要求用户确认页面结构。
示例：
## 4. 原型结构
### 页面 1：仪表盘
- 左侧：
- 主区域：
- 操作：
- 空状态：
- 验收标准：
6. 编写详细功能模块
如果是 AI 产品，需要包含：
- Agent 工作流
- 提示词设计
- Tool/function calling 体系
- RAG/知识库设计，如适用
- 人工复核/兜底机制
- 模型输出格式
- 失败状态
如果是传统产品，需要包含：
- 数据模型
- API 行为
- UI 交互逻辑
- 权限
- 状态流转
- 边界情况
只写用户已确认范围内的内容。细节要足够编码使用，但不要写成汇报材料。
7. 定义验收标准
每个功能都要有可观察的具体验收标准。
好的写法：
- “点击
创建报告后，打开一个弹窗，包含报告标题、项目类型、参考文件字段。” - “如果上传失败，显示
上传失败，请重试，并保留该文件在上传列表中。” - “生成完成后，大纲以可编辑的多级章节形式展示。”
不好的写法：
- “体验流畅。”
- “模型输出质量高。”
- “页面用户友好。”
8. 最终输出
按以下结构输出完整 Markdown PRD：
# Vibe Coding PRD：[产品名称]
## 0. 来源类型与范围
- 来源类型：
- MVP 包含：
- 暂不包含：
- 已确认假设：
## 1. 需求定义
- 目标用户：
- 使用场景：
- 核心痛点：
- 产品形态：
- 核心价值：
- MVP 目标：
## 2. 用户流程
1. 写清用户从进入产品到完成核心目标的第一步。
2. 写清用户的关键操作和系统响应。
3. 写清用户最终看到的结果或产出。
## 3. 功能清单与优先级
| 模块 | 功能 | 描述 | 优先级 | 是否本期做 | 理由 |
|---|---|---|---|---|---|
| 示例：项目管理 | 示例：创建项目 | 示例：用户填写项目名称并创建一个新项目 | P0 | 是 | 示例：主流程入口，MVP 必须具备 |
## 4. 推荐技术栈
在这里填写前端、后端、数据库、AI 模型/API、文件存储、部署方式，以及每个选择的理由。
## 5. 原型结构
在这里填写核心页面、布局区域、主要按钮、空状态、加载状态、成功状态、失败状态和页面跳转关系。
## 6. 详细功能设计
在这里填写每个模块的输入、处理逻辑、输出、权限、状态流转和边界情况。
## 7. AI / Agent 设计
仅 AI 产品需要保留本节。填写 Agent 工作流、提示词、工具调用、RAG/知识库、人工复核和失败兜底。
## 8. 数据模型 / API 设计
只保留编码 Agent 需要的信息。填写核心数据表/字段、接口入参出参和关键业务规则。
## 9. 边界情况与兜底
在这里填写异常输入、空数据、接口失败、权限不足、AI 输出失败等情况的处理方式。
## 10. 验收标准
| 功能 | 验收标准 |
|---|---|
| 示例：创建项目 | 示例：点击“创建项目”后出现表单；填写项目名称并提交后，项目出现在列表第一行 |
## 11. 编码 Agent 执行说明
- 开发顺序：
- 不要开发：
- 重要约束：
- 最终验证：
## 12. 待确认内容
> 只列阻塞开发或会明显影响实现方向的问题。必须使用选项题，不要只列开放式问题。
1. 示例：登录方式选择
- A. 企业 SSO（推荐）：符合内部系统权限要求，但需要对接企业身份系统
- B. 账号密码：开发最快，但不适合正式企业环境
- C. 暂不做登录：只适合本地 Demo
质量检查
最终输出前检查：
- 编码 Agent 是否不用再追问“这个产品是什么”就能开始实现？
- MVP 和非 MVP 功能是否明确分开？
- 每个功能是否都有可观察的验收标准？
- AI 工作流是否具体到可以实现？
- 是否反映了用户确认结果，而不是擅自假设？
- 所有待确认内容是否都改成了选项题，并标出了推荐项？
- PRD 是否足够精简，能直接粘贴给 Claude Code/Codex？