design-distinctive-ui

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Distinctive UI

设计独特 UI

Create interfaces with a brief-specific point of view, sound interaction design, and production verification. Treat anti-slop as a reasoning discipline, not as a fixed visual style.

围绕具体需求简报构建界面，使其具备鲜明的设计观点、合理的交互设计和生产级验证。将反模板化视为一种推理纪律，而非固定的视觉风格。

Select the mode

选择模式

Build (default): create a new page, surface, or application.
Component: create or refine one component and all states applicable to its behavior.
Audit: inspect and report; do not edit unless the user also requests fixes.
Redesign: change visual structure while preserving agreed product boundaries.
Study: extract transferable design DNA from a screenshot or public URL; never pixel-clone.
Polish: improve an existing artifact with a few decisive, verified changes.

Read references/audit-redesign-study.md for Audit, Redesign, Study, or Polish. Use the workflow below for Build and Component.

Build（构建）（默认）：创建新页面、界面或应用。
Component（组件）：创建或改进单个组件，以及其行为涉及的所有适用状态。
Audit（审计）：检查并报告问题；除非用户同时要求修复，否则不进行编辑。
Redesign（重新设计）：在遵循既定产品边界的前提下改变视觉结构。
Study（研究）：从截图或公开 URL 中提取可迁移的设计 DNA；绝不进行像素级克隆。
Polish（打磨）：通过少量明确且经过验证的改动改进现有成果。

对于 Audit、Redesign、Study 或 Polish，请阅读 references/audit-redesign-study.md。Build 和 Component 请使用下方工作流。

Non-negotiables

不可妥协的原则

Inspect before inventing. Read the repository instructions recognized by the active host, including
```
AGENTS.md
```
,
```
CLAUDE.md
```
, or an equivalent file when present. Inspect existing design tokens, fonts, routes, components, dependencies, content, and real verification commands before editing.
Respect the project. Preserve routes, component ownership, analytics hooks, field names, SEO, brand assets, and working behavior unless the user requested changes to them. Never delete or replace broad areas implicitly.
Follow the active package policy. Detect the repository's real package manager and obey its instructions. When the WERIXO
```
/Users/rootml
```
policy applies, use pnpm only: never npm, npx, or yarn, and use
```
pnpm dlx
```
for ephemeral binaries.
Do not fabricate proof. Never invent metrics, testimonials, customers, awards, specifications, or product capabilities. Use supplied facts, clearly marked placeholders, or a structure that does not require proof.
Accessibility is a floor. Target WCAG 2.2 AA, semantic HTML, keyboard operation, visible unobscured focus, adequate target size, reduced motion, reflow, and contrast. Read references/accessibility-and-quality.md.
Use applicable states. Every interactive element needs the states its behavior can actually enter. Never invent error/loading/success states for a static link; never omit them from an asynchronous control that needs them.
Lock the system, not the imagination. Once visual tokens are chosen, consume semantic tokens consistently. Do not force a new token file when the project already has a sound system.
Verify the rendered result. Static code review cannot judge rhythm, overlap, clipping, or responsive behavior. Render and inspect when tools allow.
Never turn anti-slop rules into a new template. A centered hero, serif, gradient, cards, or illustration may be correct when the brief earns it. Flag combinations without rationale, not isolated ingredients.
Stay host-neutral. Use capabilities by purpose, not vendor-specific tool names. Resolve relative resources from the directory containing this
```
SKILL.md
```
. Read references/platform-compatibility.md when installing, distributing, or troubleshooting this skill.

先检查，再创新。 编辑前，阅读当前宿主环境所识别的仓库说明，包括存在时的
```
AGENTS.md
```
、
```
CLAUDE.md
```
或同等文件。检查现有的设计 token、字体、路由、组件、依赖、内容以及实际可用的验证命令。
尊重项目。 除非用户明确要求修改，否则保留路由、组件归属、analytics hooks、字段名、SEO、品牌资产和正常工作的行为。绝不在未经明确指示的情况下删除或替换大范围内容。
遵循当前软件包策略。 识别仓库实际使用的软件包管理器，并遵守相关说明。当 WERIXO
```
/Users/rootml
```
策略适用时，只使用 pnpm：不得使用 npm、npx 或 yarn；临时二进制工具应使用
```
pnpm dlx
```
。
不得伪造证据。 绝不虚构指标、评价、客户、奖项、规格或产品能力。使用用户提供的事实、明确标记的占位内容，或不依赖证明材料的结构。
无障碍是最低标准。 以 WCAG 2.2 AA 为目标，确保语义化 HTML、键盘可操作、焦点清晰可见且不被遮挡、目标尺寸充足、支持减少动态效果、可重排并具有足够对比度。阅读 references/accessibility-and-quality.md。
使用适用的状态。 每个交互元素都需要覆盖其行为实际可能进入的状态。绝不为静态链接虚构错误、加载或成功状态，也不得为需要这些状态的异步控件遗漏它们。
锁定系统，而非想象。 一旦选定视觉 token，就应持续一致地使用语义化 token。当项目已经具备合理的设计系统时，不要强行引入新的 token 文件。
验证渲染结果。 仅靠静态代码审查无法判断视觉节奏、重叠、裁切或响应式行为。在工具允许时，应渲染并检查实际效果。
绝不要把反模板化规则变成另一套模板。 居中的 hero、衬线字体、渐变、卡片或插画，在需求确有需要时都可能是正确选择。应质疑缺乏设计理由的组合，而不是孤立否定某个元素。
保持宿主中立。 根据目的使用能力，而不是依赖特定厂商的工具名称。相对资源应以当前
```
SKILL.md
```
所在目录为基准进行解析。安装、分发或排查此 skill 时，请阅读 references/platform-compatibility.md。

Build and Component workflow

Build 与 Component 工作流

0. Preflight

0. 预检查

Inspect:

local instructions and real build/test/lint/typecheck commands;
framework, package manager, styling approach, component library, and motion stack;
existing tokens, typography, spacing, radii, shadows, icons, imagery, breakpoints, and themes;
routes, page hierarchy, content source, brand assets, analytics-sensitive names, and accessibility patterns;
the current surface at desktop and mobile when it already renders.

State only material findings. Do not create cache, log, token, or design-system files unless they improve the requested project.

检查：

本地说明以及实际可用的构建、测试、lint 和类型检查命令；
框架、软件包管理器、样式方案、组件库和动效技术栈；
现有 token、排版、间距、圆角、阴影、图标、图像、断点和主题；
路由、页面层级、内容来源、品牌资产、对 analytics 名称敏感的内容以及无障碍模式；
如果现有界面可以正常渲染，则检查其桌面端和移动端表现。

仅陈述重要发现。除非确有助于完成所请求的项目，否则不要创建缓存、日志、token 或设计系统文件。

1. Form the design read

1. 形成设计解读

Infer and state:

Surface · audience · primary job · tone · constraints

Ask at most one question only when two plausible answers would materially change the result. Otherwise proceed with explicit assumptions.

Set three contextual dials from 1–10:

Variance: symmetric/conventional → art-directed/unexpected
Motion: static/feedback-only → cinematic/scroll-led
Density: spacious/editorial → operational/cockpit

These are decision aids, not user-facing configuration. Public-sector, regulated, accessibility-critical, and dense product surfaces usually lower variance and motion. Brand, editorial, and experiential work may raise them.

Read references/direction-and-structure.md before choosing the visual direction.

推断并说明：

界面载体 · 受众 · 核心任务 · 语调 · 约束

仅当两个合理解释会实质改变结果时，最多提出一个问题。否则应在明确假设的前提下继续。

设置三个范围为 1–10 的情境调节项：

差异度（Variance）：对称／传统 → 艺术指导／出人意料
动效（Motion）：静态／仅用于反馈 → 电影感／滚动主导
密度（Density）：宽松／编辑感 → 操作型／驾驶舱式

这些数值仅用于辅助决策，不作为面向用户的配置项。公共部门、受监管、无障碍关键型及高密度产品界面通常应降低差异度和动效数值。品牌、编辑类和体验型项目则可以提高这些数值。

选择视觉方向前，请阅读 references/direction-and-structure.md。

2. Commit to one visual thesis

2. 确定统一的视觉主张

Write one sentence describing the interface's material, rhythm, typography, and energy. Then choose:

one structural fingerprint appropriate to the user journey;
one dominant visual idea per section or workspace region;
one type system, one palette logic, one radius logic, one icon family, and one motion language;
one memorable element grounded in the product or brand.

Do not choose a mood by stacking trendy effects. Distinction comes from content hierarchy, proportion, rhythm, and specificity before decoration.

用一句话描述界面的材质、节奏、字体排印和能量感。然后确定：

一个适合用户旅程的结构特征；
每个内容区段或工作区区域一个主导视觉概念；
一套字体系统、一套配色逻辑、一套圆角逻辑、一个图标体系和一整套动效语言；
一个植根于产品或品牌的难忘元素。

不要通过堆叠流行效果来选择某种情绪。差异化应首先来自内容层级、比例、节奏和具体性，而非装饰。

3. Shape content around the task

3. 围绕任务组织内容

Order marketing content by user uncertainty: problem, mechanism, evidence, action.
Start product UI with the working surface, not a marketing hero.
Give every section or region one job.
Use utility copy for operational UI and brand copy for marketing UI.
Remove repetition, vague adjectives, decorative metadata, and proof-shaped filler.
Select imagery only when it carries narrative or product information. Typography-only can be complete; an unmotivated stock image cannot.

按用户的不确定性组织营销内容：问题、机制、证据、行动。
产品 UI 应从工作界面开始，而不是从营销 hero 开始。
每个内容区段或区域只承担一个明确任务。
操作型 UI 使用功能性文案，营销型 UI 使用品牌文案。
删除重复内容、含糊形容词、装饰性元数据以及伪装成证据的填充内容。
仅在图像能够承载叙事或产品信息时使用图像。纯文字排版也可以构成完整方案；没有叙事动机的图库图片则不可以。

4. Establish the design contract

4. 建立设计契约

Prefer existing semantic tokens. If none exist, define the smallest useful contract:

surface, text, muted text, border, accent, accent text, focus, danger, success;
display/body/mono roles only when needed;
spacing, type scale, radius, elevation, motion duration/easing, and z-index layers;
responsive content widths and layout breakpoints.

Use raw values only inside token definitions. Components consume tokens.

For a standalone interactive component, demonstrate all applicable states together in a preview or story when practical.

优先使用现有的语义化 token。如果不存在，则定义最小且实用的契约：

界面表面、文本、次要文本、边框、强调色、强调色文本、焦点、危险、成功；
仅在确有需要时定义 display（展示）、body（正文）、mono（等宽）角色；
间距、字号层级、圆角、层级阴影、动效时长／缓动以及 z-index 层级；
响应式内容宽度和布局断点。

原始值只能出现在 token 定义中。组件必须消费 token。

对于独立交互式组件，在可行的情况下，应在预览或 story 中集中展示所有适用状态。

5. Implement with project-native patterns

5. 使用项目原生模式实现

Match the established framework and component conventions.
Reuse installed packages; verify before importing.
Add a dependency only when it is justified and approved by project policy.
Prefer semantic HTML and native controls.
Keep animation on
```
transform
```
and
```
opacity
```
when possible; provide cleanup and reduced-motion behavior.
Use real content and assets supplied by the user. Clearly label temporary placeholders.
Keep changes scoped. Do not reformat or rewrite unrelated code.

遵循既定的框架和组件规范。
复用已安装的软件包；导入前先进行确认。
仅在新增依赖具有充分依据且得到项目策略批准时添加依赖。
优先使用语义化 HTML 和原生控件。
尽可能将动画限制在
```
transform
```
和
```
opacity
```
上；提供清理逻辑和减少动态效果的行为。
使用用户提供的真实内容和资产。清楚标记临时占位内容。
控制改动范围。不要重新格式化或重写无关代码。

6. Run the quality loop

6. 运行质量循环

Read references/anti-slop-gates.md and references/accessibility-and-quality.md.

Run discovered repository checks.
Locate the directory containing this loaded
```
SKILL.md
```
, then run the bundled static heuristic from that directory:
```
python3 scripts/ui_quality_lint.py --html <file> --css <file> --format text
```
Treat its findings as prompts for inspection, not proof of design quality or WCAG conformance.
Render and inspect at the reference widths appropriate to the product. Include 320, 375, 414, 768, and 1280 px for public web pages unless scope says otherwise.
Test keyboard flow, focus, hover/touch parity, long content, empty/error/loading states, zoom/reflow, reduced motion, and both themes when both are supported.
Re-read all visible copy and verify every claim.
Fix failures and rerun the relevant checks.

阅读 references/anti-slop-gates.md 和 references/accessibility-and-quality.md。

运行检查仓库时发现的实际检查命令。
找到当前已加载
```
SKILL.md
```
所在目录，然后从该目录运行内置静态启发式检查：
```
python3 scripts/ui_quality_lint.py --html <file> --css <file> --format text
```
应将这些结果视为检查提示，而不是设计质量或 WCAG 符合性的证明。
根据产品特性选择适当的参考宽度进行渲染和检查。除非范围另有说明，公共网页应覆盖 320、375、414、768 和 1280 px。
测试键盘流程、焦点、悬停／触控一致性、长内容、空／错误／加载状态、缩放／重排、减少动态效果；如果支持双主题，则两种主题都要测试。
重新阅读所有可见文案，并核实每项声明。
修复失败项，并重新运行相关检查。

7. Self-critique before handoff

7. 交付前进行自我批评

Score 1–5:

Purpose: does the design express why this product or page exists?
Hierarchy: is the primary task obvious within seconds?
Specificity: could this plausibly belong to another brand unchanged?
Coherence: do type, color, spacing, shape, icons, and motion agree?
Restraint: has every visible element earned its place?
Robustness: does it survive real states, content, devices, and input methods?

Any score below 3 requires another pass. Do not add the scores to production code unless the user requests an audit trail.

按 1–5 分评分：

目的（Purpose）：设计是否表达了此产品或页面存在的意义？
层级（Hierarchy）：主要任务能否在几秒内被明确识别？
特异性（Specificity）：设计是否足够独特，不会原封不动地放到另一个品牌下也依然显得合理？
连贯性（Coherence）：字体、颜色、间距、形状、图标和动效是否协调一致？
克制（Restraint）：每个可见元素是否都有存在的理由？
健壮性（Robustness）：设计能否适应真实状态、内容、设备和输入方式？

任何低于 3 分的项目都需要再次迭代。除非用户要求保留审计记录，否则不要将评分加入生产代码。

Output expectations

输出要求

Lead with the result. Report:

the design read and key visual thesis;
important files changed;
verification commands and outcomes;
anything not verified;
remaining placeholders, assumptions, or risks.

For audits, rank findings by user impact and cite file/line or visible region. Separate evidence from taste.

先展示结果，并报告：

设计解读和关键视觉主张；
已修改的重要文件；
验证命令及其结果；
尚未验证的事项；
剩余占位内容、假设或风险。

对于审计，应按对用户的影响排序发现项，并引用文件／行号或可见区域。将客观证据与主观审美判断区分开来。

References

参考资料

references/direction-and-structure.md: direction, dials, structural families, design-system choice, imagery.
references/anti-slop-gates.md: contextual anti-pattern and originality review.
references/accessibility-and-quality.md: WCAG 2.2, responsive, state, performance, and visual QA.
references/audit-redesign-study.md: read-only audit, safe redesign, reference study, and polish workflows.
references/platform-compatibility.md: shared Agent Skills format, discovery paths, invocation, and portability checks for Claude Code, OpenCode, Codex, and Kimi Code.

references/direction-and-structure.md：视觉方向、调节项、结构类型、设计系统选择和图像使用。
references/anti-slop-gates.md：结合情境检查反模式与原创性。
references/accessibility-and-quality.md：WCAG 2.2、响应式、状态、性能和视觉 QA。
references/audit-redesign-study.md：只读审计、安全重新设计、参考研究和打磨工作流。
references/platform-compatibility.md：共享 Agent Skills 格式、发现路径、调用方式，以及 Claude Code、OpenCode、Codex 和 Kimi Code 的可移植性检查。

Provenance

来源说明

This is an original synthesis informed by Hallmark (MIT),

design-taste-frontend

frontend-skill

frontend-design

impeccable-design-polish

, and

design-auditor

. Preserve the useful disciplines without copying their house style or treating any single catalog as the answer.

本文档是原创的综合整理，参考了 Hallmark（MIT）、

design-taste-frontend

、

frontend-skill

、

frontend-design

、

impeccable-design-polish

和

design-auditor

。应保留其中有价值的实践规范，但不要照搬其特定风格，也不要将任何单一技能目录视为标准答案。