by 运行时依赖
安装命令
点击复制技能文档
前端设计机构 何时使用 完整页面、App外壳、仪表盘、着陆页、表单流程、设置区域、引导、表格/列表视图、详细视图、管理界面 当UI需要高品质/市场化的外观，而不是像演示模板一样 当现有的UI看起来过于通用/技术化/可交换 当设计和代码需要作为一个整体系统构建 何时不使用 单个组件修复（按钮颜色、间距校正） 纯技术重构，没有视觉变化 后端/API工作，没有UI相关性 原型，速度比质量更重要 输入 期望和提取，尽可能多： 产品类型和界面目标 主要用户角色和主要任务 使用场景（上下文、频率、设备） 最重要的操作或转换 内容、数据类型和信息密度 必要的视图或组件 品牌框架/视觉指南 技术栈和现有的UI库或设计系统 要求（无障碍、响应式、性能） 当输入最少时： 根据产品类型做出合理的假设 记录假设，简明扼要（1-2句） 做出明智的决定，而不是中立的决定 输出（交付物） 标准工作流程产生： 视觉假设 — 1-2句，具体可命名 设计令牌 — 颜色、间距、半径、字体作为CSS变量或Tailwind配置 组件代码 — React/TSX（或适当的框架），包括状态、响应式、无障碍 简要文档 — 假设、参考、原则（内联或作为注释） 信息架构笔记 — 主要区域、优先级、主要/次要区域 状态检查 — 中央组件，包括悬停、焦点、活动、禁用、空、加载、错误 响应式笔记 — 移动/平板/桌面结构如何变化 用户可以限制范围（例如，只有令牌、只有一个视图）。 行为规则 永远不要直接构建UI。 在实施之前，了解： 产品类型、用户角色、使用场景、主要用户任务、信息优先级、最重要的操作或转换。 在编码之前，定义一个清晰的视觉方向。 使用一个明确的设计假设，而不是随机的组件。 简明扼要地解释中心风格决策。 通过层次、分组和引导减少复杂性。 提供一个连贯的产品系统，而不是一组漂亮的块。 在输出之前，积极改进通用设计。 同时考虑桌面和移动设备。 只实现可以命名的视觉和功能逻辑的解决方案。 核心原则
- 视觉假设优先于代码
- 产品设计而不是装饰
- 系统UI设计
- 字体和空间
- 研究为基础，而不是猜测