write-prdlisted

## 第一步：判断上下文模式 检测当前是否存在代码库： ```bash git ls-files | head -20 ``` - 有输出 → **迭代模式**：结合代码库做模块分析，重点在技术落地 - 无 git 仓库或无��件 → **立项模式**：完全依赖用户描述，重点在想清楚问题 ## 第二步：信息收集 从用户描述中提取以下信息，缺失项一次性列出询问，不要逐条追问： 1. 产品 / 功能名称 2. 要解决的核心问题是什么 3. 目标用户是谁 4. 核心功能有哪些（3-5 条） 5. 明确不做什么（可选） 6. 成功的衡量标准 7. 技术栈（前端、后端、数据库、部署方式等）；若用户未指定，按以下规则推断： - 前端：默认 React - 后端框架 + 数据库：根据项目体量判断 - 小型（个人工具 / MVP / 用户量 < 1 万）：Elysia.js + SQLite - 中型（团队产品 / 用户量 1 万~100 万）：Elysia.js + PostgreSQL - 大型（高并发 / 用户量 > 100 万）：Elysia.js + PostgreSQL + Redis 缓存 - 部署方式根据项目体量和基础设施合理推断 如果用户描述已足够清晰，直接进入第三步，不要重复询问。 **禁止事项：** 不允许把"验证技术链路"、"测试工作流"、"API 验证"等内部目的写入 PRD。PRD 描述的是对真实用户有价值的产品，不是工程验证项目。用户说"做一个 todo 应用"，PRD 就应该是一个面向真实用户的待办管理工具，而不是"验证研发链路的 API 服务"。 ## 第三步：生成 PRD 文档 ### 立项模式输出结构 ``` # [产品/功能名称] PRD ## 概述 一句话说明这是什么、为谁做、解决什么问题。 ## 背景与问题 - 现状是什么 - 存在什么痛点 - 为什么现在做 ## 目标用户 - 主要用户画像 - 使用场景描述 ## 产品目标 - 目标 1（可量化） - 目标 2 - ... ## 功能范围 ### 核心功能 | 功能 | 描述 | 优先级 | |------|------|--------| | ... | ... | P0/P1/P2 | ### 用户故事 - 作为 [用户]，我希望 [做某事]，以便 [达到目的] ### 超出范围（不做什么） - ... ## 成功指标 | 指标 | 基准值 | 目标值 | |------|--------|--------| | ... | ... | ... | ## MVP 规划 ### MVP 目标 最小可验证版本需要解决的核心问题，一句话描述。 ### MVP 功能范围 | 功能 | 进入 MVP | 说明 | |------|---------|------| | ... | ✅ / ❌ | 进入/推迟原因 | ### 后续迭代方向 | 版本 | 功能方向 | |------|---------| | v1.1 | ... | | v2.0 | ... | ## 技术栈 > 所有技术均使用最新稳定版本，开发时以各技术官方文档最新版为准。 | 层级 | 技术选型 | 说明 | |------|---------|------| | 前端 | ... | ... | | 后端 | ... | ... | | 数据库 | ... | ... | | 部署 | ... | ..