name: product-prototype-builder description: 当用户想把产品想法、平台概念、功能需求、需求讨论、PRD、需求文档、Markdown 方案、HTML 原型、页面原型，或“我想做一个产品/平台/功能”这类请求，逐步转化为明确需求、版本化 PRD 和单文件可交互 HTML 原型时使用本 skill。
产品原型构建器
使用本 skill，将一个模糊的产品想法从 0 到 1 推进为三个阶段的交付物：
- 需求讨论
- 需求方案
- 单文件可交互 HTML 原型
用户可以只提供一个初始想法。除非前一阶段已经有足够且被用户确认的信息，否则不要直接跳到 PRD 或原型生成。
核心规则
- 用户使用中文时，默认使用中文沟通和交付。
- 将本流程视为协作式产品探索，而不是一次性文档生成。
- 持续记录需求、决策、开放问题、假设和版本变化。
- 重要产品决策必须先和用户确认，再写入最终方案。
- 用户明确确认需求讨论已经足够完整之前，不生成 PRD。
- 用户明确确认 PRD 没问题并可以开始生成原型之前，不生成原型。
- 如果用户在 PRD 或原型生成后修改需求，先更新需求讨论记录，再按影响范围创建新的 PRD 或原型版本。
- 当市场、竞品、政策、技术、价格、行业现状等信息可能影响需求判断时，使用可用的联网搜索工具补充资料，并总结来源与结论。外部资料只能作为假设，必须经用户确认后才能成为需求结论。
工作区结构
在当前工作目录中创建并维护以下结构：
workspace/
├── 01-discussions/
│ └── {需求名称}-讨论.md
├── 02-specifications/
│ └── {需求名称}/
│ ├── v001-{需求名称}-方案.md
│ ├── v002-{需求名称}-方案.md
│ └── index.md
└── 03-prototypes/
└── {需求名称}/
├── v001-{原型名称}.html
├── v002-{原型名称}.html
└── index.md
如果项目中已经存在合适的根目录，可以使用现有目录，不要重复创建 workspace/。文件名应简洁、清晰，并避免使用不适合文件系统的特殊字符。
版本管理规则
- PRD 和原型必须使用
v001、v002、v003等版本号。 - 不要覆盖已有的版本化 PRD 或原型文件。每次重要修改都创建下一个版本。
- 每个
index.md需要记录：- 版本号
- 文件路径
- 创建或更新时间，如果可获取
- 简短变更说明
- 状态，例如
draft、confirmed、superseded
- 需求讨论文件是持续演进的需求事实来源，需要在整个过程中持续更新。
阶段一：需求讨论
目标：将用户的初始想法整理为清晰、完整、可确认的需求基础。
执行动作：
- 创建或更新
workspace/01-discussions/{需求名称}-讨论.md。 - 使用自由对话方式提出聚焦问题。每轮优先提出 3 到 7 个高价值问题。
- 记录以下内容：
- 原始想法
- 目标用户与使用场景
- 用户痛点与产品价值
- 核心使用流程
- 功能需求
- 数据对象与关键字段
- 用户角色与权限
- 业务规则
- 交互预期
- 视觉与风格偏好
- 约束条件与非目标范围
- 待确认问题
- 已确认决策
- 发现不合理、有风险、互相矛盾或缺失的需求时，需要指出问题、说明影响，并给出可选方案。
- 有必要时，查询同类产品、行业实践、政策限制或技术可行性。总结查询结论，并询问用户是否采纳相关假设。
- 在讨论过程中定期总结当前需求，并同步写入需求讨论文件。
阶段门禁：
- 进入阶段二之前，必须询问用户是否确认需求已经足够完整，可以生成 PRD。
- 可以接受的确认包括“可以生成 PRD”、“需求没问题”、“生成需求文档”等同义表达。
- 如果用户过早要求生成 PRD，先总结当前缺口，再只追问最必要的问题。
阶段二：需求方案
目标：生成完整、结构清晰的 Markdown PRD 文档。
在以下路径创建下一个版本：
workspace/02-specifications/{需求名称}/v00N-{需求名称}-方案.md
推荐 PRD 结构：
# {需求名称} 产品需求文档 v00N
## 1. 需求目标
## 2. 背景与用户痛点
## 3. 用户角色与核心场景
## 4. 需求范围
## 5. 非目标范围
## 6. 产品架构
## 7. 使用流程
## 8. 产品风格与功能布局
## 9. 功能明细与交互逻辑
## 10. 数据对象与字段
## 11. 状态、规则与异常处理
## 12. 原型页面清单
## 13. 验收标准
## 14. 待确认问题
## 15. 版本记录
PRD 质量要求：
- 内容必须具体到足以支撑原型生成。
- 不只罗列功能名称，还要描述页面级和组件级行为。
- 根据需要描述空状态、加载状态、错误状态、权限状态和重要边界情况。
- 产品结构应美观、易用、功能逻辑清晰。
- 所有假设都要明确标注，并说明是已确认还是待确认。
交付后：
- 更新需求方案区的
index.md。 - 询问用户是否需要修改 PRD。
- 如果用户要求修改，先更新需求讨论文件，再创建新的 PRD 版本。
阶段门禁：
- 用户明确确认 PRD 没问题并可以开始生成原型之前，不进入阶段三。
- 可以接受的确认包括“PRD 没问题”、“可以生成原型”、“开始做 HTML”等同义表达。
阶段三：可交互 HTML 原型
目标：生成一个美观、统一、可操作、可体验的单文件 HTML 原型。
进入本阶段时，必须读取并执行 references/prototype-quality.md 中的原型质量规范。
生成文件之前：
- 先简要告诉用户预期原型效果，包括主要页面、交互深度、视觉风格和模拟逻辑。
- 只有在必要时才说明关键限制。
- 生成“原型交互清单”，明确每个页面、导航、按钮、Tab、筛选、搜索、表单、弹窗、抽屉、增删改查、动态组件的交互行为。
- 对工作流编排、可视化图谱、流程图、看板、拖拽排序、节点关系等复杂组件，必须说明会实现哪些动态交互，不能只做静态展示。
在以下路径创建下一个版本：
workspace/03-prototypes/{需求名称}/v00N-{原型名称}.html
原型要求：
- 最终交付一个独立的
.html文件。 - HTML、CSS、JavaScript 默认全部内联在同一个文件中。
- 文件必须可以直接在主流浏览器中打开。
- 原型必须是可交互的功能原型，而不是静态截图。
- 根据需求实现真实感较强的 UI 状态、页面切换、表单、弹窗、抽屉、标签页、筛选、搜索、校验、模拟流程和业务逻辑。
- 所有可点击元素都必须绑定可感知的交互结果。不能出现看起来可点击但点击无反应的主要按钮、菜单、Tab、图标按钮或操作入口。
- 增删改查按钮必须具备模拟逻辑，例如新增数据、编辑回填、删除确认、详情查看、搜索过滤、状态更新或提示反馈。
- 页面布局必须经过间距检查，避免侧边栏与内容区贴边、按钮紧挨、文字压线、元素重叠、内容被遮挡等问题。
- 使用模拟数据和浏览器端状态。需要提升体验时，可以使用
localStorage保存临时数据。 - 默认不依赖后端服务、真实数据库、构建步骤、包安装或外部 API。
- 除非用户明确同意，否则不要依赖外部 CDN。
- 整体视觉系统必须统一，包括间距、字体、颜色、组件样式、按钮、表格、卡片、表单、图表、导航和反馈状态。
- 所有主要流程都应能通过示例数据演示。
- 交互深度要足以让用户体验产品的核心行为。
重要说明：
- “单文件 HTML 原型”不等于“没有交互”。
- 它指的是原型可以在浏览器本地运行，并通过前端模拟实现交互和业务逻辑。
- 如果用户要求真实登录、真实接口、数据库持久化、支付、文件存储或生产部署，需要说明这已经超出单文件原型范围，并询问用户是要在原型中模拟，还是转为工程实现方案。
验证要求：
- 检查生成的 HTML 是否存在失效引用。
- 如果可用浏览器或渲染工具，打开 HTML 并验证布局、响应式表现和核心交互。
- 交付前修复明显的布局重叠、流程断裂、状态缺失或 JavaScript 错误。
- 使用
references/prototype-quality.md中的交付前验收清单逐项自检。发现未实现、无响应或布局不合理时，必须先修复再交付。
交付后：
- 更新原型区的
index.md。 - 告诉用户文件路径和创建的版本号。
- 先总结原型包含的内容，再询问用户反馈。
对话方式
- 保持主动，但严格遵守阶段门禁。
- 只在问题会明显改善结果时提问。
- 当用户不确定时，提供 2 到 4 个具体方案，并给出推荐方案。
- 当用户要求快速推进时，可以基于合理假设创建第一版，但跨阶段前仍必须获得确认。
- 当用户要求修改时，判断修改会影响需求讨论、PRD、原型，还是三者都会影响。
- 当用户要求回退时，使用对应的
index.md和版本化文件定位目标版本。
迁移说明
本 skill 以通用 Markdown 工作流指令编写。迁移到非 Codex 工具时，可使用 references/portable-prompt.md 作为系统提示词、自定义指令、项目规则或智能体规则。