我喜欢有趣的设计系统。这种喜欢始于两次惊喜——我有幸见证了心目中最优秀的两套设计系统的诞生：初代 Material Design 和初代 Fluent Design。请注意，这里我非常严格地限定了「初代」，而且 Material Design 指的不是后来被 Luke Wroblewski 糟害过的那个版本。在我看来，这两套系统在当年最优秀的地方，是非常好地平衡了趣味性、视觉丰富程度与可访问性，同时也给专业的设计师留下了足够多自己发挥的空间，不至于让世面上的所有软件做出来都变成一股香辣牛肉面的味道。

他们背后是一种极致的人文与科技的融合。

与之相对的，我并不喜欢后来的 Material Design 2 和 Material You，不喜欢苹果搞出来的 Liquid Glass，也不喜欢微软现在的 Fluent Design 2。一点浅薄的个人观察，现在的工业界视觉设计品质是在超速沉沦的。原本初代 Material Design 的设计文档精致到让人想要打印出来装订成册天天看，结果现在的 Google 开始向微软学习设计文档质量，几乎是什么正经原理都不讲[^1]。而 Fluent Design 2 浑身上下都透着一股子看齐苹果的味道，浓烈到我甚至怀疑这些微软的设计师是不是每天都拿着 Mac 上班，从来不用自己设计出来的产品；它变得保守、单调、无趣，哪怕你直接把它塞到苹果平台上，八成也能做到「视觉语言兼容得七七八八」。至于 Liquid Glass，纯粹就是花里胡哨不知所云的玩意，新奇和吸睛碾压过了一切设计价值，甚至碾压过了最基本的可访问性，让人无所适从。

至于 Material Design 2，其实是一个非常可惜的东西。虽然它跟初代 Material 有延续性，但它的问题是太像教科书，几乎没办法对开发者形成什么约束。一个好的设计系统应当提高设计美感的下限，且没有降低设计美感的上限。它必须能够通过约束为界面设计和实现者提供足够多的支持，同时为设计师留出一定的设计空间。完整且健全规则不能完全束缚一个好的设计师（哪个设计师还没点脾气不是）。很明显 Material Design 2 没有做到这种兜底，一丝不差的遵照设计规范你完全有可能设计出不堪入目的玩意（比如官方的 Material Study）。Material Design 2 与其说是设计系统，不如说是某种很难执行的设计哲学。

但平心而论，这些新老系统里各自都有非常迷人的东西。像是初代 Material Design 的阴影、Material You 的图形系统（它确确实实拯救了单调无聊的卡片地狱）、以及初代 Fluent Design 的光效、材质与空间隐喻。它们都是那种令人感到欣喜、做出来之后会忍不住把玩、一看再看的设计。

如果把这些自己最喜欢的东西全都摘出来，揉到一起，会不会拼出一个全新的「飞天小女警」呢？Sugar, spice, and everything nice！

抱着这样的想法，我在脑袋里做了很多很多的实验。这也是七年前我开始动手写 Axiom Design System时的动机。

尸块

想把不同设计系统里的精华摘出来捏成一个整体，听起来很美好，但只要稍微往深处想一步，就会撞上很棘手的冲突。

从实用主义的角度来看，初代 Material Design 的空间隐喻是更贴合日常设计实践的。特别是它的阴影设计，通过多层不同扩散半径与浓淡的阴影去拟合现实世界里的真实光照效果（环境光与主光），光影之下的那种柔和之感，令人觉得界面仿佛是沐浴在一种柔和的阳光之中，在我看来这是一种颇具人文精神的表达。

而从品牌辨识度与交互反馈的角度来讲，初代 Fluent Design 的 Reveal Highlight 则做得非常卓越。它不仅给冷冰冰的界面带来了几分灵动和趣味，也提供了很高的可访问性价值。微软设计团队当年在探讨光效背后的认知科学原理与认知包容性设计时专门讲过，人类的视网膜和大脑神经通路对光线与运动变化有着天然的直觉反应；如果把所有按钮的边框常驻画在屏幕上，密集的线条会造成视觉噪声与认知负荷，而 Reveal 光效在平时隐藏了非必要的边框，只在指针靠近时用柔和的光晕照亮当前焦点，并顺带点亮周围可交互元素的边界。这种渐进式的视觉引导能够极大地缓解信息过载，对注意力容易分散的神经多样性群体（比如 ADHD 或自闭症谱系用户）相当友好。

但问题在于，这两种拼合是需要取舍与消化的。比如初代的 Material Design 和 Fluent Design 都有强烈的空间隐喻，但就我个人的浅薄理解，二者的纵深方向完全相反： Material Design 是从屏幕内部「向外」堆叠纵深空间，像桌面上越垫越高的纸张；而当时的微软因为续哟考虑自家的头牌产品 HoloLens，所以整个 Fluent 的空间纵深是「向内」走的，亚克力面板恰如一扇能让人窥见背后奇妙世界的窗子。

如果你对这些底层的设计逻辑与渲染机制不做消化，直接把它们生硬地凑在一起，做出来的就会是犹如「尸块」一样的东西，甚至根本不能称之为一个系统。

在如今 AI 盛行的年代，我们能够在网上看到大量所谓的「特效 UI 库」，库里几乎没有组件在共享同一套视觉语言，个个长得不一样，东造一个西抄一个，让人很难想象它们怎么可能组合成一个圆融的整体去表达一段完整的设计叙事。

千禧年间，曾流行一种光盘，里面是二进制格式的电子书，打开全是各种令人目眩的「网页特效大全」。我光用文字描述你就能回忆起那些东西。像是鼠标移动时出现星星、光点或拖着一大串彩虹文字，网页背景循环变色，或者显示雪花、气泡，页面标题文字滚动，状态栏显示滚动信息。

它们有趣，但说不上多有品味，与现在的尸块库如出一辙。但至少当年的那些网页特效有工程师仔细打磨细节，现在的尸块则是粗糙到一言就能看到无数设计原则层面的错误。加之它们的底层实现通常都很粗糙，性能烂到没边，That’s exactly AI Slop。

不幸的是，七年前我写出来的初代 Axiom Design System，虽然在单个特效的还原度上死磕到了极致，但在工程架构上，恰恰也卡在了「各自为战的尸块」这一步。

七年

七年前那会儿是没有 AI 的，写代码全靠我自己读硕士那会儿抽空折腾还有一个人大半夜下班之后彻夜奋战。我还记得在操场跑步的时候满脑子都是怎么从缝里抠出来性能，还有什么组件能做。

靠着一种颇为质朴办法，我把脑子里「飞天小女警」的几个核心零件一个个手搓了出来。

为了复刻 Fluent Design 的 Reveal Highlight 光效，同时保证鼠标移动时跟手、不触发浏览器的 DOM 重排（Reflow），我们选择直接用 Canvas 来画。为了复刻初代 Material 那种沐浴在阳光下的柔和阴影，我们做了 Elevation 组件；因为我很不喜欢原版 CSS 只有几个固定整数倍档位的限制，于是就把所有档位的参数全都拉了出来，做了一个线性回归拟合，让它变成了一个可以从 0 开始无限往上拉、中间数字随便调的无级阴影 Design Token。

我在博客里一直强调阴影是不可以乱用的，在你表达物理遮挡这个隐喻的时候，阴影就只能是黑的（如果你想要表达发光，那是另外一回事），为了防止有人调出像后来的 Liquid Glass 那样花里胡哨毁掉可访问性的怪东西，我在组件里根本没给颜色的选项，也不允许调方向，只允许调深度，控制得非常严格。

再加上微软难得在设计文档里把每一层写得明明白白、被我在 Web 上用客户端预烘焙噪点贴图复现出来的 Acrylic 亚克力材质，Windows 10 商店导航栏那个切换位置时会拉伸回弹的 Navigation 指示器，以及磁贴按下去会发生三维倾斜的 Pressure 组件，一整套 Design Essentials 算是初具雏形。

但头昏闹热做了一大堆组件之后，就没有然后了。因为没有统一的图形绘制基建，这些零件在工程上很难整合成一个完整的系统。

最直接的冲突就爆发在「形状」上。最早做 Reveal Highlight 的时候，它只支持正方形，因为 Windows 10 原版磁贴就只有直角。后来很多人跑来跟我要圆角，我就硬着头皮在 Canvas 里把圆角给画上去了（眼含血泪大半夜坐在电脑前面拿着纸笔哗哗的推公式，初中高中做几何题都没那么认真过）；再后来又顺着 CSS 边框装饰（Border Decoration）的早期提案，手搓出了向内凹陷的反圆角，也就是类似于邮票边缘的形状。我记得当年光是用 Canvas 把直角画出来就已经很恶心了，后来把圆角和反圆角做出来更是让人不忍回忆。

形状你能用 Canvas 画，但亚克力怎么办？亚克力的背景模糊滤镜可没法在 Canvas 里做。我当时想过要不要干脆全切到 SVG，但 SVG 的性能和兼容性都没那么好，这事儿就卡住了。

当时我们还试过把「按压三维倾斜」也叠上去，结果出现了更让人感到绝望的情形。一方面，组件一旦按下去发生倾斜，鼠标的平面坐标和内部 Canvas 的坐标映射就变了你必须做三维空间的逆仿射变换才能把光圈的位置算准；另一方面，Firefox 的渲染器里有一个陈年 Bug，只要你在亚克力背景模糊那组容器上上面再叠一个三维变换，它的帧缓冲区（Framebuffer）就会直接被冲烂，鼠标划过去或者按下去的时候画面会不停闪烁，这事情直到七年后的几年也没人修（然后他们的人非常却在非常专注的把 Firefox 改得越来越辣眼睛）。

架构和工程是解决这些窘境的唯一方式，我曾构思在所有组件底下抽出一套统一的图形基建：让光效、阴影、亚克力和三维倾斜全部长在同一个几何底座和渲染调度器上。

道理讲讲谁都懂，但是这么大的阵仗孩子哪见过啊。过去几年没写代码的时候，我脑子里也一直在构思这套底层图形基建该怎么设计。但苦于我自己的数学实在不行，再加上没有 AI 的年代全靠手写，维护负担和心智负担实在太重了。一想到要把所有组件的几何算法都过一遍、要解决 Canvas 和 SVG 形状的对齐、还要去搞各种浏览器内核的 Bug（当年 Chromium 的 Web Component 实现解 CSS Typed OM 是有概率触发数值不刷新的 bug 的），靠爱发电可发不起。于是这个念头就只能在脑子里悬置着，一晃就是七年。

直到最近因为在找工作，手里需要拿出一份设计系统相关的作品，而我手里现成的设计系统只有这一个。我想着既然这次要重新收拾它，干脆召唤智慧之神克劳德桑，圆了我这个梦想。

基建

要把各自为政的组件真正捏合成一个有秩序感的设计系统，需要建立一套标准统一的规范：统一的渲染调度（Surface）、统一的图形系统（Shape）、统一的 Design Token 解析机制（Typed OM）。

智慧之神赐我力量

动手的第一步，我先把以前写得最完整的 Reveal Highlight 源码交给了 Claude Opus，让它帮我找找有没有性能问题。

你要知道，当时为了做极端性能调优和兼容性调优，是下了不少苦功夫的。甚至请教了做游戏引擎的朋友，我自以为每一个小地方都已经优化到了极致。结果 Opus 看了一眼，前后不到五分钟，就跟我说：「不太对，你的时序排得有点问题，布局出现了又读又写的情况，完全没有必要。」

然后，几乎是眨眼之间，它就拿出来了方案和 Benchmark，把整个渲染性能提高了 20 多倍。

令人错愕。

我感觉自己就像白痴一样，那我当年点灯熬油到底在干个三小叮当？破真时间能解决一切问题是吧。

为了进一步往前推推进性能表现，这个库也吸纳了我以前做 Web 基建的经验，接管了所有组件的渲染生命周期，引入了 Frame Budget 的概念和优先级排程机制，确保整个 Canvas 动效渲染不会卡到其他东西，且尽可能在用户感知上保证流畅。

图形系统与双端实现

如前所述，要做的第一件事请就是把图形系统抽出去做成基建，确保所有包都能共用同一个绘制流程，这既是 Shape 包啦。众所周知的，Axiom Design System 是一个基于 Web Component 的组件库，那么 Design Token 自然也是走自定义 CSS 属性。毕竟 JS API 这玩意能少暴露一点是一点。在 Token 设计上我有一点自己的想法。个人觉得在描述圆角的时候 border-radius 是一个很不恰当的词汇，特别是在我的图形系统中，「角」和「边」都有自己的装饰方法。

具体而言，border 上可以凸出来一块，可以凹下去一块，这个形状可以是圆形方形三角形。 Corner 可以是圆角，也可以是切角、内凹圆形和内凹方形。这些 decoration 会有自己的 shoulder，你比如内凹圆角本身会画出一个锐利的切口，你可以独立调整这个切口的圆润程度。这样你就可以组合出来各种各样不同的形状。比如它可以 border decoration 内凹进来一个 V 字形，或者是突出来一个尖角形，你就可以做一个漫画气泡出来，或者是做一个 Material Shape 里边 bun 图形的效果。

我对这套系统构思了很久，但苦于数学水平实在是烂到没变，所以一直没有把它完整地实现出来，但是现在可以了。

我和 Opus 大概讲了一下我对整个图形系统的构想，它给我做了一些纠正。比如说它觉得我可以给四个角加位移，就能实现我想要的平行四边形的效果，不一定非要很复杂地去做什么斜切的装饰。我觉得它的想法很好，就让它帮我整理了一下整个的 API 设计。我把我的概念给它，把我整个的 Spec 大纲给它，它帮我把它整理成了一个标准的实现。

至于 Canvas 和 SVG 的等价实现，因为多模态能力很强，以我直接告诉 Opus 需求，它就自己手脚无比码力的写代码，把两个图形叠在一起开始数毛了。真的是很省心。

此时的心情可以说是非常复杂，我苦恼了这么多年的问题，它开着柴油推土机稀里哗啦地半个小时就把所有艰难险阻铲得一马平川。

虽然它还是「我」的东西，但又感觉不太像是「我」的东西了。而且 Opus 推进的速度之快让我感觉自己很蠢。有一种渺小人类站在巨人之下的压迫感。心情非常非常的复杂。

But anyway，最后有东西就好。

系统集成

这一套 Shape 系统和 Design Token 系统做好之后，我就把它铺到了其他组件上。

底下的 Shape 和 Typed OM 基建铺完后，原本只在光效里面被支持的各种花哨形状就能延展到了阴影、亚克力，乃至导航栏底部的指示器上。

导航指示器

把图形系统接进 Indicator 是一件特别好玩的事情。以前的位置指示器就是个无聊的黑色棒状物；但现在，它不仅可以导圆角、变成平行四边形，甚至还解锁了动画能力。

比如，这是我们做的一个额外小功能：当指示器从一个位置飞向另一个位置时，前进方向的那一端会动态伸出一个三角形尖角，视觉上就像射出一支箭一样飞出去；等抵达终点停稳的时候，那个箭头又会收拢回去。

为了增强开发者体验，我们在 Token 的设计边界上花了不少心思。静态的形状 Token 自然能全盘继承自 Shape 系统，因为折腾这一大堆架构的初衷就是让同一套形状语义在任何组件上都能复用。但对于「箭头伸出与收回」这个动态变形过程，则做了特化。

具体考虑是这样的：在一个只有几个像素厚的扁平小横条上，边缘形状的细微起落只是一个小小的添头，大概率设计师不太需要去调很细节的动画参数，像是时间、动效曲线；而且这个曲线这东西非常不好调，我来来回回调了几个小时，发现处理不好极容易出现尴尬、诡异的抽搐。这属于我也麻烦用户也麻烦的破事，因此在这里 Token 的设计暴政了一下，我直接在组件内部提前把形变的时序和细节全部调好，底层改用线性插值（Lerp）驱动，只向外暴露一个阻尼参数来改变它的收敛速度。你只需要关心自己想要什么装饰形状、希望它怎么变，剩下的全是黑盒。

在 Indicator 上面，我还找 DeepSeek 一起补上了微软当年没搞的小细节：动画打断。

初代 Fluent 导航指示器动画会有一种类似橡皮筋「啪」地弹过去的爽快感。其背后是因为的首尾两端采用了贝塞尔曲线去做位移动画，先拉开长度再回弹收拢。但贝塞尔曲线在工程上有一个缺陷：它是基于固定起止点的预设轨迹，中间改目的地有点麻烦，且很容易搞得效果不自然。

微软当年面对这种情况的处理方式非常粗暴，基本就是「我不管了」，只要半途发生打断，指示器就直接硬跳变过去。你倒是不能说这个做法是错的，但就不咋对劲。我觉得直接跳变的手感实在太差，所以设计了一套 AB 双模式：正常触发时走预设的贝塞尔曲线（A 模式），保留原本的动效质感；一旦在半路检测到打断操作，引擎就立刻切换到线性插值模式（B 模式）。因为 Lerp 是每帧根据当前位置朝新目标增量收敛的，自然能支持目标随时改变。

一点令人怦然心动的小细节是，在 Lerp 模式下，我们同样让它保持一端伸出去、一端缩回来的结构，并对前后两端做了一点简单的时序差调整去模仿原本伸缩（虽然不太可能百分之百复现啦）。即使底层的数学机制变了，手感会有一点微妙的差异，但它最大程度保证了无论怎么疯狂乱戳，动效都是平滑连续的。

压力（以及 Firefox 的灵压）

前面的其实都还好说，但是在项目被推出去之前我算是真的遇到大魔王了。

就是那个按下磁贴的三维倾斜效果 Pressure。

当年我之所以没法把按压倾斜和亚克力、光效统一成同一套系统，很大原因都是被 Firefox 和三维坐标变换给卡死了。这涉及到 Firefox 渲染器里的陈年老 Bug，这 bug 悠久到七年前我写第一版的时候它就在，没想到七年过去了，它居然还没有修（Moz 你们能不能做点人事不要天天再去改那浏览器的破皮肤了，越改越烂）。

具体而言，在同一个二维空间中（无论是嵌套还是层的都一样），如果元素有 backdrop-filter 的亚克力背景模糊系统上面，再叠加一层 CSS 三维变换时（无论是你用 z-index 叠的还是外面套的，只要在同一个座标空间下就算），只要鼠标划过去或者按下去触发重绘，Firefox 的帧缓冲区（Framebuffer）就会直接被冲烂，整个画面开始疯狂闪烁，非常难解。

当年我是嗅到了一股不妙的味道，于是就赶紧把整套东西束之高阁了。结果就是 Tile 一直都没真正接通。但是这次因为有压力所以必须得修到底，于是我拉着 Kimi 和 Claude 爆肝修了一个通宵，前前后后光是买 Token 就花了 150 多块。而且这活你不能指望顶模之外的模型能做，老实讲哪怕是 Opus 调试这个问题的时候思路也是糊的。

Claude 给出了半个答案，既然在 CSS 层面做三维变换这么难伺候，那就直接不要在 CSS 上做容器翻转了。直接把三维倾斜下沉到图形运算层面上来实现。也就是直接改锚点的座标映射，让出来的二维形状轮廓看起来像是三维的。

至于另外一半，其实在不理解问题上下文的情况下，我们只能暴力穷举所有组合、条件、可能性。基本上对于前端开发者来说，遇到引擎 bug 就会变成跟克苏鲁对谈了。我人生中只有一次遇到内核 bug，去浏览器源码那找到过答案，剩下的基本都是暴力穷举。特别是在 Pre-AI 年代，真的是痛不欲生。

中间过程多么惨不忍睹我们就不谈了。最后的解决方案是，在 Firefox 下面，包裹文字的内容层不要做倾斜，只有亚克力、光效、阴影有倾斜效果（数学算出来的，也不是 CSS 3D）。因为按压时的倾斜幅度本身就设计得很克制，你正常盯着看的话，只要外框的形状发生了符合透视规律的倾斜变化，在视觉上就已经足够骗过大脑，让你产生「它被按下去了」的直觉。

反正，这事情总算是给糊弄过去了（dbq）。

阴影

Elevation 是另外一个我明确为了视觉牺牲了性能的库。

这次的阴影我们改成用 Canvas 来画了。因为这样可以解决非整数倍屏幕缩放下的边缘抖动。当你的系统显示缩放倍率不是整数倍的时候（比如常见的 125% 或 150% 缩放），浏览器引擎哪怕渲染原生的 CSS 阴影，在做动画的时候阴影边缘都是不连续的，你盯着看会发现阴影在不停的闪烁和抽搐。但是用 Canvas 自绘的话，我们可以在底层精确控制它的像素对齐行为，保证阴影在任何缩放倍率下动起来都是连续的，这个烦人的破事就算给消了。

考虑到原版 Windows 10 的磁贴本来也没有阴影，我个人觉得这点性能开销反而不是什么太严重的问题。

卷轴

很多直排或者横向滚动的网站都会多多少少遇到这个问题，你想要让鼠标滚动的时候页面横向滚动。但实际上这里面的眉眉角角非常多。鼠标滚轮还好，触板怎么处理？平滑滚动怎么处理？其实还有很多小细节，我们把这些细节封装到了 Scroll 组件里。

把纵向滚轮自然映射为横向展开的卷轴，属于我们心心念念了很久但一直没精力组件化的东西。最近横向滚动在一个非常小的独立博客圈子里面变成了一种新的时尚潮流，我自己也认同横向滚动在信息呈递、空间利用率上的效率更高且对用户认知的消极影响更少。为了追赶这个时髦，我之前甚至还专门花了些力气把它集成到了我自己的博客里面（偷偷的塞到了侧边栏的一个小挂件上）。但当时的开发也就停在博客挂件的水平了。要不是这次推动 Axiom Design System 大改版的压力推着我走，估计下辈子这东西都没机会把它抽出来做成组件。

开始菜单

另一个是复刻广受好评的 Windows 动态磁贴网格 Tile Group。在这个组件的许愿上（对，不是我写得，Claude 写的），我真的是觉得 Claude Opus 猛得有点邪门。

开始菜单的排版和拖拽算法我当年自己试着写过很多个版本，结果全都无疾而终。因为磁贴网格那套多尺寸混排、分栏换行以及拖拽时实时避让重排的算法真的太难了，我不管怎么试都理解不了里面的逻辑，去网上查资料也没得到什么有意义的信息。

结果 Claude 看到我的诉求，只是淡淡地说了一句：「我也查不到资料，但是我印象中应该是这么做。」然后它就凭着这个所谓的「印象」直接把整套排版和拖拽重排逻辑给写出来了，跑起来丝毫不差。

印象中……印象中……在连资料都查不到的情况下，你这个印象到底是打哪儿来的…… 淦……这也太鬼了吧……

尾巴

把这里面大大小小的门道全部理顺，这两天我基本上就没有合过眼，一直在连续不断地调细节、修边界 Bug。最后把整套东西调出来的时候，认真觉得还蛮开心的。现在用这套图形系统可以组合出非常多非常炫炮的玩意，实测下来整体性能也完全在可接受的范围内，算是填了一个旷日持久的大坑。

但另一方面，折腾完这一遭，心里还是免不了感叹人类的渺小。

想当年为了把一个简单的正方形 Reveal Highlight 光效做到百分之百精确复刻，我连续熬了好几个月，而且还是好几个裙友一起帮忙修 Bug、调打包构建，才一点点把东西磨出来。结果到了今天，你修了好几个月的 bug，Claude 扫一眼就把它秒了。你说爆肝两天是很累，但是各种条件的网格搜索如果让人来做指不定还要做多久。现在新的模型都带多模态了，很多时候 debug 都会变得更省心，它会自己开浏览器自己写代码自己截图，我也就是盯着并且提供一些专家直觉。

但另外一方面，我也得公允地讲，如果七年前我们没有花时间在那边数毛、做回归、算公式，也没有在脑子里想清楚整套图形基建应该怎么拆解，那今天就算直接把诉求交给 LLM，它们可能也没法把质感复刻得这么准确。

就像我前面说的，半吊子的尸块动效是最糟糕的东西。

嘛，虽然道理都懂，但偶尔还是会忍不住开始怀疑人生，甚至我自己也不知道到底在怀疑什么。

以上，这就是今天的技术报告，如果你对这套重做之后的图形系统和组件感兴趣，欢迎去 Axiom Design System 官网 或者 GitHub 仓库把玩一下。

感谢你能读到这里。祝你大便通畅、不沾马桶。