01 / 03

Friendly

适合新手引导、教育、健康和社区服务，粉绿柔彩配圆润组件、友好衬线与充足留白，亲近直觉而不幼稚。

通用设计明快多彩高对比度奢华质感

设计语言预览

Friendly Pastel Foundation

Soft Rose

#f2d9dc

主行动、欢迎区、个人计划和温暖提示表面。

Soft Mint

#d9f2d8

社区模块、支持内容、已选区域和柔和辅助表面。

Surface White

#ffffff

页面、阅读卡片、字段和高可读内容表面。

Friendly Ink

#111827

标题、正文、边界和控件文字，确保粉彩上的可读性。

Explicit Care Status

Success

#16a34a

只用于已完成、稳定和准备就绪状态，并配文字。

Warning

#d97706

只用于下一步、需留意和临近事项。

Danger

#dc2626

只用于重要提醒、错误和破坏性操作。

字体层级

friendly-title

Noto Serif Display · 40 / 700 / -2%

用更温柔的方式，照顾每天的自己。

section-heading

Noto Serif Display · 32 / 600 / 1.16

有人愿意在你此刻的位置与你相遇

body-copy

Noto Serif Display · 16 / 400 / 1.6

短小清楚的提示，让加入、暂停和重新开始都没有压力。

label-caps

Space Mono · 14 / 700 / +4%

NEXT CIRCLE · WED 18:00 · PRIVATE

间距、层级与形状

compact-1 4px

compact-2 8px

compact-3 12px

compact-4 16px

compact-5 20px

compact-6 24px

形状

full

按钮、字段、状态标签和紧凑控件使用 4px；社区卡、计划面板和内容模块使用 8px；圆形只用于头像、情绪、人物和状态点。

层级

Level 0 · #ffffff 充足留白画布Level 1 · 1px 墨色边界组织紧凑信息Level 2 · #f2d9dc 温暖欢迎与个人计划Level 3 · #d9f2d8 社区支持与已选内容

组件样张

button-primary

#f2d9dc 填充、#111827 文字、1px 边框、4px 圆角和至少 44px 高度，用于加入、保存和主要下一步。

button-secondary

白底、#111827 1px 边框与 4px 圆角，用于探索、预览和次级操作；薄荷绿用于支持性选中状态。

button-icon

计划卡、签到、字段与状态标签覆盖 default、hover、focus-visible、active、disabled、loading 与 error。

text-input 搜索内容

content-row

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

元信息 · 状态 · 更新时间

布局与响应式

柔和表面降低进入压力，清楚层级让下一步始终明确。

桌面端使用双栏欢迎区、紧凑社区模块和侧栏个人空间；平板减少并列内容；移动端按欢迎、选择、支持与行动顺序单列。

断点	宽度	关键变化
移动端	< 768 px	40px 标题保持上限，模块单列，简化装饰头像，触控目标至少 44px。
平板	768 - 1099 px	保留粉绿核心模块，社区日程与提示纵向折叠，减少并列状态。
桌面端	>= 1100 px	完整双栏欢迎区、12 栏社区内容与侧栏个人计划工作区。

使用边界

应该

以 #ffffff 白色和充足留白建立清爽画布，用 #f2d9dc 与 #d9f2d8 分隔欢迎与支持内容。
标题、正文和主要控件使用 Noto Serif Display；Space Mono 只用于时间、状态和系统标签。
严格采用 14/16/18/24/32/40 字阶，最大标题不超过 40px。
控件和标签使用 4px 圆角，内容卡、面板和柔彩模块使用 8px；头像和情绪图标可为圆形。
保持紧凑但不拥挤的密度，模块间距优先采用 4/8/12/16/20/24px。
让加入、暂停、跳过和错误状态清楚可见，并保证焦点、文字和至少 44px 触控目标。

不要

不要加入米黄、蓝紫、天空蓝等规范外粉彩；核心识别只来自粉、绿、白和墨色。
不要用 Public Sans 或通用无衬线替代 Noto Serif Display 与 Space Mono 的明确分工。
不要使用 24–48px 超大卡片圆角、全胶囊控件或松软玩具化组件。
不要加入彩色渐变、玻璃模糊和厚重投影，粉彩表面本身应承担亲和感。
不要把 friendly 理解为幼儿化；文案必须简洁、自信、有帮助，并尊重用户选择。
不要只用绿、橙、红传递状态；必须同时提供清楚文字或图标。

---
name: Friendly
colors:
  primary: "#F2D9DC"
  secondary: "#D9F2D8"
  success: "#16A34A"
  warning: "#D97706"
  danger: "#DC2626"
  surface: "#FFFFFF"
  text: "#111827"
  neutral: "#FFFFFF"
typography:
  h1:
    fontFamily: "Noto Serif Display"
    fontSize: 2.5rem
  body-md:
    fontFamily: "Noto Serif Display"
    fontSize: 1rem
  label-caps:
    fontFamily: "Space 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: "compact density mode"
---

## 概览

亲和且直觉友好的设计：圆润元素、充足留白与柔和粉彩色板。

## 风格基础

- **视觉风格：** 大胆、活泼、高级
- **字号级差：** 14/16/18/24/32/40
- **字体：** primary=Noto Serif Display, display=Noto Serif Display, mono=Space Mono
- **字重：** 100, 200, 300, 400, 500, 600, 700, 800, 900
- **色板：** 主色、辅色、中性
- **间距级差：** 紧凑密度模式

## 色板

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

## 技能指引

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

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

## 品牌

Friendly UI/UX 设计通过圆润元素、充足留白与柔和粉彩色板，打造亲和、直觉且引人入胜的体验。

## 风格基础
- 视觉风格：大胆、活泼、高级
- 字号级差：14/16/18/24/32/40 | 字体：primary=Noto Serif Display, display=Noto Serif Display, mono=Space Mono | 字重=100, 200, 300, 400, 500, 600, 700, 800, 900
- 色板：主色、辅色、中性 | Tokens：primary=#F2D9DC, secondary=#D9F2D8, success=#16A34A, warning=#D97706, danger=#DC2626, surface=#FFFFFF, text=#111827
- 间距级差：紧凑密度模式

## 无障碍
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 -->