interface-design

界面设计

以顶尖设计团队的匠心打造产品界面——Linear、Vercel、Stripe、Apple。它们与泛泛之作的区别不在于天赋，而在于每个决定都经过了深思熟虑，层级一目了然，且上百处细节同时做到位。这项技能能助你做到这一点。

范围

适用于： 仪表板、管理面板、SaaS 应用、工具、设置页面、数据界面。

不适用于： 落地页、营销网站、营销活动、纯品牌设计。此类项目请使用营销／前端设计技能。

这项技能涵盖完整内容：方向、视觉层级、设计系统架构，以及交付生产级 UI 所需的润色和动效要点。

---

问题所在

你会生成泛泛之作。你的训练数据里有成千上万个仪表板，其中的模式根深蒂固。你可以完整走完流程——探索领域、确定特色、明确意图——最终仍然产出一个模板：冷硬的结构配上暖色，普通的布局配上亲切的字体。

这是因为意图存在于文字中，而代码生成依赖模式。两者之间的鸿沟正是默认选项占上风的地方。流程有所帮助，却无法保证匠心。你必须及时察觉问题，也必须知道那些默认选项不会采用的具体做法。

标准： 如果另一个 AI 根据类似的提示词会产出大致相同的结果，那你就失败了。不是为了不同而不同，而是因为这个界面源自这个用户、这个任务、这个世界。照搬默认选项进行设计，一切都会显得千篇一律，因为大家用的是同一套默认选项。

---

默认选项藏身之处

默认选项常伪装成基础设施——那些看起来只要能用就好、无需设计的部分。

• 排版看起来像容器。 但字体不是承载设计的容器，字体本身就是设计。标题的粗细、标签的个性、段落的质感，会在任何人读到文字之前决定产品给人的感受。使用你惯用的字体，意味着你没有在设计。
• 导航看起来像脚手架。 但导航就是产品——你在哪里、可以去哪里、什么最重要。漂浮在空间中的页面是组件演示，不是软件。
• 数据看起来像展示内容。 但屏幕上的数字不等于设计。它对观看者来说意味着什么？进度环和堆叠标签都能显示“3 / 10”——一个讲述故事，一个填充空间。
• 令牌名称看起来像实现细节。 但 --ink 和 --parchment 会让人联想到一个世界；--gray-700 和 --surface-2 则让人联想到一个模板。只看你的令牌名称，读者就应该能猜出这是哪种产品。

不存在不属于设计的结构性决定。每件事都是设计。一旦你不再追问“为什么这样？”，默认选项就会接管一切。

---

意图优先

在动手编写代码之前，先回答这些问题。除非方向需要用户确认，否则请将其作为简洁的工作简报。

• 这个人是谁？ 不是泛泛的“用户”，而是真实的那个人。他打开这个界面时身处何处？他在 5 分钟前做了什么，5 分钟后又要做什么？早上 7 点喝着咖啡的老师，不是午夜还在调试的开发者，也不是在两场投资人会议间隙的创始人。
• 他们必须完成什么？ 用动词描述。批改这些作业。找出故障部署。批准这笔付款。答案决定什么内容放在前面、什么放在后面、什么需要隐藏。
• 这应该带给他们什么感受？ 用有实际含义的词来描述。“简洁现代”毫无意义——每个 AI 都会这么说。像笔记本一样温暖？像终端一样冷峻？像交易大厅一样密集？像阅读应用一样平静？这会影响颜色、字体、间距、信息密度——方方面面。

如果提示过于模糊，以至于无法判断这个人、任务和感受，就提出一个简洁的问题。如果上下文足以支持负责任的假设，就简要说明并继续。

意图必须贯穿整个系统。 口头上说“温暖”，实际却使用冷色，这就不算贯彻意图。如果意图是温暖的，那么表面、文本、边框、强调色、语义色和字体都应当温暖。如果意图是密集的，那么间距、字号和信息架构都应当密集。检查每个设计令牌是否符合既定意图。对于每个选择——布局、色温、字体、间距比例、层级——你都必须能说出为什么。“大家都这么做”或“能用”意味着你只是采用了默认选项。

---

探索产品领域

默认做法往往会在这里露馅——或者不会。泛泛的路径：任务类型 → 视觉模板 → 主题。精心设计的路径：任务类型 → 产品领域 → 标志性特征 → 结构 + 表达。两者的区别在于，开始任何视觉构思之前，是否花时间深入了解产品所处的世界。

提出任何方向之前，先完成以下四项：

• 领域——来自产品世界的概念、隐喻和词汇。不是功能，而是领域本身。至少列出 5 项。
• 色彩世界——这里自然存在哪些颜色？不要只说“暖色”或“冷色”，要深入真实的世界。如果这个产品是一个实体空间，你会看到什么？至少列出 5 种。
• 标志性特征——一个只有这个产品才可能拥有的元素（视觉、结构或交互皆可）。如果想不出，就继续探索。
• 默认选项——为这种界面类型列出 3 个显而易见的选择，既包括视觉设计，也包括结构。你无法避开自己尚未点明的模式。

检验方法： 去掉产品名称后，读一遍你的方案。别人还能判断这是做什么的吗？如果不能，就继续深入探索。

能渲染时就渲染

如果会话中有可内联渲染视觉内容的工具（例如能在对话中内联渲染 HTML 或 SVG 的 show_widget / visualize 工具），优先展示设计，而不是描述它。困在文字里的设计方向，实用性远不如能让人亲眼看到的设计。此原则有条件：如果没有这类工具（例如在 CI、无头 Agent 或纯终端中），就退而使用代码、设计令牌和书面方案。切勿假定工具存在；先检查，再使用。

在三个时机进行渲染：

1. 提出设计方向时。 除了 Suggest + Ask 区块，还要渲染一个小型实时样例：展示实际的调色板色块、真实字体的字号阶梯、层叠卡片呈现的表面层级，以及作为真实组件的标志性元素。让人亲眼看到“像一本温暖的笔记本”，而不是只读到这句话。
2. 设计组件时。 渲染实际组件（或紧凑的前后对比图，将两个版本并排展示），让间距、边框、层级和状态等设计细节清晰可见，而不是仅仅口头说明。在必要时渲染真实状态（默认、悬停、空状态、错误）。
3. 评审或审查时。 将当前版本和改进版本一并渲染，直接展示差异，而不是只用文字描述。

渲染规则：

• 小组件只展示视觉内容。所有推理、领域探索、排除的默认方案清单和建议都留在回复文本中，切勿将说明文字贴进小组件。
• 遵循渲染工具自身的设计系统规范（如果有 read_me/指南，就先加载）。使用其主题变量，让样例适配浅色/深色模式，并自然融入宿主界面。不要与宿主界面争抢风格。
• 样例仍须通过下述检查。渲染出来的默认设计依然是默认设计；渲染能让设计细节显现出来，但不能取而代之。
• 渲染结果出现在对话中，而非项目里。实际实现仍须通过常规编辑落入代码库。

目标是缩短“这是我的想法”和“它看起来是这样的”之间的反馈循环，让对方能在一条消息中直接回应。

---

视觉层级与构图

“看起来经过设计”与“看起来像生成的”之间，最大的区别就在于此。默认设计会显得扁平——所有内容的尺寸、字重和间距都一样，没有视觉引导，视线也无处落脚。精心设计则能形成层级——一眼就能看出什么最重要。这些都是具体的设计手法，不是凭感觉行事。

每个视图只设一个视觉焦点

每个屏幕都应有一个用户打开它要完成的任务。这个任务要通过尺寸、对比度、位置或周围的留白，成为屏幕的主角。当所有元素都在争抢注意力时，就没有赢家，界面看起来像个停车场。开始构建前，先明确说出视觉焦点是什么。然后让它脱颖而出：放大、提高对比度，或用留白环绕。刻意弱化其他所有内容。

字号比例有章可循，字重比字号更重要

不要凭感觉选字号。先确定一个比例，再按比例递进：~1.2（小三度）适用于密集、平静的 UI，~1.25 适用于大多数产品 UI，~1.333 适用于表现力更强的界面。从 14–16px 的正文开始，这样得到的字号层级会有明显区分，而不是 15/16/17 那种模糊差异。以 14px 为基准、比例为 1.25：caption 11 · body 14 · h4 16 · h3 18 · h2 22 · h1 28 · display 44+。取整到整数像素，并与间距网格对齐。

Apple/Linear 的做法：字重和颜色比字号更能构建层级。 单一的 14px 字号，只用字重和不透明度就能呈现三个层级——value: 600 / primary、label: 500 / secondary、meta: 400 / muted——比两个相差 2pt 的常规字重区分得更清楚。综合运用三个杠杆（字号、字重、颜色/不透明度），不要只依赖字号。如果眯起眼睛后仍分不清标题、正文和标签，说明层级不够鲜明。

示例——同一项指标，平淡版与有主次版。平淡版： Revenue / $48,200 都是 14px 常规灰色，三个相同的框，没有视觉焦点。有主次版： REVENUE 11px/500/次要色/加宽字距 · $48,200 28px/600/主要色/等宽数字（视觉焦点）· ↑12% 12px/500/成功色。同一组数据，易读性却截然不同——数字通过字号、字重和一种强调色引领视线，标签弱化处理，次要指标则降到更低一级。

密度是一种选择，以 px 表达

Linear 紧凑，Stripe 宽松。两者都不是默认选项——它们都是刻意选择的结果，而且这种选择会通过同一个数值反复体现。提前确定密度并明确数值：工具面板采用 12–16px 内边距，会显得紧凑务实；同一张卡片采用 24px，则会显得像宣传册。同一个数值在一种场景中恰到好处，在另一种场景中却可能显得敷衍。审慎选择，然后始终如一地坚持。

空间节奏——疏密相间

出色的界面不会让所有元素间距相同。密集的控件区与开阔的内容区交替；厚重元素与轻盈元素相互平衡；视线有目的地移动。单调的布局——卡片大小相同、间距相同、各处密度相同——说明没有人做出设计决策。刻意变化节奏：紧密排列密切相关的元素，再在各组之间留出充足空间。

比例会传递信息

在全宽内容旁放一个 280px 的侧边栏，传达的是“导航服务于内容”；360px 的侧边栏则表示“两者地位相当”。具体数值会说明什么更重要。如果你说不清某种比例传达了什么，它就什么也没传达。选择能体现关系的宽度和比例。

分布与克制（“昂贵感”）

• ~60/30/10：以中性主色面为主，辅以次要色调，再用约 10% 的强调色。颜色是稀缺资源——屏幕的大部分应由结构构成。
• 一种经过审慎运用的强调色，胜过五种随意使用的颜色。灰色构建结构；颜色负责传达信息（状态、操作、身份）。毫无缘由的颜色只会制造噪声。
• 通过空间和字重建立层级，而不是依赖线条。 优先利用留白和色调变化，再考虑边框和分隔线。最有质感的界面，大多采用隐性的结构。
• 大字号的视觉调整：字号越大，字距越紧（标题的字距略微收紧）；正文则放宽行高以提升可读性（~1.5）。紧凑的字距显得精心打磨；32px 标题沿用默认字距，则像文档。

---

设计工艺基础

微妙的层次感（设计骨干）

无论采用何种方向，这一点都适用于所有内容。你应该 几乎察觉不到系统正在运作 —— 看到 Vercel 的仪表板时，你不会想“边框真不错”，而是自然而然地理解其结构。看不见的匠心，才是真正发挥作用的匠心。

表面层级。 表面层层叠加：下拉菜单位于卡片之上，卡片位于页面之上。建立一套编号系统——从基础层开始，逐级递增。每次跳变的亮度只需相差几个百分点——例如，深色模式下基础层 → +7% → +9% → +12%；浅色模式则保持明亮，改用阴影。单独看每一级几乎难以察觉，但层层叠加后，层次关系便会显现。细微的变化，感受得到却不显眼。

• 侧边栏： 与画布背景相同，而不是采用不同颜色。不同颜色会把空间割裂成“侧边栏世界”和“内容世界”。一道细微的边框就足够了。
• 下拉菜单/弹出层： 比其父级表面高一个层级，否则它们会融为一体，层次关系也会消失。
• 输入框： 比周围环境稍微 暗一些，而不是更亮。输入框是内凹的——用于接收内容。较暗的填充色能在不依赖粗重边框的情况下传达“在此输入”。

边框。 不刻意寻找时应该看不见，但需要结构时又能找到。低不透明度的 rgba 能与背景融合，在定义边缘的同时不引人注意；相比之下，纯色 hex 边框显得生硬。深色模式下，数值通常在 rgba(255,255,255,0.06–0.12) 左右；浅色模式下则略高一些。建立一套递进层级——标准、弱分隔、强调、焦点环——并根据边界的重要性调整强度。

眯眼测试： 对着界面眯起眼睛。你仍应该能感知到层次关系——哪些元素位于上层、区块在哪里分隔——但没有任何内容应该跳出来。没有刺眼的线条，也没有突兀的变化，只有安静的结构。这一点做错了，其他一切都无关紧要。

无限表达

每种模式都有无限种表达方式——没有两个界面应该看起来一样。 指标可以呈现为醒目的大数字、行内统计、迷你折线图、仪表盘、进度条、对比变化值或趋势徽章。每次都使用相同的侧边栏宽度、相同的卡片网格、相同的“左侧图标、大号数字、小号标签”指标卡，会立刻显得像 AI 生成的内容，而且令人难忘。Linear 的卡片不像 Notion 的；Vercel 的指标也不像 Stripe 的。概念相同，表达方式却无限多样。动手构建前，先问问自己：用户在这里做的 ONE 件事是什么？哪个产品把类似问题解决得出色？

色彩自有归属

每个产品都存在于一个世界中，而那个世界有自己的色彩。在选择调色板之前，先走进这个空间的实体场景——那里有什么材质、光线和物件？你的调色板应该让人觉得它来自某个地方，而不是被套用到某个东西上。色温只是一个维度；还要考虑安静还是鲜明、紧凑还是宽敞、严肃还是活泼、几何还是自然。有交易终端，也有冥想应用，两者都“专注”——但专注的类型截然不同。

---

编写每个组件之前

每次编写 UI 代码时——即使只是小幅增补——都要说明：

Intent:     [who is this human, what must they do, how should it feel]
Hierarchy:  [the focal element, and how it wins — size / weight / contrast / space]
Palette:    [colors from your exploration — and WHY they fit this world]
Depth:      [borders / subtle shadows / layered — and WHY it fits the intent]
Surfaces:   [your elevation scale — and WHY this temperature]
Typography: [typeface + the size/weight/color levers — and WHY]
Spacing:    [base unit + chosen density]

此检查点为强制要求。如果你无法解释每一项的原因，说明你只是在默认行事——停下来想一想。

---

善用已有内容

AI 让代码库质量下降，最常见的原因就是重复手写已有内容。在项目自带的 Button 旁边，用一个自制的 <div onClick> 充当“按钮”；在已安装、支持键盘操作的基础组件旁边，从零构建一个不支持键盘操作的下拉菜单；每张卡片上都复制粘贴 14 个 Tailwind 类，而不是使用现成的组件或设计令牌。这些问题本质上都是同一种失误——生成新内容，而不是利用已有内容——结果就是不一致、不可访问且难以维护。在构建控件或为元素添加样式之前，先看看项目已经提供了什么。

控件：原生 → 基元 → 手写实现

1. 能用原生 HTML 时优先使用。 <button> 就是按钮；<a> 就是链接；还有 <input type="text">、<dialog>、<details>。平台已有现成实现时，绝不要用 <div onClick> 来代替——否则就白白失去焦点、键盘和语义支持。
2. 对于有状态且难以正确实现的控件，使用经过实战检验的无头基元，例如选择框、组合框、对话框、弹出框、工具提示、下拉菜单、标签页、日期选择器。这些控件自带键盘导航、焦点管理、ARIA 以及碰撞检测和定位功能，若要正确复刻，可能需要数天。优先选用生态系统已有信赖的方案（例如 React 中的 Radix UI、React Aria、Ark、Headless UI、Vaul、cmdk；其他框架中则选用相应的无障碍基元），然后按你的设计方向为其设置样式。“自定义构建”指的是组合并设置基元的样式，而不是从头编写行为。
3. 只有在确实别无选择时才手写实现——没有合适的基元，或依赖预算有限。这时，你就必须完整实现行为契约：键盘导航（方向键、Enter、Escape）、焦点陷阱／焦点返回、完整的 ARIA 角色和状态、点击外部区域关闭，以及覆盖层的滚动锁定。缺少这些功能的样式化控件就是有问题的，无论它看起来多好。

样式：系统 → 组件 → 令牌 → 工具类

1. 如果项目有设计系统，就使用它。 shadcn/Button、CVA 变体集、主题、组件库——先使用 <Button variant="…"> 和已有变体，而不是另写一次性实现。遵循代码库的样式约定（Tailwind、CSS modules、CSS-in-JS），不要另起一套。
2. 样式化元素重复出现时，就提取为组件。 同一串工具类用在九个按钮上是重复，而不是设计。由一个组件（或一个 CVA／变体）统一管理；调用处保持简洁。第二次真正复用时就提取，而不是等到第一次。
3. 绑定语义令牌，不要硬编码字面值。 使用 bg-card border-border text-muted-foreground，而不是 bg-white border-gray-200 text-gray-500。硬编码的 gray-200／#fff／px-4 原始值，是 Tailwind 形式的随意十六进制值——它们会破坏主题和深色模式，也表明没有设计系统。（参见下文的令牌架构。）
4. 内联工具类只用于真正的一次性场景——例如只用一次的布局微调。代码粗糙的标志，是同一长串 className 到处出现；这说明缺少的是组件或令牌，而不是样式。

设计系统要点

支撑每项设计决策的令牌、间距和层次架构。

• 令牌架构。 每种颜色都能追溯到一小组基础令牌：前景（文本）、背景（表面）、边框、品牌、语义（破坏性操作／警告／成功）。不使用随意的十六进制值——所有颜色都映射到基础令牌。
• 文本层级——四个级别。 主要、次要、三级、弱化（默认／辅助／元数据／禁用）。只用两个级别会让层级过于扁平。
• 间距。 选择一个基础单位（4 或 8px），只使用它的倍数。根据场景调整比例：微间距（图标间隙）、组件间距（按钮／卡片内部）、区块间距（组与组之间）、大间距（区域之间）。随意使用数值会让人感觉缺乏系统性。
• 内边距。 保持对称——如果一侧有数值，其他侧也应相同，除非内容确实需要不对称。
• 层次——选定一种并贯彻始终。 仅使用边框（简洁、专业、适用于密集型工具）· 轻微阴影（亲和）· 多层阴影（高级、有立体感）· 表面颜色变化（色调，不用阴影）。不要混用策略。
• 圆角——建立比例。 输入框／按钮使用小圆角，卡片使用中圆角，模态框使用大圆角。不要随意混用尖锐和柔和的圆角。
• 控件令牌。 输入框／选择框／复选框应有专用的背景、边框和聚焦令牌——不要复用表面令牌，这样才能独立调整控件。原生 <select>/<input type="date"> 无法设置样式——应组合无头基础组件，而非手动实现（参见“使用现有资源”）。
• 深色模式。 深色背景下阴影效果较弱——应更多依靠边框。略微降低语义颜色的饱和度。使用相同的层级系统，但反转明暗值。保持色相不变；只调整不同表面上的亮度。

---

润色与动效要点

上百个细节累积起来，就会让界面“感觉很棒”。以下是最具影响力的做法——足以打造真正精致的 UI。

静态润色

• 同心圆角。 嵌套的圆角元素应满足：outerRadius = innerRadius + padding。父元素与子元素使用相同圆角，是最常见的界面观感不协调问题。
• 等宽数字。 任何动态数字（计数器、价格、计时器、表格列）都应设置 font-variant-numeric: tabular-nums，以防布局偏移。
• 视觉对齐。 几何居中看起来不对时，应按视觉效果调整——图标侧内边距约为文本侧内边距减 2px；将播放三角形向右微调约 2px。
• 状态不可或缺。 每个交互元素都需要默认、悬停、激活、聚焦、禁用状态。数据需要加载、空、错误状态。缺少状态会让界面感觉失灵——这是判断界面尚未完成最快的方法。
• 点击区域——44×44px（WCAG），至少 40。 如果可见控件更小（例如 20px 的复选框），就用伪元素扩展点击区域。绝不要让两个点击区域重叠。
• 用阴影表现高度，而非边框。 对于凸起的卡片／按钮／容器，优先使用分层的透明 box-shadow（能适配任何背景）；将真实边框用于分隔线和输入框轮廓。浅色模式下的凸起效果由三层叠加构成——1px 环线加两层柔和阴影，例如 0 0 0 1px rgba(0,0,0,.06), 0 1px 2px -1px rgba(0,0,0,.06), 0 2px 4px rgba(0,0,0,.04)；深色模式则简化为单层环线 0 0 0 1px rgba(255,255,255,.08)（深色背景下深度阴影不明显）。
• 文本换行。 在标题上使用 text-wrap: balance；在正文／说明文字上使用 text-wrap: pretty，避免出现孤行。
• 字体平滑。 在根元素上设置 -webkit-font-smoothing: antialiased（否则 macOS 上的渲染会显得过粗）。
• 图像轮廓。 使用 1px 内描边，浅色模式为纯 rgba(0,0,0,0.1)／深色模式为 rgba(255,255,255,0.1)——不要使用带色调的近黑色／近白色（边缘看起来会很脏）。

动效

动效应该让人感受到，而不是被人注视。快速、有目的，绝不妨碍操作。

• 是否应该添加动效？ 每天重复 100 次以上的操作（键盘快捷键、命令面板）不添加动效——这会让操作显得迟缓。偶尔使用的界面（模态框、抽屉、提示消息）使用标准动效。罕见或首次运行的时刻可以增添惊喜。
• 界面动效时长 < 300ms。按钮按下为 100–160ms；工具提示/弹出层为 125–200ms；下拉菜单为 150–250ms；模态框/抽屉为 200–500ms。180ms 的下拉菜单比 400ms 的感觉更灵敏。
• 使用自定义 ease-out，绝不使用 ease-in。 内置曲线太弱。进入/交互时使用 cubic-bezier(0.23, 1, 0.32, 1)；屏幕内移动时使用 ease-in-out（cubic-bezier(0.77, 0, 0.175, 1)）。ease-in 会延迟第一帧——也就是用户正在注视的时刻——让动效显得迟缓。
• 按压反馈。 在 :active 上设置 transform: scale(0.97)（绝不低于 0.95）。以触觉般的反馈确认界面已响应点击。
• 绝不从 scale(0) 开始动效。 任何元素都不应凭空出现——从 scale(0.95) + opacity: 0 开始。
• 弹出层应以触发位置为基准。 弹出层应从其触发元素缩放（将 transform-origin 设为触发元素），而不是从中心缩放。模态框例外——保持居中。
• 只为 transform 和 opacity 添加动效（由 GPU 合成）。为宽度/高度/外边距/内边距添加动效会触发布局和绘制，导致丢帧。绝不使用 transition: all——应明确指定属性。
• 错开元素入场动效，每个元素间隔 30–80ms，形成自然的级联效果；离场动效应比入场更快、更轻微。
• 遵循 prefers-reduced-motion——保留不透明度/颜色过渡，移除位移动效。

---

避免

• 生硬的边框——如果你第一眼看到的是边框，那它就太突出
• 明显的表面跳变——层级变化应低调克制
• 扁平的层级——所有内容大小/字重相同，没有明确的视觉焦点
• 单调的布局——各处的卡片尺寸、间距和密度都相同
• 间距不一致——这是缺乏设计系统最明显的迹象
• 混用不同的纵深策略——选定一种并贯彻到底
• 缺少状态——悬停、焦点、禁用、加载、空状态、错误
• 夸张的投影——应当微妙，而非引人注目
• 小元素使用大圆角；使用粗厚的装饰性边框
• 用渐变和颜色作装饰——颜色应有明确含义
• 使用多种强调色——会分散视觉焦点
• 不同表面使用不同色相——保持同一色相，只调整亮度
• 使用默认排版——已经确定设计方向，却仍使用系统字体/Inter 字体，并仅通过字号建立层级
• 使用结构性变通方案——用负外边距抵消父元素内边距、用 calc() 作为逃生通道，或用绝对定位规避布局流

---

工作流

沟通

保持隐形。不要宣布模式，也不要叙述过程。绝不要说“我正在 ESTABLISH MODE”或“让我检查一下 system.md”。直接开始工作；提出建议时说明理由。

执行规范

将此技能作为工作规范，而不只是建议。编辑 UI 时：

1. 检查现有应用、设计令牌、组件模式，以及 .interface-design/system.md（如果存在）。
2. 在选择布局、颜色、字体、密度和导航之前，先具体探索领域。
3. 对于从零开始的屏幕、大幅重新设计或方向模糊的情况，如果有图像生成工具，可考虑先进行视觉参考探索（否则跳过——它只是辅助，绝不是交付成果）。有四种模式：方向板（编码前探索 2–3 种抽象的氛围／材质／配色方案——不包含真实 UI）、UI 参考图（所选方向的中保真构图）、覆盖绘制（对现有截图进行强化设计）、栅格素材（空状态插画、纹理——绝不用于图标／Logo／图表）。始终拒绝通用 SaaS 风格、难以辨认的文字和不符合领域的配色；提取配色、密度、比例和标志性元素，然后用真实代码实现并在浏览器中验证。
4. 修改实现，然后在可用时运行相关的构建、类型检查和测试。
5. 对于重要的 UI，进行视觉验证。使用内嵌渲染工具、本地浏览器或桌面和移动宽度的截图；在展示前修复重叠、间距异常、空白状态、难以辨认的文字、缺失素材和通用构图等问题。
6. 面向用户的进度更新应简短。不要透露冗长的内部设计思路——只需说明有用的建议或决定。

提出建议并询问

先探索并给出建议，然后确认：

Domain:     [5+ concepts from the product's world]
Color world:[5+ colors that exist in this domain]
Signature:  [one element unique to this product]
Rejecting:  [default 1] → [alternative], [default 2] → [alternative], [default 3] → [alternative]
Direction:  [approach connecting to the above]

接着询问：“这个方向合适吗？”如果有内嵌渲染工具，请在同一条消息中渲染该方向的实时示例——展示配色、字体和标志性元素，不要只说出名称。

构建流程

• **如果存在 .interface-design/system.md：**读取并遵循其中的内容——相关决策已经确定。
• **如果不存在：**探索领域（输出全部四项）→ 提出方案（参考全部四项）→ 如果方向不明确或更改成本高，则先确认 → 构建 → 运行以下检查 → 提议保存。

检查项（展示前）

针对你的输出运行这些检查；如果有任何一项未通过，请迭代后再展示。

• 替换测试 — 将字体替换为常见字体，将布局替换为标准模板：是否会让人觉得有所不同？替换后毫无差别的地方，就是你使用默认方案的地方。
• 眯眼测试 — 眯起眼睛看：层次仍然清晰吗？有没有什么元素特别刺眼？
• 标志性测试 — 指出五个体现设计风格的具体元素。“整体感觉”不算。
• 令牌测试 — 大声读出 CSS 变量：它们符合该产品的特性，还是适用于任何项目？

---

完成任务后

始终主动提出保存：“要我保存这些模式，供之后的会话使用吗？”如果用户同意，将内容写入 .interface-design/system.md：

• 设计方向和氛围
• 层次策略（边框／阴影／分层）和间距基准单位
• 层级决策（字体比例、密度值、焦点模式）
• 关键组件模式——当某个组件重复使用 2 次以上、可复用，或包含值得记录的尺寸时，添加该组件（不要记录一次性组件或属性变体）。记录具体值，例如 Button primary — 36px h · 12px 16px pad · 6px radius · 14px/500。
• 视觉方向说明，以及图像探索过程中影响设计的参考资料

一致性检查。 如果 system.md 定义了相关值，就应遵循：间距符合网格、始终采用已声明的层次策略、颜色来自调色板、复用已记录的模式而不是重新设计。这些积累会产生复利——每保存一次，未来的工作就会更快、更一致。

---

命令

• /interface-design:design-review — 严格审查构建成果的工艺与层级，并设置审批门槛；条件允许时渲染前后对比
• /interface-design:design-deslop — 快速检查差异范围，清除分支中的视觉杂乱

如果用户用自然语言询问设计状态、审计或模式提取：读取 .interface-design/system.md 并进行总结，检查 UI 文件是否偏离其中的规范，或扫描重复出现的间距、圆角、颜色和组件值，并提出一份 system.md — 直接执行等效操作。