01 / 03

Doodle

适合教育内容、青年社区和创意笔记产品，蓝色手绘涂鸦配不规则线条、手写字体与随性图形，轻松非正式。

通用设计明快多彩

设计语言预览

Doodle Foundation

Sketch Blue

#49b6e5

主要行动、手绘重点、注释底色与参与提示。

Deep Blue

#263d5b

不完美轮廓、次级行动、参数标签与主要结构线。

Paper White

#ffffff

页面、笔记纸和手绘图形内部的主要表面。

Readable Ink

#111827

标题、正文和关键信息，保证涂鸦环境中的阅读对比。

Explicit Feedback

Success

#16a34a

只用于已保存、完成和可分享状态，并提供文字。

Warning

#d97706

只用于待补充、需要复核和注意状态。

Danger

#dc2626

只用于失败、错误和阻断状态。

字体层级

display-doodle

Delius Swash Caps · 40 / 400 / -2%

画出来，做出来，再亲手验证。

heading-note

Delius Swash Caps · 24 / 400 / 1.25

线条可以松，指引必须清楚

body-helpful

Delius Swash Caps · 16 / 400 / 1.7

用简洁、自信且有帮助的文字说明动作、观察和下一步。

label-caps

JetBrains Mono · 14 / 600 / +7%

EXPERIMENT 12 · STEP 2 OF 3 · READY

间距、层级与形状

xs 4px

sm 8px

md 12px

lg 16px

xl 24px

2xl 32px

形状

full

按钮、输入、步骤标签使用 4px；活动卡、笔记纸和主要容器使用 8px；不完美感来自线条与轻微偏移，不来自任意圆角。

层级

Level 0 · #ffffff 纸张画布Level 1 · #edf8fc 手绘分区、网格纸和笔记底色Level 2 · 天蓝行动块与深蓝双线轮廓，不依赖重阴影

组件样张

button-primary

天蓝填充、深蓝文字和轮廓、4px 圆角、至少 44px 高度，承担主行动。

button-secondary

白底、深蓝双线感轮廓与 4px 圆角，用于次级操作。

button-icon

活动、上传和记录控件覆盖 default、hover、focus-visible、active、disabled、loading 与 error。

text-input 搜索内容

content-row

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

元信息 · 状态 · 更新时间

布局与响应式

草图负责邀请参与，稳定结构负责完成任务。

桌面端使用双栏手绘首屏和实验记录工作区；平板减少装饰轨迹；移动端按说明、草图、步骤、观察、状态和分享顺序单列。

断点	宽度	关键变化
移动端	< 768 px	标题降至 32px，草图和步骤单列，保留 44px 目标与清楚的实验顺序。
平板	768 - 1099 px	保留主草图与核心注释，减少辅助轨迹、箭头和并列卡片。
桌面端	>= 1100 px	完整双栏首屏、三类手绘标记和实验记录工作台，最大标题 40px。

使用边界

应该

用涂鸦、草图、手写字体和轻微不完美线条建立活泼、非正式的情感连接。
以 #49b6e5 表达行动和手绘重点，以 #263d5b 统一结构轮廓与次级操作。
Delius Swash Caps 承担标题和正文，JetBrains Mono 只用于步骤、参数和状态标签。
严格采用 14/16/18/24/32/40 字阶与 4/8/12/16/24/32 间距。
即使线条不完美，按钮、卡片、字段和阅读顺序仍必须保持一致。
交互提供可见焦点、明确文字和至少 44px 的键盘与触控目标。

不要

不要改用暖米色、粉肤色或彩虹涂鸦；核心色板是天蓝、深蓝、白色与墨色。
不要让随机旋转、线条抖动或装饰符号破坏层级和扫描顺序。
不要使用 Geist 等通用 SaaS 正文字体替代 Delius Swash Caps。
不要用超大软圆角或重偏移阴影伪装成手绘感；控件和卡片保持 4/8px。
不要仅用表情、草图或颜色表示状态，必须同步提供清晰文字。
不要使用模糊、玩笑式操作标签，也不要牺牲对比度追求原始感。

---
name: Doodle
colors:
  primary: "#49B6E5"
  secondary: "#263D5B"
  success: "#16A34A"
  warning: "#D97706"
  danger: "#DC2626"
  surface: "#FFFFFF"
  text: "#111827"
  neutral: "#FFFFFF"
typography:
  h1:
    fontFamily: "Delius Swash Caps"
    fontSize: 2.5rem
  body-md:
    fontFamily: "Delius Swash Caps"
    fontSize: 1rem
  label-caps:
    fontFamily: "JetBrains Mono"
    fontSize: 0.875rem
  sourceScale: "14/16/18/24/32/40"
  weights: "100, 200, 300, 400, 500, 600, 700, 800, 900"
rounded:
  sm: 4px
  md: 8px
spacing:
  sm: 4px
  md: 8px
  sourceScale: "4/8/12/16/24/32"
---

## 概览

手绘涂鸦风：随手画、手写体与不规则线条，营造活泼非正式的氛围。

## 风格基础

- **视觉风格：** 活泼
- **字号级差：** 14/16/18/24/32/40
- **字体：** primary=Delius Swash Caps, display=Delius Swash Caps, mono=JetBrains Mono
- **字重：** 100, 200, 300, 400, 500, 600, 700, 800, 900
- **色板：** 主色、辅色、中性、成功、警告、危险
- **间距级差：** 4/8/12/16/24/32

## 色板

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

## 技能指引

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

## 使命

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

## 品牌

一种富创意、活泼、非正式的风格：涂鸦、草图、手写体与不规则线条，营造情感连接和原始艺术质感。

## 风格基础

- 视觉风格：活泼
- 字号级差：14/16/18/24/32/40 | 字体：primary=Delius Swash Caps, display=Delius Swash Caps, mono=JetBrains Mono | 字重=100, 200, 300, 400, 500, 600, 700, 800, 900
- 色板：主色、辅色、中性、成功、警告、危险 | Tokens：primary=#49B6E5, secondary=#263D5B, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
- 间距级差：4/8/12/16/24/32

## 无障碍

WCAG 2.2 AA、键盘优先交互、可见的焦点状态

## 文字调性

简洁、自信、有帮助

## 规则：应当

- 优先使用语义 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 -->