---
slug: "prd-generator"
source_type: "skill_md"
source_url: "https://cdn.jsdelivr.net/gh/scalershare/prd-generator@main/SKILL.md"
repo: "https://github.com/scalershare/prd-generator"
source_file: "SKILL.md"
branch: "main"
---
---
name: prd-generator
description: "Generate production-ready Product Requirement Documents (PRD) for Claude Code development. Use this skill whenever the user wants to create a product requirements document, development specification, PRD, technical specification, or system design document — especially when the deliverable is intended to be executed by Claude Code or AI-assisted development tools. Also trigger when the user says things like 'help me plan a new product', 'I need a development document for...', 'write a PRD', 'create a spec for Claude Code', '帮我写产品需求文档', '生成开发文档', '我要做一个系统', or any variation requesting structured product planning for software development. This skill is particularly powerful for users who are not professional developers but want to build real production systems with AI assistance."
---

# PRD Generator v4.0 — Claude Code 生产级开发规范文档生成器

## Overview

本Skill帮助用户从一个模糊的产品想法，通过结构化的引导对话，最终输出一份**Claude Code可以直接执行的完整产品需求文档（PRD）**。

核心价值：**用户不需要懂技术，只需要清楚地描述他们想要什么。Skill负责把"想要什么"翻译成Claude Code能理解的"怎么做"。**

## ⚠️ Production-First 核心理念

**本Skill生成的PRD，默认目标是生产环境——真实用户、真实数据、真实流量。** 不是Demo、不是原型、不是课堂作业。

1. **技术选型必须经过生产验证**：推荐的每个框架/库/数据库都必须是真实生产环境中被广泛使用的成熟方案。用户问"靠不靠谱"时，必须给出生产案例和社区成熟度说明，不能说"理论上可以"。
2. **技术选型要主动推荐**：根据项目特征直接给出最适合的方案并解释理由，不要给用户一堆选项让他们自己选。用户不是技术专家，选择太多会造成纠结。用户有异议时再讨论替代方案。
3. **高并发必须提前设计**：PRD必须包含逐环节的并发承载分析——每个用户操作能扛多少人同时操作、瓶颈在哪里、用什么方案解决。
4. **安全不是可选项**：HTTPS、密码加密、注入防护、XSS防护、权限校验、文件上传校验——这些是V1上线的硬性前提。
5. **异常路径和正常路径同等重要**：加载中/失败/超时/无数据/无权限/AI服务不可用——每个状态都必须定义用户看到什么。
6. **运维可持续**：备份/监控/告警/日志/故障排查/版本更新回滚——必须预先设计，不能上线后再想。
7. **成本透明**：用户在开发前就要知道每月运行这个系统花多少钱。
8. **技术解释要向用户讲清楚**：用户有权知道"为什么选这个"。被质疑时用数据和案例回答，不回避。
9. **架构韧性优先**：系统设计必须识别单点故障、定义故障影响范围、设计自动恢复和优雅降级方案。不能只考虑"正常跑起来"，必须考虑"挂了怎么办"。
10. **第三方依赖是风险源**：每个外部服务（支付、认证、AI API、短信、云存储）都是潜在的故障点。必须盘点配额上限、风控规则、冷启动限制、扩容时间，不能假设"第三方永远可用"。
11. **兜底机制必须分层**：技术降级→人工应急→用户沟通，三层兜底缺一不可。最后一道防线是人，不是代码。

## Workflow: 六阶段生成流程

### 阶段一：需求探查（Requirement Discovery）

**目标**：弄清楚用户到底要做什么，不遗漏任何关键信息。

用以下问题框架引导（根据用户已提供的信息跳过已知项，每轮最多问2-3个）：

**产品定位**：
1. 这个产品是做什么的？一句话描述
2. 谁来用？列出所有角色
3. 首批用户量级？（几十/几百/几千/几万）
4. 内部工具还是面向公众？
5. 有没有参考产品？

**业务逻辑**：
6. 每个角色的核心操作流程？
7. 数据从哪来？手动输入/Excel/API/爬虫？
8. 有没有AI服务需求？
9. 权限怎么分？
10. 有没有耗时>3秒的操作需要异步处理？

**非功能需求**：
11. 主要用什么设备？需不需要移动端适配？
12. 需不需要微信内打开？
13. 国内还是海外部署？
14. 预算范围？
15. 时间节点？

**生产环境专项**：
16. 峰值同时在线人数？**（必须用峰值估算法帮用户算，不能只问"多少人"）**
17. 哪些环节最不能卡顿？
18. 数据丢失的后果？
19. 宕机1小时的影响？
20. 有没有合规要求？（《个保法》/GDPR/未成年人数据保护？）

**⚠️ 峰值流量估算法（必须主动帮用户计算）**：

用户通常不会算并发量，必须引导：
- **有集中触发时间点的场景**（抢票/开课/秒杀/出分）：按**全量用户同时到达**设计。1万人的活动 = 1万人在30秒内全部到达 ≈ 333 QPS，不是"日均1000访问"
- **无明确峰值的常规系统**：峰值QPS ≈ 日活用户数 × 每用户每日请求数 / 86400 × 峰值系数（通常3-5倍）
- **关键区分**：日活≠并发。1000日活可能只有10-50并发，但如果有集中时间点，可能瞬间1000并发
- **必须追问**：有没有"所有人在同一时间做同一件事"的场景？（开学选课、抢名额、限时活动、统一考试）

**第三方服务风险探查（v4.0 新增）**：
21. 涉及哪些第三方服务？（支付/认证/短信/AI/云存储/地图等）
22. 这些服务的账号是新开的还是已有交易记录？（冷启动风险）
23. 是否了解各服务的配额/限额/费用模型？

**关键原则**：
- 用户说不清楚时，给出推荐方案（附理由），不给一堆选项让用户纠结
- 用户遗漏的常见需求主动提醒
- 不假设用户懂技术术语
- **用户说的"并发数"大概率不准确，必须用估算法帮他算一遍**

### 阶段1.5：V1功能范围裁剪（Scope Definition）

**目标**：明确V1做什么、V2做什么，防止功能蔓延。

在需求探查结束后，将所有功能按优先级分三级：
- **P0 Must Have**：V1不做就不能上线的功能
- **P1 Should Have**：V1有了更好，但可以简化实现
- **P2 Nice to Have**：明确放到V2，V1不碰

向用户确认这个分级。只有P0和P1进入PRD，P2记录在附录"V2规划"中。

### 阶段二：方案设计与确认（Solution Design & Confirmation）

**目标**：给出技术方案并逐项确认关键决策。

**技术选型**：参考 `references/tech-stack-guide.md`。
- **主动推荐最成熟的方案**，并解释为什么这个最适合
- 不要列一堆选项让用户选
- 用户有不同想法时，对比分析利弊后给出建议

**决策确认**：参考 `references/decision-checklist.md`。
- 将适用项整理成编号列表，每项给推荐方案
- 用户逐项确认
- 模糊回答时追问到位

### 阶段三：PRD生成（Document Generation）

**目标**：生成Claude Code可以直接执行的完整PRD。

**输出格式**：Markdown文件（.md），除非用户特别要求其他格式。

**文档结构**：参考 `references/prd-template.md` 中的完整模板。

**安全设计**：参考 `references/security-design.md`。

**容灾与兜底设计**：参考 `references/resilience-design.md`（v4.0新增）。

**必须同时生成的文件**：
1. **PRD主文档**（xxx-PRD-v1.md）：完整的产品开发规范
2. **CLAUDE.md模板**：Claude Code的项目入口文件，内容包括：
   - 项目一句话简介
   - 技术栈摘要
   - PRD文档位置指引
   - 开发规范（代码风格、Git提交规范、分支策略）
   - 关键命令（启动开发环境、运行测试、构建部署）
   - **禁止事项**（必须包含）：
     - 不要引入PRD中未列出的第三方依赖
     - 不要直接修改数据库表结构，必须通过迁移工具
     - 不要修改.env中的变量名
     - 不要跳过PRD中定义的权限校验逻辑
     - 不要在代码中硬编码密码、密钥、API Key
     - 每个功能开发完成后必须能通过对应的测试
     - 关键写入接口必须实现幂等性
     - 日志中不得输出密码、Token、身份证号等敏感信息原文
   - **开发红线（v4.1新增）**：
     - 写第一个功能代码之前，先跑通最小异步测试用例验证框架组合
     - 时间类型、主键类型、枚举值大小写全局统一，禁止混用
     - 异步ORM禁止lazy loading，所有关联查询显式声明加载策略
     - 测试数据清理按FK逆序，conftest.py清理fixture先于第一个测试设计
     - 测试环境独立（独立数据库+独立Redis db），禁止复用开发环境
     - Docker服务间用服务名连接，禁止localhost

**写作原则**：
- 数据模型必须有完整SQL DDL
- 每个API必须标注方法/路径/说明/角色，并给出请求和响应的JSON示例
- **所有API必须定义请求体和响应体的Schema**（字段名、类型、必填/可选、校验规则），不能只有JSON示例没有字段说明
- 权限矩阵必须覆盖角色×功能×数据范围的完整组合
- **每个功能模块必须说明数据流向**：前端调哪个API→后端哪个Service处理→读写哪张表→返回什么数据。Claude Code需要这个链路信息来组织代码调用关系
- 安全措施必须是具体实现方式，不是空话
- 目录结构必须列到文件级别
- 第三方依赖必须锁定版本号
- Docker Compose配置必须包含完整的服务定义
- **API路径命名必须统一规范**：资源名用复数（/students不是/student）、层级清晰（/api/{模块}/{资源}）、风格一致
- **涉及支付/外部交易的接口必须设计状态机**：定义中间态（如"支付中"），禁止从"待支付"直接跳到"已取消"

### 阶段四：用户走查（User Walkthrough）

**目标**：PRD生成后，带用户走一遍核心流程，确保没有理解偏差。

**必须覆盖的四类场景**：

1. **正常主流程**：按每个角色从登录到完成核心任务的完整路径走一遍
   - "学生登录后看到什么 → 点哪里 → 做了什么 → 看到什么结果"
   - "管理员登录后看到什么 → 怎么导入数据 → 怎么管理用户"

2. **关键异常流程**：至少走查以下场景
   - 密码输错5次后会怎样？
   - 网络断了正在提交的数据会丢吗？
   - AI服务超时用户看到什么？
   - 上传了格式错误的Excel会怎样？
   - 同一个表单提交了两次会创建两条记录吗？（幂等性）
   - 支付成功但系统超时没收到回调怎么办？（跨系统一致性）

3. **权限边界流程**：
   - 教师能不能看到别的班的学生？
   - 普通用户能不能通过修改URL访问管理页面？
   - A学校的管理员能不能看到B学校的数据？

4. **容灾流程（v4.0新增）**：
   - 如果AI服务完全不可用（不是超时，是彻底挂了），用户能做什么？
   - 如果数据库只读了（磁盘满/主从切换），用户看到什么？
   - 如果整个系统完全不可用，用户怎么知道情况？谁来告诉他们？
   - 系统恢复后，之前未完成的操作怎么处理？

如果用户说"不对，这里应该是..."，立即修正PRD。

### 阶段五：扫雷审查（Gap Analysis）

**目标**：自动执行完整的质量检查。

参考 `references/gap-analysis-checklist.md`。

问题分三级：
- 🔴 RED（阻塞开发）→ 必须解决
- 🟡 YELLOW（影响体验）→ 需明确方案
- 🟢 GREEN（优化项）→ V2处理

所有RED项解决后，更新PRD文档，标记为"Final"状态。

### 阶段六：上线准备审查（Go-Live Readiness）— v4.0新增

**目标**：在PRD标记为Final后，生成上线前必须完成的检查清单。

参考 `references/go-live-checklist.md`。

此阶段产出一份**上线检查清单**作为PRD附录，包含：
- 上线前必须验证的技术项
- 第三方服务预热任务
- 灰度发布策略
- 上线后 Smoke Test 清单
- 快速回滚触发条件
- 人工应急预案

## Output Quality Standards

生成的PRD必须满足以下19项标准：

1. **Claude Code可执行性**：一个不了解背景的Claude Code实例，仅凭此文档能独立完成开发
2. **数据模型完整性**：DDL完整、外键清晰、索引定义、JSONB结构有示例
3. **API无歧义性**：每个API的方法/路径/角色/请求体/响应体都明确
4. **权限无死角**：角色×功能×数据范围的完整交叉表
5. **安全非空话**：具体到算法/参数/配置，不是"要做安全"
6. **前端可开发性**：页面/路由/布局/移动适配/路由守卫都明确
7. **部署可执行性**：Docker Compose/服务器/域名/CI-CD方案具体可操作
8. **成本可预估**：服务器/API/第三方/总成本都有数字
9. **并发扛得住**：逐环节分析，瓶颈有优化方案
10. **用户体验完整**：正常路径和异常路径（加载/失败/超时/空状态/无权限）都定义
11. **运维可持续**：备份/监控/告警/日志/排查/更新/回滚都有方案
12. **技术选型有据**：每个选择有理由，能经得起"为什么"的追问
13. **测试可执行**：核心功能的测试用例或测试策略已定义
14. **依赖版本锁定**：requirements.txt / package.json 中的版本号明确
15. **架构韧性达标**：单点故障已识别、故障影响矩阵已绘制、RTO/RPO已定义
16. **容灾兜底完整**：熔断/降级/人工应急三层兜底均有方案
17. **第三方风险可控**：所有外部服务的配额/风控/冷启动限制已盘点
18. **日志可排查**：结构化日志规范、链路追踪、敏感信息脱敏均已定义
19. **开发陷阱已预防**：类型统一规约、框架兼容性验证、FK级联策略、测试隔离方案、本地/生产差异对照均已定义

## Reference Files

| 文件 | 用途 | 何时读取 |
|------|------|---------|
| `references/tech-stack-guide.md` | 技术选型决策树+推荐逻辑 | 阶段二 |
| `references/decision-checklist.md` | 必须确认的决策项清单 | 阶段二 |
| `references/prd-template.md` | PRD文档完整章节模板+写作标准 | 阶段三 |
| `references/security-design.md` | 安全设计标准模板 | 阶段三 |
| `references/resilience-design.md` | 容灾/韧性/兜底设计标准模板 | 阶段三 |
| `references/gap-analysis-checklist.md` | 扫雷检查清单 | 阶段五 |
| `references/go-live-checklist.md` | 上线准备检查清单 | 阶段六 |

## Language & Style

- 与用户交互：使用用户的语言，口语化、易懂，每轮最多2-3个问题
- 生成PRD：技术术语准确，结构清晰，Claude Code和人类开发者都能读懂
- 非技术用户：用比喻解释概念，不堆砌术语
- 技术选型：主动推荐+解释理由，不给一堆选项
- **并发量：不相信用户的直觉，必须用公式帮他算**