没有 liquid-glass.css：审美潮流与官方设计系统的分界
本文所有仓库信息核对日为 2026-08-09，以上游仓库最新内容为准。
「做个 Apple 那种 Liquid Glass 的首屏」是个听起来很具体、其实很危险的需求。危险在于它长得像一个可以 npm install 的东西，但它不是。taste-skill 的默认 skill 在 §2 里专门为这类需求划了一条线：一侧是有官方包的真实设计系统，另一侧是只有名字、没有包的审美潮流。这条线画在哪，决定了你（和你指挥的模型）接下来是去装包还是去写近似实现。
一、§2 是一个岔路口，不是一张表
先说清楚这一节的结构，很多人读串了。
skills/taste-skill/SKILL.md（文件夹名是 taste-skill，install name 是 design-taste-frontend，两者不是同一个字符串；全文 1206 行）的 §2 标题是 BRIEF → DESIGN SYSTEM MAP，它的立场原文是一句很硬的话：有官方包的东西不要自己手写 CSS，也不要把审美潮流冒充成官方体系。
这一句里其实藏了两个方向相反的禁令，所以 §2 底下挂着两张表：
- §2.A 是「需求读起来像某个真实设计系统」的映射，十二行，从 Fluent UI、Material 3、Carbon 一路到 GOV.UK Frontend、USWDS、Bootstrap 5.3。命中这张表的处理方式是装官方包。这张表怎么读、Honesty rule 和 One system per project 两条硬规则各自管什么，我们另有一篇专门讲，这里不铺开。
- §2.B 是本文的主角：当需求是一种审美而不是一个体系时该怎么办。
区别在哪？§2.A 那些名字背后都有一个你能装、能查文档、能引 token 的官方仓库。§2.B 里的那些名字背后什么都没有，只有一堆网上流传的写法。
二、§2.B 的八行：全是「无库」
skill 给的这张表，原文措辞是：这些方向没有单一官方包，实现方式是原生 CSS + Tailwind + 维护良好的组件库，并且要在代码注释里诚实标注哪些是借鉴、哪些是官方材料。
| 审美 | 诚实的实现方式 |
|---|---|
| Glassmorphism / 磨砂玻璃 | backdrop-filter、层叠边框、高光叠层；为 prefers-reduced-transparency 提供实色回退 |
| Bento（Apple 式瓦片网格） | CSS Grid 混合单元格尺寸。没有任何库拥有这个模式 |
| Brutalism | 原生 CSS、等宽字体、生硬边框。无库 |
| Editorial / 杂志 | 衬线字体、非对称栅格、慷慨留白。无库 |
| Dark tech / hacker | 等宽 + 霓虹强调色、终端符号。无库 |
| Aurora / mesh 渐变 | SVG 或层叠径向渐变。无库 |
| Kinetic typography | 原生 CSS 动画、滚动驱动动画，劫持滚动时用 GSAP。无库 |
| Apple Liquid Glass | Apple 只为 Apple 平台记录了它。没有官方的 liquid-glass.css。Web 实现是用 backdrop-filter + 层叠边框 + 高光做的近似，必须明确标注为近似 |
八行里有五行的实现列直接写着「无库」（Brutalism、Editorial、Dark tech、Aurora、Kinetic typography），Bento 那行写的是「没有任何库拥有这个模式」，Apple Liquid Glass 那行写的是「没有官方的 liquid-glass.css」。也就是说，八行里有七行在明确告诉你：别去找包了。这是这张表最值得注意的地方：它不是在教你怎么做玻璃拟态，它是在否定一批不存在的依赖。
为什么要专门写一节去否定不存在的东西？因为模型很容易顺着名字往下编。你说 Bento，它可能就给你 import 一个听起来很合理的 bento 库；你说 Liquid Glass，它可能就给你一段 @import 指向一个不存在的 CDN。这一整节的作用，是把这条路提前堵死。
顺带一提，同一份 skill 的 §3.F 把这件事又强调了一遍：引入任何第三方库之前先查 package.json，包不存在就先输出安装命令，原文用的是 Never assume a library exists。§2.B 和 §3.F 是同一个焦虑的两种写法。
三、Apple Liquid Glass 这一行，值得逐字读
表里第八行是唯一一个被 skill 单独拎出来写成整个附录的。
Appendix C 的标题是 “Apple Liquid Glass: Honest Web Approximation”，它把这件事拆成了三段：
什么是官方的。 Apple 在自己的 Human Interface Guidelines 和开发者文档里，为 Apple 平台记录了 Liquid Glass，它是 Apple 平台 UI 里使用的一种动态材质。Apple 的原生实现属于 Apple 平台 API 和系统组件，不是一个公开的 web CSS 包。
什么不是官方的。 附录原文一句话：Apple 没有为普通网站提供 liquid-glass.css。
那 Web 上能做什么。 可以用 backdrop-filter、透明背景、层叠边框、高光叠层、渐变、动效，再配强对比回退。但附录同时钉死了一句：那是 web 玻璃拟态 / 磨砂近似，不是官方 Apple Liquid Glass，要在注释里如此标注。
附录里给了一段 .liquid-glass-web-approx 的 CSS 骨架，包含 ::before / ::after 高光层、@media (prefers-color-scheme: dark) 的暗色变体，以及 @media (prefers-reduced-transparency: reduce) 下的实色回退。名字本身就带 -web-approx 后缀，这是把「标注为近似」这件事直接编进了类名里。
附录还留了一句很实在的提醒：prefers-reduced-transparency 的浏览器支持并不均匀，要测；而且即使在完全没有模糊的情况下，对比度也必须足够。这一句是给你的验收动作，不是给模型的修辞。
附录结尾的原话是：安装命令是「现实锚点」，Apple Liquid Glass 骨架是被标注过的近似，不是 Apple 发布的包。
四、判断依据：你的需求到底该走哪一侧
规则读完了，真正的问题是怎么用。给几个可操作的判断点。
第一步，问「这个名字背后有没有一个我能查的官方文档站」。 有，走 §2.A，去装包；没有，走 §2.B，老实写近似。Bento 这一行的措辞是「没有任何库拥有这个模式」——Apple 的控制中心长成那样，不代表存在一个 Apple 发布的 bento 组件库。名字来自产品观感，不等于名字来自某个仓库。
第二步，玻璃这类效果要先过语境关，再谈实现。 §5 把 Liquid Glass / Glassmorphism 列在 CONTEXT-AWARE PROACTIVITY 里，明写它适用于 premium consumer、Apple 邻近、奢侈品牌、媒体叠层这几种调性，不适用于仪表盘、公共部门、以及原文直白称呼的「无聊 B2B」。也就是说：客户说想要玻璃感，但页面是个 B2B 后台，skill 的口径是不该上。
第三步，真要做就别停在 backdrop-blur。 §5 给的做法是再加 1px 内边框（border-white/10）和轻微内阴影（shadow-[inset_0_1px_0_rgba(255,255,255,0.1)]），用来做边缘折射感，同时在 prefers-reduced-transparency 下给实色回退。§2.B 的第一行和 §5 这段是一致的口径，两处都点了那个回退。
第四步，别在同一个项目里混。 §2.A 的 One system per project 原文管的是设计系统这一侧：不许在同一棵树里混 Fluent React 和 Carbon，也不许把 shadcn/ui 组件塞进 Material 3 应用。把它推到审美侧是我们的类推，不是 skill 原文，但道理是一样的：一个页面同时上磨砂玻璃、brutalism 硬边框和 editorial 衬线，得到的不是「层次丰富」，是三种互相打架的语言。
第五步，检查表里有对应的那一格。 §14 Pre-Flight Check 一共 62 个复选框（完整清单我们另有一篇专门拆），其中与本文直接相关的是这一条：设计系统是否按 §2 选定，或者审美是否被诚实标注。换句话说，这条分界线不是 §2 里的一句劝告，它在交付前的检查矩阵里有一个自己的位置。清单末句原文是：若有任何一个复选框不能诚实打勾，页面就没做完。
五、必须说清楚的一件事：这些是提示词，不是工程保障
我们实读这个仓库的顶层：没有 src/、没有 npm 包、没有构建产物，scripts/ 下那 4 个 .mjs 处理的是 README 的图片资源，与 skill 功能无关。核心资产就是 skills/*/SKILL.md 这几份 Markdown。也就是说，SKILL.md 里的每一条都是写给模型看的提示词约束，包括本文讲的这条分界线；这份默认 skill 当前自标 v2 (experimental)，仍在迭代。
所以「必须明确标注为近似」这句话的性质是指令，不是「装了这个 skill 之后你的代码注释里就一定会出现这行标注」的结果。同理，「没有官方的 liquid-glass.css」是写在提示词里的一条知识陈述，它会不会被遵守、遵守到什么程度，取决于模型和上下文，我们没有做过任何验证，也不该当成工程保障。真正的确定性只能来自你自己的构建链：装包前跑一次依赖核实、代码评审时搜一遍不存在的 @import、CI 里让 npm install 自己去报错。规则文本管的是倾向，构建链管的才是结果，这两件事不要混。
判断要不要采纳这一节，标准也就清楚了：如果你的团队经常收到「做个 XX 风格」的需求，而模型交上来的代码里带着查不到的依赖，那这一节直接对着你的痛点；如果你的场景本来就只用一套内部设计系统，从不接审美潮流类需求，§2.B 对你基本是空转的。
六、一句话收尾
§2 真正教的不是「玻璃怎么做」，而是怎么诚实地回答「这个东西有没有官方版本」。有，就用官方的；没有，就写近似并且说明白它是近似。Liquid Glass 只是这条规则最容易撞上的那个例子。
本文依据 taste-skill 官方仓库（github.com/Leonxlnx/taste-skill）的 README、CHANGELOG、
skills/ 下的 SKILL.md 与 .claude-plugin/ 清单整理，核对日 2026-08-09。
本文内容为仓库文档口径，我们没有安装或运行过其中任何一个 skill，
文中所有规则均为写给模型的提示词约束，不构成对输出结果的保证。
skill 内容随上游更新而变动，默认 skill 当前自标为 v2 (experimental) 且仍在迭代，请以仓库最新内容为准。
文中涉及 Apple Liquid Glass 的部分转述自该 skill 的附录，具体材质定义与平台支持请以 Apple 官方文档为准。