| name | vibe-coding-prd |
|---|---|
| description | 创建一份精简的 Vibe Coding PRD，可直接交给 Claude Code、Codex 或其他编码 Agent 使用。当用户说“帮我写一个用来vibe coding的PRD”，或希望把需求、原始 PRD、竞品分析、想法、笔记、截图、文档、杂乱产品输入整理成可实现的 PRD，或需要在写 Agent 友好型 PRD 前进行需求澄清时使用。 |
Vibe Coding PRD
目标
将需求笔记、原始 PRD、竞品分析或模糊的产品想法，整理成一份面向编码 Agent 的精简 Markdown PRD。重点是实现清晰，而不是商业叙事。
不要替用户猜测真实需求。当关键产品决策不清楚时，先让用户用简短选项确认，再继续。如果 request_user_input 可用，优先用它发起确认；否则在对话中提出简洁的选择题。
工作流
1. 判断输入类型
在撰写 PRD 前，先判断用户提供的材料类型：
- 明确需求：能识别出用户、场景、痛点和期望的产品结果。继续进入功能设计。
- 原始 PRD：面向工程师或干系人的文档，混有商业、运营和技术细节。只提取编码 Agent 需要知道的信息；去除市场规模、商业价值、内部博弈、宏观战略和重复背景。
- 竞品分析：描述参考产品、功能对比、流程、截图、优缺点。将观察转化为用户需求、目标行为、候选功能和差异化点。询问哪些参考要复制、改造或避免。
- 其他或不清晰输入：想法、片段、口号、会议记录或模糊请求。用选择题引导用户说出真实需求。
如果输入不清晰，每次最多问三个问题。优先使用类似选项：
- 目标用户：
个人用户 / 团队成员 / 管理者 / 客户 / 运营人员 / 其他 - 产品形态：
网页应用 / 移动端 / 浏览器插件 / 桌面工具 / 自动化脚本 / AI Agent / 其他 - 核心价值：
提升效率 / 生成内容 / 管理数据 / 协作审批 / 分析决策 / 降低错误 / 其他
在用户至少确认目标用户、核心场景、要解决的问题和产品形态前，不要进入完整 PRD 输出。
2. 定义需求
需求清晰后，先总结并请用户确认：
- 给谁用：目标用户和角色。
- 在什么场景用：用户何时、何地、为什么使用。
- 解决什么问题：痛点或要完成的任务。
- 产品形态：应用、工具、AI Agent、工作流、插件、看板等。
- 成功结果：产品可用后，用户或业务会发生什么具体变化。
使用直白语言。避免只写“提升用户体验”这类抽象表达，除非同时给出具体行为。
3. 设计功能模块
先草拟功能清单，包含：
- 一级模块。
- 二级功能。
- 功能描述。
- 用户价值。
- 建议优先级：
MVP、V1、Later或Do not build。 - 依赖关系或优先级理由。
然后询问用户确认哪些现在做、哪些以后做、哪些不做。判断 MVP 优先级时询问：
- 哪些功能是产品可用的必要条件？
- 哪些功能第一版可以人工处理、模拟实现或暂时跳过？
- 哪些功能依赖其他功能？
- 哪些功能交付风险最高？
在用户确认前，不要最终锁定功能范围。
4. 推荐技术栈
为非技术用户推荐技术实现方案。根据产品大小、复杂度、上线时限、用户规模、数据敏感度、AI 能力需求和部署需求判断。
对每个主要模块说明：
- 推荐实现方式。
- 为什么适合。
- 复杂度：低、中或高。
- 用简单语言说明取舍。
给出一个默认推荐方案。除非选项会明显影响开发时间、成本、可维护性或能力边界，不要罗列过多等价方案。
推荐示例：
- 小型网页工具：
Next.js + Supabase + Vercel，因为登录、数据库和部署都容易快速完成。 - 内部管理看板：
React 管理端 UI + 托管数据库 + 角色权限，因为高频数据操作比视觉包装更重要。 - AI 产品：
网页应用 + API 后端 + 大模型服务 + tool calling + 持久化任务存储，因为只靠提示词很难支撑稳定可复用的工作流。 - 自动化脚本：先做
Python 脚本或 CLI，因为可以先验证工作流，再决定是否做完整 UI。
5. 设计框架版原型
在最终 PRD 前，先为核心界面创建框架级原型说明：
- 页面名称。
- 主要布局区域。
- 关键控件。
- 主要用户路径。
- 必要时补充空状态、加载状态和错误状态。
简单产品可使用文本线框图或 Mermaid 流程图。较复杂产品先定义主页面和导航结构。
在写详细功能规格前，先让用户确认页面结构。
6. 撰写明细功能设计
根据产品类型选择明细设计方式。
如果是 AI 产品，包含：
- Agent 工作流：触发、输入、规划、工具调用、生成、审核、输出、重试或兜底。
- 提示词设计：系统角色、用户输入结构、约束、输出格式，必要时包含示例。
- Tool 体系：工具名称、用途、输入、输出、失败处理、权限要求。
- 记忆与数据：存储什么、不存储什么，以及必要的留存和隐私说明。
- 人工确认节点：Agent 在哪些决策前必须询问用户。
如果是传统产品，包含：
- 数据模型或主要实体。
- 页面或模块行为。
- 权限和角色。
- API 或集成需求。
- 状态变化和边界情况。
- 错误处理。
技术细节应服务于编码 Agent 实现。不要加入装饰性的商业语言。
7. 定义验收标准
每个功能都必须有具体的验收标准。使用可观察的行为：
- 好：
点击“新建项目”后打开创建弹窗；填写名称并提交后，项目出现在列表第一行。 - 好：
当输入为空时，提交按钮置灰，并显示“请输入需求内容”。 - 差：
体验良好。 - 差：
系统智能地完成分析。
只有在 Given/When/Then 能让标准更清晰时才使用它。否则使用简短编号检查项。
8. 输出最终 Markdown PRD
完成必要确认后，输出一份完整 Markdown 文档。保持精简，并且可以直接用于实现。
使用以下结构：
# [产品/功能名] Vibe Coding PRD
## 1. 背景输入类型
- 输入类型：[明确需求 / 原始PRD / 竞品分析 / 其他]
- 已确认信息：[简述]
- 已排除内容：[商业价值、市场背景等不进入开发的信息]
## 2. 需求定义
- 目标用户：
- 使用场景：
- 要解决的问题：
- 产品形态：
- 成功结果：
## 3. MVP 范围
| 优先级 | 一级模块 | 二级功能 | 功能描述 | 为什么现在做 |
|---|---|---|---|---|
## 4. 暂不做 / 后续做
| 功能 | 处理方式 | 原因 |
|---|---|---|
## 5. 技术栈建议
| 模块 | 推荐实现 | 复杂度 | 说明 |
|---|---|---|---|
## 6. 核心界面原型（框架版）
### 页面/流程 A
- 布局：
- 控件：
- 主路径：
- 状态：
## 7. 明细功能设计
### 模块 A
- 功能说明：
- 输入：
- 处理逻辑：
- 输出：
- 边界情况：
- 权限/数据：
## 8. AI Agent / 提示词 / Tool 设计（如适用）
### Agent 工作流
### Prompt 设计
### Tool 体系
## 9. 验收标准
### 功能 A
1. ...
2. ...
## 10. 给编码 Agent 的实现备注
- 先实现：
- 可 mock：
- 注意事项：
可以删除不适用的章节，但不要省略 MVP 范围、技术栈建议、明细功能和验收标准。
交互规则
- 在做不可逆的范围决策前，先询问用户。
- 尽量使用选择题进行确认。
- 如果用户要求“直接写”，仍然先给出简短假设，并标记需要确认。
- 优先使用紧凑表格，而不是长段落。
- 除非用户要求其他语言，否则使用中文。
- 最终 PRD 应让 Claude Code、Codex 或类似编码 Agent 在没有额外商业背景的情况下也能看懂。