pm-frontend-prototype git:20261013.60e8978A

Immutable. This exact content never changes and is served at /api/v1/blob/a701e20725d0a59f.

---
name: pm-frontend-prototype
description: 仅当用户明确要求在已有前端项目中生成、制作、构建或完善“原型”（例如高保真原型、可点击演示或评审 Demo）时使用此 Skill。默认基于现有源码复用组件、设计变量和技术栈，创建与正式业务入口隔离的原型页面或路由，并使用页面级模拟数据完成可点击演示；除非用户明确要求，否则不直接改动正在使用的业务页面、不接入后端或生产数据链路。
---

# 产品经理前端高保真原型 Skill

## 一、目标

在已有前端项目的源代码基础上，创建高保真、可点击且与正式业务入口隔离的原型，让产品经理能够快速查看、演示和讨论产品方案。

优先保证：

- 与现有项目风格一致。
- 页面像真实产品，而不是临时 Demo。
- 使用符合业务的模拟数据。
- 核心流程可以点击。
- 交互可以用于需求评审。
- 页面容易继续修改。
- 可以立即在本地运行和预览。
- 默认不影响正在使用的业务页面和路由。

除非用户明确要求，否则不要把任务当成从零重做整套系统。

当前目标是高保真原型时，不优先开发后端接口、生产数据链路或复杂架构。

**默认隔离约定：** 先复用现有项目的源码、布局、组件和视觉规则，再在独立的原型页面、原型路由或功能目录中实现。不得默认修改正在使用的业务页面、生产入口或现有接口调用；只有用户明确要求“直接在原页面演示”或“将原型覆盖到现有页面”时才可以这样做。

---

## 二、适用场景

当用户提出以下需求时，使用本 Skill：

- 基于已有 React、Vue、HTML 或其他前端项目源码创建独立原型页面或路由。
- 用户明确要求时，在已有产品页面中演示原型交互。
- 增加后台管理页面、CRM 页面、SaaS 页面、运营后台或业务工作台。
- 将静态页面改成可点击原型。
- 增加真实感较强的模拟数据和交互状态。
- 增加或优化表格、表单、筛选、Tab、抽屉、弹窗、图表、详情页或业务流程。
- 按照现有项目风格扩展新功能。
- 不开发后端，先完成用于评审的高保真 Demo。
- 优化视觉层级、信息密度、响应式或交互反馈。

常见表达：

- 在现有后台中增加一个客户列表页面。
- 根据当前项目风格增加一个经营数据看板。
- 在现有详情页中增加跟进记录模块。
- 把这个页面补成可以点击的原型。
- 增加搜索、筛选、状态切换、抽屉和弹窗交互。
- 优化这个现有页面，但不要改变整个系统风格。

---

## 三、不适用场景

以下情况不默认使用本 Skill：

- 用户希望从空目录开始创建一个全新产品。
- 用户只需要营销官网或落地页。
- 用户要求开发后端接口、数据库或生产服务。
- 用户需要技术架构文档，而不是原型。
- 用户只要求生成视觉图片或静态截图。
- 当前任务主要是需求分析或 PRD 编写。

如果当前目录为空，应说明本 Skill 主要面向已有项目，并优先使用“从零生成 HTML 高保真原型 Skill”。

---

## 四、核心原则

### 1. 先检查项目，再开始设计

不要收到需求后立即写代码。

先查找 `docs/product/` 中与当前项目、当前端（`c-end/` 或 `admin/`）对应的产品体验基线。基线存在时，读取其中的产品术语、导航、页面模式、视觉与交互规则；它补充项目源码的技术约定，但不能取代组件库、路由和数据架构。

如果用户正在启动首版需求，或当前功能暴露出跨页面反复出现但尚未定义的产品规则，建议先使用 `product-experience-foundation`。普通单功能原型不得擅自创建或重写全局产品基线。

先检查现有项目中的：

- 相邻页面。
- 页面布局框架。
- 路由结构。
- 组件目录。
- 公共 Hook 和工具函数。
- CSS 变量。
- 主题文件。
- 设计 Token。
- 图标使用方式。
- 表格样式。
- 表单样式。
- 弹窗和抽屉样式。
- 消息和通知样式。
- 当前状态管理方式。

需要理解现有项目的：

- 信息密度。
- 页面间距。
- 字体层级。
- 圆角大小。
- 颜色使用方式。
- 导航结构。
- 组件调用方式。
- 响应式策略。

新增内容应该像现有系统自然扩展出来的，而不是重新做一套系统。

### 2. 优先复用，不重新造轮子

优先复用项目已有的：

- 按钮。
- 表格。
- 表单。
- 下拉选择。
- 日期选择器。
- Tab。
- 弹窗。
- 抽屉。
- 分页。
- 状态标签。
- 消息提示。
- 页面布局组件。
- 图标。
- 工具函数。
- Hook。
- 设计 Token。

如果现有项目已经具备相应能力，不要重新创建第二套组件系统。

### 3. 默认隔离原型入口

原型必须基于现有源码实现，而不是复制出一套脱离项目的静态网站；同时默认与正式业务入口隔离。

优先选择项目现有约定支持的以下方式之一：

- 独立原型路由，例如 `/__prototype/<feature>` 或项目已有的 demo 路由约定。
- 独立原型页面或功能目录，并仅在开发/预览环境暴露入口。
- 不改变原页面默认行为的显式原型入口，例如查询参数、开发菜单或临时导航项。

原型入口要能复用真实页面外壳和组件，但不得默认替换线上入口、修改既有业务数据或影响其他功能。项目已有原型约定时必须优先遵循；没有约定时，选择对生产代码影响最小且易于移除的方式，并在最终回复中说明入口位置。

### 4. 把任务当成产品原型，而不是正式重构

优先服务：

- 产品评审。
- 业务演示。
- 需求讨论。
- 设计与研发对齐。
- 快速迭代。

优先使用直接、容易修改的实现方式。

除非现有项目本身已经采用相应模式，否则不要引入：

- 大范围全局重构。
- 新的架构层。
- 重型依赖。
- 过度抽象。
- 复杂状态机。

### 5. 使用模拟数据，不急着开发后端

除非用户明确要求，否则不要：

- 接入真实接口。
- 设计后端 API。
- 创建服务层。
- 处理生产数据链路。

模拟数据尽量放在页面或当前功能附近，方便产品经理调整。

使用本地状态模拟：

- 新增。
- 编辑。
- 删除。
- 搜索。
- 筛选。
- 排序。
- Tab 切换。
- 选择。
- 状态变化。
- 抽屉打开。
- 弹窗打开。
- 表单提交。
- 二次确认。
- 成功提示。
- 错误提示。

### 6. 原型必须可以点击

除了核心主流程，还应根据需求补充产品经理评审时需要查看的状态：

- 搜索。
- 筛选。
- Tab。
- 选择。
- 详情查看。
- 空状态。
- 加载状态。
- 表单校验。
- 禁用状态。
- 二次确认。
- 成功反馈。
- 错误反馈。
- 返回路径。
- 多步骤导航。

如果需求包含多个步骤，应让流程可以完整跳转，而不是留下多个互不关联的静态页面。

### 7. 不要把业务系统做成营销官网

当用户需要的是应用、工具、后台、CRM、运营系统或业务工作台时：

- 不要制作超大首屏标题。
- 不要优先使用营销式视觉构图。
- 不要用大量装饰性渐变和背景作为主视觉。
- 不要为了视觉效果大幅降低信息密度。
- 不要用营销卡片替代真实业务控件。

---

## 五、编码前需要完成的分析

开始写代码前，先从需求和项目中提取：

- 产品目标。
- 目标用户或角色。
- 用户需要完成的核心任务。
- 需要新增或修改的页面。
- 现有相似页面。
- 页面入口。
- 主要用户流程。
- 必要字段。
- 必要状态。
- 不同角色的权限差异。
- 必须实现的交互。
- 模拟数据需求。
- 产品假设。
- 尚未明确的业务规则。

用户已经提供的信息不要重复询问。

如果只是展示层细节缺失，可以使用合理假设。

不能擅自补充会改变产品范围的核心业务规则。

---

## 六、项目检查流程

### 第一步：识别技术栈

确认：

- 前端框架。
- 构建工具。
- 路由方式。
- UI 组件库。
- 图标库。
- 样式方案。
- 状态管理方式。
- 数据请求约定。
- 测试或预览方式。

### 第二步：寻找相似页面

优先查找：

- 同类型列表页。
- 同类型详情页。
- 同类型表单。
- 同类型数据看板。
- 同类型弹窗或抽屉。
- 同类型业务流程。
- 同类型空、加载和错误状态。

以这些页面作为新页面的实现参考。

### 第三步：识别可复用内容

列出本次应复用的：

- 组件。
- Hook。
- 设计 Token。
- 工具函数。
- 页面布局。
- 交互方式。

避免重复实现已有能力。

### 第四步：理解现有视觉系统

检查：

- 页面宽度。
- 内容区内边距。
- 模块间距。
- 字体层级。
- 按钮样式。
- 表单密度。
- 表格密度。
- 状态颜色。
- 边框样式。
- 阴影使用。
- 响应式断点。

### 第五步：确定原型范围

明确：

- 原型入口放在哪里，以及它与正式入口如何隔离。
- 需要新增的原型页面或模块。
- 用户是否明确要求修改既有业务页面。
- 哪些交互必须可点击。
- 哪些数据使用模拟数据。
- 哪些状态必须体现。
- 哪些产品假设是必要的。
- 当前功能复用了哪些产品级页面模式。
- 哪些新模式仅限当前功能，哪些可作为后续晋升候选。

---

## 七、模拟数据标准

模拟数据应使用真实业务语言。

避免使用：

- Test User。
- Lorem ipsum。
- Company A。
- Sample Data。
- User 001。

模拟数据应尽量覆盖：

- 不同状态。
- 长文本。
- 缺失值。
- 警告信息。
- 边界数据。
- 不同用户决策。
- 不同业务阶段。
- 空结果。
- 禁用操作。

模拟数据的作用不是填满页面，而是帮助产品经理发现页面和交互问题。

---

## 八、产品假设规则

AI 可以合理补充展示层细节，例如：

- 示例姓名。
- 示例日期。
- 示例列表数据。
- 空状态文案。
- 成功和错误提示。
- 常见筛选条件。
- 符合现有项目习惯的交互方式。

AI 不得默默补充以下核心业务逻辑：

- 新的业务状态。
- 新的角色权限。
- 新的审批规则。
- 新的业务计算方式。
- 新的管理模块。
- 新的产品范围。
- 新的外部系统依赖。

如果为了演示必须做出假设，应在最终回复中集中说明。

如果新交互与产品体验基线冲突，不得静默覆盖。应遵循已确认基线，或将偏离原因和“是否需要回写基线”列为待确认项。

---

## 九、UI 与交互标准

### 1. 信息架构

优先保证：

- 层级清晰。
- 分组合理。
- 字段选择有效。
- 主操作明显。
- 信息密度稳定。
- 页面容易扫描。

### 2. 控件选择

优先使用用户熟悉的控件：

- 工具操作使用图标按钮。
- 模式切换使用分段控制。
- 二元设置使用开关或复选框。
- 数值设置使用输入框、滑块或步进器。
- 多选项使用菜单或下拉。
- 同级视图使用 Tab。
- 次级任务使用抽屉或弹窗。

### 3. 卡片使用

不要出现卡片嵌套卡片。

卡片适合用于：

- 重复列表项。
- 弹窗。
- 抽屉。
- 独立工具。
- 需要明确框定的数据组。

不要把页面每一个区块都包成卡片。

### 4. 控制装饰

避免：

- 装饰性渐变光团。
- 漂浮圆球。
- 散景效果。
- 无意义 SVG 装饰。
- 纯氛围背景。
- 营销式首屏。
- 单一色调占满页面。

实现后检查 CSS，如果页面几乎只剩一种色系，应适当调整。

特别注意避免：

- 大面积紫色或蓝紫渐变。
- 大面积米色或沙色。
- 大面积深蓝或灰蓝。
- 大面积棕色或橙色。

### 5. 文本与布局稳定性

确保文字能够适配：

- 按钮。
- 表格单元格。
- 卡片。
- 侧边栏。
- 抽屉。
- 弹窗。
- 移动端容器。

根据需要使用：

- 自动换行。
- 文本截断。
- 最小和最大宽度。
- 稳定网格。
- `aspect-ratio`。
- 容器相对尺寸。

不要根据视口宽度动态缩放字体。

除非现有设计系统要求，否则字间距保持为 `0`。

### 6. 不在产品界面里解释原型

不要在页面中展示以下说明：

- 这个原型是如何制作的。
- 使用了哪些临时方案。
- 评审者应该如何理解页面。
- 哪些交互是模拟的。

只有产品本身确实需要帮助内容时，才在界面内增加说明。

---

## 十、响应式范围

### 桌面后台系统

如果项目明显是桌面后台：

- 优先把桌面端做好。
- 保持稳定的信息密度。
- 确保小屏下不会完全崩坏。
- 避免关键操作不可访问。
- 尽量避免不必要的横向滚动。

### 移动端或消费者产品

如果产品面向消费者、移动优先，或用户明确要求移动端：

- 同样认真设计移动端布局和交互。
- 检查点击区域大小。
- 检查控件裁切。
- 检查固定定位元素。
- 检查安全间距。
- 根据需要检查键盘和表单行为。

### 所有页面都需要检查

- 文字重叠。
- 控件裁切。
- 操作入口隐藏。
- 页面导航断点。
- 横向溢出。
- 表格不可读。
- 抽屉或弹窗无法使用。

---

## 十一、实现流程

### 第一步：读取现有项目

检查相关项目结构和相似页面。

### 第二步：明确原型入口与范围

整理：

- 原型页面、路由或功能目录的位置。
- 与正式业务入口的隔离方式。
- 仅当用户明确要求时修改的既有页面或模块。
- 核心用户流程。
- 必须实现的交互。
- 模拟数据状态。
- 可复用组件。

### 第三步：沿用现有项目方式实现独立原型

保持现有：

- 技术框架。
- 组件系统。
- 样式方式。
- 路由方式。
- 图标。
- 工具函数。
- 状态管理习惯。

### 第四步：增加模拟数据和交互

使用本地状态实现本次评审所需的完整流程。

### 第五步：补充必要状态

只增加与当前功能相关的状态：

- 空状态。
- 加载状态。
- 校验状态。
- 禁用状态。
- 成功状态。
- 错误状态。
- 二次确认。
- 无权限状态。
- 数据不可用状态。

### 第六步：实际运行项目

需要时启动现有本地开发服务。

项目无法预览前，不要宣称任务已经完成。

### 第七步：进行视觉和交互检查

检查：

- 页面不是空白。
- 样式正常加载。
- 图标和资源正常显示。
- 文字没有明显溢出。
- 布局不会异常跳动。
- 核心交互可以使用。
- 导航没有死路。
- 响应式表现可接受。

有条件时，使用浏览器检查或截图验证。

---

## 十二、最终交付物

根据任务实际情况，最终应包括：

- 新增或修改的前端源码。
- 独立原型页面、功能目录或路由，以及入口说明。
- 仅在用户明确要求时修改的既有业务页面。
- 复用的公共组件。
- 本地模拟数据。
- 可点击的核心交互。
- 相关空、加载、校验、禁用、成功和错误状态。
- 可正常使用的页面导航。
- 项目运行或预览说明。
- 产品假设说明。
- 尚未明确的业务规则清单。
- 如创建 `demo.md`，记录评审确认后的推荐交付路径与判断证据；它只做交接标记，不替代 OpenSpec、Superpowers 或项目工程流程的正式工件。正式交付与实现交给 `prototype-to-product`。

除非对运行或评审有帮助，否则不要额外创建大量文档或架构文件。

---

## 十三、完成标准

满足以下条件后，原型才算完成：

- 原型页面或模块已经存在于当前项目中，并与正式业务入口隔离（除非用户明确要求覆盖原入口）。
- 视觉风格与现有项目一致。
- 已合理复用现有组件和设计 Token。
- 核心用户流程可以从开始走到结束。
- 每个主要操作都有明确反馈。
- 页面导航没有死路。
- 关键操作后模拟数据能够更新。
- 相关页面状态已经体现。
- 文字没有明显溢出。
- 项目可以在本地正常运行，没有阻塞错误。
- 没有擅自扩大已经确认的产品范围。
- 最终回复明确说明了产品假设和待确认规则。

---

## 十四、最终回复要求

完成后，使用产品经理容易理解的方式说明：

- 新增或修改了哪些页面、模块和流程。
- 原型入口的位置，以及它如何与正式业务入口隔离。
- 哪些交互已经可以点击。
- 增加了哪些模拟数据和页面状态。
- 复用了哪些现有组件和项目规范。
- 做出了哪些产品假设。
- 哪些业务规则仍待确认。
- 如何运行或预览原型。
- 完成了哪些视觉和交互检查。
- 复用了哪些产品体验基线；如出现重复新模式，说明其是否只是候选，未确认前不将其抽成全局规则。
- 评审确认后推荐的交付路径：`direct`、`openspec`、`superpowers` 或项目指定流程；仅记录判断证据，不在原型阶段伪造工程工件或擅自实现生产代码。实际交付与实现由 `prototype-to-product` 执行。

最终回复应简洁，重点说明产品经理需要评审的内容。