design-distinctive-ui

打造独具特色的 UI

打造契合具体需求、交互设计扎实且经过生产验证的界面。将反模板化视为一种推理准则，而非固定的视觉风格。

选择模式

• Build（默认）：创建新页面、新界面或新应用。
• Component：创建或优化一个组件，并涵盖其行为适用的所有状态。
• Audit：检查并报告；除非用户也要求修复，否则不要编辑。
• Redesign：调整视觉结构，同时保留已商定的产品边界。
• Study：从截图或公开 URL 中提炼可迁移的设计特征；绝不进行像素级仿制。
• Polish：通过少量有针对性且经过验证的改动，改进现有成果。

如需执行 Audit、Redesign、Study 或 Polish，请阅读 references/audit-redesign-study.md。如需执行 Build 或 Component，请使用以下工作流。

不可妥协的要求

1. 先检查，再构思。 阅读当前宿主识别的仓库说明，包括存在时的 AGENTS.md、CLAUDE.md 或同类文件。编辑前检查现有设计令牌、字体、路由、组件、依赖项、内容以及实际验证命令。
2. 尊重项目现状。 除非用户要求更改，否则保留路由、组件归属、分析钩子、字段名称、SEO、品牌资源和正常运行的行为。绝不擅自大范围删除或替换内容。
3. 遵循当前的软件包策略。 检测仓库实际使用的软件包管理器并遵守相关说明。当 WERIXO /Users/rootml 策略适用时，只能使用 pnpm：禁止使用 npm、npx 或 yarn；临时二进制文件使用 pnpm dlx。
4. 不得伪造依据。 绝不编造指标、用户评价、客户、奖项、规格或产品功能。使用提供的事实、明确标注的占位内容，或不需要此类证明的结构。
5. 无障碍是底线要求。 以 WCAG 2.2 AA 为目标，使用语义化 HTML，支持键盘操作，确保焦点可见且不被遮挡、目标尺寸适当，并支持减少动态效果、内容重排和足够的对比度。请阅读 references/accessibility-and-quality.md。
6. 应用适用的状态。 每个交互元素都需要具备其行为实际可能进入的状态。静态链接不应凭空添加错误、加载或成功状态；需要这些状态的异步控件则不可遗漏。
7. 固定设计系统，不束缚想象力。 选定视觉令牌后，应统一使用语义令牌。如果项目已有完善的设计系统，不要强行添加新的令牌文件。
8. 验证渲染结果。 仅通过静态代码审查无法判断节奏、重叠、裁切或响应式行为。条件允许时，应渲染并检查。
9. 绝不要把反模板规则变成新模板。 居中主视觉、衬线字体、渐变、卡片或插图，只要符合需求，都可以使用。应指出缺乏依据的组合，而非孤立的设计元素。
10. 保持宿主中立。 根据用途使用能力，而非特定供应商的工具名称。从包含此 SKILL.md 的目录解析相对资源。安装、分发或排查此技能时，请阅读 references/platform-compatibility.md。

Build 和 Component 工作流

0. 预检

检查：

• 本地说明，以及实际的构建、测试、代码检查和类型检查命令；
• 框架、软件包管理器、样式方案、组件库和动态效果技术栈；
• 现有令牌、字体排版、间距、圆角、阴影、图标、图片、断点和主题；
• 路由、页面层级、内容来源、品牌资源、对分析敏感的名称以及无障碍模式；
• 当前界面在桌面端和移动端的渲染效果（如果已有可渲染版本）。

仅说明重要发现。除非有助于改进用户要求的项目，否则不要创建缓存、日志、令牌或设计系统文件。

1. 形成设计判断

推断并说明：

界面 · 受众 · 核心任务 · 语气 · 约束

只有当两个合理答案会显著改变结果时，才最多提出一个问题。否则，明确假设后继续。

将三个情境维度设为 1–10：

• 变化度：对称／常规 → 艺术指导／出其不意
• 动效：静态／仅反馈 → 电影感／滚动驱动
• 密度：宽松／编辑式 → 操作型／驾驶舱式

这些是辅助决策的工具，不是面向用户的配置项。公共部门、受监管、无障碍要求关键，以及内容密集的产品界面通常应降低变化度和动效。品牌、编辑和体验型项目可以提高这两个维度。

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

2. 确定一个视觉主旨

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

• 一种适合用户旅程的结构特征；
• 每个版块或工作区区域各一个主导视觉理念；
• 一套字体系统、一种配色逻辑、一套圆角规则、一个图标系列和一种动效语言；
• 一个扎根于产品或品牌的记忆点。

不要靠堆叠流行效果来营造氛围。差异化首先来自内容层级、比例、节奏和具体性，而非装饰。

3. 围绕任务组织内容

• 营销内容按照用户的不确定性排序：问题、机制、证据、行动。
• 产品 UI 应从工作界面开始，而不是营销主视觉。
• 每个版块或区域只承担一项任务。
• 操作型 UI 使用实用文案，营销型 UI 使用品牌文案。
• 删除重复内容、含糊的形容词、装饰性元数据，以及看似证明内容的填充物。
• 只有在图像能传达叙事或产品信息时才使用。仅用字体也可以构成完整设计；缺乏明确动机的图库图片则不行。

4. 确立设计契约

优先使用现有语义化令牌。如果没有，则定义最精简且实用的契约：

• 表面、文本、弱化文本、边框、强调色、强调色文本、焦点、危险、成功；
• 仅在需要时定义展示、正文、等宽字体角色；
• 间距、字体比例、圆角、层级、动效时长／缓动，以及 z-index 层级；
• 响应式内容宽度和布局断点。

原始值仅用于令牌定义中。组件应使用令牌。

对于独立的交互组件，实际可行时，应在预览或故事中一并展示所有适用状态。

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

• 遵循既有框架和组件约定。
• 复用已安装的软件包；导入前先确认。
• 只有在符合项目策略且有充分理由时才添加依赖。
• 优先使用语义化 HTML 和原生控件。
• 尽可能将动画限制在 transform 和 opacity 上；提供清理逻辑和减少动效的行为。
• 使用用户提供的真实内容和资源。临时占位内容应明确标注。
• 控制改动范围。不要重新格式化或改写无关代码。

6. 执行质量检查循环

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

1. 运行已发现的仓库检查。

2. 找到此已加载 SKILL.md 所在目录，然后从该目录运行附带的静态启发式检查：

   python3 scripts/ui_quality_lint.py --html <file> --css <file> --format text

   将检查结果视为供检查参考的提示，而非设计质量或 WCAG 合规性的证明。

3. 在适合该产品的参考宽度下渲染并检查。除非范围另有规定，公共网页应包含 320、375、414、768 和 1280 px。

4. 测试键盘操作流程、焦点、悬停／触控一致性、长内容、空／错误／加载状态、缩放／重排、减少动效，以及两种主题（若均受支持）。

5. 重新阅读所有可见文案，并核实每项声明。

6. 修复问题并重新运行相关检查。

7. 交付前自我审查

按 1–5 分评分：

• 目的：设计是否体现了该产品或页面存在的理由？
• 层级：用户能否在几秒内明确主要任务？
• 独特性：原样照搬后，这套设计是否也可能属于其他品牌？
• 一致性：字体、颜色、间距、形状、图标和动效是否相互协调？
• 克制：每个可见元素是否都有存在的必要？
• 健壮性：在真实状态、内容、设备和输入方式下是否依然可靠？

任何分数低于 3，都需要再次修改。除非用户要求提供审计记录，否则不要将评分加入生产代码。

输出要求

先给出结果。报告以下内容：

• 设计解读和关键视觉理念；
• 改动的重要文件；
• 验证命令及结果；
• 尚未验证的内容；
• 剩余的占位符、假设或风险。

进行审计时，按对用户的影响排列发现，并注明文件与行号或可见区域。将证据与审美判断分开。

参考资料

• 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 的可移植性检查。

来源

这是参考 Hallmark（MIT）、design-taste-frontend、frontend-skill、frontend-design、impeccable-design-polish 和 design-auditor 综合原创而成。保留其中有益的方法，但不要照搬其固有风格，也不要将任何单一目录视为标准答案。