vibe-coding-prd git:20260702.5be0cf2A

Immutable. This exact content is served forever at /api/v1/blob/287e213d39796d96.

---
name: vibe-coding-prd
description: "把需求、原始 PRD、竞品分析、零散笔记或模糊产品想法提炼成可直接发给 Claude Code、Codex 或其他编码 Agent 的精简中文 Markdown PRD。触发：用户说“帮我写一个用来vibe coding的PRD”、要求整理 coding-agent-ready PRD/spec/prompt，或希望从业务/产品材料中抽取实现所需信息。"
---

# Vibe Coding PRD

## 目标

把用户提供的需求、原始 PRD、竞品分析或零散想法，整理成一份能直接交给 Claude Code、Codex 或其他编码 Agent 执行的中文 Vibe Coding PRD。

## 核心规则

- 不要默默推断用户想要什么。目标用户、场景、痛点、产品形态、范围、优先级或技术方向不清楚时，先确认再写。
- 优先用弹框或选择题确认。若当前环境有 `request_user_input` 或等价弹框工具，用 1-3 个简短选择题引导；若没有，就在聊天里给选择题并等待用户回答。
- 把用户当作技术小白解释技术栈，用白话说明为什么推荐、适用哪些功能、风险是什么、有没有更简单替代方案。
- PRD 保持精简，只保留编码 Agent 需要知道的信息；删除商业价值、市场规模、战略背景、空泛黑话和重复说明。
- 最终 PRD 之前必须完成并确认：输入分类、需求定义、功能范围/优先级、技术栈方向、核心原型图。
- 验收标准必须可观察、可执行，不写“体验良好”“效果准确”“速度快”这类主观表述。

## 工作流程

### 1. 判断用户输入类型

把用户材料归为一种主类型，并用一句话告诉用户：

- **明确需求**：已经有清晰用户、场景、痛点和期望结果。进入需求清晰度确认。
- **原始 PRD**：像给工程师或产品团队看的正式文档。抽取编码 Agent 需要的信息：产品目标、用户、流程、页面、功能、数据字段、权限、约束、边界情况、验收标准；删除商业价值、市场背景、公司战略、重复背景和实现无关描述。
- **竞品分析**：主要分析其他产品。抽取可复用功能、交互方式、内容/数据结构、可改进点和差异化方向；询问用户要复刻、改进、融合多个竞品能力，还是做差异化版本。
- **不清晰或其他**：缺少明确用户、场景、痛点或目标。不要直接写 PRD，先用选择题引导用户说出真实需求。

如果分类不确定，先让用户确认。

### 2. 需求清晰度确认

正式设计前，确认这些字段：

- 给谁用？
- 在什么场景用？
- 解决什么问题？
- 产品形态是什么？例如 Web 应用、Chrome 插件、移动 App、桌面工具、飞书应用、命令行工具、自动化脚本、AI Agent。
- 希望做到什么程度？例如只做 MVP、先做可用 Demo、做成可上线产品。

缺字段时，一次最多问 1-3 个选择题。示例：

```text
我先确认一下真实需求，选最接近的即可：
1. 给自己用的效率工具
2. 给团队/客户用的业务系统
3. 复刻或改造某个竞品功能
```

只有用户确认后才继续。若用户明确要求“先按你的假设写”，可以继续，但必须在 PRD 的“假设/开放问题”里标注。

### 3. 输出需求定义并确认

先写一段简短需求定义，包含：

- 产品名称或暂定名称
- 目标用户
- 使用场景
- 要解决的问题
- 产品形态
- MVP 目标，一句话说明

写完后让用户确认。用户确认后再进入功能清单。

### 4. 设计功能清单和优先级

输出功能表，字段必须包含：

- 一级模块
- 二级模块
- 功能描述
- 建议优先级：P0 MVP、P1 下一版、P2 以后做、暂不做
- 建议时间：现在做、下一轮做、以后做
- 为什么这个优先级适合当前 MVP

然后询问用户：哪些做、哪些不做、哪些推迟、优先级是否调整。

优先级排序原则：

- 优先保证主流程跑通。
- 优先做能验证核心价值的功能。
- 优先做实现成本低但体验收益高的功能。
- 暂缓复杂、非必要、装饰性或重运营功能。

### 5. 推荐技术栈

根据产品形态、产品大小、复杂度、数据复杂度、AI/tool 调用需求、登录权限、上线时间、本地自用或生产上线要求推荐技术栈。

技术栈表格包含：

- 产品层或功能
- 推荐技术
- 为什么适合
- 更简单的替代方案
- 风险或成本

如果是 AI 产品，补充模型/API 选择建议、Agent 是否需要工具调用、是否需要记忆或数据库、是否需要人工确认节点。涉及最新模型、API 或框架版本时，先查官方文档；无法查证时标注“待确认”，不要凭记忆写死。

写完技术栈建议后，让用户确认方向。

### 6. 设计核心原型图（框架版）

为核心主功能界面设计低保真原型。不要做营销页，不写装饰性描述，只设计用户真正操作的界面。

每个核心页面包含：

- 页面目的
- 主要区域
- 主要操作按钮
- 输入区域
- 输出区域
- 空状态
- 加载状态
- 错误状态
- 如何进入和离开

可用文本框架、简单布局描述或 Mermaid。输出后让用户二次确认，再写详细功能模块。

### 7. 写详细功能模块

如果是 AI 产品，输出：

- Agent 工作流：触发方式、输入解析、计划步骤、工具调用、生成结果、自检/验证、输出格式。
- 提示词设计：系统角色、用户输入槽位、约束条件、输出格式、需要澄清时怎么问、不应该做什么。
- Tool 体系：需要哪些工具、每个工具的输入/输出、什么时候调用、调用失败怎么处理。
- 记忆和状态：存什么、存多久、如何复用、是否允许用户清除。
- 人工确认节点：哪些步骤必须确认，哪些步骤可自动执行。

如果是传统产品，输出：

- 用户流程
- 页面和组件行为
- 数据模型或关键字段
- 后端/API 行为
- 权限设计
- 错误状态
- 边界情况
- 编码 Agent 必须知道的实现说明

### 8. 写验收标准

每个 P0 功能和用户确认要做的 P1 功能都要写验收标准。推荐格式：

```text
Given [初始状态]
When [用户执行明确动作]
Then [系统出现可观察结果]
```

示例：

```text
Given 用户已经进入需求输入页面
When 用户粘贴一段竞品分析并点击“生成 PRD”
Then 系统展示“输入类型：竞品分析”，并出现 4 个方向选择按钮：“复刻功能”“改进功能”“融合多个产品”“差异化版本”
```

避免：

- 页面体验良好
- 生成结果准确
- 操作很方便
- 加载速度快

## 最终输出模板

确认完成后，输出一份完整 Markdown PRD。按实际情况删除不适用章节，不要为了完整而填废话。

```markdown
# [产品名称] - Vibe Coding PRD

## 1. 需求定义
- 目标用户：
- 使用场景：
- 解决问题：
- 产品形态：
- MVP 目标：

## 2. 范围和优先级
| 优先级 | 一级模块 | 二级模块 | 功能 | 是否现在做 | 时间 | 说明 |
|---|---|---|---|---|---|---|

## 3. 推荐技术栈
| 层级/功能 | 推荐技术 | 推荐理由 | 替代方案 | 风险/成本 |
|---|---|---|---|---|

## 4. 核心原型图（框架版）
### 页面：[页面名称]
[低保真文本框架、页面区域和关键操作]

## 5. 详细功能设计
### 模块：[模块名称]
- 目的：
- 用户流程：
- 输入/数据：
- 功能行为：
- 边界情况：
- 实现说明：

## 6. AI Agent 设计
<!-- 仅 AI 产品保留本节 -->
### Agent 工作流
### 提示词设计
### Tool 体系
### 记忆/状态
### 人工确认节点

## 7. 验收标准
### 功能：[功能名称]
- Given ...
- When ...
- Then ...

## 8. 暂不做范围
- ...

## 9. 假设和开放问题
- ...
```