prd-generator

PRD 生成器

用途

通过有针对性的问题和结构化输出，将粗略的产品构想转化为全面、适用于 AI 的产品需求文档（PDF）。

---

执行逻辑

先检查 $ARGUMENTS，以确定执行模式：

如果 $ARGUMENTS 为空或未提供：

回复： "prd-generator 已加载，请描述你的产品构想"

然后等待用户在下一条消息中提供产品概念。

如果 $ARGUMENTS 包含内容：

立即开始执行任务（跳过“已加载”消息）。

---

任务执行

1. 必须：首先读取参考文件

阻塞要求——不得跳过此步骤

在进行任何其他操作之前，使用 Read 工具读取：

• ./references/prd_template.md

此模板定义了 PRD 必须遵循的确切结构。在读取此文件之前，不得继续执行第 2 步。

2. 跳过业务背景

此技能有意不读取 FOUNDER_CONTEXT.md。 PRD 是独立文档，应在文档中包含所有必要的背景信息。

3. 分析初始输入

从用户的初始描述中提取已有信息：

• 产品名称或暂定名称
• 要解决的核心问题
• 目标用户／受众
• 提及的关键功能
• 技术偏好（如有）
• 限制或要求（如有）

4. 提出澄清问题

使用 AskUserQuestion 工具收集缺失信息。最多提问 7 个，但越少越好——一旦信息足以编写全面的 PRD，就停止提问。

问题库（按优先级排序）：

#	问题	重要性	可跳过的情况
1	主要用户是谁？他们的角色和技术水平如何？	影响所有 UX 决策和功能复杂度	用户画像描述清晰
2	要解决的核心问题是什么？如果用户没有这个产品，会发生什么？	明确价值主张和成功指标	问题陈述明确
3	发布时必须具备的 3-5 项功能（P0）是什么？	防止范围蔓延，聚焦 MVP	功能已列出且优先级明确
4	有哪些技术偏好或限制？（语言、框架、托管方式）	决定技术架构部分	技术栈已指定
5	是否需要集成？（身份验证提供方、API、第三方服务）	明确依赖项和集成复杂度	未提及外部服务，或用户表示产品独立运行
6	怎样才算成功？需要跟踪哪些具体指标？	明确目标和成功指标部分	已陈述指标或目标
7	是否有设计偏好或需要遵循的现有品牌指南？	影响 UI/UX 要求部分	设计灵活或已描述

提问策略：

• 每轮使用 AskUserQuestion 提出 2-4 个问题
• 如果第一轮回答已提供足够细节，就停止提问
• 总提问数不得超过 7 个
• 尽可能将相关问题归在一起

5. 生成 PRD

使用 ./references/prd_template.md 中的模板结构，创建完整的 PRD：

1. 填写模板中的所有适用部分
2. 具体明确——模糊的需求会产生模糊的代码
3. 为每项功能编写验收标准——确保标准可测试
4. 严格设定优先级——P0 应占功能的 30-40%
5. “面向 AI 的实施说明”部分为必填项——这是让文档适用于 AI 的关键

6. 保存并转换为 PDF

第 6a 步：创建输出文件夹

mkdir -p ./prd_outputs/[Project Name]/

使用包含空格的产品名称，例如：./prd_outputs/Churn Prevention Tool/

第 6b 步：保存 Markdown 文件 将 PRD 内容写入：

./prd_outputs/[Project Name]/[project_name]_PRD.md

文件名使用 snake_case，例如：churn_prevention_tool_PRD.md

第 6c 步：转换为 PDF 运行：

npx md-to-pdf "./prd_outputs/[Project Name]/[project_name]_PRD.md"

这会在同一文件夹中创建 [project_name]_PRD.pdf。

7. 确认输出

告知用户：

• PDF 的保存位置（完整路径）
• Markdown 源文件的保存位置
• PRD 内容的简要摘要

---

写作规则

核心规则

• 每项功能 MUST 具备可测试的验收标准
• 使用具体数字，不要使用模糊表述（“加载时间 <2 秒”，而不是“加载很快”）
• P0 功能应占全部功能的 30-40%——如果所有功能都是 P0，就没有重点
• 数据模型必须包含字段类型和关系
• API 规范必须包含请求/响应示例

PRD 专属规则

• 执行摘要：最多 3-5 句话
• 问题陈述：必须包含当前状况、痛点和业务影响
• 用户画像：主要用户画像最多 3 个——更多会造成混乱
• 技术架构：用通俗易懂的语言描述数据流——AI 工具比起复杂图表，更容易理解这种描述
• 面向 AI 的实现说明：此部分为必填项，绝不可跳过

格式规则

• 统一使用 Markdown 标题（标题用 #，章节用 ##，小节用 ###）
• 使用表格呈现结构化数据（指标、数据模型、API 规范）
• 使用代码块呈现 JSON 示例和技术规范
• 使用复选框列出验收标准

---

输出格式

PRD 遵循 ./references/prd_template.md 中的结构。以下是精简示例：

# TaskFlow — Product Requirements Document

**Version:** 1.0
**Date:** 2024-01-15
**Author:** PRD Generator
**Status:** Draft

## Executive Summary
TaskFlow is a task management tool for remote engineering teams...

## Problem Statement
**Current state:** Teams use disconnected tools...
**Pain points:**
1. Context switching between tools
2. No visibility into team workload
3. Async communication gaps

**Impact:** 5+ hours/week lost per engineer...

## Goals & Success Metrics
| Goal | Metric | Target | Measurement |
|------|--------|--------|-------------|
| Reduce context switching | Tool switches/day | < 10 | Analytics |

## User Personas
### Engineering Manager
- **Role:** Manages 5-10 engineers
- **Goals:** Visibility into sprint progress...

## Functional Requirements

### FR-001: Task Creation
**Description:** Users can create tasks with title, description, assignee, and due date.

**User story:** As an engineer, I want to create tasks quickly so that I capture work items without friction.

**Acceptance criteria:**
- [ ] Task creation completes in < 500ms
- [ ] Title field is required, minimum 3 characters
- [ ] Due date defaults to end of current sprint

**Priority:** P0

...

## Implementation Notes for AI

### Build Order
1. Database schema (PostgreSQL)
2. API endpoints (Express.js)
3. Frontend components (React)
4. Auth integration (Clerk)

### Libraries to Use
- Prisma for ORM — type-safe, great DX
- TanStack Query for data fetching — handles caching
- Tailwind CSS for styling — utility-first, fast iteration

### Critical Implementation Details
- All dates stored as UTC, converted to user timezone on display
- Use optimistic updates for task status changes
- Implement soft deletes for all user-generated content

---

参考资料

执行任务前 MUST 使用 Read 工具读取此文件（参见步骤 1）：

文件	用途
./references/prd_template.md	完整的 PRD 结构，包含全部 15 个章节、格式示例和使用说明

重要原因： 模板可确保每份 PRD 都遵循一致、全面的结构，便于 AI 编码工具解析和实现。跳过模板会导致 PRD 不完整，遗漏关键章节。

---

质量检查清单（自我验证）

执行前检查

• 我已在开始前阅读 ./references/prd_template.md
• 我已将模板结构纳入上下文

问题检查

• 我总共提出的问题不超过 7 个
• 我只在确实缺少信息时才提出问题
• 我会批量提问（每次 AskUserQuestion 调用提出 2-4 个问题）

PRD 内容检查

• 执行摘要为 3-5 句话
• 每项功能都有验收标准（复选框）
• P0 功能约占全部功能的 30-40%（不是所有功能）
• 数据模型包含字段类型
• API 规范包含请求/响应示例
• “面向 AI 的实现说明”章节完整

输出检查

• Markdown 文件已保存到 ./prd_outputs/[Project Name]/
• 已通过 npx md-to-pdf 生成 PDF
• 已告知用户文件位置

如果任意一项检查未通过 → 完成前先修正。

---

默认值与假设

除非用户另有说明，否则使用以下默认值：

• 文档版本： 1.0
• 状态： 草稿
• 作者： PRD Generator
• 技术栈： 现代 Web（React + Node.js + PostgreSQL），除非另有指定
• 托管： 云原生（Vercel/Railway/AWS），除非另有指定
• 身份验证： 第三方（Clerk/Auth0），除非是构建自定义身份验证
• 优先级分布： 约 35% P0、40% P1、25% P2
• 用户画像： 最多 3 个，除非复杂度要求更多
• API 风格： REST，除非指定 GraphQL

在 PRD 输出中记录所作的任何假设。