个人网站 UI设计系统深度调研与推荐规范

推荐方向：Quiet Ink UI（静墨）——暖中性色画布、墨灰正文、单一低饱和墨蓝强调色、系统优先无衬线字体、列表优先而非卡片优先、轻边框而非重阴影、快速且克制的功能性动效。

打开 Quiet Ink UI v1 可交互样例：可实时切换明暗主题、列表密度，筛选入口并复制当前主题令牌。

0. 先给结论

这套个人网站不应追逐“2026 年最时髦”的表达性视觉，而应采用一套更接近 editorial + productive UI 的混合范式：公开内容页像一份有层级的现代刊物，私有服务入口像一件安静、可靠的工具。

最终应形成以下视觉印象：

• 第一眼知道“这是谁、这里有什么、下一步去哪”，而不是先注意到渐变、图标、阴影或动效。
• 页面主要依靠字体层级、对齐、留白和分组建立秩序，颜色只负责链接、选择、焦点和状态。
• 中文正文以 16px/26px 或 16px/28px 为基准；只使用 400、500、600 三个常用字重；不使用 Light/Thin。
• 默认只使用一套系统优先无衬线字体；不为“设计感”混用多种几何字体、圆体和手写体。
• 默认画布是略暖的灰白 #F7F7F5，正文是墨黑 #1B1B1A，强调色是低饱和墨蓝 #2E5EAA。
• 首页首屏只允许一个核心身份陈述、一个主入口和一个次入口；同一区域不出现多个争抢注意力的彩色按钮。
• 重复信息默认用带分隔线的列表或表格；只有内容确实具有独立边界、独立操作或需要响应式重排时才使用卡片。
• 圆角以 6px/10px 为主，不使用到处都是的 20–32px 大圆角；阴影只用于真正浮在内容上方的菜单、弹层和对话框。
• 动效只解释状态变化，常规 90–180ms；禁止滚动入场表演、视差、漂浮光斑、持续脉动和装饰性弹跳。
• WCAG 2.2 AA 是最低验收线：普通正文 4.5:1、重要控件边界 3:1、键盘焦点可见、最小目标 24×24 CSS px，并在 320 CSS px/400% 缩放下正常回流。

一句话设计契约：

用结构而不是装饰制造高级感；用一个稳定入口回答一个明确问题；任何新增的颜色、字体、卡片、图标和动画都必须说明其语义。

1. 研究简报

1.1 目标

建立一套适用于个人网站、研究报告站、项目展示页和私有服务入口的统一前端 UI 规范，使今后的人工实现和 Codex 生成页面都能保持稳定视觉语言。

1.2 决策背景

现有反面案例由一次缺少约束的一句话生成：配色过度表达、字体阅读感不佳、入口层级可能被装饰元素稀释。需要解决的不是单页“改得更好看”，而是给所有后续页面建立可验证的约束。

1.3 受众

• 主要：网站所有者本人，以及后续执行设计或前端实现的 Codex/开发者。
• 次要：访问个人主页、项目、研究报告和工具入口的技术同行、合作方与普通访客。

1.4 范围

• 视觉原则与风格方向。
• 信息架构、首页入口与导航范式。
• 色彩、字体、字号、行高、间距、栅格、圆角、边框、阴影、图标和动效。
• 链接、按钮、列表、卡片、标签、输入框、导航等基础组件规则。
• 浅色、深色、响应式与无障碍。
• 设计令牌、实现顺序、Codex 生成约束和验收清单。

1.5 排除项

• 不替代正式品牌策略、Logo 设计或摄影艺术指导。
• 不规定具体前端框架；React、Astro、Next.js 或原生 HTML 均可实现。
• 不把某个流行设计系统整套照搬进个人网站。
• 不以转化率营销、广告投放或电商成交为主要优化目标。

1.6 必答问题

1. 哪些属于行业硬标准，哪些只是成熟设计系统的惯例，哪些是个人审美判断？
2. “简约、入口明确”如何转化为可以检查的页面规则？
3. 如何防止配色、字体、卡片、圆角和动效再次失控？
4. 中英文混排和长文阅读应使用什么字体与排版尺度？
5. 公开个人网站和私有服务入口应共用什么、又应在哪里分化？
6. 如何把规范交给 Codex，使它不会重新发明一套视觉风格？

1.7 来源优先级与时效

研究以 2026-08-25 可访问资料为截止点。证据优先级依次为：W3C/WAI 标准与工作组说明；GOV.UK、USWDS、IBM Carbon、Apple HIG、GitHub Primer、Microsoft Fluent、Material 等官方设计系统；原始 HCI 研究；其他资料只作背景。

2. 反面案例：从实际源码提取的设计问题

在方案落地阶段已经直接检查旧版页面源码。为保护公开网站的信息边界，本报告只保留与个人网站设计相关的结构事实，不公开私有域名、端口、服务清单、认证方式或运行状态。

旧版页面同时使用了深蓝渐变画布、两个径向彩色光斑、网格纹理、半透明玻璃面板、卡片阴影、彩色渐变图标、发光状态点和悬浮位移。单个效果并不必然错误，但它们在同一页面叠加后产生了三个可复验的问题：

• 色彩角色过多：蓝、绿、紫、黄、红既参与装饰又表达状态，强调色缺少稳定预算，真实入口与状态提示会争夺注意力。
• 容器层级过重：几乎每个入口都变成带圆角、阴影、图标和箭头的独立卡片，重复外壳占据的视觉面积超过了入口名称与用途。
• 信息同权：三列网格让高频工作入口、基础设施入口、公开内容和待恢复项目使用近似视觉重量，用户必须逐卡扫描才能判断优先级。
• 装饰性动效无额外语义：卡片上浮和箭头位移说明“可点击”，但原生链接、下划线、焦点与稳定的行式入口已经可以更直接地完成这个任务。
• 字体契约不完整：虽然使用系统回退栈，但字重出现非标准的 760/800，标题又依赖强烈负字距；中文设备上的实际回退很难得到同样的视觉结果。

因此，重构不是把深色换成浅色，也不是删掉几个渐变。真正的修复是把入口从“卡片展览”改成按任务分组的列表目录，让名称、用途、访问类型与状态恢复明确优先级；颜色只保留一个动作色，状态色只服务真实状态。

这些问题的共同根因不是审美能力不足，而是生成前缺少设计契约。如果没有限定可用字体、色彩角色、页面模板、组件状态和禁用模式，模型会把“看起来设计过”误当成“设计得好”。

3. 什么是真正的行业规范

行业里没有一份规定“个人网站必须长什么样”的统一标准。可靠的依据实际分为四层。

3.1 可访问性不是附加项，而是视觉规范的底板

WCAG 2.2 于 2023-10-05 成为 W3C Recommendation。与视觉系统直接相关的最低要求包括：

• 普通文本与背景至少 4.5:1；大文本至少 3:1。W3C 还特别提醒，极细字体即使数学对比度达标，抗锯齿后也可能显得更淡，因此应避免 Thin/Light 并留出对比余量。W3C：Contrast Minimum
• 颜色不能是传达状态、动作或差异的唯一方式；链接、错误、成功和选中状态还需文字、图标、下划线、边框或形状等线索。W3C：Use of Color
• 指针目标至少 24×24 CSS px，或满足规定的间距例外；这是 AA 最低线，不是理想按钮高度。W3C：Target Size Minimum
• 页面在相当于 320 CSS px 宽度下应回流，不应要求横纵两个方向同时滚动；文本还应支持至少 200% 放大。W3C：Reflow
• 键盘焦点必须可见，不能通过 outline: none 抹掉而没有等效替代。W3C：Focus Visible
• 标题和标签应准确描述主题或目的；链接目的应从文字或上下文中可判断。这直接支持“信息入口明确”。W3C：Headings and Labels、W3C：Link Purpose
• 页面不能因为用户把行高设为 1.5、段后距设为 2em、字距设为 0.12em、词距设为 0.16em 就丢失内容或功能。注意：WCAG 要求的是可适配这些覆盖值，不是强制作者默认使用全部数值。W3C：Text Spacing

W3C 的认知无障碍建议进一步强调：清楚说明站点、页面、区域和控件的目的；使用熟悉的层级、术语、图标和位置；保持视觉与操作一致。这些建议不仅帮助认知障碍用户，也正是“打开即知道往哪走”的设计基础。W3C：Help Users Understand What Things Are

3.2 “少即是多”只有在内容优先级明确后才成立

GOV.UK Government Design Principles 的关键不是某种政府网站外观，而是工作方式：从用户需求开始、做得更少、用数据设计、为简单付出困难工作、保持一致但不僵硬统一。

这意味着个人站首先要回答：

1. 访问者最常见的 3 个意图是什么？
2. 每个意图的最短入口是什么？
3. 哪些内容应在首页，哪些只需要被搜索或归档？
4. 哪些装饰元素没有帮助用户区分或行动？

在没有回答这些问题时，“少放一些卡片”只会得到稀疏而不清楚的页面。

3.3 视觉复杂度会在极短时间内影响第一印象

Tuch 等人在 2012 年对网站截图进行实验，发现视觉复杂度（visual complexity）与原型熟悉度（prototypicality）在最短 17–50ms 的暴露中就会影响审美判断；整体上，低视觉复杂度且高原型熟悉度的网站更受欢迎。Google Research 收录的原论文摘要

这项研究不等于“越空越好”。它支持的是：

• 入口、导航、链接和列表应看起来像用户熟悉的入口、导航、链接和列表。
• 不要让用户先学习一套只属于这一个页面的视觉语法。
• 应减少无意义的颜色、形状、阴影和动效种类，而不是减少必要信息。
• 有价值的信息密度可以高，但表现方式要有稳定的对齐、层级和重复模式。

3.4 成熟设计系统的共识远大于它们的外观差异

参考：GOV.UK Layout、GOV.UK Type Scale、USWDS Typography、Carbon 2x Grid、Apple Typography、Primer Color Usage、Fluent Design Tokens、Material 3 Theme and Color Hierarchy

4. 设计范式比较与选择

4.1 四类常见范式

4.2 推荐：Quiet Ink = Editorial shell + Productive core

Carbon 把“学习/探索”与“完成任务”区分为 expressive 和 productive 时刻，这个区分非常适合个人网站，但无需采用 Carbon 的品牌外观。Carbon Typography Style Strategies

• 页面外壳：较宽松、可阅读、编辑式；用于个人介绍、研究、文章、项目说明。
• 入口和控件：紧凑、直白、功能式；用于导航、搜索、服务列表、状态和操作。
• 视觉表达：通过一处大标题、一个重点项目或一张有意义的图像形成节奏，不通过多个彩色容器同时表达。

这套范式的目标不是“极简主义作品集”，而是安静的高信息效率。

5. 信息架构：先决定入口，再决定皮肤

5.1 公开个人站的推荐顶层结构

顶层导航控制在 4–5 个稳定入口：

1. 首页（Home）
2. 项目（Projects）
3. 研究（Research）
4. 文章/记录（Notes，可选）
5. 关于（About）

联系入口不必永远做成高亮 CTA；可放在 About、页脚或首屏次操作。只有当“联系我”确实是网站的主要目标时才使用填充按钮。

首页推荐顺序：

全局页头：姓名/标识 | 项目 研究 记录 关于 | 搜索

身份区：
  一句话说明“我是谁 + 主要做什么”
  一句补充当前关注方向
  [查看项目]  [阅读研究]

精选内容：3 项以内，列表行
  标题 | 一句说明 | 类型/日期 | →

按主题浏览：3–5 个领域入口

最近更新：3–5 项

页脚：简短身份、稳定外链、版权/更新日期

5.2 私有服务门户的推荐结构

私有门户不应套用“作品集 Hero + 营销卡片”。推荐：

页头：Home | 搜索/过滤 | 状态摘要 | 账户

最近使用（可选，最多 4 项）

按真实任务分组：
  工作与研究
  开发与基础设施
  文件与媒体
  家庭与设备

每项：服务名 + 一句话用途 + 状态/环境 + 明确链接

分组名必须按用户心智模型命名，不能按部署技术命名。比如用户想“看研究报告”时，不应先判断它部署在 Cloudflare、Docker 还是某个端口。

5.3 可检查的入口规则

• 5 秒测试：陌生人 5 秒后能回答“这是谁”“网站提供什么”“最主要的两个入口是什么”。
• 首屏测试：在 1440×900 和 390×844 下，核心身份、主导航和至少一个内容入口可见。
• 三级规则：任意常用内容从首页不超过 3 次明确点击；不是要求所有页面都塞到首页。
• 标签规则：入口使用用户要去的地方或要做的事命名，不使用“探索更多”“了解详情”“点击这里”。
• 同权限制：同一视区最多一个填充式主按钮；同一区域最多两个直接操作。
• 图标规则：图标只能辅助文字，不能替代不熟悉的入口名称。
• 搜索阈值：当项目、研究或服务超过约 30–50 个且用户常按名称寻找时，增加全局搜索；不要用搜索掩盖混乱分类。

6. Quiet Ink UI v1 视觉规范

6.1 风格关键词

应有：安静、清晰、可信、温和、精确、内容优先、技术但不“赛博”。

不应有：糖果色、霓虹、玻璃拟态、巨型渐变、随机圆角、漂浮光斑、过量插画、装饰性等宽字体、全屏滚动表演。

6.2 色彩系统

原则

1. 中性色承担 85% 以上的页面面积。
2. 单一 accent hue 承担链接、选中、焦点和主要操作。
3. success/warning/danger 只表达真实状态，不能当装饰配色。
4. 组件只引用语义 token，不直接引用 blue-500 或十六进制值。
5. 常态依靠明度和边框建立层级，不依靠每个区域不同色相。
6. 纯装饰分隔线可以低于 3:1；识别控件所必需的边界必须达到 3:1。

浅色主题

深色主题

以上对比度按 WCAG 2.x 相对亮度公式计算。它们是第一版工程基线，仍需在真实字体、字号、抗锯齿、显示器和状态组合中复验。

色彩预算

• 一个页面视区内，除状态提示外最多出现一个 accent hue。
• 主按钮填充色每个视觉区域最多一个。
• 大面积背景禁止使用饱和 accent；accent.subtle 也只用于小范围选中或提示。
• 默认不使用渐变。若未来品牌确需渐变，只能在一处非交互品牌图形中出现，不能作为正文或入口背景。
• 深色模式不是把浅色值机械反相；保持语义角色，分别校验前景/背景组合。

6.3 字体系统

推荐默认：系统优先

--font-sans:
  system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI",
  "Noto Sans CJK SC", "Noto Sans SC", "Microsoft YaHei UI",
  "PingFang SC", Arial, sans-serif;

--font-mono:
  ui-monospace, "SFMono-Regular", "Cascadia Code", "Roboto Mono",
  "Noto Sans Mono CJK SC", Consolas, monospace;

为什么默认不先上“有设计感”的 Web Font：

• Apple 明确建议减少字体数量，并避免 Ultralight、Thin、Light；字体过多会削弱信息层级与一致性。Apple HIG Typography
• 中文字体文件大，加载与切换容易造成延迟、布局变化和中英文字面不协调。
• 系统字体通常是用户最熟悉、在当前 OS 上调校最成熟的 UI 字体。
• 个人偏好已经明确排斥不舒服的陌生字体，因此应先以阅读舒适和稳定为优先级。

如果后续跨平台截图一致性确实比性能更重要，可单独测试 Inter Variable + Noto Sans SC，但必须：

• 只加载实际使用的 400–600 字重或 variable range。
• 使用 WOFF2、合理的 unicode-range 与 font-display。
• 同时测试中文、英文、数字、代码、标点和粗体，不以纯英文样张决定字体。
• 在字体加载失败时页面仍保持可接受的层级和换行。

字号、行高与角色

长文阅读可把 Body 行高提高到 28px。标题行高随字号增大而收紧，正文行高更宽松，符合 IBM type scale 与 USWDS 的共同做法。IBM Type Scale、USWDS Typography

排版硬规则

• 每页一个 H1；语义层级不跳级。
• 正文默认左对齐，不做两端对齐。
• 长文行宽目标 60–72ch，上限 75ch；USWDS 给出 45–90 字符的一般范围和约 66 字符的长文目标，GOV.UK 建议通常不超过 75。USWDS Measure、GOV.UK Layout
• 中文行长不能机械按 Latin ch 完全等价，需在真实中文内容下复核；视觉上以每行约 28–40 个全角汉字为起始测试范围。
• 段落间距默认 1em，不首行缩进；标题上方空间至少大于下方，令标题靠近它所引领的正文。
• 正文不修改字体默认 letter-spacing；大标题可轻微 -0.01em，中文不得过度压缩。
• 禁止大段全大写、斜体、粗体；强调优先靠标题、短句或 callout，而非整段加粗。
• 等宽字体只用于代码、路径、端口、快捷键和机器标识，不能用作全站“技术感”正文。

标题文案、语义断句与命名

标题的换行属于内容编辑，而不是浏览器的纯视觉决定。Quiet Ink UI 对页面标题、区域标题、卡片标题和首屏副标题采用以下硬规则：

• 标题末尾不加标点：标题结尾不使用 。、.、！、?、：、； 或逗号。标题内部为了表达并列或转折可以保留必要标点。
• 短标题优先单行：先缩短文案、放宽合理的标题栏，再考虑减小字号；不得为了制造“海报感”把八到十二个汉字的短标题挤成多行。例如使用“服务与工作入口”，不写“服务与工作入口。”，也不主动拆成两行。
• 必须换行时按语义切分：在完整名词短语、并列项或谓宾边界之后设置允许换行点，不按字数居中。比如“把研究、系统与工具 / 做成可用的长期资产”，断点放在“工具”之后。
• 副标题按信息层分行：一行只承担一个信息层。首行说明对象，第二行列出主要视觉特征，第三行给出原则性结论；不让浏览器在“个人网站与 / 研究内容”这类词组内部随机断开。
• 不以 text-wrap: balance 代替编辑：自动平衡只理解盒子宽度，不理解中文语义。实现时把标题拆成 semantic-phrase，宽屏能容纳时仍保持单行，空间不足时只在片段边界换行；确实需要固定编辑式分行时使用 copy-line。
• 片段自身应能适配小屏：语义片段不能长到在 320 CSS px 下溢出。若单个片段仍过长，应进一步按次级语义切分，而不是恢复任意逐字换行。
• 昵称统一为 JingYiJun：凡是在标题、品牌、署名、导航或示例中把网站所有者当作昵称、网名或显示名时，只写 JingYiJun。域名、URL、项目标识和文件路径按技术要求保持原有大小写，不把 jingyijun.com 强改成显示名。

推荐实现：

<h1>
  <span class="semantic-phrase">让内容先被看见，</span><span class="semantic-phrase">让界面安静地工作</span>
</h1>

<p class="lead">
  <span class="copy-line">一套面向个人网站与研究内容的统一视觉语言</span>
  <span class="copy-line">暖中性色、单一墨蓝、系统字体、列表优先</span>
  <span class="copy-line">每一处都有理由的层级</span>
</p>

.semantic-phrase { display: inline-block; }
.copy-line { display: block; }

6.4 间距与布局

采用 4px 基础单位、8px 主节奏：

Carbon 以 8px mini unit 建立统一节奏，同时允许更小单元处理密集内容；本规范用 4px 解决控件细部、用 8px 的倍数决定绝大多数布局。Carbon 2x Grid

容器与栅格

• 全站最大容器：1120px。
• 普通桌面左右边距：clamp(20px, 4vw, 48px)。
• 长文主栏：min(100%, 72ch)，可配 240–280px 目录/侧栏。
• 首页/项目网格：桌面 12 列、24px gutter；平板 6 列、20px gutter；移动单列、16px 边距。
• 断点用于内容失效时重排，不按某款设备命名：建议从 40rem、64rem、80rem 起步，再按实际内容调整。
• 小屏优先单列。不要通过缩小字体把桌面三列硬塞到手机。
• 对齐关键线必须稳定：页头、标题、列表文字、分隔线和页脚尽量共享左边界。

6.5 形状、边框和阴影

规则：

• 常态容器优先使用留白或 1px 分隔线，不使用阴影。
• 阴影表达 z 轴关系；不浮动就不应有阴影。
• 不把所有内容都装进有背景、有圆角、有边框的盒子。
• 卡片 hover 不做大幅上浮；最多边框/背景变化和 1–2px 轻微位移，且不是必要反馈。

6.6 图标与图像

• 图标使用同一套线性图标，推荐 1.75–2px 视觉笔画；常用 16/20/24px 三档。
• 入口图标必须配文字；外链、下载、警告等可用图标加强语义。
• 不混用 emoji、填充彩色图标、线性图标和 3D 图标。
• 没有信息价值的“科技插画”不放在首屏。
• 项目封面统一使用 3:2 或 16:9；同一列表不得随机比例。
• 截图用于说明真实项目，不加无意义设备 mockup、倾斜透视和发光边框。

6.7 动效

推荐 token：

--duration-instant: 70ms;
--duration-fast: 110ms;
--duration-normal: 160ms;
--duration-slow: 240ms;
--ease-standard: cubic-bezier(0.2, 0, 0.38, 0.9);
--ease-enter: cubic-bezier(0, 0, 0.38, 0.9);
--ease-exit: cubic-bezier(0.2, 0, 1, 0.9);

Carbon 的 productive motion 为微交互提供 70/110/150/240ms 等尺度，并强调表达性动效只用于少数重要时刻；这与本人的偏好高度一致。Carbon Motion

规则：

• hover/focus 70–110ms；菜单、折叠、popover 150–180ms；大弹层不超过 240ms。
• 动效只用于反馈、揭示关系或解释状态变化。
• 禁止 bounce、elastic、无意义 scale、滚动触发的批量淡入和视差。
• 支持 prefers-reduced-motion: reduce，关闭非必要位移与缩放。W3C：Animation from Interactions
• 颜色和透明度变化也要克制，不能让整个页面持续呼吸或闪动。

7. 组件规范

7.1 全局页头

• 高度建议 64px；移动端 56px。
• 左侧姓名/站点标识，右侧 4–5 个文字入口。
• 当前页通过字重 + 下划线/底边或背景表达，不能只变颜色。
• 滚动后可 sticky，但不得遮挡键盘焦点；不要默认透明毛玻璃覆盖正文。
• 移动端如必须折叠，触发器明确写“菜单”，不要只给三条线。

7.2 链接

• 正文内链接默认 accent.fg + 下划线；hover 加深或增粗 underline。
• 导航与列表整行链接可不常驻下划线，但 hover/focus 必须明显。
• 文案描述目的：查看 AvaFlow 项目，不要写孤立的更多。
• 外链如需提示，用小型外链图标并提供可访问名称，不在每个普通链接后堆视觉噪声。

7.3 按钮

• 主按钮：填充 accent；每区域最多一个。
• 次按钮：中性边框或低强调背景。
• 文字按钮：用于低优先级、取消和列表操作。
• 推荐高度 40px；触屏主要操作 44–48px；紧凑桌面控件可 32px，但点击区仍需足够。
• 水平 padding 14–18px；按钮文字 14–15px/500–600。
• disabled 不能只降低到近乎看不见；还应不可交互并正确表达状态。
• 危险按钮只有在真实破坏性操作时使用红色。

7.4 列表与卡片

默认采用列表行：

项目标题                    2026-08-25
一句说明，解释内容和价值                 →

只有同时满足以下至少一项才用卡片：

• 内容可作为独立对象拖动/选择/操作。
• 需要封面图或状态与其他项显著区分。
• 响应式下需要从多列重排为单列。
• 边界有助于理解，而不是只为了让页面“有设计感”。

卡片规则：背景默认与画布相同或只高一个 surface 层级；圆角 10px；1px 边框；内边距 20–24px；标题、说明、元数据保持固定顺序；整卡可点击时内部不能再嵌套冲突链接。

7.5 标签与状态

• 标签用于分类，状态用于当前事实，二者视觉不同。
• 分类标签以中性背景为主，不给每个类别随机颜色。
• 状态由文字 + 图标/点 + 颜色共同表达，如“● 正常”“△ 维护中”。
• 标签不滥用 pill；短状态可 full radius，筛选器更适合 6px 圆角控件。

7.6 输入与搜索

• 标签常驻在输入框上方；placeholder 只提供示例，不替代标签。
• 高度 40–44px，边框使用 border.strong，focus 使用 2px ring + offset。
• 搜索结果按标题、类型、简短摘要组织；匹配高亮不能只靠颜色。
• 错误同时给文字说明、错误图标和对应字段关系。

7.7 焦点状态

推荐双层焦点，兼顾不同背景：

:focus-visible {
  outline: 2px solid var(--color-focus-ring);
  outline-offset: 2px;
  box-shadow: 0 0 0 4px var(--color-bg-canvas);
}

在浅/深 surface、accent 按钮和图片背景上分别验证，不要只在白底上看一次。

8. 设计令牌架构

8.1 两层起步，三层按需

Primer 和 Fluent 都区分原始值与语义值：base/global token 只存颜色和尺寸，functional/alias token 表达用途；组件只消费语义值。Primer Color Usage、Fluent Design Tokens

对个人网站最合适的起点：

Primitive tokens
  neutral.0, neutral.50, blue.600, space.4, radius.2
        ↓
Semantic tokens
  bg.canvas, fg.primary, border.strong, action.primary.bg
        ↓
Component tokens（仅当组件确有例外时）
  button.primary.hover, nav.item.active

禁止组件直接使用 neutral.700 或 #5F625E。主题切换时只替换 semantic mapping，组件语义不变。

8.2 交换格式

Design Tokens Community Group 在 2025-10-28 发布首个稳定版 2025.10，定义跨工具交换 token 的 JSON 格式。它是稳定的 Community Group Report，但不是 W3C Standards Track 标准；新项目可采用，同时保留适配演进的空间。DTCG 2025.10 Format Module、DTCG FAQ

示例：

{
  "color": {
    "$type": "color",
    "bg": {
      "canvas": {
        "$value": { "colorSpace": "srgb", "components": [0.9686, 0.9686, 0.9608], "alpha": 1 }
      }
    }
  }
}

工程中可以先用 CSS Custom Properties 作为运行时接口，DTCG JSON 作为未来 Figma/Style Dictionary/多端交换源；不要为了个人小站在第一天搭建过度复杂的 token pipeline。

9. 给 Codex 的生成契约

以后不要再用“帮我做一个好看的首页”这种开放式指令。至少提供内容、优先级、token、组件范围、禁用模式和验收条件。

推荐模板：

请按 Quiet Ink UI v1 实现这个页面，不得自行发明新的视觉语言。

目标与用户：
- 页面目标：<一句话>
- 主要用户：<谁>
- 首要任务：<最多 3 个，按优先级>

信息架构：
- 顶层导航：<4–5 项>
- 首屏必须出现：<身份、主入口、次入口>
- 页面 section 顺序：<明确列出>

视觉约束：
- 使用既有 semantic tokens；不得直接写新的随机 hex 色。
- 中性画布 + 单一墨蓝 accent；状态色只表达状态。
- 使用系统优先 sans；仅 400/500/600；正文 16/26。
- 页面和区域标题末尾不加标点；短标题优先单行。
- 多行标题必须提供语义片段和允许断点，不使用 `text-wrap: balance` 猜测中文断句。
- 昵称、网名和署名统一写作 JingYiJun；域名与 URL 保持原样。
- 4px 基础间距、8px 主节奏；容器 1120px；正文 72ch。
- 列表优先；卡片必须说明独立边界的理由。
- 圆角只用 4/6/10px；阴影只用于浮层。
- 动效 70–180ms；禁止渐变、玻璃拟态、霓虹、光斑、视差、滚动入场和大面积彩色卡片。

交互与无障碍：
- 完整 hover/focus/active/disabled 状态。
- WCAG 2.2 AA；普通文字 4.5:1，关键控件边界 3:1。
- 键盘可达；focus-visible 清楚；320 CSS px 与 200%/400% 缩放不丢内容。
- prefers-reduced-motion 下关闭非必要动画。

交付前自检：
- 5 秒内能回答“这是什么”和“下一步去哪”。
- 每个视区最多一个填充式主按钮。
- 移除颜色后仍能区分层级和状态。
- 不出现没有语义的新颜色、图标、字体、圆角或动画。

如果 Codex 想引入新 token，应先说明：现有 token 为什么无法表达、该 token 的语义、使用范围、浅/深主题值、对比度和弃用条件。

10. 实施路线

Phase 0：内容与入口清点

• 列出所有现有页面、服务、项目和研究入口。
• 为每个入口记录：用户意图、使用频率、公开/私有、状态、上级分组。
• 选出首页首要 3 个意图，剩余内容下沉到分类与搜索。

产物：sitemap、内容优先级表、旧站入口映射。

Phase 1：基础 token 与字体样张

• 实现浅色 token，先不急着做深色。
• 制作中文、英文、数字、代码、长标题、粗体、表格的字体样张。
• 校验所有正文、链接、状态和按钮对比度。

产物：tokens.css / DTCG JSON、type specimen、color matrix。

Phase 2：基础组件

按顺序实现：链接 → 按钮 → 输入/搜索 → 导航 → 列表 → 标签/状态 → 必要卡片 → 弹层。

每个组件同时实现 default、hover、focus-visible、active、disabled、loading/error（适用时）和浅/深主题。

Phase 3：两类页面模板

• Public editorial template：个人介绍、项目、研究、文章。
• Private productive template：服务入口、状态、搜索与分组列表。

两类模板共享 token、字体、页头基本逻辑和组件；只在信息密度与 section spacing 上分化。

Phase 4：迁移与验证

• 先迁移首页和一个长文页，再迁移服务门户。
• 做真实内容截图，不用 lorem ipsum 决定布局。
• 对照旧站完成入口映射，避免“变好看但找不到东西”。
• 小范围使用后根据真实点击和寻找失败调整，而不是继续加装饰。

11. 验收清单

信息架构

• [ ] 首页首屏明确回答“谁、做什么、去哪”。
• [ ] 顶层导航不超过 5 个稳定入口。
• [ ] 主要入口使用名词或动作，不使用“更多/探索/点击这里”。
• [ ] 同一区域只有一个视觉主操作，最多一个次操作。
• [ ] 常用目标不超过 3 次明确点击。
• [ ] 分类按用户任务而非部署技术组织。

视觉一致性

• [ ] 页面只消费 semantic tokens，无散落随机 hex。
• [ ] 除状态外只有一个 accent hue。
• [ ] 字体不超过一套 sans + 一套 mono；字重仅 400/500/600。
• [ ] 字号、间距、圆角均来自受控 scale。
• [ ] 阴影只用于浮层，卡片使用有明确理由。
• [ ] 图标来自同一风格，且非熟悉入口都有文字标签。
• [ ] 灰度截图中仍能识别层级、链接和状态。

排版与响应式

• [ ] 中文正文至少 16px，默认 26–28px 行高。
• [ ] 长文主栏约 60–72ch，不超过约 75ch。
• [ ] 页面、区域与组件标题末尾没有尾随标点。
• [ ] 能单行容纳的短标题没有被人为挤成多行。
• [ ] 多行标题和首屏副标题只在预先标记的语义边界断行。
• [ ] 昵称、网名和署名统一为 JingYiJun，且没有误改域名或 URL。
• [ ] 320 CSS px 下无非必要水平滚动。
• [ ] 200% 放大和 400% 回流不丢内容或功能。
• [ ] Windows、macOS、iOS、Android 至少各抽测一种字体回退。
• [ ] 自定义字体失败时布局仍可读，且无明显 CLS。

可访问性与交互

• [ ] 普通文本对比度 ≥ 4.5:1；大文本 ≥ 3:1。
• [ ] 必要控件边界/图标 ≥ 3:1。
• [ ] 状态不只靠颜色表达。
• [ ] 所有交互键盘可达，焦点顺序符合阅读顺序。
• [ ] focus-visible 在浅、深、surface、accent 背景上均清楚。
• [ ] 目标至少符合 WCAG 24×24 CSS px；主要触摸操作建议 44px 以上。
• [ ] reduced motion 下关闭非必要位移、缩放与过渡。
• [ ] 标题、链接、按钮和表单标签描述真实目的。

认知与主观验收

• [ ] 5 秒测试通过。
• [ ] 让 3–5 名真实用户完成“找项目、找研究、找某个服务”任务，记录误点和犹豫。
• [ ] 页面移除所有装饰图后仍完整、清楚。
• [ ] 每一个颜色、字体、图标、卡片和动画都能回答“它表达了什么语义”。
• [ ] 网站所有者本人连续阅读 10 分钟后没有明显字体疲劳或视觉烦躁。

12. 风险、局限与开放问题

已知局限

• 反面案例的分析来自当时实际源码，但本公开版本主动移除了域名、端口、服务名、认证方式与运行状态，因此不能用来还原任何私有基础设施。
• 字体舒适度具有显著个体差异；system-first 是最稳健起点，不代表所有设备上绝对一致。
• 对比度达标不等于整体可读；字重、字号、抗锯齿、屏幕亮度和观看环境都需要实测。
• 视觉复杂度研究能解释总体趋势，不能直接推出唯一正确的个人风格。
• 深色模式并非必需首发功能；如果使用频率低，先完成高质量浅色模式比同时交付两个半成品更好。

待用户决定

1. 个人站主要是公开身份/研究门户，还是私有服务导航？两者都要时，是否使用不同域名或清晰的 public/private shell？
2. 墨蓝是否符合长期偏好，还是更喜欢墨绿、棕红等同样克制的单一 accent？
3. 是否需要深色模式首发？
4. 是否希望正文完全 system-first，还是愿意承担字体资源与跨平台测试成本来换取更统一的字形？
5. 当前真实入口清单和访问频率是什么？这会决定首页，不应由视觉设计臆测。

13. 最终建议

把这套规范当作一个“约束系统”，而不是一张 moodboard。第一阶段只做以下五件事：

1. 确定公开站与私有门户的角色和真实入口清单。
2. 锁定 Quiet Ink 的浅色语义 token 与 system-first 字体。
3. 用列表优先的方式重做首页信息层级。
4. 实现链接、按钮、导航、列表、搜索五个基础组件及完整状态。
5. 用真实内容完成 5 秒测试、键盘测试、320px 回流和字体舒适度测试。

不要先做 Logo 动画、渐变 Hero、深色特效、3D 卡片或大规模组件库。对于这个个人网站，真正的“高级感”来自内容组织、字形舒适、对齐稳定、取舍坚定，以及每一处强调都有理由。

14. 主要证据索引

• W3C Web Content Accessibility Guidelines 2.2
• W3C Designing for Web Accessibility
• W3C Cognitive Accessibility: Help Users Understand What Things Are
• GOV.UK Government Design Principles
• GOV.UK Design System: Layout
• GOV.UK Design System: Type Scale
• U.S. Web Design System: Typography
• IBM Carbon: 2x Grid
• IBM Carbon: Typography Style Strategies
• IBM Carbon: Motion
• Apple Human Interface Guidelines: Typography
• GitHub Primer: Color Usage
• Microsoft Fluent 2: Design Tokens
• Material 3: Accessible Theme and Color Hierarchy
• Design Tokens Format Module 2025.10
• Tuch et al. 2012: Visual Complexity and Prototypicality