frontend-design

前端设计

创建适合用户、任务、内容、产品类别和技术约束的界面。“最佳”意味着适合具体情境，而非遵循某一种视觉风格。

无障碍性、功能正确性、有效的实现示例以及可用的响应式行为都是硬性门槛。不要批准视觉效果出众，却会造成键盘陷阱、控件不可访问、内容难以阅读、状态失效、严重的响应式缺陷或不合理性能开销的结果。

操作决策标准

使用以下权重比较可行的设计选择。这是一套操作决策标准，并非通用的数学标准；无论如何，都不能用它来弥补未通过硬性门槛的问题。

标准	权重
用户与任务契合度	20%
无障碍性	20%
易用性与信息架构	15%
视觉一致性与恰当的独特性	15%
响应式与自适应行为	10%
性能与韧性	10%
交互与状态完整性	5%
可维护性与验证	5%

标准发生冲突时，优先保障主要任务和硬性门槛。记录仍然存在的任何有意取舍。

精简工作流

1. 检查现有产品、项目惯例、设计系统、组件、内容和约束。
2. 明确目标用户、主要任务、内容类型、产品类别、品牌约束、所需平台和输入方式。
3. 选择一种主要设计模式。只有在有助于提升契合度时，才添加至多一种次要影响。
4. 用一句话确立视觉主张，制定精简的内容或信息方案；只有在需要有意义的交互或动效时，才制定交互主张。
5. 优先复用项目既有的设计系统和组件，而不是创建新内容。
6. 设计并实现完整的状态模型和真实的内容层级。
7. 在具有代表性的视口宽度下，使用相关输入方式验证渲染结果。
8. 如实报告证据和未解决的限制。

规划应与任务规模相称。小型组件改动只需明确几项决策，无需撰写冗长的设计文档。

设计模式选择指南

根据产品用途选择模式，而非追逐时髦的美学风格。

产品或工作区

适用于应用、管理工具和运营界面。

• 优先采用以实用性为主的文案和易读的信息密度。
• 明确划分工作区、导航和上下文区域。
• 克制使用色彩和界面装饰。
• 只有在分组、容纳内容或交互语义确有需要时才使用卡片。
• 默认不要添加着陆页主视觉区块。

营销或品牌

适用于着陆页、发布页面、作品集和宣传网站。

• 确立清晰的视觉主张，突出品牌或产品形象。
• 每个版块聚焦一个主导的视觉创意。
• 保持叙述简洁，并明确转化路径。
• 有目的地使用图像；只有在能支撑叙事时才加入动效。

数据或仪表盘

适用于分析、监控和决策支持界面。

• 优化信息浏览、对比和状态可见性。
• 围绕决策组织筛选器、表格、图表和逐层深入路径。
• 保持高密度布局的可读性。
• 显示数据新鲜度、单位、范围，以及空状态或错误状态。
• 避免装饰性的仪表盘卡片拼贴。

编辑或内容

适用于文章、出版物、文档和富媒体内容。

• 保持易读的行长和清晰的排版层级。
• 提供清晰的内容导航。
• 有意识地安排媒体内容。
• 通过节奏和留白支持持续阅读。

商务或服务

适用于购物、预订、申请、入门引导和交易服务。

• 优先保障信任感、清晰度和用户熟悉的类别结构。
• 明确展示发现方式、价格、步骤、承诺事项和主要操作。
• 防止错误发生，并提供恢复途径。
• 在关键流程中尽量减少干扰。

沉浸式或实验性设计

仅当需求和产品场景适合表达性体验时才使用。

• 确立鲜明的艺术指导方向，并支持渐进增强。
• 有选择地使用动画和高级效果。
• 完整支持减少动态效果的设置。
• 保留易用的移动端、触控和键盘操作备用方案。

预加载器、平滑滚动库、自定义光标、磁性按钮、视差、固定定位区块、横向滚动旅程、WebGL、GSAP、Lenis、Framer Motion 和 React Three Fiber 都是可选技巧，并非质量要求。仅当某项技巧能切实支持设计目标，且项目能够承担其在无障碍、性能和维护方面的成本时，才引入它。

通用质量规则

目的、层级与内容

• 明确页面的用途和主要操作。
• 保持符合逻辑的阅读顺序和熟悉的交互模式。
• 根据实际产品界面撰写内容；不要将提示词语言或设计说明放入 UI。
• 让每个区块或区域各司其职。
• 必要时使用渐进式披露来处理复杂内容。
• 不要捏造指标、用户评价、宣传主张、库存或用户数据。
• 尽可能让破坏性操作可撤销；否则应提供确认和恢复方式。

视觉一致性与独特性

• 用字体、间距、色彩、图像、形状和动效构建统一的设计系统。
• 优先追求实用的独特性，避免使用通用模板或与任务争夺注意力的装饰。
• 有意识地控制视觉复杂度，并移除不会增加信息、操作提示、层级或氛围的元素。
• 仅在卡片有助于实现有意义的分组、内容承载或交互时使用。
• 将 60-30-10 配色规则视为可选的调色板平衡经验法则，而非普遍规则。
• 对于以图像为主导的设计，应选择能传达含义、支持叠加文字清晰可读，并符合品牌和内容的图像。
• 让动效适度、有明确目的，并与交互理念保持一致。

无障碍基线

以 WCAG 2.2 AA 级作为基线。区分规范性要求与更严格的建议。

规范性基线

• 优先使用语义化 HTML，而非 ARIA。
• 提供准确的无障碍名称和描述。
• 确保所有功能均可通过键盘操作，焦点顺序合理且可见，并且不存在键盘陷阱。
• 在对话框、删除流程和临时覆盖层关闭后恢复焦点。
• 将标签、说明、验证错误和状态播报与其所描述的控件或区域相关联。
• 文本对比度应至少达到普通文本 4.5:1、大号文本 3:1；WCAG 要求时，非文本内容的对比度应达到 3:1。
• 不要仅靠颜色传达含义。
• 支持内容重排、200% 文本放大和缩放，且不丢失内容或功能。
• 指针目标至少为 24 x 24 CSS 像素，或符合适用的 WCAG 2.2 AA 例外情形，例如间距、行内、等效、用户代理或必要呈现。
• 产品有需要时，应支持触控、鼠标和键盘操作。
• 尊重减少动态效果的偏好，同时避免使用会破坏依赖状态的过渡效果的全局规则。
• 不要让关键信息或操作只能通过悬停访问。
• 确保加载、空内容、错误、禁用和成功状态都清晰可感知、易于理解。

更严格的建议

• 在布局允许时，优先为频繁使用、高风险或以触控为主的操作提供 44 x 44 CSS 像素的目标尺寸。这高于 WCAG 2.2 AA 的 24 像素最低要求，并符合增强型目标尺寸准则。
• 对重要或复杂的工作流进行真实屏幕阅读器测试。
• 对于复杂控件，请参考 WAI-ARIA Authoring Practices Guide，然后验证实际实现；不要将示例视为可直接用于生产环境的代码。

如果任务涉及表单、对话框、复杂控件、破坏性操作、密集数据或无障碍审查，请阅读 无障碍检查清单。

响应式与自适应行为

根据内容和可用空间进行设计，而不只是根据设备名称。

• 检查较窄的手机屏幕、较宽的手机或平板屏幕，以及桌面屏幕。
• 检查缩放或放大的文本、粗略和精细指针，以及仅使用键盘的操作方式。
• 测试长内容、缺失内容和本地化后的内容扩展。
• 随着区域堆叠或重新布局，保持阅读顺序、优先级和控件不变。
• 避免预设大量必需的断点。仅在内容或交互确有需要时添加断点。
• 不要仅为让窄屏截图看起来整洁而隐藏关键功能。

性能与韧性

如果可以测量应用，请将当前 Core Web Vitals 的“良好”目标作为实际运营目标：

• LCP 不超过 2.5 秒。
• INP 不超过 200 毫秒。
• CLS 不超过 0.1。
• 有现场数据时，按第 75 百分位评估现场结果。

未经测量，不要声称已达到这些目标。区分实验室观察结果和现场证据。

• 为图片、字体、客户端 JavaScript、第三方代码和动画依赖设置预算。
• 预留媒体尺寸，并确保加载过渡保持稳定。
• 在适当情况下，优先使用 transform 和 opacity 实现动画；避免不必要的布局计算和滚动劫持。
• 使用渐进增强；当可选媒体、脚本或效果失效时，仍要保留核心任务。
• 在相关情况下，验证慢速加载、离线、数据过时和重试行为。

交互与状态完整性

对用户实际可能遇到的状态进行建模。根据功能需要，涵盖：

• 初始、加载、骨架屏和渐进式状态；
• 空状态、无结果、筛选后为空状态和首次使用状态；
• 成功、部分成功、过时、离线和重试状态；
• 验证、权限、身份验证和服务端错误；
• 控件的悬停、焦点、激活、选中、禁用和忙碌状态；
• 破坏性操作的确认、取消、撤销和恢复。

确保状态转换易于理解。对有意义的异步变化进行提示，防止重复提交，保留可恢复的用户输入，并且绝不要在操作成功之前显示成功状态。

设计系统与可维护性

• 复用现有组件、间距、排版、颜色和交互令牌。
• 添加令牌时，应能减少不一致或支持重复主题和组件；对于小型独立界面，不必强制采用正式的多层令牌架构。
• 避免重复使用原始值，但不要仅为满足此技能而重构整个应用。
• 除非明确将替换纳入范围，否则保留现有品牌和组件契约。
• 将框架机制留给负责这些内容的 React、Next.js、Vite、JavaScript、Tailwind、Figma、Stitch 或测试技能处理。
• 保持实现示例简短、语法有效、概念正确且切实有用。

组件评审标准

在批准 React、Next.js、Vite 或其他前端技术栈中的组件之前，请应用这份精简标准：

1. 契约与数据所有权： Props、事件、状态、副作用、验证、错误和所有权边界都已明确。
2. 完整状态： 已涵盖相关的加载、空、错误、成功、禁用、权限、过时和响应式状态。
3. 无障碍与输入方式： 语义、名称、键盘行为、焦点、对比度、触摸、指针和减少动态效果均达到基线要求。
4. 视觉层级与品质： 排版、间距、颜色、图像、信息密度和动态效果都能服务于组件的用途。
5. 响应式行为： 内容能够重新排布，不会被裁切、丢失操作、顺序错乱或在缺乏合理理由的情况下隐藏。
6. 性能影响： 已了解渲染、打包体积、媒体、 hydration 和动画的成本，且这些成本与收益相称。
7. 项目一致性： 组件复用项目现有的设计体系，不引入可避免的平行模式。
8. 渲染验证： 已在有代表性的宽度、状态和输入方式下检查实际组件。

资源

• 无障碍检查清单：针对 WCAG 2.2 AA 的重点检查和状态级验证。
• 对比度检查器：用于单个颜色或文件的本地标准库颜色对比度计算。

跨客户端可移植性

此技能旨在适用于 GitHub Copilot、Claude Code 和 Codex。

• GitHub Copilot：将文件夹放在 Copilot 可见的技能路径中；如果无法发现文件夹，则将工作流封装在项目指令中。
• Claude Code：将文件夹放在本地技能目录或兼容的插件源中。
• Codex：将文件夹安装或同步到 $CODEX_HOME/skills/frontend-design，并在进行重大更改后重启 Codex。

MCP 可用性与回退方案

首选 MCP 服务：无需使用

• 回退提示词：“在不使用 MCP 的情况下使用前端设计技能。依赖其本地指令、随附资源、标准 Shell 或编辑器工具，以及直接验证。得出结论前，请展示所依据的证据。”
• 如果当前宿主未提供 MCP 操作，不要声称使用了该操作。
• 将本地文件、测试、渲染输出、日志或屏幕截图作为回退证据。

反模式

• 尚未了解用户、任务、内容和约束，就选择时髦的模式。
• 自动替换已有的设计体系。
• 将落地页主视觉、卡片、渐变、玻璃效果或深色主题视为通用默认方案。
• 为了达到“高级”品质而要求使用高成本效果、动画库、自定义光标、平滑滚动或 3D。
• 使用会与主要任务争抢注意力的装饰性 UI。
• 批准虚假数据、不完整状态、无障碍控件问题、损坏示例或未经测量的性能声明。
• 将静态屏幕截图、源代码检查或自动化评分视为完整渲染行为的证明。

验证协议

在宣称前端设计工作流成功之前：

1. 通过/未通过：主要模式、视觉理念、内容计划和相关约束都已明确，且符合请求。
2. 通过/未通过：功能正确性、WCAG 2.2 AA、有效示例和响应式行为均通过所有硬性门槛。
3. 通过/未通过：已实现相关组件和页面状态，内容真实，失败时可以恢复。
4. 通过/未通过：已在有代表性的视口宽度下检查实际渲染结果，并使用键盘及相关指针或触控输入进行检查。
5. 通过/未通过：尽可能测量性能开销；否则应报告为未经验证，而非自行假定。
6. 压力测试：使用长内容、放大后的文本、减少动态效果、缓慢或失败的依赖项，以及最窄的受支持宽度，重复执行主要任务。
7. 成功指标：每项验收都引用渲染、行为、测试或测量证据，并列出任何尚存限制。

相关技能

• web-design-reviewer：实现后用于基于浏览器的视觉 QA 和响应式缺陷诊断。
• react-development：用于 React 特定的组件架构和实现。
• nextjs-development：用于 Next.js 路由、渲染、数据和框架行为。
• vite-development：用于 Vite 配置、构建行为和应用集成。
• stitch-design：用于 Stitch 特定的设计和实现工作流。
• figma-implement-design：当实现必须遵循 Figma 这一事实来源时使用。