frontend-design

前端设计

创建一个观点明确、贴合具体主题的可用前端，并在渲染后的 UI 中验证设计效果。

约定

• 对于评审、审核或设计计划，检查相关产品并报告设计方向，不要编辑文件。
• 对于构建或重新设计，完成请求范围内的修改，并运行本地、非破坏性验证。
• 将用户明确提出的要求、提供的参考、仓库说明、现有产品行为和本地设计系统视为权威依据。要求高度还原时，以还原要求为准，覆盖本技能的默认设置。
• 保留技术栈和现有功能。除非请求有所要求，否则不要替换框架或设计系统、添加依赖项或臆造功能。
• 重新设计时保留独特的现有艺术素材和有用的视觉线索。替换之前，先确认替代内容能保留它们对产品识别、理解或交互的作用。
• 如果有助于实现艺术方向，可使用原创的代码编写 SVG 或图库图片。只有在请求要求时才生成其他媒体。
• 如果缺少主题、受众或页面用途信息，请做出尽可能小且合理的假设，并在开始构建前说明。仅当答案会实质性改变范围或产品识别时才提问。

布局和主题默认设置

将每次构建都视为服务于特定目的的独立页面。除非用户另有要求，否则采用以下默认设置：

• 仅针对桌面浏览器窗口构建。不要添加移动端或响应式布局。
• 只构建一种主题。不要添加第二种主题、主题切换开关或 prefers-color-scheme 变体。
• 选择颜色前，检测系统外观。仅当系统使用浅色模式时才使用浅色主题；否则使用深色主题。
• 在 macOS 上，运行 defaults read -g AppleInterfaceStyle。深色模式下会输出 Dark。浅色模式下由于该键不存在，命令会报错。

修改现有界面时，保留其现有的响应式和主题行为。除非用户提出要求，否则不要将这些行为扩展到新内容。

工作流程

1. 绘制页面前先了解产品

检查受影响的路由或组件、相邻 UI、设计令牌、排版、素材、依赖项和仓库验证命令。明确以下内容：

• 具体主题和目标受众。
• 屏幕的单一主要用途和内容层级。
• 现有的视觉语言和交互惯例。
• 所需的视口、主题、状态和无障碍约束。

尽可能使用真实的产品内容和提供的素材。如果缺少文案，只编写帮助用户理解界面并采取行动所必需的内容。

2. 确定一种艺术方向

开始编码前，先定义一个精简的方向：

• 核心主张： 用一句话将视觉构想与主题及屏幕用途联系起来。
• 系统： 基于角色的颜色标记、明确的字体角色与字号比例、间距与信息密度，以及经过考量的布局和对齐方式。
• 标志性元素： 从该领域的对象、工作流、数据形态、环境或语言中提炼一个令人难忘的元素。
• 突破点： 有意偏离一种显而易见的方案，并说明这样做为何符合本项目要求。
• 动效与文案： 说明动效在何时有帮助、界面如何表达，以及哪些地方需要克制。

根据现有的品牌约束调整这一方向，而不是另起一套设计语言。除非用户要求在不同方向中做选择，否则应将备选方案和过程说明保留在内部。

对于构建和大幅改版，应针对具体情况评估图像。考虑将图库照片、艺术作品或原创 SVG 用于背景、区块过渡或焦点细节。只有在图像能强化网站主题、氛围或内容层级时才使用。无图像设计同样有效。选择或制作原创 SVG 图案时，请阅读 SVG 设计。

当图库图片适合这一方向时，使用 $chromium-browser 搜索 Google 或 Unsplash。使用图片前，请打开原始来源，核实使用权限及任何署名要求。仅凭搜索结果无法确认素材可以再次使用。

将图像与彩色背景组合成统一的调色板。选择相辅相成的颜色、经过考量的裁剪方式，并在文字和控件背后留出安静的空间。避免使用可以套用到任何无关网站的通用图库图片。

3. 进行反默认设计评估

进行主题替换测试：在脑海中将主题替换成无关主题。任何无需改变就依然适用的重要设计选择，很可能只是模板默认项。请修改该选择，或说明它为何在结构上合理。

每种视觉手法都必须有其存在的理由。卡片、胶囊、渐变、编号、分隔线、超大字体、分栏主视觉、插画和动画，都必须传达层级、功能、顺序或主题，而不只是装饰。将表现力集中在标志性元素上，并让周边系统为其提供支撑。

清晰的区分是功能性要求。当边框和容器有助于快速识别分组和归属时，它们就是合理的。不要仅仅为了让设计更扁平或不那么常见，就移除有用的边界。

将具体设计模式视为评估提示，而非绝对禁令。如果项目要求不支持，就要审视奶油色背景、斜体标题点缀、01/02/03 区块标签、等宽字体标签和胶囊形按钮。对重复出现的装饰卡片、阴影和区块进入动效也应进行同样的审视。如果这些选择符合项目要求或有明确功能，就应保留。首次渲染后，找出其他未经审视的默认设计并进行修改。

4. 构建实际体验

• 引入新的基础组件前，先遵循本地组件、设计令牌、样式架构和依赖版本。
• 根据用途匹配布局：运营工具应便于快速浏览信息和高效重复操作。编辑或营销界面则可以采用更具表现力的叙事方式。
• 让首屏同时展现产品标识和主要用途。对于应用或工具，应展示实际工作界面，而不是将其包装成未经要求的落地页。
• 使用清晰的边框、表面反差和间距，让项目、记录和独立面板易于区分。除非渲染后的替代方案能让边界至少同样清晰，否则应保留实用的分组边框。
• 使用卡片呈现相关或重复对象。仅在嵌套容器能体现真实层级时才使用。
• 为展示、正文和工具类文字明确设定字体用途。优先使用现有字体。不要仅为追求新奇而添加字体依赖。一到两种字体即可满足这些用途。
• 保持正文易读，每行通常少于 80 个字符。根据字体和内容调整行宽与行高。
• 从用户视角撰写界面文案：使用具体名词、主动动词、统一的操作名称、句首字母大写的句式，以及实用的空状态和错误状态。控件标签必须清楚说明操作结果。
• 使用常见控件和项目的图标库。对于不熟悉的纯图标控件，应提供无障碍名称，并在适当时显示可见的工具提示。
• 动效并非必需。使用动效时，应将其集中在能说明层级或提供有用交互反馈的地方。尊重减少动态效果的偏好，并确保没有动画时体验依然清晰。
• 在适用的所有宽度下，避免内容重叠、裁切、换行后难以阅读和布局偏移。默认适用范围为一种桌面宽度。用户要求响应式行为时，应根据内容而非设备标签构建响应式约束，并涵盖窄屏和宽屏。
• 对于图片，应选择能保留视觉焦点且不会造成不必要下载负担的响应式裁切方式和资源尺寸。为有意义的图片提供实用的替代文本，装饰性图片则使用空替代文本。
• 保持语义结构、键盘操作、可见焦点、足够的对比度和目标尺寸。若项目的无障碍标准更严格，则应遵循该标准。
• 让选择器特异性和组件归属关系保持可预测。不要依赖相互竞争的选择器或脆弱的层叠顺序来设置间距和状态。

5. 渲染、检查并修订

运行仓库要求的检查，以及能够验证改动行为的范围最小的附加检查。根据受影响的部分，选择格式检查、lint、类型检查、测试和构建。除非编辑内容或未解决的问题使已通过的检查结果失效，否则沿用这些结果。然后，在本次会话中 chromium-browser 技能可用时，使用它进行渲染验证；否则使用主机的 DevTools/浏览器工具。DevTools 浏览器工具可用时，不要改用 Computer Use 或临时编写的 Playwright 脚本。

根据改动调整检查矩阵的范围。仓库说明可能会缩小视口/状态矩阵的范围，包括免除多视口检查。请遵循这些说明。若无此类说明，对现有 UI 的小改动只需在一个有代表性的视口中验证改动涉及的状态。新增或经过大幅重新设计的界面，需要在单一主题下检查一个桌面视口，以及所有发生变化的交互和状态。用户要求响应式行为或多种主题时，再添加有代表性的窄、宽视口和每种指定主题。若仓库中已有自动化测试，应在其中验证行为。涉及视觉、布局和主题的问题则使用浏览器检查。

检查渲染结果中的内容层级、分组边界、主体明确性、资源加载、溢出、重叠、截断、对比度、焦点、悬停、动画、空状态/错误状态，以及范围内的主题变体。确认在所测试的宽度和主题下，每个项目所属的分组以及每个分组的范围都一目了然。将结果与需求说明和美术指导进行比较。修复可见缺陷，并移除任何对实现目标或美术指导没有实质帮助的元素。

渲染可用时，不要仅凭源码检查就声称已完成视觉验证。如果环境无法渲染 UI，请说明这一限制，并准确报告已验证的内容。

完成

完成工作需要交付所需的产物或代码、在实现中体现针对具体主题的设计方向、通过相关本地检查，并在工具允许时提供渲染检查证据。用一句话说明设计方向，并报告执行的检查和视口，以及任何剩余限制。

构建完成后，请使用 ### ✨ Built: <surface>、🎨 Direction — <one sentence> 和 ### 🧪 Verification。检查了多个状态时，请使用简洁的视口/状态/结果表格。有截图或产物时，请添加链接。仅在存在未解决事项时添加 ### ⚠️ Remaining。Agent 报告中的装饰格式不代表可以在交付的界面文案、快照或源码中使用 emoji 或 ASCII 装饰，除非需求说明或设计系统要求这样做。