本文作者：meng shao（@shao__meng）。版权归作者所有，未经授权禁止转载。

前端设计资源从来不缺。真正稀缺的是一套判断方法：什么时候需要看真实产品，什么时候应该查设计规范，什么时候可以复制组件，什么时候必须回到无障碍、性能和用户任务本身。

今天整理我自己在 X Bookmark 的很多设计资源，内容已经多到只能收藏吃灰，所以就让 Codex 帮我整理归类，从产品案例库、设计系统、组件基础层、动效资源与质量标准这些角度整理，作为一张面向实际工作的资源地图。

有效的使用顺序是：

真实案例提供证据 → 设计原则解释原因 → 设计系统形成约束 → 组件资源加速实现 → 无障碍与性能完成验收

一、先区分五种资源

很多资源表面上都在展示“好看的界面”，但它们解决的问题并不相同。

| 类型 | 它回答的问题 | 典型输出 | 最容易产生的误用 |
| --- | --- | --- | --- |
| 真实产品案例 | 成熟产品实际上怎样解决这个任务？ | 页面、完整流程、交互录像 | 只抄视觉，不理解业务条件 |
| 设计模式与拆解 | 这个方案为什么有效？ | 原则、模式、正反例 | 把通用原则当成固定答案 |
| 设计系统与令牌 | 如何让多个页面和团队保持一致？ | Tokens、组件规范、维护规则 | 过早建设庞大系统 |
| 组件与动效实现 | 怎样更快、较可靠地完成开发？ | 源码、CLI、可复制组件 | 拼装出缺乏统一语言的产品 |
| 质量标准与测试 | 它是否真的可用、可访问、够快？ | WCAG、测试、性能指标 | 只跑自动化分数，不做人工验证 |

只要先判断当前问题属于哪一类，资源检索的效率就会明显提高。

二、真实产品案例：先研究任务，不要先挑风格

1. 产品界面与完整用户流程

UXSnaps：强调“为什么这样设计”

UXSnaps 将真实产品案例按信息架构、渐进披露、错误预防、视觉层级、转化、反馈等原则标注，并提供 Quick Read 与 Deep Dive 两种阅读方式。它适合产品经理、设计师和前端工程师共同讨论方案，因为关注点不是单张截图，而是设计选择及其理由。

适合查询：AI 工作台、仪表盘、搜索结果、设置、订阅、编辑器、结算和复杂表单。

Mobbin：覆盖面最广的真实界面数据库

Mobbin 同时收录移动应用、Web 产品、网站、UI 元素和完整流程。其官网当前展示超过 1,000 个 iOS 与 Web 应用，并支持按 Screens、UI Elements、Flows 及截图文字检索；部分流程可用视频或交互热点逐屏查看，也可以复制到 Figma。Mobbin 官方介绍

它适合回答非常具体的问题，例如：

  • 不同产品如何设计 Paywall、Checkout、Onboarding？
  • 复杂设置页的信息层级通常怎样组织？
  • 用户完成支付、退款或账户初始化时会经历哪些步骤？

Mobbin 的局限是信息量巨大且大量高级能力付费。使用时应带着任务检索，而不是漫无目的浏览。

SaaSFrame：更聚焦 SaaS 的网站、产品和邮件

SaaSFrame 将营销网站、产品界面、用户流程和邮件序列放在同一个资料库中，官网称目前包含 5,000 多个真实案例，并支持页面、产品流程、版本对比和截图文字搜索。SaaSFrame 官方介绍

它特别适合 B2B SaaS：可以同时研究获客页面、注册、激活、升级、账单和生命周期邮件，而不是把网站与产品体验割裂处理。

其他值得保留的入口

  • Page Flows：侧重真实产品流程和交互录像。
  • Refero：适合快速检索 Web 与 App 界面参考。
  • SaaS UI：按 SaaS 模式和软件类别整理真实产品案例。

这些站点更接近“设计证据库”，优先级通常高于纯视觉画廊。

2. 营销页面、品牌和视觉表达

posts.design：真实品牌发布内容

posts.design 收集公司实际发布到社交媒体的产品公告、品牌卡片和 Launch 内容，并支持 Recent、Announcements、Top Launches、By Brand 等视图。它适合研究产品发布的视觉包装，不适合作为复杂产品交互的依据。

Landingfolio、Godly 与 Siteinspire

  • Landingfolio：按 Landing Page、Hero、Pricing、Login、Signup 和组件组织经过筛选的页面参考。官方介绍
  • Godly：偏实验性、当代感较强的 Web、App 和视觉作品。官方介绍
  • Siteinspire：适合按行业与风格检索网站，覆盖排版、网格、作品集、电商和艺术指导等维度。官方目录
  • Made in Webflow：既可以观察已发布网站，也能筛选并克隆可复用项目。Webflow 当前将其定位为可浏览、克隆和定制的网站集合。官方展示库

这类画廊最适合确定视觉方向、构图和品牌气质。它们无法证明某个页面的转化效果，也不能替代可用性验证。

三、设计模式与细节：从“好看”进入“有理由”

Design Spells：收集让产品有生命力的细节

Design Spells 记录真实产品里的微交互、转场、拟物细节、彩蛋和特殊反馈，并按 Mobile、Desktop、Interaction、Animation、Motion、Transition、3D 等标签组织。

它适合研究：

  • 为什么某个完成状态令人愉悦；
  • 如何让等待、解锁或状态切换更有反馈；
  • 哪些品牌化细节可以形成记忆点。

使用原则是“解释反馈”，而不是“到处加动画”。高频工具和企业后台尤其需要克制。

Component Gallery：横向比较成熟设计系统

The Component Gallery 不是组件代码市场，而是把多个公共设计系统中的同类组件放在一起比较。当前官网展示 60 类组件、95 个设计系统和 2,600 多个例子，还可以按开源、代码示例、无障碍、使用规范、语气与技术栈筛选。Component Gallery

当团队需要定义自己的 Breadcrumb、Popover、Rating、Tree View 或错误提示时，先横向阅读多个成熟系统，通常比直接发明规则更可靠。

Design System Checklist：检查完整性

Design System Checklist 将建设工作分为设计语言、基础、核心组件和维护四部分。它的价值是提醒团队：设计系统不仅是 Figma 组件库，还包括命名、文档、版本、贡献机制和长期维护。

UI Skills：将设计知识转成 Agent 可执行规则

UI Skills 汇集无障碍、动效、视觉、交互、性能和系统设计技能，并提供 CLI、MCP、Agent 集成与细粒度 Playbook。它代表了一种新的资料形态：设计规则不只供人阅读，还可以在生成、审查和改造界面时交给编码 Agent 执行。

这类技能更擅长放大已有约束。若项目缺少内容结构、用户目标和品牌判断，安装更多技能并不会自动产生好设计。

四、设计系统与 Design Token：把一次性界面变成可维护产品

1. 使用标准化 Design Token

颜色、排版、间距和圆角如果只散落在 Figma 与 CSS 中，系统会在迭代中逐渐分裂。Design Token 通过有意义的名称连接设计决策与代码实现。

Design Tokens Community Group 已在 2025 年发布稳定的 2025.10 技术报告；其格式规范旨在提高不同设计和开发工具之间的互操作性。DTCG 稳定规范

Tokens Studio 适合在 Figma 中管理颜色、尺寸、间距、排版、阴影和主题，并将 Tokens 转换到开发工作流。Figma 也将设计令牌定义为带名称的可复用设计决策，用来保持设计文件与生产代码同步。Figma 的设计令牌指南

实践上可以分三层：

Primitive Token blue-600 / space-4 / radius-3 ↓ Semantic Token color-action-primary / space-section ↓ Component Token button-primary-bg / dialog-padding

不要一开始就 Tokenlize 所有数值。先处理颜色、排版、间距、圆角和高频组件，再根据真实复用需求扩展。

2. 用 Storybook 把组件变成可验证文档

Storybook 适合独立开发和记录组件状态，并将交互、视觉与无障碍测试放到组件层。其官方测试文档强调在同一组件故事中开发、调试、维护和协作，而不只是展示静态 Demo。Storybook UI 测试

一个成熟组件条目至少应包含：

  • 适用与不适用场景；
  • 默认、Hover、Focus、Disabled、Loading、Error 等状态；
  • 键盘与屏幕阅读器行为；
  • 内容长度、国际化和响应式边界；
  • 设计令牌与可覆盖范围；
  • 视觉回归和交互测试。

五、组件实现：先选基础层，再选视觉层

组件资源最好分成三层理解。

第一层：行为与无障碍基础

  • Base UI：无样式 React 组件，强调组合能力、可访问性和边界情况；官网说明其遵循 ARIA Authoring Practices，并覆盖与组件行为相关的 WCAG 2.2 要求。Base UI 官方说明
  • React Aria：适合表单密集、国际化和复杂交互场景。
  • Radix Primitives：提供焦点管理、键盘导航、ARIA 属性等低层能力，可逐步采用。Radix 官方介绍

截至 2026 年 7 月，shadcn/ui 已将 React Aria 作为一等组件基础，同时继续支持 Base UI 和 Radix，可在初始化项目时选择底层实现。shadcn/ui 官方更新

第二层：可复制的视觉与业务组件

ReUI

ReUI 当前提供超过 1,000 个面向 React、Tailwind CSS 和 shadcn/ui 的组件示例，覆盖 Data Grid、Gantt、Kanban、Event Calendar、File Upload、Dashboard、CRM、Billing 和电商等复杂场景。

它适合快速实现后台和 SaaS，但复制后仍需统一项目自己的令牌、内容结构、焦点行为和响应式策略。

21st.dev

21st.dev 是由多个设计工程师贡献的 React 组件、模板、主题、Shader 和渐变注册表。与单一 npm 组件库不同，它聚合不同作者和视觉方向，并将代码复制进项目；官网当前展示超过 12,000 个条目。21st.dev 官方目录

它适合探索和快速组装，但不同来源的组件在 API、依赖、质量和视觉语言上可能不一致。正式产品中应先筛选，再纳入内部组件系统。

第三层：团队自己的设计系统

外部组件只能作为原料。最终仍需用自己的 Tokens、组件 API、内容规范、Storybook 与测试，把它们收敛为一个系统。

六、动效与视觉增强：从状态变化出发

日常产品动效

Transitions.dev

Transitions.dev 围绕 Card Resize、Modal、Tooltip、Toast、Tabs、Skeleton Reveal、错误抖动、数字变化、流式文本和 AI Reasoning 等真实状态提供可预览、可复制的 CSS，并带有 Agent Skill 与 Refine 工具。

它适合作为常规产品动效基线，因为多数动画都对应清晰的状态变化。

Motion Primitives 与 Animate UI

  • Motion Primitives：开源、可复制、可定制的动效组件，面向设计师与工程师协作。官方介绍
  • Animate UI：基于 React、Tailwind CSS、Motion 和 shadcn registry 的动画组件分发，区分带动效的 Primitives 与更完整组件。官方文档
  • Motion：更适合需要自己控制布局动画、手势、滚动和时间线的项目，而不是只复制现成效果。Motion 官方网站

强表现力和品牌场景

  • Amicro：弹簧、惯性、磁吸、液体、折叠和趣味型微交互，适合关键反馈和品牌化节点。
  • ThreeUI：程序化 three.js 组件、3D Hero、WebGL 背景和 Landing Page 模板，适合低频、高关注度的营销页面。
  • Magic UI：面向设计工程师的 React、TypeScript、Tailwind 和 Motion 动画组件。官方介绍

强动效使用前必须检查：

  • 是否解释了层级、因果或状态变化；
  • 是否支持 prefers-reduced-motion；
  • 是否阻塞输入或延迟任务完成；
  • 在中低端设备和触屏环境下是否稳定；
  • 是否增加 LCP、INP 或布局偏移成本。

背景、渐变和视觉素材

  • Backgrounds Supply：成品渐变、AI 背景与动态视频，用于网站、演示、社媒和动效项目。
  • Grainient：颗粒与动态渐变。
  • Ditther：实验性图像生成与视觉处理。
  • Haikei：可导出的 SVG 背景生成器。

素材库解决的是制作效率，不是品牌策略。购买前应查看许可证正文；例如 Backgrounds Supply 首页当前不同区域出现过不同的素材总数和集合数量，实际权益应以结账页和许可证为准。

七、质量验收：好看不是完成

1. 无障碍

WCAG 2.2 是当前正式的 W3C Web 内容无障碍建议。它覆盖可感知、可操作、可理解和健壮性，并建议在制定或更新无障碍策略时采用当前版本。W3C WCAG 2.2

ARIA Authoring Practices Guide 提供常见控件的键盘行为、角色、状态与属性示例，但 W3C 明确说明 APG 是指导性资料而非规范本身，也不是一套 UI 设计系统。APG 说明

The A11Y Project Checklist 将检查拆为内容、键盘、图片、标题、控件、表格、表单、媒体、动画、颜色对比和移动触控等部分。它适合作为日常清单，但官方也明确指出，清单不能保证网站完全无障碍，仍需要人工及专业测试。A11Y Project

2. 性能与稳定性

web.dev 提供由 Chrome 团队及外部专家维护的性能、无障碍和 Web 平台资料。当前 Core Web Vitals 关注三项用户体验指标：LCP、INP 和 CLS，分别对应主要内容加载、交互响应和视觉稳定性。Core Web Vitals 指标说明

| 检查方向 | 至少要验证 |
| --- | --- |
| 键盘 | 所有功能可操作，焦点顺序合理，Focus 清晰可见 |
| 屏幕阅读器 | 名称、角色、状态和错误信息可理解 |
| 颜色 | 文字和控件对比度满足目标等级，不能只靠颜色传达状态 |
| 动效 | 减少动态偏好生效，不闪烁，不阻碍任务 |
| 响应式 | 窄屏、缩放、长文本和国际化内容不会破坏结构 |
| 性能 | 真实设备和网络条件下检查 LCP、INP、CLS |
| 状态完整性 | Loading、Empty、Error、Offline、Permission、Success 均有设计 |
| 自动化之外 | 至少进行键盘、读屏、触屏和真实任务的人工走查 |

八、四类项目的推荐组合

1. SaaS 后台或复杂业务系统

Mobbin / UXSnaps / SaaSFrame ↓ Component Gallery / Design System Checklist ↓ Base UI 或 React Aria ↓ ReUI 作为业务组件参考 ↓ Tokens + Storybook + WCAG / Core Web Vitals

优先级：信息架构、表单行为、数据密度、权限与错误状态高于视觉特效。

2. 产品发布页或品牌网站

posts.design / Landingfolio / Godly / Siteinspire ↓ 明确品牌叙事与内容层级 ↓ Transitions.dev / Motion Primitives ↓ 选择性使用 Amicro / ThreeUI / 背景素材 ↓ 移动端、Reduced Motion、LCP / INP 验收

优先级：内容、排版和视觉节奏高于动画数量。

3. AI 产品与 Agent 界面

UXSnaps 中的 AI Workspace 案例 ↓ 研究流式输出、思考状态、取消、重试和权限边界 ↓ UI Skills + Transitions.dev ↓ ReUI / 21st.dev 选取实现原料 ↓ 重点测试长任务、失败恢复和用户控制

AI 界面的核心不是“Shimmer 效果”，而是让系统状态、能力边界和用户控制始终清晰。

4. 从零建立团队设计系统

Design System Checklist ↓ Component Gallery 横向研究 ↓ DTCG Tokens + Tokens Studio / Figma Variables ↓ Base UI / React Aria / Radix ↓ Storybook 文档与组件测试 ↓ WCAG + 人工辅助技术测试

优先建设高频、行为复杂、风险较大的组件，不必追求一次覆盖所有页面。

九、把收藏变成可复用知识

仅仅保存链接，很快会形成第二个无法检索的信息流。建议每条参考至少记录以下字段：

| 字段 | 示例 |
| --- | --- |
| 资源类型 | 完整流程 / 设计模式 / 组件 / 动效 / 素材 / 标准 |
| 解决的问题 | SaaS Onboarding、数据筛选、AI Loading |
| 值得借鉴 | 信息层级、反馈方式、内容表达 |
| 不应照搬 | 品牌色、业务假设、过度动效 |
| 实现成本 | 低 / 中 / 高，以及关键依赖 |
| 风险 | 无障碍、性能、许可证、维护状态 |
| 项目关联 | 当前哪个产品或页面可能使用 |

每次开始界面任务，可以用四个问题筛选收藏：

  1. 我要解决的用户任务是什么？
  2. 有哪些真实产品已经处理过类似任务？
  3. 哪些原则和约束能够解释可取之处？
  4. 哪种实现能在不牺牲无障碍、性能和一致性的前提下复用？

十、精简后的核心书签

如果只保留一组高频入口，可以缩减为以下 15 个：

研究真实产品

  • Mobbin
  • UXSnaps
  • SaaSFrame
  • posts.design

建立原则与系统

  • Component Gallery
  • Design System Checklist
  • UI Skills
  • DTCG Design Tokens

实现组件与动效

  • Base UI
  • React Aria
  • ReUI
  • Transitions.dev
  • Motion Primitives

验收质量

  • W3C WCAG 2.2
  • web.dev

结语

成熟的前端设计工作并不是从组件库开始，也不会以“页面看起来不错”结束。

高质量结果通常来自一条完整链路：先用真实产品理解问题，用设计模式和原则解释方案，再通过 Tokens、组件和动效实现，最后以无障碍、性能和真实任务测试验证。AI 与组件市场可以显著加快其中的执行环节，但无法替代上下文、取舍与品味。

真正值得积累的不是更多链接，是知道每个链接在设计决策中扮演什么角色。