Fec Ui Design

---
name: fec-ui-design
description: 用于构建、审查或改进需要产品专属设计方向的前端 UI，包括设计系统生成、Master/Page 覆盖、独特视觉识别、反通用界面选择、首屏层级、UI 打磨、图表 UX、交互状态、响应式行为或视觉 QA。外部设计文件为权威时，应从该来源实现，而不是自行发明方向；中文触发词包括 UI 设计、设计系统、视觉风格、不要模板化、高级感、界面打磨、交互状态。
---

# UI 设计

适用于需要把前端界面推进到“符合产品语境、可扫描、可信赖、有辨识度，并且细节稳定”的 UI 任务。需要系统化设计建议时，加载 [design-intelligence.md](references/design-intelligence.md)；需要长期沉淀设计系统时，加载 [master-page-overrides.md](references/master-page-overrides.md)；上线前做 UI/UX QA 时，加载 [pre-delivery-checklist.md](references/pre-delivery-checklist.md)。

可执行设计系统生成器位于 [design-system.mjs](scripts/design-system.mjs)，其原创知识包包括 [product-rules.json](data/product-rules.json)、[style-archetypes.json](data/style-archetypes.json)、[ux-quality-rules.json](data/ux-quality-rules.json) 和 [stack-ui-rules.json](data/stack-ui-rules.json)。

## 用途

为页面、组件、仪表盘和工具界面建立设计方向，并完成可落地的视觉与交互 polish。

## 流程

1. 明确界面的工作
   - 先说清它帮助用户完成什么任务，而不是先选颜色或布局。
   - 判断这是日常高频工具、营销展示、内容阅读、可视化探索、游戏，还是配置/管理后台。
   - 如果已有 Figma、Sketch、MasterGo、Pixso、墨刀、摹客或截图是事实来源，优先还原设计上下文，不自行发明方向。

2. 读取设计语境
   - 在决定布局、色彩、字体或动效前，先写出一行设计读取：页面类型、目标受众、主要任务、品牌约束和可信赖感来源。
   - 判断当前界面是视觉型网站、作品/品牌展示、产品营销、工具工作区、数据密集界面、移动原生流程，还是设计稿还原任务。
   - 如果 brief 有明显分歧，例如“极简但强烈实验性”，只问一个会改变方向的问题；否则基于上下文做出明确选择。
   - 受监管、公共服务、医疗、金融、儿童或强可访问性场景优先稳定、清晰和可恢复，不为审美冒险牺牲可用性。

3. 定义审美主张
   - 写出目标用户、使用场景、可信赖感来源和一个可被记住的视觉锚点。
   - 视觉锚点可以来自信息结构、真实媒体、数据形态、行业材质、字体性格、交互节奏或空间组织，而不是空泛装饰。
   - 表现力必须服务业务语境：工具型界面重效率和稳定，展示型页面重主体识别和记忆点。
   - 为页面类型设定设计拨盘：视觉张力、动效强度、信息密度、媒体真实性和内容说服力；这些拨盘必须随任务变化，而不是沿用同一套模板。
   - 工具型和数据型界面默认提高信息密度、降低装饰动效；营销、作品集和品牌页可以提高视觉张力，但仍要保证首屏任务、主体和 CTA 可见。
   - 设计拨盘用于约束实现选择：高视觉张力不等于混乱排版，高动效强度不等于滚动劫持，高媒体真实性不等于堆 stock 氛围图。

4. 生成或读取设计系统
   - 若项目还没有设计系统，可运行 `node skills/fec-ui-design/scripts/design-system.mjs "<product audience tone>" --project "<name>"` 生成建议。
   - 若需要跨会话复用，使用 `--persist` 生成 `design-system/<project>/MASTER.md`；页面差异用 `--page <page>` 写入 `pages/<page>.md`。
   - 构建具体页面时先读页面 override，再读 Master；页面规则只覆盖差异，不复制全量设计系统。

5. 建立首屏与视觉层级
   - 工具型界面：首屏直接呈现核心工作区、列表、表格、画布或编辑器。
   - 落地页：H1 使用品牌、产品、地点、人名或明确品类，价值说明放在辅助文案。
   - 产品/对象页：首屏必须可见真实产品、对象、状态或可检查媒体。
   - 首屏应留下一个明确记忆点，但不能遮挡核心任务、导航和状态反馈。
   - 营销和产品页需要先写清受众、痛点、承诺、证据和行动入口；文案结构服务转化，但不使用夸张、空泛或不可验证的声明。
   - 视觉型页面的首屏不能只是文字、渐变和装饰物；需要真实产品、人物、空间、品牌应用、数据状态或可检查的生成资产承担主体信息。
   - 导航在桌面端应保持单行且高度克制；CTA 文案保持短而清楚，桌面端不应换成多行按钮。

6. 组织视觉语言
   - 字体：优先沿用项目字体体系；若任务允许建立新方向，选择能表达产品性格的标题/正文字体组合，并保证可读性。
   - 色彩：明确主色、功能色、中性色和强调色的角色，避免所有元素平均用力。
   - 空间：根据任务选择高密度、留白、非对称、分栏、画布式或编辑器式布局，不套用固定卡片模板。
   - 动效：只为页面入场、层级展开、状态确认、错误反馈和重点引导建立节奏，并尊重 `prefers-reduced-motion`。
   - 媒体：优先使用真实产品、真实状态、真实图表、可检查截图或本地生成资产；不要用模糊氛围图、占位 URL 或无关插画替代主体信息。
   - 图表：先判断数据任务是趋势、比较、构成、分布还是流程，再选择图表，不把所有数据都做成卡片或饼图。
   - 视觉参考：没有权威设计稿且页面视觉质量是核心目标时，可先生成或收集分区级参考图，再从图中提取布局、层级、色彩和媒体策略；不要把整站压成一个不可读长图。

7. 对齐设计系统、组件与 token
   - 先复用项目已有组件、token、图标库、路由和布局约定。
   - 缺少 token 时集中补齐或明确记录，不要在多个组件里散落硬编码。
   - 复杂 UI 在实现前写出复用组件、新建组件、响应式策略和状态覆盖。
   - 设计系统先定义语义 token、组件 API、状态矩阵和使用边界，再落到 Tailwind、CSS Modules、组件库或 CSS 变量实现。
   - Tailwind 专项 token、variant、dark mode 和 class 治理分流到 Tailwind 设计系统工作流；跨设备布局、容器查询和触摸目标分流到响应式布局工作流。
   - 组件 API 应区分基础组件、业务组件和页面私有组件；避免让单个 `variant` 同时承担语义、尺寸、密度和权限含义。

8. 打磨几何、文本和状态
   - 嵌套圆角遵循“外层圆角约等于内层圆角 + 间距”的光学关系。
   - 非对称图标、播放三角、箭头、星标等需要按视觉中心微调。
   - 标题和短文本可使用 `text-wrap: balance` 或 `text-wrap: pretty`。
   - 表格、价格、计数器、计时器使用 `font-variant-numeric: tabular-nums`。
   - 小控件点击区域至少 40x40px，空间允许时优先 44x44px。
   - focus ring 用于键盘定位，hover/active 用于鼠标反馈，disabled 不只靠透明度表达。
   - 不在连续多个区块重复同一种三卡片、左右交错或大标题加右侧说明段落；每个区块的布局服务该区块的具体信息任务。
   - Bento 和 feature grid 的格子数量必须由真实内容决定，不用空格子补构图；多格网格至少有明确主次、媒体或状态差异。
   - 小型 uppercase eyebrow 要克制使用，不能成为每个区块的节奏拐杖。

9. 验证设计结果
   - 检查 loading、empty、error、disabled、hover、focus、selected 状态。
   - 在 mobile(375px)、tablet(768px)、desktop(1440px) 检查文案是否溢出或遮挡。
   - 对依赖图片、图表、画布或 3D 的界面，确认资源真实渲染且承担主体信息。
   - 复核是否存在默认紫色渐变、空泛 hero、卡片堆叠、单一色相或无语境字体等模板化痕迹。
   - 检查首屏是否同时具备任务入口、主体识别、可信证据和下一屏内容线索；若只剩装饰，应回到信息架构重做。
   - 对生产级控件补齐 hover、active、focus-visible、disabled、loading、selected、invalid 和 skeleton 状态。
   - 对仪表盘、表格、编辑器和配置台检查扫描路径、密度、固定尺寸和重复使用时的疲劳感。
   - 对营销页、作品集和品牌页检查首屏是否适配常见小笔记本高度，导航是否单行，CTA 是否对比合格且不换行。
   - 复核是否存在连续三段以上相同 section 结构、重复 zigzag、重复三卡片、卡片套卡片、假截图或没有主体信息的视觉资产。

## 约束

- 不把工具型应用做成营销落地页；首屏应是可用工作区。
- 不用通用紫色渐变、装饰光斑、堆叠卡片或空泛 hero 作为默认方案。
- 不用三等分 feature cards、连续 zigzag、重复 eyebrow、假产品截图或不可检查媒体作为默认页面节奏。
- 不使用无语境默认字体、均匀无重点配色、重复圆角卡片和模板化双栏 hero 来替代真实设计判断。
- 不在卡片里再套大卡片；页面分区优先用全宽区域或无框布局。
- 不用可见文案解释控件本该表达的功能，常见动作优先用图标和 tooltip。
- 不为了质感添加大面积装饰、模糊光斑、无语义渐变或无关重写。
- 不为了统一风格让整个界面落入单一色相；颜色应有层次和语义区分。
- 不把生成器输出当成不可修改的设计稿；它是决策起点，必须结合项目已有组件、token、用户任务和真实数据校正。
- 不用不可检查的远程占位图、通用 stock 氛围图或 lorem 文案作为交付主体；缺素材时明确生成、制作或降级为真实结构化内容。
- 不让视觉 polish 破坏键盘路径、触摸目标、文本可读性或低端设备性能。
- 不把 Tailwind、组件库或 Storybook 文档等实现载体当成设计方向本身；它们应承接已经明确的产品语境和 token 边界。
- 不因参考系统偏好而强制某个框架、图标库、动效库或 CSS 工具；始终优先遵循当前项目依赖和设计系统。

## 预期输出

输出应包含明确的设计方向、首屏记忆点、视觉语言策略、组件/布局边界、状态覆盖、响应式策略和验证结果。复核时界面应符合业务语境、视觉层级支持快速扫描、交互状态完整，并避免泛化模板感。