软件原型与 PRD 制作

Overview

根据用户的需求描述，先产出结构化的产品需求文档（PRD），再生成可交互的 HTML 原型。PRD 风格可根据项目规模在「传统完整 PRD」和「敏捷精简 PRD」之间灵活切换。

工作流程

需求输入 → 需求澄清 → 选择 PRD 风格 → 生成 PRD → 生成原型 → 迭代优化

第一阶段：需求理解

当用户提出需求时，首先快速判断需求范围：

1. 如果需求描述清晰完整（已包含目标用户、核心功能、场景），则直接进入 PRD 风格选择。
2. 如果需求模糊，通过简洁的追问明确以下关键信息：
   - 是什么类型的产品？（App / 后台 / 官网 / 小程序 / H5）
   - 目标用户是谁？
   - 核心要解决什么问题？
   - 有没有参考竞品？

追问原则：每次最多问 2-3 个问题，避免审问式沟通。优先从需求描述中推断信息，仅在确实模糊时才提问。

第二阶段：选择 PRD 风格

根据需求特征选择 PRD 风格，同时向用户确认：

• 传统完整 PRD：全新产品、大版本、多团队协作、需要正式评审。包含需求背景、目标、功能详述、业务流程、非功能需求、埋点、风险评估等完整板块。
• 敏捷精简 PRD：小功能迭代、MVP 验证、单一团队。以用户故事 + 验收标准为核心，简洁实用。

快速判断规则：
- 如果用户只说"做个 XX 功能" → 敏捷 PRD
- 如果用户说"设计一个完整的 XX 系统/产品" → 传统 PRD
- 如果不确定 → 向用户确认偏好

第三阶段：生成 PRD

根据选定的风格，参考对应模板生成 PRD：

• 传统风格：assets/prd-traditional-template.md
• 敏捷风格：assets/prd-agile-template.md

生成规则：

1. 先加载模板和写作指南：在开始写 PRD 之前，先读取对应的 assets/ 模板和 references/prd-writing-guide.md，确保格式和内容符合规范。
2. 填充内容时遵循原则：
   - 说人话，非技术人员也应该看得懂
   - 每个功能从用户视角出发
   - 覆盖空状态、错误状态、加载状态等边界条件
   - 优先级标注明确（P0/P1/P2）
   - 目标和指标尽可能量化
3. PRD 输出为 Markdown 文件，保存到用户工作区，文件名格式：PRD-[产品名称]-[日期].md

第四阶段：生成交互原型

PRD 确认后，生成可交互的 HTML 原型。

生成前先读取：references/prototype-guide.md，了解原型规范、尺寸选择、必须覆盖的状态等。

原型生成规则：

1. 确定尺寸：
   - 移动端 App/小程序/H5：375px 宽度，居中展示
   - 管理后台：全宽布局（最小 1200px）
   - 响应式网站：自适应布局

2. 必须覆盖的状态（每个页面）：
   - 默认状态（正常数据展示）
   - 加载中状态（骨架屏或 Loading）
   - 空状态（无数据时的引导）
   - 错误状态（网络异常/操作失败）
   - 确认弹窗（删除/退出等危险操作）

3. 使用真实中文内容，不要 Lorem Ipsum。

4. 代码规范：
   - 单个 HTML 文件包含所有 CSS 和 JS
   - 使用 CSS 变量管理主题色
   - 原生 JavaScript，不依赖框架
   - 关键交互要有实现：Tab 切换、列表筛选、弹窗、Toast、表单校验等

5. 文件命名：prototype-[产品名称].html，保存到用户工作区。

第五阶段：迭代优化

原型和 PRD 都生成后，根据用户反馈进行调整。

核心原则：增量修改，避免重写。 迭代时基于已有的原型文件做局部修改（使用 Edit 工具），而非每次重新生成整个 HTML 文件。这能极大提高效率、保留已有的交互逻辑，同时降低引入新 bug 的风险。

典型迭代操作：
- 修改 PRD 中某个功能描述
- 调整原型中特定页面的布局、文案或样式
- 补充遗漏的状态（空状态、错误状态等）或新增一个页面
- 修复某个交互行为（如弹窗逻辑、Tab 切换）
- 将 PRD 导出到腾讯文档等在线协作平台（如果有需要）

只有在原型已完全无法满足新需求（如产品方向重大调整、技术栈变更）时才考虑重新生成。

当用户要求将 PRD 导出为在线文档时，使用腾讯文档相关工具创建。

资源清单

assets/（模板文件）

references/（参考文档）

使用方式：在开始写 PRD 前加载 prd-writing-guide.md，在开始做原型前加载 prototype-guide.md。不要一次性加载所有参考文档。