--- 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/` 或项目已有的 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`，记录评审结论与待确认事项；它只做交接标记，不替代项目自己的工程工件。 除非对运行或评审有帮助，否则不要额外创建大量文档或架构文件。 --- ## 十三、完成标准 满足以下条件后，原型才算完成： - 原型页面或模块已经存在于当前项目中，并与正式业务入口隔离（除非用户明确要求覆盖原入口）。 - 视觉风格与现有项目一致。 - 已合理复用现有组件和设计 Token。 - 核心用户流程可以从开始走到结束。 - 每个主要操作都有明确反馈。 - 页面导航没有死路。 - 关键操作后模拟数据能够更新。 - 相关页面状态已经体现。 - 文字没有明显溢出。 - 项目可以在本地正常运行，没有阻塞错误。 - 没有擅自扩大已经确认的产品范围。 - 最终回复明确说明了产品假设和待确认规则。 --- ## 十四、最终回复要求 完成后，使用产品经理容易理解的方式说明： - 新增或修改了哪些页面、模块和流程。 - 原型入口的位置，以及它如何与正式业务入口隔离。 - 哪些交互已经可以点击。 - 增加了哪些模拟数据和页面状态。 - 复用了哪些现有组件和项目规范。 - 做出了哪些产品假设。 - 哪些业务规则仍待确认。 - 如何运行或预览原型。 - 完成了哪些视觉和交互检查。 - 复用了哪些产品体验基线；如出现重复新模式，说明其是否只是候选，未确认前不将其抽成全局规则。 - 评审确认后由研发按原型实现；不在原型阶段伪造工程工件，也不擅自实现生产代码。 最终回复应简洁，重点说明产品经理需要评审的内容。