01 / 03

Clean

适合文档中心、SaaS 设置和通用工具页，大面积白底配易读字体、有限蓝紫点缀与规整间距，安静清晰。

通用设计极简主义

设计语言预览

Limited Interface Palette

Primary Blue

#3b82f6

主行动、链接、焦点和最重要的选中状态。

Secondary Purple

#8b5cf6

仅用于少量次级分类或辅助强调，不与主行动竞争。

White Surface

#ffffff

页面画布、主要内容区和控件表面。

Text Ink

#111827

标题、正文和高对比控件文字。

Semantic Status

Success

#16a34a

完成、已保存和成功状态，并同时提供文字。

Warning

#d97706

待确认、临近风险和注意状态。

Danger

#dc2626

错误、阻断与破坏性操作。

字体层级

heading-page

Poppins · 32 / 600 / -2.5%

清楚找到答案，然后继续工作。

heading-section

Poppins · 24 / 600 / -1.5%

指导内容不需要视觉噪音

body-default

Roboto · 16 / 400 / 1.6

正文易读、友好、直接，适合帮助文章、设置说明和表单反馈。

label-caps

Inconsolata · 12 / 600 / +6%

WORKSPACE SETTINGS · ALL CHANGES SAVED

间距、层级与形状

1x 8px

2x 16px

3x 24px

4x 32px

6x 48px

8x 64px

形状

full

按钮、输入框和小控件使用 4px，卡片与主要容器使用 8px；以细边框和留白为主，避免 pill 与厚阴影。

层级

Level 0 · 纯白页面画布Level 1 · 白色内容区或 #f8fafc 轻分区Level 2 · 1px 灰色边框，最多极轻阴影

组件样张

button-primary

蓝色填充、白色文字、4px 圆角和至少 44px 高度，承担主行动。

button-secondary

白底、1px 灰色边框、深色文字，用于次级操作。

button-icon

控件覆盖 default、hover、focus-visible、active、disabled、loading、success 和 error，焦点轮廓清晰可见。

text-input 搜索内容

content-row

一行核心内容保持清晰标题。

元信息 · 状态 · 更新时间

布局与响应式

让阅读顺序和任务状态先于装饰表达。

桌面端使用宽松内容栏和明确侧栏；平板减少并列内容；移动端按标题、说明、行动、内容顺序单列，并保持 8pt 节奏与 44px 触控目标。

断点	宽度	关键变化
移动端	< 768 px	四栏入口变单列，标题保持 28-32px，设置项在标签与控件之间垂直堆叠。
平板	768 - 1099 px	入口使用双列，文章与状态区减少为单栏或主次双栏。
桌面端	>= 1100 px	使用四栏快速入口、宽松双栏文章和 32px 页面标题。

使用边界

应该

使用充足白色空间、有限蓝紫点缀和清晰内容分组降低视觉干扰。
Poppins 用于 20/24/32px 标题，Roboto 用于 12/14/16px 正文，Inconsolata 用于短标签。
所有垂直节奏对齐 8pt 基线网格，常用区间为 8/16/24/32/48/64px。
按钮使用 4px，卡片和主要容器使用 8px，层级主要依靠留白与细边框。
为 empty、loading、error、success 和 disabled 状态提供明确文案与下一步。
先使用语义化 HTML，再补充 ARIA，并保证触控目标至少 44px。

不要

不要用大面积彩色背景、渐变、发光或装饰图形填满留白。
不要让紫色与蓝色同时竞争主行动；紫色只承担有限辅助强调。
不要使用 pill、超大圆角或厚重阴影破坏简洁结构。
不要使用低对比灰字、含糊标签或只靠颜色表达状态。
不要加入无目的动效；需要支持 reduced-motion。
不要忽略空态、加载态和错误态，也不要让布局在加载时跳动。

---
name: Clean
colors:
  primary: "#3B82F6"
  secondary: "#8B5CF6"
  success: "#16A34A"
  warning: "#D97706"
  danger: "#DC2626"
  surface: "#FFFFFF"
  text: "#111827"
  neutral: "#FFFFFF"
typography:
  h1:
    fontFamily: "Poppins"
    fontSize: 2rem
  body-md:
    fontFamily: "Roboto"
    fontSize: 1rem
  label-caps:
    fontFamily: "Inconsolata"
    fontSize: 0.75rem
  sourceScale: "12/14/16/20/24/32"
  weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 8px
  md: 16px
  sourceScale: "8pt baseline grid"
---

## 概览

以简洁为核心：充足留白 + 易读字体 + 克制色板，把视觉干扰降到最低。

## 风格基础

- **视觉风格：** 极简、干净
- **字号级差：** 12/14/16/20/24/32
- **字体：** primary=Roboto, display=Poppins, mono=Inconsolata
- **字重：** 100, 200, 300, 400, 500, 600, 700, 800, 900
- **色板：** 主色、中性、成功、警告、危险
- **间距级差：** 8pt 基线网格

## 色板

- **Primary (#3B82F6)：** 来自"风格基础"的 Token。
- **Secondary (#8B5CF6)：** 来自"风格基础"的 Token。
- **Success (#16A34A)：** 来自"风格基础"的 Token。
- **Warning (#D97706)：** 来自"风格基础"的 Token。
- **Danger (#DC2626)：** 来自"风格基础"的 Token。
- **Surface (#FFFFFF)：** 来自"风格基础"的 Token。
- **Text (#111827)：** 来自"风格基础"的 Token。
- **Neutral (#FFFFFF)：** 由 surface Token 派生，以兼容官方格式。

## 技能指引

<!-- TYPEUI_SH_MANAGED_START -->
# Clean 设计体系技能（通用）

## 使命
你是 Clean 的资深设计体系规范作者。
输出可直接落地、工程师和设计师都能直接用的实用规范。

## 品牌

Clean 设计风格聚焦简洁、极简与高可用性，用充足留白、易读字体与有限色板降低视觉干扰。

## 风格基础
- 视觉风格：极简、干净
- 字号级差：12/14/16/20/24/32 | 字体：primary=Roboto, display=Poppins, mono=Inconsolata | 字重=100, 200, 300, 400, 500, 600, 700, 800, 900
- 色板：主色、中性、成功、警告、危险 | Tokens：primary=#3B82F6, secondary=#8B5CF6, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
- 间距级差：8pt 基线网格

## 无障碍
WCAG 2.2 AA、键盘优先交互、可见的焦点状态、先语义化 HTML 再补 ARIA、经屏幕阅读器验证的标签、支持减弱动效、触控目标不小于 44px

## 文字调性
清晰、友好

## 规则：应当
- 优先使用语义 Token 而非原始值
- 让交互状态明确可见
- 为空态/加载/错误场景做设计

## 规则：不应
- 避免低对比度文字
- 避免不一致的间距节奏
- 避免无目的的装饰动效
- 避免含义模糊的标签

## 期望行为
- 先遵循风格基础，再关注组件一致性。
- 不确定时，优先无障碍与清晰度，而非追求新颖感。
- 提供具体默认值，并在存在备选方案时说明取舍。
- 保持规范鲜明、精简，且面向实现。

## 规范撰写流程
1. 在提出规则前，先用一句话复述设计意图。
2. 先定义 Token 与基础约束，再给出组件级规范。
3. 明确组件结构、状态、变体与交互行为。
4. 包含无障碍验收标准与文案撰写要求。
5. 补充反模式，以及既有不一致 UI 的迁移建议。
6. 以一份可在代码评审中执行的 QA 清单收尾。

## 输出结构要求
生成设计体系规范时，请按以下结构组织：
- 背景与目标
- 设计 Token 与基础
- 组件级规则（涵盖结构、变体、状态与响应式行为）
- 无障碍要求与可测试的验收标准
- 文案与调性规范，附具体示例
- 反模式与不允许的实现
- QA 清单

## 组件规则要求
- 定义必须实现的状态：default、hover、focus-visible、active、disabled、loading、error（视需要）。
- 描述键盘、指针与触屏下的交互行为。
- 明确说明间距、字体与色彩 Token 的使用方式。
- 覆盖响应式行为与边界场景（如长标签、空态、内容溢出）。

## 质量门禁
- 规则不应只依赖含糊形容词；必须以 Token、阈值或示例作为锚点。
- 每一条无障碍主张，在实现中都必须可测试。
- 优先保证体系一致，而非局部的一次性优化。
- 当美观与无障碍冲突时明确指出，并以无障碍为先。

## 约束语言示例
- 用"必须"表述不可协商的规则，用"应"表述建议。
- 每条"应当"规则至少配一个具体的"不应"反例。
- 引入新模式时，同步提供既有组件的迁移指引。

<!-- TYPEUI_SH_MANAGED_END -->