Prd Generator

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. 有没有参考产品？

业务逻辑：

1. 每个角色的核心操作流程？
2. 数据从哪来？手动输入/Excel/API/爬虫？
3. 有没有AI服务需求？
4. 权限怎么分？
5. 有没有耗时>3秒的操作需要异步处理？

非功能需求：

1. 主要用什么设备？需不需要移动端适配？
2. 需不需要微信内打开？
3. 国内还是海外部署？
4. 预算范围？
5. 时间节点？

生产环境专项：

1. 峰值同时在线人数？（必须用峰值估算法帮用户算，不能只问"多少人"）
2. 哪些环节最不能卡顿？
3. 数据丢失的后果？
4. 宕机1小时的影响？
5. 有没有合规要求？（《个保法》/GDPR/未成年人数据保护？）

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

用户通常不会算并发量，必须引导：

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

第三方服务风险探查（v4.0 新增）：

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

关键原则：

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

阶段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. 正常主流程：按每个角色从登录到完成核心任务的完整路径走一遍

• "学生登录后看到什么 → 点哪里 → 做了什么 → 看到什么结果"
• "管理员登录后看到什么 → 怎么导入数据 → 怎么管理用户"

1. 关键异常流程：至少走查以下场景

• 密码输错5次后会怎样？
• 网络断了正在提交的数据会丢吗？
• AI服务超时用户看到什么？
• 上传了格式错误的Excel会怎样？
• 同一个表单提交了两次会创建两条记录吗？（幂等性）
• 支付成功但系统超时没收到回调怎么办？（跨系统一致性）

1. 权限边界流程：

• 教师能不能看到别的班的学生？
• 普通用户能不能通过修改URL访问管理页面？
• A学校的管理员能不能看到B学校的数据？

1. 容灾流程（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和人类开发者都能读懂
• 非技术用户：用比喻解释概念，不堆砌术语
• 技术选型：主动推荐+解释理由，不给一堆选项
• 并发量：不相信用户的直觉，必须用公式帮他算

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: scalershare
• Source: scalershare/prd-generator
• License: MIT

Install and usage instructions live in the source repository linked above.