explain-interface

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Interface explanation

界面解释

This skill answers how something was built.

/explain-interface how the gradient on example.com was built

finds the layers producing that gradient and explains the mechanism, in enough detail to rebuild it.

It explains rather than judges. There is no verdict, because how someone else built their interface is not a finding. Reviewing against a standard is

interface-review

and

better-interface

; exploring alternatives for your own is

variant

该技能用于解答某一内容的构建方式。输入

/explain-interface how the gradient on example.com was built

，它会找到生成该渐变的层级，并详细解释其实现机制，足以支持你重构该效果。

它仅做解释而非评判，不会给出结论，因为他人构建界面的方式并非需要判定的内容。若要对照标准进行评审，可使用

interface-review

和

better-interface

；若要为你自己的方案探索替代选项，可使用

variant

。

Scope to the question

聚焦问题范围

Two questions, both first-class, sharing nothing but the evidence rules:

The question	What you produce	Method
How was this site built?	The frontend: framework and rendering strategy, styling system, component library, tokens, the type, spacing and color systems, motion, breakpoints, how fonts and images are served	read-the-system.md
How was this built?	The layer stack behind one effect, and the smallest code that reproduces it	find-the-effect.md

Given a named thing, scope to it. A type scale and a token dump are not a longer answer to "how is the gradient built", they answer a question nobody asked. Pull in a neighbour only where the effect cannot be explained without it, and say why.

Either question can be asked of a screenshot instead of a URL, which changes the answer in kind. See From a screenshot, it is a reconstruction.

两类核心问题，仅在证据规则上一致：

问题	输出内容	方法
这个网站是如何构建的？	前端相关信息：框架与渲染策略、样式系统、组件库、tokens、排版、间距与色彩系统、动效、断点、字体与图片的加载方式	read-the-system.md
这个元素是如何构建的？	单个效果背后的层级堆栈，以及可复现该效果的最简代码	find-the-effect.md

若指明了具体内容，需聚焦于该内容。排版比例和tokens导出并非「渐变如何构建」问题的延伸答案，它们回答的是无人提出的问题。仅当无法脱离相邻元素解释效果时，才需引入相邻元素，并说明原因。

两类问题均可针对截图而非URL提出，这会从本质上改变答案。详见基于截图的重构部分。

What you can actually read

实际可读取的内容

How you reach the page decides what you may claim. Say which route you used.

	A scriptable browser	Fetched HTML and CSS
Gives you	What actually paints: computed values, paint order, pseudo-elements, live animations	The source: authored declarations, responsive variants, generated utilities, every `:root` token
Blind to	Any width or state you did not visit	Which rule wins, and anything injected at runtime

Neither is a downgrade. A browser at one viewport misses the

md:

variants raw HTML hands over, and raw CSS cannot say which of nine matching rules won. Use both where the question is worth it.

The Chrome DevTools MCP is the easiest browser to get:

bash

claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

It gives you

evaluate_script

for the recipes here,

resize_page

and

take_screenshot

for another width,

list_network_requests

for what is served, and

performance_start_trace

for a stutter. Prefer it over the fetch method when:

The effect is a
```
canvas
```
or a shader.
Styles arrive at runtime, through CSS-in-JS or a theme script.
Several rules match and you need the one that won.
The answer depends on motion.

Without a browser, no-browser.md holds the fetch method.

访问页面的方式决定了你可得出的结论，需说明你使用的方式。

	可脚本化浏览器	获取HTML和CSS
提供信息	实际渲染内容：计算后的值、渲染顺序、伪元素、实时动画	源代码：手写声明、响应式变体、生成的工具类、所有 `:root` 下的tokens
无法获取	未访问过的任何宽度或状态	生效的规则，以及运行时注入的任何内容

两者并无优劣之分。单一视口下的浏览器会遗漏原始HTML提供的

md:

变体，而原始CSS无法判断九条匹配规则中哪一条生效。若问题值得，可结合两种方式使用。

Chrome DevTools MCP是最易获取的浏览器工具：

bash

claude mcp add chrome-devtools -- npx chrome-devtools-mcp@latest

它提供了本文档示例所需的

evaluate_script

、用于切换宽度的

resize_page

和

take_screenshot

、用于查看加载资源的

list_network_requests

，以及用于检测卡顿的

performance_start_trace

。在以下场景中，优先使用该方法而非获取源代码：

效果基于
```
canvas
```
或着色器实现。
样式通过CSS-in-JS或主题脚本在运行时加载。
多条规则匹配，需确定生效规则。
答案依赖于动效。

若无浏览器，可参考no-browser.md中的获取源代码方法。

Measured, derived, inferred

测量、推导、推断

An explanation is only worth reading if you can tell which claims are facts. Every claim carries one of three tiers, stated rather than implied:

Tier	Means	Example
Measured	Read off the page or sampled from pixels. Reproducible.	`filter: blur(50px)` , `--radius: 0.625rem`
Derived	Computed from measurements.	"Four stops, evenly spaced to 100%", "1496px wide in a 1440px viewport"
Inferred	A judgement about intent. Never stated as fact.	"Oversized so no edge lands inside the viewport"

Inventing a plausible value and presenting it as measured is the one failure that makes the whole answer worthless. "Roughly 50px of blur, unmeasured" is useful; a

box-shadow

you made up because it looks right is not.

一份有价值的解释需明确区分哪些结论是事实。每个结论需明确标注以下三个层级之一：

层级	含义	示例
测量	直接从页面读取或从像素采样得出，可复现。	`filter: blur(50px)` 、 `--radius: 0.625rem`
推导	通过测量值计算得出。	"四个渐变断点，均匀分布至100%"、"在1440px视口中宽度为1496px"
推断	对意图的判断，绝不作为事实陈述。	"元素尺寸超出容器，确保边缘不会出现在视口中"

编造看似合理的值并将其作为测量结果呈现，是会导致整个答案失效的唯一错误。「约50px模糊，未测量」是有用信息；而因视觉效果相似就编造

box-shadow

则毫无价值。

From a screenshot, it is a reconstruction

基于截图的重构

Without the page there is no code to read, so the answer changes in kind. You are not explaining how it was built. You are proposing how it could be built to look like that. Say so in the answer, rather than leaving the reader to assume you measured.

Two things stay exact, because they come from the pixels themselves: the colors you sample, and the contrast between any two of them. Everything else is a ratio, since the capture scale is unknown, or an inference from appearance.

Several things are unavailable. The tokens, the framework, the styling system, the breakpoints, the motion, and every state but the captured one. You cannot even be sure the effect is CSS: a gradient may be a flat image, a

canvas

, or a shader.

So where the page is live, ask for the URL. One command replaces the whole estimate. from-an-image.md holds the method for when it is not.

若无页面代码可读取，答案本质会发生改变。你并非在解释它是如何构建的，而是在提出一种可实现该视觉效果的构建方案。需在答案中明确说明这一点，而非让读者误以为你进行了测量。

有两点是完全准确的，因为它们直接来自像素：你采样的颜色，以及任意两种颜色之间的对比度。其余内容均为比例（因截图缩放比例未知）或从外观推断出的结论。

有多项信息无法获取：tokens、框架、样式系统、断点、动效，以及除截图状态外的所有状态。你甚至无法确定效果是否由CSS实现：渐变可能是一张扁平图片、

canvas

或着色器。

因此，若页面可访问，优先请求URL。一条命令即可替代所有估算。若页面不可访问，可参考from-an-image.md中的方法。

Find the layers, not the element

寻找层级，而非元素

Ask what makes a gradient and the answer is almost never one declaration. Modern visual effects are stacks, and the stack is the explanation.

A hero gradient is commonly four things at once:

An element oversized past its container and pushed partly outside it, so no edge is ever visible.
A multi-stop gradient at low alpha, often 4 stops around 20% opacity.
A large filter: blur()
, which is what turns discrete stops into a wash.
Sometimes a layer above carrying backdrop-filter
, frosting whatever shows through.

Report the stack in paint order with the declaration doing the work on each layer. A reader who has the stack can rebuild it. A reader given only the

linear-gradient()

cannot, because the blur and the oversize produce most of what they were looking at.

find-the-effect.md holds the search recipes, including the three things that otherwise cost you the answer: pseudo-element layers, the idle values animation libraries leave behind, and generated stop lists.

询问渐变的实现方式，答案几乎从不只是一条声明。现代视觉效果是层级堆栈，而堆栈本身就是解释。

一个 hero 渐变通常同时包含四个部分：

元素尺寸超出容器，并部分移出容器，确保边缘永远不可见。
低透明度的多断点渐变，通常是4个断点，透明度约20%。
大半径的**
```
filter: blur()
```
**，这是将离散断点转化为渐变效果的关键。
有时上方会有一层带有**
```
backdrop-filter
```
**的元素，对透过的内容进行模糊处理。

需按渲染顺序报告层级堆栈，并标注每层起作用的声明。掌握堆栈信息的读者可以重构效果；而仅拿到

linear-gradient()

的读者无法做到，因为模糊和超出容器的设置才是视觉效果的核心。

find-the-effect.md包含了搜索技巧，包括三种容易导致答案出错的情况：伪元素层级、动画库遗留的闲置值、生成的断点列表。

Rebuild it small

最简重构

Close with the smallest thing that produces the effect. For a targeted question this beats an essay, because it is checkable: paste it, see the effect, done.

Keep it to the layers that matter and drop the product's own tokens, class names, and framework. Then add one line on anything that does not transfer. A licensed typeface, a brand hue, a blur radius tuned to a viewport width you do not have.

Where the effect depends on something you could not read, say so rather than guessing past it. A cross-origin stylesheet, a canvas, or a WebGL shader are all honest stopping points.

From a screenshot the reproduction is a proposal, not a recovery. Label it as one way to get that look, and expect the real implementation to differ.

结尾附上可实现该效果的最简代码。对于针对性问题，这比长篇大论更有用，因为它可验证：粘贴代码即可查看效果，完成验证。

仅保留关键层级，去掉产品自身的tokens、类名和框架。然后添加一行说明无法迁移的内容，如授权字体、品牌色调、针对特定视口宽度调整的模糊半径。

若效果依赖无法读取的内容，需明确说明而非猜测。跨域样式表、canvas或WebGL着色器都是合理的终止点。

基于截图的重构是一种方案，而非还原。需标注为实现该视觉效果的一种方式，并说明实际实现可能有所不同。

Before you finish

完成前检查

Mistake	Fix
A plausible value presented as measured	State the tier, or say it is unmeasured
One declaration reported as the whole effect	Report the layer stack in paint order
Pseudo-elements never checked	Read `::before` and `::after` on every candidate
`filter: blur(0px)` reported as an effect	It is an animation library's idle state; filter it out
Twelve interpolated stops listed verbatim	Name the technique that generated them
The whole system dumped for a question about one thing	Answer what was asked and go deep instead of wide
An explanation with no reproduction	End with the smallest code that produces the effect
Exact `px` values claimed from a screenshot	Only colors and contrast are exact from pixels
A screenshot answer written as though the code was read	Call it a reconstruction and name what could not be known

错误	修正方式
将看似合理的值作为测量结果呈现	明确标注层级，或说明未测量
将一条声明作为整个效果的答案	按渲染顺序报告层级堆栈
未检查伪元素	检查每个候选元素的 `::before` 和 `::after`
将 `filter: blur(0px)` 报告为效果	这是动画库的闲置状态，需过滤掉
逐字列出12个插值断点	说明生成这些断点的技术
针对单个元素的问题，输出整个系统的信息	聚焦问题，深入解答而非宽泛输出
解释内容中未包含重构代码	结尾附上可实现效果的最简代码
从截图中声称精确的 `px` 值	仅颜色和对比度可从像素中精确获取
截图答案的表述如同读取了代码	明确标注为重构，并说明无法确定的内容