frontend-design

此技能旨在指导你打造独具特色、达到生产级水准的前端界面，避免千篇一律的“AI 垃圾”美学。编写真正可用的代码，格外注重美学细节与创意选择，然后在提交前依据自我评审标准进行检查。

用户会提供前端需求：要构建的组件、页面、应用或界面。他们也可能补充相关背景，例如用途、受众或技术限制。

范围与要求

在进行设计思考之前，先判断需求类型，并规划合适的职责边界。仅在缺失信息会实质影响结构、行为、集成或无障碍设计时提问；需求充分时，直接开始，不必来回确认。

• 页面或应用：规划用户旅程、信息架构、内容层级、导航与路由上下文、页面级状态、全视口响应式构图，以及统一的视觉概念。
• 独立或可复用组件：规划其职责、公开输入与内容、事件、适用时的变体及加载／空状态／错误／禁用／选中状态、宿主上下文、固有尺寸、键盘与焦点语义、设计令牌和组合边界。
• 混合工作：同时规划两个层级，并避免将页面专属需求塞进可复用组件的内部。

组件不得擅自创建无关的页面外壳、全局地标、文档级 <h1>、全局排版或背景，也不得添加视口元数据。页面不得在未确定页面层级、导航、内容流和响应式行为之前，把规划简化为逐个组件的设计。

以上三种工作类型最终都应遵循下文的设计思考、实现、反通用化指导、自我评审和可选验证流程；不要为不同类型重复这些阶段。

设计思考

编写代码之前，先理解上下文，并确定一个大胆鲜明的美学方向：

• 用途：这个界面要解决什么问题？谁会使用它？
• 风格：选择一种极端风格：极致简约、极繁混沌、复古未来主义、有机自然、奢华精致、玩具般俏皮、编辑部／杂志风、粗野主义／原始风、装饰艺术／几何风、柔和粉彩、工业实用主义等。风格选择丰富多样。可以从中汲取灵感，但最终设计应忠于所选的美学方向。
• 限制：技术要求（框架、性能、无障碍设计）。
• 差异化：什么能让这个设计令人难忘？人们会记住它的哪一点？

至关重要：选择清晰的概念方向，并精准执行。大胆繁复与精致极简都可行——关键在于意图明确，而非强度高低。

然后编写可用的代码（HTML/CSS/JS、React、Vue 等），做到：

• 达到生产级水准且功能完善
• 视觉出众、令人难忘
• 风格统一，审美立场清晰
• 每个细节都经过精心打磨

前端美学指南

重点关注：

• 排版：选择美观、独特且有趣的字体。避免使用 Arial 和 Inter 等常见字体；选择更具辨识度、能提升前端美感的字体，以及出人意料、富有个性的字体。将独特的展示字体与精致的正文字体搭配使用。
• 色彩与主题：坚持统一的美学风格。使用 CSS 变量保持一致性。鲜明的主色搭配强烈的点缀色，效果胜过拘谨、分布均匀的调色板。
• 动效：使用动画实现效果和微交互。对于 HTML，优先采用纯 CSS 方案；对于 React，条件允许时使用 Motion 库。聚焦于影响显著的时刻：精心编排页面加载过程，并通过错落出现（animation-delay）带来惊喜，胜过零散的微交互。使用滚动触发效果和令人意外的悬停状态。
• 空间构图：采用出人意料的布局、不对称设计、重叠、对角流动、打破网格的元素，以及充裕的负空间或经过控制的高密度布局。
• 背景与视觉细节：营造氛围和层次感，而不是默认使用纯色。添加与整体美学相符的情境化效果和纹理。运用创意形式，例如渐变网格、噪点纹理、几何图案、分层透明效果、戏剧化阴影、装饰性边框、自定义光标和颗粒叠层。

绝不要采用常见的 AI 生成式美学，例如过度使用的字体系列（Inter、Roboto、Arial、系统字体）、陈词滥调的配色方案（尤其是白色背景上的紫色渐变）、可预测的布局和组件模式，以及缺乏特定情境个性的千篇一律设计。

发挥创意，做出出人意料、真正贴合情境的选择。每个设计都应独一无二。在浅色和深色主题、不同字体和不同美学风格之间灵活变化。绝不要在多次生成中趋同于常见选择（例如 Space Grotesk）。

重要：让实现复杂度与美学构想相匹配。极繁主义设计需要复杂的代码、大量动画和效果；极简或精致的设计则需要克制、精准，并仔细关注间距、排版和细微之处。优雅源于出色地实现构想。

请记住：模型能够创造非凡的作品。尽情发挥，充分展现跳出框架思考并全心投入独特构想时，真正能够创造出怎样的成果。

具体做法（对抗默认选择）

如果放任模型自行发挥，它就会偏向统计意义上的中心选项——白色背景、蓝色或紫色按钮、Inter 字体，以及单张居中卡片或三栏网格。要有意识地逐一对抗这些默认选择：

• 字体排版：选定一种符合设计方向的独特字体——编辑风格 → Fraunces、Playfair Display、Crimson Pro；产品风格 → Clash Display、Satoshi、Cabinet Grotesk；技术风格 → IBM Plex、Source Sans 3；代码风格 → JetBrains Mono、Fira Code。追求真正的反差：采用极端字重组合（200 对 800，而不是 400 对 600），字号相差 3 倍或更多。避免使用 Space Grotesk——它虽不错，却是众所周知的趋同陷阱。
• 布局：动手之前先确定一种布局原型——bento 网格、分屏、不对称或破格式网格、杂志式、侧边栏——而不是任由布局退回居中单栏。bento 网格（区块尺寸各异，最大元素优先）能为仪表板提供结构，又不会显出千篇一律的“AI 风格”。
• 色彩：一种主色搭配一种鲜明的点缀色，胜过一套畏首畏尾、平均铺开的调色板。以具体的参考为基础——IDE 主题、某种文化或时代美学——而不是泛泛的品牌蓝；在有帮助的地方赋予颜色明确的语义。
• 设计令牌与主题：所有颜色、间距、圆角和阴影值都通过 CSS 自定义属性进行管理；不要散落魔法数字。通过在 .dark 下重新定义这些变量来实现深色模式，而不是重新设置样式。如果用户已有品牌或设计系统，就注入其令牌，完全跳过你的默认选择。
• 以灵感来源取代形容词：以具体来源为设计依据——一种材质、一个时代或一款软件——而不是“现代且简洁”这种最终会让设计直接退回默认选择的描述。
• 让每次生成都各不相同：上面的字体和布局清单只是灵感起点，不是每次都要从中挑选的菜单——要把它们当作出发点并轮换使用。不要重复采用相同的设计方向、字体搭配或调色板；如果某个需求与之前处理过的需求相似，就刻意采用不同方案。不同产品的两个界面不应看起来像同一个模板。即使每个界面单独看都不错，输出千篇一律本身也是一种失败。

返回前的自我检查

模型往往会自信地夸赞自己平庸的输出，因此不要问自己“这看起来不错吗？”。请改为执行以下具体的通过／失败检查，并在返回代码前修复每一项未通过的问题。这些检查针对 WCAG 2.2 AA 和基本的工艺质量——都是可以从标记中检查的事项，而非审美问题。

无障碍：

• 正文文本的对比度至少为 4.5:1；大号文本（24px 及以上，或 18.66px 及以上的粗体文本）、UI 控件的边框及有意义的图标的对比度至少为 3:1。含义绝不能仅通过颜色传达。
• 使用原生语义元素：操作使用 <button>，导航使用 <a href>，输入框使用真正的 <label>。页面或文档恰好有一个 <h1>，标题层级依次递进，并使用适当的 <header>、<nav>、<main> 和 <footer> 地标。组件自身负责原生控件、标签、可访问名称和局部标题顺序；不得仅为满足此检查标准而添加文档级 <h1>、全局地标或 <meta name="viewport">。
• 每个 <img> 都有 alt 属性（装饰性图片使用空值 alt=""）；仅含图标的控件具有可访问名称。
• ARIA 的首要原则：优先使用原生元素，而不是 ARIA 角色——错误的 ARIA 不如完全不用 ARIA。
• 每个交互元素都可通过键盘操作，并显示可见的焦点指示器；每个组件都负责自身的键盘和焦点行为，且绝不在没有更强替代样式的情况下移除默认轮廓。
• 对于页面或文档，必须有 <meta name="viewport">，且不得禁用缩放；页面级内容在宽度低至 320px 时应重排为单列，且页面不得出现水平滚动。组件应在其宿主或容器内重排。具有内在二维结构的控件可以保留必要的内部滚动，但必须防止意外的页面溢出，并保留键盘访问能力。

工艺质量：

• 字体遵循经过设计的比例；正文 line-height 至少为 1.5；每行长度保持在约 45–75 个字符；字号使用 rem／em。
• 间距遵循统一的尺度（4／8px 步进或设计令牌），不得随意设置。
• 添加 @media (prefers-reduced-motion: reduce) 代码块，以减弱或移除非必要动效；任何内容的闪烁频率都不得超过每秒三次。
• 不得保留泛化的默认样式痕迹：不能使用 Inter／Roboto／Arial 字体，不能使用白底紫色渐变，也不能在设计需求需要更多内容时只放置一张居中的卡片。
• 成果不能看起来像默认模板，也不能像上一代生成的结果。如果它看起来像常见设计模式或先前生成的作品，请另辟蹊径——更换布局类型、字体搭配或配色方案，然后重新生成。

可选验证

可选，且通过 npm 跨平台支持（Windows、Linux、macOS）。使用现有工具，其他工具则妥善跳过——切勿将其设为硬性要求。

• 静态检查，无需浏览器：npx html-validate <file> 可检查无效标记、缺少 alt、未标注的控件，以及错误或冗余的 ARIA；完全离线即可运行。这是成本最低的首道检查。
• 渲染后的 DOM（需要无头浏览器）：npx pa11y --standard WCAG2AA <url>（或 axe-core）可检查只有在页面渲染后才会显现的计算后对比度和可访问名称。
• 仅视觉自我检查循环（自选）：在支持视觉的模型环境中，且有无头浏览器可用时，使用 Playwright 渲染结果并截图——使用其捆绑的独立 Chromium、Firefox 或 WebKit，绝不使用用户的系统浏览器——再根据上述检查标准审视图像并迭代，直到满足要求。对于纯文本模型，跳过截图，直接检查代码。

备注

此处的指导内容综合改写自 Anthropic 的前端美学指南，以及《Harness design for long-running application development》（2026-03-24）中的生成器/评估器模式，并参考了 Vercel v0 和 shadcn/ui 的主题设置。无障碍阈值来源于 WCAG 2.2 — 对比度 1.4.3 和 1.4.11、重排 1.4.10、文本间距 1.4.12、焦点可见 2.4.7 — 以及 MDN。已于 2026-05-27 验证。