PRD 转交互式 HTML 原型
概述
本技能将产品需求文档转化为一个单文件、自包含、离线可运行的 .html 文件，演示产品的页面、流程和关键交互。输出为高保真交互原型，内联所有 CSS 和 JS，适合演示和评审。
触发条件
当出现以下情况时使用此技能：
- 用户提供 PRD、需求文档、功能列表或脑图大纲，并要求生成原型
- 用户要求将产品需求可视化为可点击的 HTML 演示
- 用户在正式开发前需要一个无依赖的快速原型
- 用户说"把需求文档转成原型"、"生成交互原型"、"PRD 转 HTML"、"需求文档生成 HTML 原型"等
输入要求
- 需求来源：用户提供一份 PRD / 需求文档 / 功能列表（Markdown、文本或脑图大纲均可）。
- 语言要求：所有输出（设计说明、代码注释、UI 文案、交互反馈）均使用中文。
- 输入边界：
- 若需求仅含一句话或极简描述，自动降级为低保真线框，并在设计说明中标注降级原因。
- 若页面超过 10 个，优先实现核心流程涉及的页面（最多 5-7 个），其余页面保留入口导航占位即可，并在设计说明中列出未完整实现的页面。
- 若用户提供截图或图片形式的需求，先提取可识别信息，无法识别之处标注为"未获取"并列入补充假设。
工作流程
第一步：解析需求文档
从需求文档中提取以下信息，若有缺失项请用合理的行业默认值补充，并在末尾以"补充假设"章节逐条列出：
- 产品/项目背景与目标
- 目标用户与核心使用场景
- 功能范围与页面清单
- 关键页面的信息架构（字段、模块、层级关系）
- 主要用户流程（如：注册 → 登录 → 浏览 → 下单）
- 交互/状态需求（空状态、加载中、错误、成功状态）
- 视觉/品牌偏好（配色、字体、风格）。若未指定，请选用现代简洁风格并说明选择理由。
第二步：输出设计说明（Design Brief）
在编写代码之前，先输出简短的设计说明，包含：
- 页面列表（每个页面标注优先级：
核心/次要） - 信息架构要点（核心页面的模块与字段）
- 3–6 个关键交互决策说明（如导航方式、表单校验策略、状态切换逻辑等）
- 降级/删减说明（若有页面未完整实现）
> 重要：输出设计说明后暂停，等待用户确认或修改意见。仅在用户回复"直接开始"、"确认"或类似明确继续指令后，才进入代码生成阶段。
第三步：生成单文件 HTML 原型
输出一个完整的 .html 文件，需满足以下全部条件：
技术约束
- 单文件：所有 CSS 和 JS 内联。图标优先使用内联 SVG，字体使用系统字体栈。禁止任何外部网络请求（无 CDN、无外部依赖），必须能在离线环境下直接打开运行。
- 响应式：桌面优先布局，移动端保持可用（不要求完美适配）。
设计质量
- 高保真：应用现代设计系统——合理的网格、间距、层级、对比度、圆角、阴影和留白。避免无样式的"裸"标记。
- 风格一致：所有页面统一配色方案、字体层级、组件样式、间距节奏。
交互能力
- 页面导航：通过导航栏、按钮、标签页等在页面/视图之间切换，使用原生 JS 控制显示隐藏或实现轻量路由（不使用框架）。
- 表单交互：表单可输入、可校验、可提交，并给出清晰的反馈提示。
- 状态覆盖：按页面优先级实现状态——
核心页面覆盖默认态、悬停态、选中态、禁用态、加载态、空状态、错误态；次要页面至少具备基础布局、导航联通、默认态。 - Mock 数据：列表页和详情页使用模拟数据填充，让原型感觉真实可用。核心页面填充 5–8 条真实感数据；图片占位使用内联 SVG 占位符或 CSS 渐变色块，不依赖外部图片服务。
可访问性
- 使用语义化 HTML 标签（如
<nav>、<main>、<header>、<button>而非<div onclick>）。 - 所有可交互元素支持键盘 Tab 切换和 Enter 激活。
- 为关键动态区域添加基础 ARIA 标签（如
aria-current、aria-expanded）。
代码规范
- 每个区块用 HTML 注释标记，例如
<!-- 首页 / Banner 区 -->、<!-- 设置页 / 表单区 -->。 - 代码结构清晰，变量和 class 命名语义化，便于后续维护。
- 所有注释使用中文。
第四步：自检清单
交付前请自行验证：
- [ ] 所有按钮/链接均有响应，无死链
- [ ] 视觉风格在所有页面间保持一致
- [ ] 无 JS 控制台报错
- [ ] 移动端视图不崩溃
- [ ] 键盘 Tab 键可遍历所有可交互元素
- [ ] 没有添加需求文档中未提及的重大功能（补充内容已标注）
第五步：交付
将最终 .html 文件写入工作目录，并向用户呈现。如果存在核心操作流程，附上一份一分钟演示脚本（点击顺序）。
分批次输出策略
若需求文档涉及页面较多（超过 10 个）或单次输出内容过长，可采用分批次输出：
- 批次划分：按用户流程或功能模块划分批次，每批次覆盖 3-5 个关联页面。
- 批次顺序：优先输出核心流程涉及的页面，再输出次要页面。
- 批次衔接：每批次结束时，输出"已完成页面清单"和"下一批次计划"，并暂停等待用户确认后再继续。
- 文件管理：所有批次最终合并为同一个
.html文件，不产生多个独立文件。
迭代修改指引
后续用户要求修改时：
- 局部修改：仅调整用户指定的页面或交互，保持其余部分不变，并说明修改范围。
- 架构级修改：若修改影响整体导航或信息架构，先输出影响说明（涉及哪些页面、交互变更点），等待用户确认后再执行。
- 每次修改后重新执行自检清单。
交付物
- 设计说明（Markdown 文本）
- 完整的
.html原型文件 - （可选）如果存在核心操作流程，附上一份一分钟演示脚本（点击顺序）
增强选项（按需附加）
可在提示词末尾追加以下任一选项：
- "采用 [Stripe / Linear / Apple / Notion …] 的设计语言。"
- "包含深色模式切换。"
- "聚焦于 [某核心流程]，其他页面保持最小化。"
- "同时提供一分钟演示脚本。"
使用示例
用户：帮我把这份 PRD 转成可点击的 HTML 原型
助手：我先解析需求文档，输出设计说明，待你确认后再生成完整的 HTML 原型...
用户：根据这个功能列表生成交互原型
助手：我已提取页面清单和核心流程，先输出设计说明供你确认...
用户：需求文档页面较多，分批次输出
助手：按核心流程优先，每批 3-5 个页面，最终合并为一个 .html 文件...
注意事项
- 不得添加需求文档中未提及的重大功能，补充内容必须标注为"补充假设"
- 设计说明后必须暂停等待用户确认，不得直接进入代码生成
- 单文件原则不可妥协——禁止任何外部网络请求或 CDN 依赖
- 核心页面与次要页面的保真度需区分对待，资源合理分配
- 所有交互元素必须可键盘操作，满足基础可访问性要求
