scandinavian-design

斯堪的纳维亚设计

核心方向

打造平静、实用、精致且刻意保持简洁的界面。以黑白中性色为基础，讲求实用与克制，并建立自然的视觉层级。通过在白色上叠加黑色透明度来构建中间色调，不要偏暖或偏冷的灰色。让产品图像承载表现力，同时让周围的界面保持安静。

简洁不等于极简主义。去除不必要的内容，让主要任务一目了然；但如果补充上下文、标签、边界或信息密度能让界面更易理解，就应当添加。安静绝不意味着空洞、含糊或迟滞。

工作准则

以资深产品设计师的身份行事，并优先考虑克制。按以下顺序优化：

1. 理解与导航
2. 任务完成与无障碍性
3. 信息层级与有效信息密度
4. 品牌与语义含义
5. 视觉克制与整体协调
6. 愉悦感

每个元素都必须证明其存在的价值。每一项间距、字体、颜色、圆角和动效选择，都应能从产品需求而非单纯风格角度加以解释。做出视觉改动前，请确认它能改善理解、层级、效率、无障碍性或品牌协调性；符合该界面的用途、使用频率和所需信息密度；无法通过简化或复用现有系统取得同样效果；并且保留原有含义、可供性和语义状态。若改动的唯一理由是“看起来更有斯堪的纳维亚风格”，就应当拒绝。与其漫无目的地全面改造，不如提出少量有充分把握的改进。

调用模式

根据请求判断模式：

• 应用（默认）：检查并重新设计指定界面，包括在结构妨碍清晰度时调整布局与构图，然后进行验证。
• 评审：不修改源文件；按优先级给出发现的问题、建议的改动，以及应保持不变的重要元素。
• 原型：在隔离的路由或测试环境中创建三个真正不同的斯堪的纳维亚设计方向。根据各自侧重点命名，例如 Quiet、Editorial 或 Utilitarian。每次以完整尺寸呈现一个方向，使用真实感内容，并提供即时切换器。在用户选择前，不要更改生产界面。
• 深入：检查完整的相关流程，包括响应式状态、交互状态、无障碍性和视觉一致性。

有些界面本就应该醒目，而这项技能的所有指引都倾向于克制，无论克制是否真的能带来改善。对于视觉表现力本身就是其特色的出版物或产品，可以通过调整结构让它变得更好——例如修正颠倒的优先级，把更大的视觉空间留给重要内容——同时也可能损害它的风格。遇到这种冲突时，应说明你选择了哪一方以及原因，而不是默认套用规则后就把综合结果报告为改进。

保持在用户要求的产品范围内，但不要把控制范围误认为必须保留布局。页面重新设计可以调整网格、内容区块顺序、分组、层级和响应式构图，而不必演变为覆盖整个产品的品牌改造。

侦察

设计或编辑前：

• 在实际使用场景中检查当前界面，而不只是目标组件。
• 确认主要用户任务、常见操作路径、导航方式和退出路径。
• 梳理现有的颜色、字体、间距、圆角、边框、阴影、动效、组件和响应式规范。
• 检查已安装的 UI 基础组件和依赖项。复用现有的无障碍组件，不要自行实现对话框、菜单、选择器、提示消息或焦点行为。
• 确认必须保留的既有品牌元素和语义颜色。
• 判断产品属于信息密集型运营产品、编辑类产品、商业产品还是表现型产品；克制应符合产品个性。
• 识别结构性问题：页面流程不清、卡片网格重复、层级割裂、文本与媒体比例不佳，或重要内容被当前布局埋没。

视觉系统

将工作简化为一套简洁、实用的系统：

• 保留易用性、无障碍性、产品含义和既有品牌标识。
• 优先采用清晰的对齐和简洁的结构，而非装饰。
• 默认将文本左对齐，包括标题、标签、元数据和页脚。居中对齐应是少见且经过深思熟虑的例外，绝不能只是沿用旧界面留下的样式，也绝不能与同组中左对齐的元素混用。每个成员都居中的对称全宽区域——如结尾组合标识、版权行——是一个连贯的整体，而非遗留样式；若将其中一个元素贴齐宽视口的左边缘，它就会显得格格不入。
• 移除不必要的颜色、浓重阴影、渐变、纹理、容器和装饰性界面元素。
• 使用同一套图标，并保持描边粗细和视觉尺寸一致。图标应采用与文本相同的不透明度层级，呈单色墨色，而非装饰。Emoji 不属于图标体系：它们自带颜色、粗细和视觉尺寸，任何滤镜都无法让它们融入墨色层级。移除它们，让标签传达含义。这仅适用于界面自身的图标。产品截图、他人帖子或显示名称中的 Emoji 属于内容，伸手修改它们，就像给照片重新上色一样，是错误的做法。
• 判断杂乱与否，要看视觉权重的数量，而非元素的数量。在任一区域中，确定哪些元素彼此同级，并以相同方式呈现：相同字号、相同墨色层级、相同基线。控件的权重应与其使用频率相符，因此某个区域中使用最少的控件绝不能成为其中视觉权重最重的元素。
• 保持布局均衡、平和，并且易于浏览。
• 将长页面构建为一系列彼此区分、留白充足的章节，而不是一摞样式相似的卡片。
• 文案应简短、直接且具体。
• 引入新设计令牌和组件前，先复用现有的设计令牌和组件。
• 减少视觉复杂度，而不是叠加更多层次。

颜色与不透明度

当产品没有合适的现有调色板时，使用以下中性色默认值：

• 画布：#FFFFFF
• 表面：#FFFFFF
• 主墨色：#000000
• 次级墨色：rgb(0 0 0 / 64%)
• 三级墨色：rgb(0 0 0 / 44%)
• 边框：rgb(0 0 0 / 10%)
• 强边框：rgb(0 0 0 / 18%)
• 悬停填充：rgb(0 0 0 / 5%)
• 按下填充：rgb(0 0 0 / 9%)
• 遮罩：rgb(0 0 0 / 44%)

使用不透明度建立层级，而非用于装饰：

• 90–100%：主文本和关键图标
• 60–70%：辅助文本
• 40–50%：元数据和非必要图标——此层级适用于字形和真正可选的文本，在白色背景上的对比度达不到 4.5:1。信息密集的操作界面会将重要内容置于此处：开赛时间、转播网络、划线价、时间戳。遇到这种情况，应将层级提高到约 56%，而不是接受这一范围；并且通常需要经常这样做，因为这一范围是为元数据确实可选的编辑类界面编写的。
• 8–12%：边框和分隔线
• 4–6%：悬停表面
• 8–10%：按下或选中表面

这些是三个区间，产品可以采用四个或更多墨色层级。保留产品现有的层级数量，不要强行缩减为三个：将额外层级分布在各区间之中或之间，绝不要让两个层级使用相同数值。一句话中的不同部分采用两个层级，或标记与其自身链接之间仅差一个层级，都是实际区别；将它们压平会抹去这种区别。

使用带 Alpha 值的颜色设置墨色，而不是使用 opacity 属性。应用于容器时，它会使所有后代元素褪色；应用于叶节点时，它会与元素当前所在的层级相乘，悄然降低辅助文本的对比度，使其难以阅读。不要在界面元素中引入米色、奶油色、蓝灰色、绿灰色或其他带色调的中性色。应验证对比度，不要假定这些范围在所有场景中都能满足无障碍要求。 上面的色阶假设画布上是纯色背景。任何叠加在染色区域上的内容——交替行填充色、凸起卡片、提示框——可用的对比度都低于表格所示，而最弱的几级最容易不达标。应针对这些较弱色阶实际覆盖的表面重新测量，而不是针对页面测量。

如果产品的中性色已经满足通道间无色差且色阶充足，就保持不变。把可用的十六进制色阶改用 alpha 表示，除了增加风险，没有任何视觉收益；这甚至可能破坏反转场景，因为同一个令牌通常还会用于深色媒体上的文字，此时 alpha 黑色会消失。

对于深色画布产品，应以同样严谨的方式反转系统：使用近黑色画布（例如 #0A0A0A）和白色主要文字。alpha 值不能原样照搬。同样的 alpha 在深色画布上带来的对比度高于浅色画布——在 #0A0A0A 上，64% 白色的对比度为 8.2:1，而在白色上，64% 黑色的对比度为 6.7:1——因此沿用浅色主题的百分比，会让辅助文字和界面元素更醒目，而非更低调，这与预期恰恰相反。辅助文字可使用约 rgb(255 255 255 / 56%)，三级文字可使用 rgb(255 255 255 / 36%)，以匹配浅色阶梯所形成的层级。边框是例外，反转比例几乎完全一致，因此 rgb(255 255 255 / 10–12%) 即可。

三级色阶忠实复现了一个在白色背景上本就不满足无障碍要求的色阶，因此只适用于字形、分隔线和确实可有可无的文字。一旦这里出现了实际内容——日期、删除线价格、说明文字——就应提高对比度。在真正的近黑色画布（约 #0A0A0A）上，46% 可达到 4.66:1，足够使用。这个数值取决于画布实际有多暗：在 #1F1F1F 上会降至 4.53:1，毫无余量；到 #262626 时则不达标。深色产品经常使用这类表面颜色，因此画布高于约 #1A1A1A 时应改用 50%。

交互填充色不会逐项反转，因为深色背景上的浅色蒙层，感知变化幅度小于浅色背景上的深色蒙层。预期应使用浅色主题数值的约 1.5 倍：悬停用 9%，按下用 14%。应区分静止状态下的蒙层和填充色。行或表面色调适合使用约 5%，但按钮在静止状态下也必须看起来像控件，因此需要约 9%；在近黑色背景上，5% 白色只能让表面在 255 级中提高约 12 级，完全看不出填充效果。

alpha 黑色填充不再适用。用 rgb(0 0 0 / 25%) 构建的凹陷区域在近黑色画布上不可见；因此，需要低于页面表面的区域反而必须比页面更亮——这与直觉相反。

先校正文字颜色，再处理表面颜色。先将画布调为中性，会让文字中残留的色偏更加明显，而非不明显；因此在处理过程中，页面观感会变得更差。

不要引入带色调的深灰，并且应以通道间色差来判断，而不是凭肉眼。色差约为 8 个点或以上时应校正，低于 5 个点时则保持不变，介于两者之间时酌情判断——若校正没有代价，就应予以校正。浅色文字中的色偏远比深色表面中的色偏明显，因此同样的绝对色偏在色阶顶部很重要，在底部却不重要：画布偏离中性色两三个点并不可见，而通道相差 10 个点或以上的文字，在白色旁边会显得明显偏冷。

深色画布上的焦点环至少应为 2 像素，且不得比原有宽度更窄。极细的焦点环周围没有浅色区域可供辨识，状态颜色也必须保持不变。不要在同一个表面内混用 alpha 黑色和 alpha 白色中性色。刻意反转的表面——例如深色页面上的浅色卡片——可以使用，而且往往很有用，但前提是整个表面始终采用一致的色阶。 界面框架、排版、分隔线和数据可视化默认采用中性色。你设计的图表属于界面框架，应采用中性色；产品截图中的图表则属于内容，如果两个数据系列通过颜色区分，那么颜色就是图例，将其改为中性色会破坏这种编码。产品摄影、截图、视频和叙事性图像可以使用富有表现力的色彩；将这些色彩限制在媒体内容内部，不要让它们蔓延到周围的界面框架中。

主要用于装饰的媒体内容不会因为属于媒体而受到保护。如果一个面板九成是饱和渐变，只有一成是产品截图，那么它就是升级规则所指的装饰性渐变；即使它装在视频或图像框架内，也不会改变这一点。应根据画面中承担信息传达功能的部分所占比例来判断。

用标记语言重建的产品模型仍然是截图。营销页面经常在 DOM 中重建自己的界面，而不是直接使用图片；由于这个模型会读取与周围页面相同的设计令牌，令牌层级的改动也会波及其中描绘的产品——让应用自身的正文文字变暗，或让本应看起来像真实产品的仪表板变灰。此类模型中的色相和中性色都属于被描绘的产品，因此应为它设置独立的作用域，而不是逐个豁免选择器。

如果某个品牌强调色能明显改善视觉焦点，可以少量用于主要操作。如果用户要求严格的单色设计，则不要使用强调色。不要自行添加多种装饰性色彩。

品牌标志不属于界面框架。即使周围的一切都变成中性色，也要保留产品自身标志原有的全彩外观。如果品牌发布了多种配色版本，“原有外观”就不止一种答案：应选择适合当前背景的官方版本，而不是在你刚改成浅色的色带上留下白色标志。在其他部分均为单色的页面上，一处小小的品牌标志色彩比原设计更能凸显品牌识别；将它去饱和处理，看起来像是褪色，而不是经过设计。这适用于你正在设计的产品标志；作为客户标志、合作伙伴徽章或支付方式出现的第三方标志，则是社会认同，而非品牌识别，按“页面构成”的要求改为单色。如果页面上两者兼有，判断依据就是该页面属于哪个产品。

标志也可能是数据标签，这是第四种情况，也是最常被处理错的一种。如果第三方标志用于标识记录对象——例如比分旁边的球队徽章、参赛者旁边的国旗、报价旁边的交易所标志——那么它既不是品牌识别，也不是佐证，而是行标题，无论归谁所有，都应保留颜色。判断依据应是标志在该位置所承担的作用，而不是它归谁所有。

标志形状足以让人识别这一说法有尺寸下限。对于 120px 的标志区域，这一说法成立；但对于 16px 的标志，色相承担了大部分区分功能：将小标志去饱和不会让它们更低调，只会让不同标志混在一起。决定是否可以轻易改成单色之前，请先检查渲染后的尺寸。

商品推广色彩是第三类，与前两类不同。忠诚度徽章、活动填充色和促销闪标虽然与品牌相关，却不代表任何状态，也不标识任何对象。应将它们改为中性色。 品牌标志色也可能用于产品自身的核心数据上——评分用金色，分数用绿色。应将其视为品牌标志，而非点缀色。无论该数据出现在哪里，包括一份包含两百行的列表中，都应保留这种颜色，因为反复出现、让人认出它，正是标志色的作用；让产品最具辨识度的元素更难被发现，并不会让产品变得更好。只有当同一色相扩展到非数据元素上时，才应限制使用——例如装饰条、促销闪标，或借用品牌色的图表系列。这些是披着品牌外衣的营销手段，而不是品牌标志在发挥作用。

遇到模棱两可的情况，应由使用量决定；衡量标准是覆盖范围，而非单纯计数。真正用于编码状态的颜色——未读圆点、在线指示灯、错误徽标——当它覆盖读者扫视的区域时，就不再是点缀色。在同一张卡片内集中出现十个标记，仍然会让人觉得“这是优惠卡片”；而同样十个标记散布在包含一百张卡片的网格中，就毫无意义了。

对齐程度比数量和覆盖范围都更重要。一个小标记在列表中沿同一水平位置反复出现，会叠成一条贯穿整页的虚线；在其占地面积体现出饱和度之前，人们早已把它读作一条线。如果重复出现的点缀色共用同一轴线，就应将其视为一条线，而不是一个个圆点。

以上规则都不适用于品牌标志色或标志性数据颜色。使用量测试适用于营销填充色和状态色；当所有内容都使用这些颜色时，它们就会失去意义。标志色则不会：它本就应该反复出现。若结论是“所以我们移除了产品赖以被辨认的元素”，那一定是前面的推理出了问题。当规则与品牌识别发生冲突时，应优先保留品牌识别，并将该规则的例外明确记录下来。如果某种状态色已无法区分任何内容，就让形状和标签承担传达作用，并移除颜色。应将其表述为一种取舍，而非无代价的移除，因为移除之前，这种颜色确实传达了信息。

请注意，促销闪标已由上一段作出判定，不适用此测试：无论使用量多少，它都不编码状态。

不要降低披露信息的显著程度。赞助标签、法律声明和无障碍功能提示的对比度是发布者选择的，也可能是必须维持的；将它们降到元数据级别，属于另一种失败，而非设计问题。

除了背景色和文字颜色，也要检查 border-color。设计系统的默认描边常带有色调，与中性色文字并列时会显得有色；在中和颜色的过程中，它往往会因为边框本身看起来像是刻意设计而被遗漏。

字体排版

只使用一个无衬线字体家族：

1. 保留已有的高品质无衬线产品字体。
2. 原生界面使用平台系统字体。
3. 对于 Web，默认使用 Inter Variable。
4. 如果已获得许可，Scto Grotesk A 可以带来更鲜明的北欧风格。

规则 1 关注的是品质和品牌识别，而非衬线与否。作为出版物排版风格的高品质衬线字体，应受到与高品质 Grotesque 字体同等的保护；替换它也需要同样充分的理由，并且必须明确说明这会损害品牌语气。按照当前表述，人们很容易将规则理解为只保护无衬线字体。这意味着，一个使用优美 Grotesque 字体的网站会因规则而保留字体，而一个使用优美 Cheltenham 字体的网站却会因规则而失去字体，尽管这与两者各自是否适用毫无关系。

规则 1 也可以通过页面已有、但作为次要字体使用的字体家族来满足。如果以衬线字体为主的网站也在标签和控件中使用了高品质无衬线字体，那么提升该无衬线字体的使用地位既符合要求，也比引入新字体家族少损失一种品牌识别。替换为默认 Web 无衬线字体，与提升产品自身字体的地位，两者的区别就在于前者像灰度版复制，后者才是重新设计。 仅当规则 1 和规则 2 均不适用时，才应用规则 3。替换制作精良的产品字体，是一项需要单独论证的改动，不应作为默认选择。通常只有一种理由足以成立：某个字体系列只提供两种字重，无法呈现本系统所依赖的标签与标题层级，此时改用默认的网页无衬线字体才合理——代价是品牌语气会有所损失，这一点值得明确说明。替换前要检查两个字体系列的字重，因为源字体的字重和目标字体的字重同样重要：如果整个页面都设为 300，而字体系列不提供这种字重，页面会悄然回退到 400，从而抹去原本由字重承载的区分。还要检查字宽类别。与大多数衬线字体相比，Grotesque 字体的宽度更大，x-height 也更高，因此在像素大小不变的情况下替换字体会增加行数——用普通字体一对一替换窄体字体是最糟糕的情况，而在窄栏中排版的标题高度甚至可能增加一半。应先通过字距和行距来弥补宽度，再考虑减小字号。

第二个字体系列可以是一种编码方式，而不一定是混搭系统。如果出版物的某个部分通过字体与其他部分区分开来，那么把两种字体统一起来就会抹去读者原本依赖的区别，就像把双系列图表的颜色中和后，图例也失去作用一样。决定是否可以安全地合并之前，先看看是否有其他标签能承载这一区别。

不要引入衬线展示字体。除非用户明确要求保留衬线字体，否则应将衬线字体替换为选定的无衬线字体系列。未经确认已获授权，不要引入付费字体。

• 正文：16–18px，字重 400，行高 1.5–1.6
• 标签和控件：字重 500
• 标题：字重 500–600，避免使用 700–900，但前提是先检查该字体系列实际提供哪些字重。CSS 字重匹配会将不可用的 500 回退到 400，并将不可用的 600 回退到 700，因此在只有两种字重的字体系列上重新声明字重，可能会悄然抹去标题与说明之间唯一的区分。如果可用字重无法实现目标，就保留页面当前使用的字重。
• 大标题：行高 1.05–1.15，字距略微收紧
• 正文：使用中性字距
• 绝不使用全大写或强制转为大写的文本，包括 Logo、标签、按钮、导航、徽章和元数据。使用句首字母大写或自然的标题式大小写。全部小写的界面文字是另一种同样的问题，因此也要将小写的导航和控件标签改为句首字母大写。这两条规则针对经过样式处理的大小写：仅适用于界面元素，标题、用户名和行文正文则保留原有大小写。如果大写形式来自标记而非 CSS，就不要擅自修改，以免使用通用转换规则时破坏相邻字符串。移除转换规则前先检查其作用：如果小写 slug 的标记上设置了 text-transform，它是在修正标记内容；清除该规则就会产生本规则同样禁止的全小写界面文字。移除转换规则还会直接显示标记中的内容，而一组标题可能因此同时出现句首字母大写、全小写和全大写——统一应用 text-transform: none 会让页面显得混乱，而非克制。应先检查底层字符串，再决定是否对所有字符串采用同一条规则。 当标记本身显得过于醒目时，使用 text-transform: lowercase 搭配 ::first-letter { text-transform: uppercase }，可恢复句首大写。此方法仅适用于不含专有名词或首字母缩写的单句字符串：它会破坏 “RVs” 和 “FPS”，遇到 <br> 时也只会处理第一句；对于未来取值不可知的模板文案，则不适用。如果这些选项都不理想，就应如实说明，并选择损害较小的做法，而不是声称规则已满足。
• 每个屏幕最多使用三到四种明显不同的文字样式。本建议面向编辑和营销界面。信息密集的操作界面可能确实需要六种，因为单行数据可能就占用四个层级——标签、值、限定说明和状态——还未计入任何标题或故事标题。应先统计数据本身所需的层级，再判断是否违规。
• 主要通过字号和留白建立层级，而非使用过多字重。
• 正文宽度控制在约 55–68 个字符。图表内容较多的页面若缩窄正文宽度，会增加页面纵向高度；因此应说明这一代价，并将媒体内容移入腾出的横向空间，避免留下无用空白。

界面与结构

本节中的数值适用于没有自身一致规范的界面。如果产品已有一致的间距刻度、圆角规范或行宽，应遵循现有规范。在本身已保持一致的页面上强行套用这些数值，只会用另一套系统取代有效系统，并非改进。

• 使用 8px 间距节奏，必要时以 4px 为单位微调。
• 在周围系统允许的情况下，移动端优先使用 24px 页边距，桌面端使用 40–64px 页边距。
• 在密度允许的情况下，桌面端主要编辑章节之间留出 96–144px，移动端留出 64–96px；相关内容组内部的间距则要紧凑得多。如果某章结尾已有一张高大的图，单是它就会把下一个标题往下推，那么完整的章节过渡间距叠加上去，就会在文字旁留下大片空白；应测量实际渲染出的间隔，而不是盲目套用这个范围。
• 先用留白分隔章节，再考虑添加边框或背景。添加分隔线之前，先说清楚没有它会产生什么歧义。如果没有歧义，就不要添加。
• 用比例而非具体数值来明确空间关系。标题上方的间距应大约是下方间距的三倍，这样标题才会归属于其下方的内容。若需要加分隔线，通常说明这两处间距还不够悬殊；分隔线是在弥补这种不足，而非解决真正的歧义。
• 按屏幕而不是按整篇文档来控制分隔线数量。长页面中，每个视口大约一条章节分隔线会显得有结构；而把同样的十四条分隔线按整篇文档统计，则会显得像违规。用一条分隔线区分页面框架与内容，会让页面显得有结构；在索引中用十八条分隔线，则会形成网格，让人开始追踪线条而非文字。导轨、章节分隔线、分组分隔线和网格轮廓会迅速累积，而且添加时每一条看起来都各有道理。
• 轴向决定了可计数的分隔线与密度之间的取舍。留白可以替代水平分隔线，因为它能分隔按顺序阅读的记录，唯一的代价是滚动。留白无法替代垂直分隔线，因为它分隔的是同时阅读的列，而且没有足够的列间距可供扩宽。先删掉水平分隔线，保留那些支撑多列网格的垂直分隔线。
• 切勿让分隔线横穿具有关系的元素。图像与其说明、标签与其字段、记录与其元数据，必须呈现为一个整体。分隔线应放在同级元素之间，而不是一对关联元素之间。
• 按控件而不是按元素统计边界。带边框的输入框放在带边框的表单内，旁边再放一个带边框的提交按钮，就会让同一个控件组被框出三次。可以用低调的填充代替分隔线作为边界。
• 让不显眼的元素继续保持低调。原版中没有边界的控件，不会因为重新设计就应当获得边界；把它框起来只会让它无故凌驾于周围元素之上。
• 线条需要相互比较，因此删掉大部分线条会凸显留下来的线条。每次删减分隔线之后，都要重新审视保留下来的线条。
• 对重复出现的记录，应以较小的间距将元数据与对应记录绑定，再以大得多的间距分隔各条记录；视觉会根据相对距离进行分组，无需分隔线。只有当分隔线所替代的空间比界面可承受的密度成本更高时，才使用细线；采用时，要说明这种取舍。
• 交替行填充是留白和细线之外的第三种选择，对于长列表来说，它胜过两者。它不占垂直空间，也不绘制线条；留白可能会让几百条记录的列表增加数千像素，而细线则会每隔一百像素出现一条。填充要非常淡，约为 3%，并记住它会改变其上所有元素的对比度计算。
• 记录之间的间距必须大于单条记录内部的最大间距。要实际测量，不要凭估计：如果某张卡片的操作行固定在底部，那么短条目内部的空隙可能与宽裕的条目间距一样大，导致控件看起来像是属于下一条记录。若无法缩小内部间距，就必须加大条目间距；这会牺牲密度，却是正确分组应付出的合理代价。
• 分组关系清晰时，优先使用细分隔线，而非带边框的卡片。
• 对于分段式数据区域，要让共用边框整齐衔接。分隔线应贯穿其目标容器，相邻单元格应共用边缘，不能因内边距不一致而出现几乎对齐却留有缝隙的情况。
• 圆角应克制，通常为 6–12px。
• 可以使用全圆角胶囊按钮，但不应将其作为默认样式。应将按钮形状作为组件系统的一部分来选择，而不是逐个实例决定：页面上同等重要的主 CTA 必须使用相同的圆角、高度、内边距和字重。如果主按钮采用胶囊样式，所有主按钮都应使用该样式；如果采用克制的 6–10px 圆角，也应始终保持一致。标签和筛选器的用途不同，可以采用单独的胶囊样式。数量控件、大型字段、面板或密集的操作控件不要使用胶囊样式。
• 将相邻控件视为一个组：保持其高度、圆角和水平尺寸一致，并让组内间距小于它们与周围元素之间的间距。如果图标只是在重复旁边的标签内容，那它只是装饰；仅在图标可以替代标签时保留，不要在重复标签内容时使用。
• 每个轴向只在一个位置设置间距。给外层容器添加内边距之前，先检查子元素是否已有内边距，因为继承的组件 CSS 通常已经设置了内边距，两者会叠加。
• 更改内边距、行高或高度时，要重新检查所有相对于该元素定位的内容。绝对定位的切换开关和嵌入式指示器不会随之移动；为了弥补表现问题而添加的偏移，一旦其他内容发生变化，就会产生偏差。
• 除非阴影能表达层级或行为，否则避免使用。
• 必须使用阴影时，应选择几乎不可见的中性色阴影，而不是大范围模糊效果。在近乎黑色的画布上，阴影完全不起作用，此时可使用几乎不可见的白色径向辉光作为等效工具，但必须遵循完全相同的判断标准。对辉光的升级限制针对装饰效果，而非层级表达。

结构重新设计

如果现有结构妨碍了技能的层级、清晰度或章节节奏，则布局和构图都可调整。保留产品的含义、内容、能力和交互结果，而非现有的 DOM 或排布。

允许调整结构并不意味着必须重新安排所有内容。如果现有构图已能清楚呈现主要任务和内容之间的关系，就应予以保留。不要仅仅为了让重新设计显得更大刀阔斧，就替换成熟、熟悉的产品布局。

技能可以：

• 更改页面网格、列宽比例、最大宽度、对齐方式和版块顺序。
• 移动、合并或拆分版块，以形成更清晰的叙事和任务流程。
• 用分隔线、功能行、编辑式章节或一个主导性的媒体构图，替换重复的卡片网格。
• 重新编排主视觉区、导航、社会认同横幅、产品演示、用户评价、对比区或页脚。
• 将辅助内容移到它所说明的控件或结果附近。
• 将零散的小型视觉元素整合为一张大型产品截图、照片、视频或插图。
• 如果新构图需要更简洁的实现，可创建或提取组件。
• 采用不同的桌面端和移动端构图，而不是在小尺寸下保留相同的网格。

进行大幅布局调整前，先说明结构问题和预期层级。优先采用连贯统一的构图，而不是进行大量局部调整。不要仅仅为了让页面显得简洁，就删除内容或功能。

媒体后方的填充色可能是一种功能提示，而非装饰。图片下方的纯色面板通常是图片加载时用于预留空间的占位区域；移除它会让每张尚未加载的图片都变成一块白洞，下方还孤零零地留着说明文字。清除媒体后方的背景前，先检查未加载状态。

装饰所占用的空间不会随着装饰消失而消失。围绕插图设置的横幅，或为避开装饰而偏移的网格，都会留下空洞，给人空荡而非宁静的感觉；即使在较小的尺度上也是如此，比如某个控件仍为空出的图标预留方框。应有意收拢释放出来的空间。

如果某个装饰元素同时是控件唯一可见的输出——例如选择器会改变渐变，按钮会重播动画——降低其视觉强度并不等于删除它。应降低其饱和度，让控件仍能表达作用，并确认不同状态之间仍可区分。

如果装饰会因项目而异，应将其统一处理，而不是降低饱和度。每个色块后方的不同色调变成不同灰色后，仍会让人以为它们编码了某种信息，而实际上并没有；统一的纯色表面表达的才是原本的意思：它并未传达任何信息。

接着检查容器是否仍有存在的价值。统一处理各项目的颜色，会让色彩各异的网格变成一面由相同方框组成的墙——这种统一性是调整过程中人为制造的，并非页面原有，而原本承载多样性的填充色如今也失去了作用。通常应移除它，让字体层级和间距来实现分组。

覆盖在媒体上的有色渐变通常承担两项作用。移除色调的同时，也会移除确保上方文字清晰可读的遮罩，因此应保留中性色遮罩，只去掉颜色。

对于电商和产品详情页面：

• 让产品媒体成为主要的视觉焦点。
• 在桌面端，如果阅读方向适合，默认采用左侧大画廊、右侧紧凑的产品与购买信息栏布局。
• 将产品名称、价格、选项、供货情况和主要购买操作放在一起。特别留意是否存在打断：促销区块、规划工具链接或服务模块插在价格和配送查询之间，造成的购买流程割裂，效果与将它们分散到不同章节一样明显，而且更常见。名称、价格、选项、供货情况或购买操作之外的内容，都不应插在它们之间。
• 并非每种产品都有规格选项控件。如果没有色板或尺码，选项区域就由尺寸、系列和目录链接填充；这些内容应属于购买区块，而不是周围的页面内容。
• 媒体的主导地位既体现在垂直方向，也体现在水平方向。购买信息栏的高度若是画廊的两倍，通常说明购买操作下方堆积了服务、会员忠诚度、融资和保障模块；应降低这些内容的视觉权重，而不是加宽信息栏。
• 购买操作不可用时，禁用控件应保留在原位，并以清晰易读的对比度说明原因——无法购买的原因绝不能成为页面上最难辨认的文字。可用的替代操作，无论是“查找类似商品”“通知我”还是“更改门店”，都可以作为主要操作突出显示，因为这是访客唯一能执行的操作。
• 价格应按基线对齐。电商系统常把货币符号和小数部分设为半尺寸的上标；将整个价格设为统一的字号和字重，通常是页面上影响最大的一项克制处理。
• 不要让主要产品图片被长篇购买前置内容挤到下方，也不要把它缩减为辅助装饰。
• 在移动端，依次展示画廊、产品详情、选项和购买操作。
• 只有当其他布局能明显改善产品评估或任务完成效果时，才偏离此模式。

无法访问源代码的网站

这项技能面向可修改的代码库——标记、样式、组件和设计令牌——以上内容也都以具备这种控制权为前提。优先修改系统，而不是在其上层叠加处理：修改令牌，而不是覆盖其使用方；删除规则，而不是重置规则；当一个组件承担两项工作时，将其拆分。与现有代码冲突的覆盖样式反映的是代码本身的问题，并非解决方案。

如果目标是已发布的网站或无法编辑的第三方网站，请阅读 websites.md，了解受限的 CSS 覆盖方案及其测试框架。请明确说明，此模式的上限较低：布局只能在现有 DOM 允许的范围内调整，而从源代码层面重新设计能实现更多改进。

页面构成与叙事

适用于营销、编辑和产品页面：

• 每个主要篇章都围绕一个清晰的核心展开。一个实用且可重复使用的结构是：简洁的标题、一段简短说明、三到四条功能概述，然后配一张主导视觉的产品图。
• 交替使用白色和极浅的中性色区块填充，例如 rgb(0 0 0 / 4%)，在添加边框或容器之前营造节奏感。深色画布上没有可用的“极浅填充色”，因此可用一条真正明亮的色带作为间隔，或者完全不加。
• 用一张大尺寸截图、照片、视频或实体产品组合，作为篇章的视觉锚点。内容值得沉浸式呈现时，可让它接近全宽。
• 优先使用少量大型篇章容器，而非大量小卡片。大型媒体篇章可以使用克制的圆角；其内部内容不应再变成卡片网格。
• 客户和合作伙伴的标志应采用单色并均匀间隔，让社会认同保持低调。这与产品自身标志使用全彩的做法相对应：第三方标志是佐证，不是身份标识；在大多数页面上，一排采用原生配色的标志是最醒目的色带。支付标志也遵循同样的原则，因为其形状本身就能让人识别。
• 偶尔用大型用户评价、案例研究图片或编辑式拼贴打破页面的整体规律。一次富有表现力的间断，比每个区块都加装饰更能赋予页面个性。
• 不需要卡片时，可用图标、简短动词和一行结果来呈现功能概述。
• 使用双色行内标题——首句采用完整墨色，后续内容在同一字号和基线上以约 60% 的深度呈现——能让营销页面真正形成层次，无需增加第二种字重或字号，而且经过弱化处理后依然有效。
• 在长篇营销页面中，每个篇章设置一个填充式主要操作按钮是惯常做法，并非违规。应将“少量使用”的范围限定为视口，而非整个文档。
• 如果同一区域内，填充式强调色按钮靠近产品自身标志，按钮的视觉优先级就会高于标志，身份识别的效果也会消失。应让按钮采用中性色，使标志成为该区域唯一的色彩。这一原则的前提是标志有颜色可供按钮压过；如果标志本身是黑色，就无需保护其身份识别效果，强调色也可以保留。
• 同样的道理也适用于尺寸，而不只是颜色。如果名称标牌和主视觉标题都以展示级字号高声呈现，名称标牌就会与页面争夺注意力，而不是引领页面。只有将旁边的元素弱化，放大标志才站得住脚；此时标志承担的身份识别作用会比原先更大，因为不再有另一个元素与之并列。
• 页脚可以更紧凑，但应保持相同的字体排版、对齐方式和中性处理。
• 在移动端，应保留每个篇章的顺序和层次。采用堆叠并简化的方式，而不是单纯缩小桌面端的布局。

交互与动效

动效应轻柔、即时且有明确目的。仅在提供反馈、保持空间连续性、指示状态或避免突兀变化时使用。

• 不要为键盘触发或极其频繁的操作添加动画。
• 对用户每天会执行数十次的交互，减少动效。
• 普通 UI 动效应控制在 300ms 以内；仅在少见的说明性场景中使用更长的动效。
• 进入和退出使用 ease-out，已在屏幕上的元素移动时使用 ease-in-out，颜色或悬停过渡使用 ease。避免在响应式 UI 中使用 ease-in。
• 优先使用 transform 和 opacity；存在可合成的替代方案时，避免为布局属性添加动画。
• 绝不要从 scale(0) 开始进入动画。适合使用缩放时，搭配透明度使用细微的 scale(0.95–0.98)。
• 弹出层和菜单应锚定到其触发元素；居中的模态框可以保持居中。
• 如果产品适合提供按压反馈，可使用细微的 scale(0.97)，持续约 100–160ms。
• 让快速触发和由手势驱动的动效可以中断。
• 遵循 prefers-reduced-motion，保留有用的颜色或透明度反馈，同时移除不必要的位移。
• 仅在 (hover: hover) and (pointer: fine) 条件下启用仅悬停时的动效。

不要仅仅为了让静态界面显得精致而添加动画。如有疑问，请移除或减弱动效。

停止持续循环的装饰性动效时，应让其回到静止状态，而不是冻结。仅禁用动画会让元素停留在最后一帧的位置；对于跑马灯或轮播，这会导致内容停在任意偏移处，并被容器边缘裁切；对于淡入效果，则可能完全透明。还应清除动画所控制的变换或透明度，并通过截图确认静止状态符合预期。

升级触发条件

当以下问题出现在范围内时，请予以修正；除非品牌或功能明确要求保留：

• 用带暖色或冷色调的灰色代替中性透明黑色调，包括从设计系统继承的默认边框颜色。若某种中性色基于产品自身的品牌色系统地推导而来，并且使用一致，则属于品牌色，而非需要修正的色调。
• 衬线展示字体或衬线/无衬线混用的字体系统
• 全大写文本或 CSS text-transform: uppercase
• 全小写的导航或控件标签
• 将表情符号用作界面图标
• 用分隔线将元素与其自身的说明文字、标签或元数据分开
• 屏幕上的规则线多到读者数不过来，而留白本可以起到同样作用。规则线在密集查找界面中分隔同级内容时，能够提升信息密度；在将它们视为杂乱之前，先想想可以用什么替代。
• 没有实际含义的装饰性渐变、纹理、光晕或高饱和色彩
• 仅为营造高级质感而使用的大面积或多层阴影
• 权重相同、没有主导元素的统一卡片。大小容器混合排布，且每个容器都展示真实产品媒体内容，这属于便当盒式布局，而非卡片网格；将其扁平化会移除唯一展示产品的地方，只剩下文字描述。
• 将普通矩形控件或容器做成药丸形
• 同类按钮和 CTA 的圆角、尺寸或内边距不一致
• 间距、对齐、圆角、边框不透明度或图标样式不一致
• 字体样式或字重超过层级所需
• 标题或留白过大，导致有效信息密度降低
• 正文或控件对比度过低
• 状态、焦点、警告、错误、成功、选中、激活或危险操作状态中的颜色被移除
• 与语义颜色搭配的形状或字形也被一并移除，导致状态只能靠色相区分。请检查剩余的视觉标记是否仍足以清楚表达状态：如果选中标签的底色变为中性色后，只剩一条细线与相邻标签区分，那么虽然形式上仍有差异，实际提示作用却已丢失。应重新编码状态，而不是仅确认差异仍然存在。
• 因字体或标签规则而连带移除语义颜色。这是颜色丢失的常见原因，并非有意更改调色板：突发新闻标记和普通引导标签通常是同一种元素，使用相同的标记语言，只是读取的令牌不同；因此，一条同时设置 color 的字号和字间距规则，会连同状态颜色一起移除，而你精心保留的令牌却不受影响。
• 缺乏功能目的的动效

修复顺序

优先采用顺序靠前的调整：

1. 修复页面流程、层级、导航、分组，以及控件与内容之间的对应关系。
2. 若当前布局妨碍上述目标，则重构布局。
3. 移除装饰、多余的表面元素和重复标签。
4. 统一间距、对齐和信息密度。
5. 统一字体排印、字号范围、字间距和行高。
6. 将颜色、边框、圆角和层级效果整合为共享令牌。更改任何令牌之前，先找出它的所有使用位置，并检查各处的用途，因为同一个值用来弱化填充色时，却可能让边框变得刺眼：将强调色改为黑色，能让所有使用该颜色的按钮显得更沉稳，却会把柔和的金色细线变成生硬的黑框，改完后反而更醒目。设计系统也会让一个令牌承担多种角色，因此品牌令牌往往会通过别名定义激活状态，而装饰性徽章也可能借用了真实错误状态的颜色。一个令牌承担两种用途，通常正是问题所在——应将其拆分，而不是折中选值。
7. 完善控件、可操作提示、焦点、悬停、按下、禁用、加载、空内容和错误状态。
8. 只有静态层级表现良好后，才添加或调整动效。

工作流

1. 确定调用模式和确切范围。
2. 完成侦查，并确定主要任务及其层级。
3. 根据运行准则评估候选变更。
4. 按修复顺序应用变更，复用并扩展现有系统，而不是另建一套并行系统。
5. 通过机械方式和视觉方式进行验证。
6. 报告变更内容、变更原因，以及有意保留的内容。

验证

浏览器验证

如果存在任何浏览器、预览、截图或计算机使用工具，则必须进行视觉验证：

1. 启动或定位真实应用，并打开确切的变更路由。
2. 分别截取变更前后的固定桌面端和移动端截图。
3. 检查渲染后的截图，而不是依赖代码或 DOM 结构。
4. 测量交互状态，而不是为这些状态拍照。悬停、焦点或按下状态的规则可能会在优先级竞争中落败，根本不会生效；截图无法揭示这一点。因此，应在强制设置状态后读取计算样式，而不要相信自己写下的规则就是最终生效的规则。
5. 在渲染结果中确认元素已移除，而不是只检查声明。并非每条线都是边框：界面也可能通过 box-shadow、::before 或 ::after 条形元素，或收缩到一个像素的元素来绘制线条，因此删除 border 并不能证明线条已消失。应盘点界面实际绘制的内容，而不是源码中提到的内容。
6. 放大检查小控件。在整页视图中，几像素的错位难以察觉，修复后也可能通过整页验证而遗留。
7. 测试主要交互、键盘焦点、悬停或按下状态，以及任何变更后的响应式行为。
8. 单独检查窄视口，而不只是顺手看一眼。为宽列设置的内边距、内缩和边框，在手机屏幕上会占据很大比例；在 1440px 下属于优化的规则，在 390px 下却可能造成回归。
9. 检查浏览器控制台是否有错误，并确认视口没有裁切或水平溢出。
10. 对于较长的页面，应滚动浏览每个章节，并截取整页截图或多个视口片段；只检查首屏是不够的。
11. 修复可见问题并重新截图，直至结果通过验证。

如果没有可用的浏览器工具，请说明无法进行视觉验证。绝不要仅凭代码检查就声称设计已经过视觉验证。

此列表中有四项检查很难通过肉眼完成，已与本文件一起编写成 scripts/ 中的脚本。每个脚本都接受一个 URL（通常是开发服务器上的路由），只需 playwright-core 和本地 Chrome：

• node scripts/lines.js <url> — 列出页面绘制的每条线，包括水平线和垂直线，并注明绘制机制。在任何移除分隔线的检查后运行。
• node scripts/tints.js <url> — 列出通道差异表明其为带色中性色的颜色，以及单色化检查必须处理的饱和色清单。
• node scripts/density.js <url> — 统计每个屏幕上可见的项目数量，以便通过测量而非估算来验证密度。
• node scripts/bands.js <url> — 将长页面切分为便于审查的视口高度截图。

请阅读脚本输出，不要以为运行成功就代表页面没有问题：每个脚本只回答一个具体问题，而上文已说明它们在哪些情况下可能产生误导。

请明确指出无法访问的状态，不要暗示已检查整个界面。已访问链接、错误和加载状态，以及需要身份验证的视图，通常无法通过截图工具访问。

如果同一原因导致某项验证步骤反复失败，请将该检查编写成脚本，而不是只提醒自己要更仔细。能让问题显现出来的工具，胜过又一条要求注意观察的指示。

在真实的桌面端和移动端尺寸下，使用真实内容检查结果。请验证：

• 主要任务和下一步操作一目了然。
• 导航能回答用户身处何处、可以前往何处，以及如何离开。
• 分组遵循邻近原则，控件靠近其影响的对象。
• 长篇文案、空状态、加载状态、错误和密集数据不会破坏布局。
• 对比度、键盘导航、可见焦点、触控目标和语义状态均保持无障碍。
• 更大的文字和更窄的屏幕不会破坏层级。
• 不会重复绘制任何内容。看起来符合预期设计，并不能证明是你的规则实现了它；添加规则前，请先检查是否已有声明绘制了相同像素。
• 不会意外赋予内容额外含义。移除颜色可能会显露出原本被饱和色彩掩盖的编码；如果结果比原设计更易读，就应停在这里，而不是继续追求单色化。
• 只有检查过容器、每一层中间包装元素以及文本节点本身，左对齐才算完成。居中会层层叠加；如果三种机制只修正了两种，就会出现区块居中而文本靠左的情况，这比一开始更糟。
• 长页面具有经过设计的章节节奏，不会变成重复堆叠的卡片。
• 结果通过了识别测试：只展示改版后的界面时，一个从未见过原版的设计师会认为这是精心设计的斯堪的纳维亚风格界面，而不是去掉颜色后的原版。
• 原界面的所有交互能力——操作、控件、导航、输入项、切换开关——仍然存在且可访问。盘点功能，不要只盘点内容和链接；弱化控件可以，但不能删除。
• 富有表现力的色彩仅用于有明确目的的媒体，或唯一获准的主强调色。
• 悬停、按下、选中、禁用和危险操作状态仍然可以区分。
• 存在动效的地方，应提供减少动效的行为。
• 控制台无错误，现有检查仍能通过。

如果视觉检查发现存在歧义、过度留白或效率降低，请恢复必要的上下文或信息密度，并再次检查。

护栏

请勿：

• 让危险操作和中性操作在视觉上无法区分。
• 移除理解内容所需的标签或边界。
• 在原本没有主要行动号召的界面中臆造一个。一个主要操作意味着最多一个，而不是必须有一个。
• 为了匹配配色而降低品牌标志的饱和度。
• 在未被要求的情况下替换既有产品标识。
• 仅为缩小代码差异而保留薄弱的布局。
• 在现有组件可以妥善解决问题时添加依赖项。
• 仅为打造更简洁的截图而隐藏高级功能。
• 将新奇误认为精致。

评审输出

评审模式下：

1. 按优先级排列问题。
2. 对每个问题，说明当前状况、建议目标，以及改进产品的原因。
3. 将必要修正与可选润色分开。
4. 添加简短的 保留 部分，指出不应更改的品牌标识、语义颜色、实用边界、信息密度或交互模式。
5. 以结论收尾：整体已协调、需要针对性优化，或需要结构性重设计。

应用模式下，总结影响最大的改动、执行的验证，以及无法通过视觉检查确认的限制。

输出标准

最终效果应显得沉静、实用、精致且刻意保持简洁。如有不确定之处，请让界面更简洁，而非降低可用性。