网站系统
本作品集背后的字体、布局和可复用组件的一份轻量参考。为一个作者、一个作品集和七个案例研究而建——结构足够让作品保持一致，但不是一套通用的设计系统。
- 角色
- 设计师 + 作者
- 年份
- 2026
- 范围
- 自发项目 · 一个作品集
- 载体
- Web · Next.js + Tailwind
概览
这个站点是为了减少摩擦而建，不是为了展示广度。视觉语言保持克制，好让读者快速扫读和比较七个很不一样的项目。颜色、动效和交互，只在能澄清层级、状态或证据时才出现。
七个案例研究——医疗健康研究、城市出行、企业银行、AI 助手——需要读起来像同一批作品。所以字体、间距和段落宽度只决定一次，然后到处使用。否则每个新案例都会重新发明布局，写案例变成布局问题而不是内容问题，作品也不再像一个整体。
上方四个标签页装着这些实际决定：颜色、字号阶梯、布局尺度、组件。系统始终次于案例内容。
- 阅读优先——不为了显得厉害而额外加东西。
- 颜色和动效要有用途——只出现在承载信息的地方，而不是作装饰。
- 为扫读而建——所有案例用一套一致的结构，让比较它们和读一个一样容易。
一览
上方的四个标签页承载着这套系统。下面每张卡片预览对应标签页里的内容——打开对应的标签页可读到实时的取值。
如何阅读
每个标签页聚焦系统的一个部分。在任意标签页里从上往下读——每一页都先给出规范取值，再解释它的角色和任何豁免。
- 颜色——调色板，加一张用途表，固定每个角色做什么，以及什么时候可以加新颜色。
- 字体——四级标题的字号阶梯，以及每一级搭配哪种正文宽度。
- 布局——四种文本宽度尺度，加上四种有意处在正文阶梯之外的模式。
- 组件——组成站点上每个案例研究页面的可复用组件，按框架、控件、表面、区块和案例专属交互分组。
用于案例
同一套系统跑在本作品集的每个案例底下。下面每一行把一个案例和它最依赖的组件配在一起——一张关于“这份参考实际在哪里发挥作用”的快速地图。
较早的华为和招行案例依赖结构性组件（多标签正文、步骤网格、详情块）。RCA 的案例依赖以文字为主的组件（bridge 表格、split、引语）。AI 小招则集中了案例专属的交互。
| 案例 | 年份 | 标志性组件 |
|---|---|---|
| 乳腺筛查中的人–AI 分歧治理 | 2026 | 背景地图 · split · 步骤 · bridge 表格 · 引语 |
| 从地下热能到城市基础设施 | 2026 | full · pair · quoteSplit · points |
| 尤斯顿车站的乘客安心引导 | 2025 | 步骤网格 · split · bridge · 问卷卡片 |
| AI 小招 —— 招商银行 | 2025 | 多标签正文 · 三个流程画布 · 对话浏览器 · 背景地图 |
| Flow —— 华为云 | 2023 | 多标签正文 · 步骤网格 · detail · bridge |
| CodeArts —— 华为云 | 2021–2022 | 三标签正文 · bridge 表格 · stats · 步骤网格 |
| 网站系统 | 2026 | 多标签正文 · 本页上的四个参考可视化 |
范围
这是一套内容与布局系统，服务于一个作者，为一个作品集网站写作。它不是一套通用的设计系统，也不是一个交付给其他团队的 token 库。这里的纪律来自 Material 3 这类系统——角色、例外、规范取值——因为这套纪律在任何规模下都成立。这个参照在 2026 年 9 月证明了它的价值：当从 Apple 继承来的灰阶没通过对比度审计时，我就是拿 M3 的角色定义去对照的。
接下来的页面就是那份参考：一张调色板、一条字号阶梯、四种布局尺度，以及一小组可复用组件。打开任意标签页，可以看到管着站点上每个案例的实际取值。
2026 年 9 月，我用 Lighthouse 审计站点之后，加了一条规则：所有用于文字的颜色都要达到 WCAG AA。旧的灰色 token 只有 3.3:1，在 64 处元素上不达标，于是把它改深，把 `ink/65` 定为可读文字的下限，并新增一个单独的 `disabled` 灰来承载 WCAG 豁免的情况。这里的颜色层级，同样依靠字号、字重和大小写，而不只靠明度。