[!info] related notes

• 所属 MOC: ui-ux-moc
• 相关概念:
• 易混淆概念:
• 相关资源:

Design System：从 Token 到产品界面

一句话理解 Design System

Design System 不是一套颜色表，也不等于组件库。

它更接近：

把产品中反复出现的视觉语言、交互行为和组合方式沉淀成可复用的规则与实现，让团队不需要在每个页面重新做一次设计决策。

最短结构：

Design Tokens
    ↓
Components
    ↓
Patterns
    ↓
Product Composition
    ↓
Pages / Features

第一层：Design Tokens

Token 是最基础的设计变量，例如：

color.background
color.surface
color.text.primary
color.text.secondary
color.border.subtle
color.intent.danger

space.1
space.2
space.3
space.4

font.body
font.heading

radius.sm
radius.md
radius.lg

motion.fast
motion.normal

为什么不应该到处写 Magic Value

如果每个页面直接写：

padding: 17px;
color: #e7e9ec;
border-radius: 11px;

页面之间会逐渐漂移。

更稳定的是使用共享尺度和语义：

space-4
surface-muted
text-secondary
radius-md

这样 Design System 才能统一调整，而不是全仓库找数字。

间距系统可以直接复用 UI设计中的间距管理。

第二层：Components

组件是可复用的基础交互单元，例如：

Button
Input
Checkbox
Dialog
Popover
Tabs
Tooltip
Toast
Card
Drawer

一个成熟组件并不只是视觉样式，还要包含状态：

idle
hover
focus
active
disabled
loading
error
selected

因此组件库和交互设计天然连接。

第三层：Patterns

Pattern 和 Component 是非常重要的区别。

Component

Dialog
Button
Input

它们只是积木。

Pattern

Delete Confirmation
Search
Empty State
Create Flow
Provider Setup
Approval Flow
Onboarding

Pattern 表达的是一类反复出现的用户任务和交互方案。

例如 Delete Confirmation 可能由：

Dialog + Warning Copy + Cancel Button + Destructive Button

组成。

如果团队只有组件库，没有 Pattern，每个业务仍然会用同一批组件拼出完全不同的行为。

第四层：Product Composition

页面不应该只是：

拿组件库里的东西拼起来

还需要遵守产品级规则：

• 什么是主导航；
• 什么放 Drawer；
• Empty State 怎样工作；
• Error 放在哪里；
• 对危险动作如何确认；
• Detail Panel 怎样切换；
• AI Tool Call 怎样展示；
• 各种状态是否使用相同语言。

这部分连接 信息架构、User Flow 和 交互设计。

Visual System：一致不是“全部长一样”

一致性意味着相同语义使用相同表达。

例如：

Primary Action
→ 始终有统一视觉优先级

Danger
→ 始终使用相同风险语义

Selected
→ 相同类型对象使用相同选中语言

Secondary Text
→ 不在不同页面随机变成不同灰度和字号

不是要求所有页面都套同一个 Card 模板。

Semantic Token 比原始颜色更重要

不理想：

gray-700
red-500
blue-600

业务组件直接依赖这些值以后，语义会散落。

更好的是：

text-primary
text-muted
surface-elevated
border-subtle
intent-danger
intent-warning
selection-active

再由主题把它们映射到具体颜色。

这样 Dark Mode、品牌调整、对比度修正都会更容易。

Responsive 也应该进入 Design System

响应式不是每个页面临时写几个 media query。

应该尽量形成共享规则：

Desktop
→ 多区域并行

Tablet
→ 次要区域折叠

Mobile
→ 单任务优先，Panel / Drawer / Tab 切换

BodySense 例如：

Desktop
Chat | Body Map | Detail

Mobile
Chat / Body / Detail
通过 Tab 或 Drawer 在上下文间切换

这不是单纯“缩小宽度”，而是信息架构在不同空间中的重新表达。

Accessibility 也是系统能力

如果每个业务自己考虑无障碍，很容易遗漏。

Design System 应把以下行为尽可能下沉到基础组件：

• Semantic HTML；
• Keyboard navigation；
• Focus state；
• 可访问名称；
• ARIA 状态的正确边界；
• Touch Target；
• Color Contrast；
• Reduced Motion。

已有知识可复用 HTML 可访问性基础 和 HTML 可访问性 MOC。

BodySense 应该沉淀哪些设计系统资产

BodySense 不一定一开始就建立庞大设计系统，但高频语义值得沉淀。

Tokens

例如：

surface/background
text hierarchy
spacing scale
body-region selection
observation status
safety intent
radius
motion

健康语义色必须稳定，避免同一个颜色在一个页面表示“选中”，另一个页面表示“风险”。

Components

可能包括：

Consultation Composer
Body Region Marker
Body Region Selector
Status Badge
Evidence Link
Inline Notice
Empty State
Loading / Skeleton

Patterns

更值得沉淀的是：

Body Region Exploration
Ask User / Clarification
AI Streaming Response
Evidence Disclosure
Safety Escalation
Correct Extracted Fact
Empty Body Record
Retry Failed Detail

尤其 Agent 应用中，Pattern 往往比单个 Button 的复用价值更大。

一个 Body Region Marker 不能只设计 Default

例如身体区域标记至少可能需要：

unrecorded
recorded
hover
focus
selected
updating
needs-confirmation

是否还需要 risk / warning，需要先确认产品语义，不能为了视觉丰富随意加颜色。

对应实现时也应该有明确的 variant，而不是散落一堆条件 class。

Design System 如何帮助 UI 减法

设计系统不仅帮助“加组件”，还帮助限制不必要的表达。

如果系统已经规定：

• Section 靠 spacing 分组；
• Card 只用于真正独立的 surface；
• Border 只在需要边界时使用；
• Secondary text 有稳定样式；

开发者就不容易在每个页面不断叠：

背景 + Card + Border + Shadow + Badge

所以 Design System 也是一种约束设计自由度、降低视觉熵的工具。

前端工程中的落地顺序

可以按下面建立：

1. Audit
盘点已有颜色、间距、字体、圆角、组件和交互差异

2. Tokens
先统一基础尺度和语义

3. Primitives
Button / Input / Dialog / Popover 等基础组件

4. States
补齐 hover / focus / loading / disabled / error 等状态

5. Patterns
沉淀 Empty / Delete / Approval / AI Streaming 等任务模式

6. Feature Composition
业务页面只组合这些规则，不随意重新发明

7. Review
检查视觉、交互、A11y 和响应式是否继续符合系统

什么时候不要过度抽象

Design System 也容易被过度工程化。

不应该因为一个页面出现一次，就立刻抽成全局组件。

一个实用判断：

• 多处重复；
• 语义稳定；
• 行为稳定；
• 一致性很重要；
• 修复应该全局生效；

这时才更值得进入设计系统。

而强业务、一次性的复杂组合可以先留在 feature 内。

Review Checklist

1. 是否直接写了大量孤立 Magic Value？
2. 相同语义是否用了不同颜色、间距或行为？
3. Component 是否只有默认态，没有 focus / loading / disabled？
4. 相同任务是否在多个页面出现不同 Pattern？
5. Dark Mode 是否仍保留语义与层级？
6. Responsive 是否只是缩放，而没有重新考虑信息优先级？
7. A11y 是否下沉到了组件，而不是靠业务页面补丁？
8. 有没有因为抽象欲望建立过多一次性组件？

最短记忆

Token 统一语言，Component 统一积木，Pattern 统一行为，Product Composition 统一整套产品的体验。

相关知识

• UI设计中的间距管理
• 视觉层级、留白与 UI 减法
• 交互设计（Interaction Design）
• 前端组件MOC
• Tailwind 设计系统 MOC
• HTML 可访问性 MOC