all-in-one-ui-ux-design

一体化 UI/UX 设计

将此技能用作默认的端到端 UI/UX 系统。 让此文件专注于工作流。仅在需要时加载参考文件。

目标：交付令人印象深刻、可用于生产、易于访问且易于维护的界面。

从这里开始

在生成或审查代码前，收集最少的上下文：

1. 产品背景：产品类型、受众、语气和品牌限制。
2. 范围：完整页面/应用、组件集、重新设计或 UI 审计。
3. 平台和技术栈：Web/移动端 + 框架/库选择。
4. 所需状态：加载、空状态、错误、成功、禁用和边缘情况。
5. 交付目标：原型、生产代码、审计结果或设计系统规范。

如果缺少信息，提出 1-3 个有针对性的问题。如果用户更看重速度，则明确说明假设后继续。

模式选择

选择符合意图的模式：

1. build：设计并实现新的 UI。
2. redesign：保留功能，替换视觉和交互层。
3. audit：审查现有 UI 并给出可执行的发现。
4. design-system：在编码前定义设计令牌、字体比例和组件基元。
5. flow：设计多屏流程（引导、结账、设置、仪表板）。

对于混合请求，依次执行 design-system -> build -> audit。

默认建议

除非用户另有要求，否则采用以下默认设置：

1. 技术栈选择： 使用代码库中已有的技术栈。 如果没有现成技术栈且任务面向 Web，默认使用 html-tailwind。 如果没有现成技术栈且任务面向移动端，使用平台原生模式。
2. 审计深度： 默认进行完整清单审计。 仅当用户明确要求优先考虑速度而非深度时，才进行快速审计。
3. 创意： 不要将僵化模板作为主要产出。 为每个项目采用独特的设计方向，以可复用原则取代克隆式布局。 将 assets/primitives/ 用作可组合的脚手架，而非最终视觉识别。

参考文件加载指南

仅加载任务所需的内容：

文件	加载时机
references/creative-direction.md	选择风格方向、字体个性、配色氛围、布局构成和视觉差异化时
references/system-build-playbook.md	制定实现计划、选择技术栈、应用 UX 优先级规则和使用最终交付清单时
references/web-interface-guidelines.md	审查 UI 代码的无障碍性、交互、性能、文案质量和反模式时

资源套件

在需要加快实现速度且不牺牲原创性的情况下，可使用以下资源：

资源	用途
assets/primitives/tokens.css	字体、颜色、间距、圆角、层级和语义令牌脚手架
assets/primitives/motion.css	动效令牌、入场效果和支持减少动态效果的行为
assets/primitives/layout.css	响应式布局基元（容器、堆叠、簇、网格、区块、表面）
assets/primitives/component-states.css	按钮、字段和卡片的无障碍默认状态
assets/blueprints/semantic-shell.html	用于快速原型设计的精简语义页面骨架

资源规则：

1. 仅复制所需内容。
2. 在最终交付前重新调整令牌主题。
3. 根据项目重新组合布局；切勿直接交付未经修改的蓝图默认样式。

核心原则

1. 确立明确的美学方向。不要制作看起来像通用模板的 UI。
2. 确保整个界面中的风格和交互保持一致。
3. 优先考虑无障碍性和易用性，然后再进行装饰性润色。
4. 有目的地使用动效，用于传达状态变化，不要徒增干扰。
5. 从第一版开始，就针对响应式行为和真实内容进行构建。
6. 优先采用可读、易维护的代码和令牌化样式，而不是临时设定的值。

不可妥协的质量标准

在任何模式下都遵循以下规则：

1. 字体排印必须经过精心设计。避免使用默认字体栈和反复采用保守方案。
2. 色彩必须协调统一。使用设计令牌或 CSS 变量定义主色、次色、强调色和语义状态。
3. 交互元素必须提供清晰可见的悬停和键盘焦点状态。
4. 触控界面上的触控目标尺寸必须至少为 44x44px。
5. 尊重减少动态效果偏好，并避免使用开销较大的动画属性。
6. 完整覆盖各种状态：常规、悬停、焦点、激活、禁用、加载、空、错误、成功。
7. 通过明确设置媒体尺寸并妥善处理文本溢出，避免布局偏移和内容裁切。
8. 避免 references/web-interface-guidelines.md 中列出的反模式。

反通用设计检查（必需）

最终交付前，如果仍存在以下任意问题，则判定输出不合格：

1. 字体选择看起来像默认设置，且缺乏明确意图。
2. 设计方向过度依赖通用渐变或模板，且品牌契合度较弱。
3. 页面结构千篇一律，稍作修改就能套用到任何产品。
4. 装饰性动效无法传达层级、反馈或状态。
5. 字体、布局、交互或视觉质感中缺少令人印象深刻的差异化特色。

端到端工作流

1. 理解需求并明确范围

1. 将请求转化为问题陈述和成功标准。
2. 提取约束条件：品牌、合规性、性能、截止日期。
3. 在编写代码前定义交付内容和验收标准。

2. 选择设计方向

1. 选择一个主要视觉方向和一个辅助影响因素。
2. 定义氛围关键词、对比度、质感策略和动效特征。
3. 在实现组件前，用简洁的设计简报确定方向。

有关可选方向和反通用设计的防护措施，请参阅 references/creative-direction.md。

3. 定义设计系统

创建精简规范：

1. 色彩令牌：背景、表面、文本、弱化文本、边框、主色、强调色、危险、成功。
2. 字体排印系统：展示/标题/正文/说明文字样式和行高规则。
3. 间距和圆角比例。
4. 海拔/阴影系统和边框样式。
5. 动效令牌：时长、缓动方式和减少动态效果时的回退方案。
6. 组件原语：按钮、输入框、选择框、卡片、模态框、工具提示、Toast、表格。

有关规则优先级和针对特定技术栈的指导，请参阅 references/system-build-playbook.md。

4. 构建布局和交互架构

1. 先拟定响应式结构（除非另有说明，否则采用移动优先断点）。
2. 定义层级、分组和浏览路径。
3. 指定交互模式：导航、筛选、验证、反馈。
4. 提前规划边缘状态，避免后期出现回归问题。

5. 按技术栈实现

1. 遵循用户选择的技术栈。如果未指定，则采用上方 Default Recommendations 部分中的默认建议。
2. 确保实现风格与设计系统一致。
3. 使用语义化 HTML 和无障碍组件 API。
4. 优先使用可组合的原语和可复用的令牌，而不是一次性类名。
5. 如果使用 Asset Kit，请在交付前自定义令牌、布局和交互细节。

6. 交付前审查

根据 references/web-interface-guidelines.md 进行自我审查：

1. 无障碍性和语义正确性。
2. 焦点、键盘和触控体验。
3. 响应式行为和溢出处理。
4. 动效、性能和水合安全性。
5. 文案清晰度和交互标签。

审查模式输出约定

当请求意图为审查／审计／检查时：

1. 先列出发现的问题，并按严重程度排序。
2. 按文件分组，并标注 file:line 位置。
3. 每条问题都应简洁且可执行。
4. 仅当文件没有问题时，才说明通过状态。
5. 列出剩余风险或测试覆盖缺失情况。

默认行为：

1. 根据完整指南集执行严格／全面审查。
2. 仅当用户要求轻量审查时，才切换为快速审查。

格式：

## path/to/file.tsx

path/to/file.tsx:42 - issue summary
path/to/file.tsx:77 - issue summary

## path/to/another.tsx

pass

构建模式输出约定

当请求意图为实现时：

1. 提供最终代码或补丁。
2. 用 2–4 条要点总结设计方向。
3. 确认关键的无障碍性和响应式设计决策。
4. 列出已知权衡和后续改进。

快速提示词模式

当需求含糊时，在内部使用以下结构：

1. “这个界面面向谁？核心操作是什么？”
2. “UI 应传达怎样的情绪基调？”
3. “有哪些技术栈或平台限制？”
4. “必须满足哪些质量要求（无障碍性、性能、品牌、本地化）？”

如果用户没有回答，请基于假设继续，并明确说明这些假设。

完成检查清单

最终交付前，确认：

1. 视觉方向鲜明且协调一致。
2. 所有关键交互均具备悬停／焦点／激活／禁用状态。
3. 标签、语义、焦点和对比度均通过无障碍性检查。
4. 已验证移动端和桌面端布局。
5. 已妥善处理对性能敏感的行为（图像、动画、列表）。
6. 文案和错误状态具体明确，并能指导用户采取行动。