毛玻璃通透设计系统

为什么需要一套玻璃拟态设计规范

毛玻璃（glassmorphism）风格在落地时常常遇到两个问题：一是视觉语言容易碎片化，卡片、按钮、导航各自为政，透明度、模糊半径、阴影随手写；二是设计稿到代码之间缺少可测试的约束，设计师觉得"通透感不够"，工程师觉得"再加层 backdrop-filter 就行"，双方在无障碍与视觉新鲜度之间反复拉扯。

这套技能的目标不是产出一张好看的效果图，而是把 glassmorphism 拆成可执行的设计系统规则：用语义化 token 替代硬编码值，用显式的状态定义替代"感觉上该这样"，用 WCAG 2.2 AA 的验收标准替代口头承诺。

技能如何工作

核心能力是按固定工作流生成实现就绪（implementation-ready）的设计规范：

• 先定义令牌，再谈组件。颜色（primary、success、danger、surface 等）、字体（Plus Jakarta Sans / JetBrains Mono 的完整字重阶梯）、间距（舒适密度模式）先固定为基础，组件层只引用语义 token，不碰裸值。
• 组件规则覆盖完整生命周期。每个组件需要明确 anatomy、variants 和 default、hover、focus-visible、active、disabled、loading、error 等状态，同时描述键盘、指针、触屏三类交互行为，并处理长标签、空状态、溢出等边界情况。
• 无障碍声明必须可测试。每条规则不能只依赖"美观"这类模糊形容词，必须锚定 token、阈值或示例；遇到审美与无障碍冲突时，优先无障碍。
• 输出结构固定为七段：Context and goals、Design tokens and foundations、Component-level rules、Accessibility requirements、Content and tone standards、Anti-patterns、QA checklist。最后一段是可以直接拿到 code review 里执行的检查清单。
• 约束语言分两级：must 用于不可妥协的规则，should 用于推荐项；每条 do 规则至少配一个具体的 don't 反例，新增模式附带现有 UI 的迁移说明。

适用边界与注意点

这套技能生成的是设计规范文本，不是自动改代码的工具。它不会替你决定某个按钮该不该用毛玻璃，也不会绕过你的技术选型去直接渲染界面。规范里的具体数值（如 #1856FF 的蓝、#FFFFFF 的 surface）是参考默认值，实际项目中通常需要按品牌校准。

另外，技能自身有明确的安全边界：不自动安装依赖、不修改系统权限、不创建持久化任务、不执行下载内容；涉及发送、发布、删除、付款、部署等外部写入操作时，必须先展示目标与影响并取得明确确认；命令与代码默认仅作参考，只有在用户明确要求且目标范围清晰时才会运行。

换句话说，它负责把 glassmorphism 的决策变成团队可以 review、可以测试、可以迁移的工程文档，而不是替你做设计决策。