---
name: award-level-web-design
description: 以 Awwwards / Webby Awards / FWA 获奖网站为品质标准来设计和实现网页，并在完成后按排版、留白、视觉层级、色彩、动效、微交互、响应式、原创性、内容九个维度做"渲染—截图—自检—修改"的循环优化，直到没有明显可提升之处。只要用户要做落地页、官网、作品集、产品页、活动页、个人主页、HTML 页面或前端界面，或提到"高级感""好看一点""设计感""获奖级""Awwwards 风格""精致""别像模板"，或要求打磨/重做已有页面的视觉，就使用这个技能——即使用户没有明确说"获奖级"。不适用于：纯后端或逻辑 bug 修复、数据图表本身的配色与绘制、PPT/海报等非网页设计。
---

# 获奖级网页设计与自检迭代

目标：做出的页面放到 Awwwards / Webby / FWA 的提名列表里不显得突兀。评委看重的是**一个清晰的创意概念被执行到每个细节**——而不是堆砌特效。"能用"和"整齐"只是起点。

"获奖级"在这里有明确的评分框架：维度按 Awwwards 的 Design / Usability / Creativity / Content 加权，每一档分数都有可观察的锚点，见 [references/award-criteria.md](references/award-criteria.md)。借鉴的是获奖站的概念贯穿和执行精度，**不借鉴**为了炫技牺牲性能和可访问性的做法。

整个流程分三段：先定方向，再实现，最后用真实渲染结果反复自检优化。第三段是这个技能的核心，不要跳过。

## 1. 动手前：定一个设计概念

概念决定页面的上限，后面的自检只能修执行，修不了想法。所以写代码之前，先完成下面三步，并把结果告诉用户。

### 1.1 发散：写出三个方向

第一个想到的方向，往往就是最平均的那个。先读 [references/art-direction.md](references/art-direction.md)，写出 3 个**来自不同美术方向**的方向，每个包含：
- 一句话概念，用这个句式："这个页面是关于 ___，它给人 ___ 的感觉，因为 ___。"（例："一家烘焙店的页面，像一张慢慢写满的烘焙记录卡，因为每一锅豆子都有自己的曲线"）；
- 美术方向和叙事结构（从参考里各选一个）；
- 3–5 个视觉关键词；
- 签名时刻是什么。

如果需要参考现有获奖站，先读 [references/deepdive.md](references/deepdive.md)，只提取可验证的原则，不复制它的布局、颜色或动效参数。

三个方向不能只是换了配色，美术方向必须不同。选定一个，用一句话说明为什么不选另外两个，然后为它写出节拍表（每屏的目的和唯一的视觉事件）。用户明确给了方向时，可以跳过发散，但节拍表仍然要写。

### 1.2 翻译：把概念落实成设计决策

把选定的概念拆成下面这张表，每一行都要能从概念推导出来。说不出理由的选择，就是模板感的来源。

| 层 | 决策 | 为什么服务于概念 |
| --- | --- | --- |
| 字体 | 一个有性格的展示字体 + 一个高可读的正文字体。中文页面按 [references/cjk-type.md](references/cjk-type.md) 选字体，并确定加载方案 | |
| 色彩 | 一个主色调 + 中性色阶 + 最多一个强调色，用 CSS 变量定义 | |
| 版式 | 网格（例如 12 栏）、间距刻度（例如 4/8 的倍数）、字号比例（例如 1.25 或 1.333）、首屏构图 | |
| 动效 | 缓动和时长的性格（沉稳 / 利落 / 弹性），以及签名动效 | |
| 文案 | 语气（编者口吻 / 工程师式精确 / 朋友聊天），以及首屏标题的 3 个备选 | |
| 签名时刻 | 至少一处让人记住的设计：独特的首屏构图、精心编排的滚动叙事，或一个巧妙的交互 | |

填完后做两个检验：
- **去掉动效还成立吗？** 想象页面完全静止，概念还能从字体、版式、色彩和文案里看出来吗？看不出来，说明你做的是特效，不是概念。
- **有没有两行在打架？** 比如工业感字体配液态缓动，或者静奢的留白配密集的信息卡片。两行矛盾，说明你同时有两个概念，砍掉一个。

这张表也是之后评审"原创性"的依据：逐行检查截图里有没有落实。

### 1.3 先写文案，再定版式

先写首屏标题和各区块的标题、关键数字，再根据文字长度决定版式。用 lorem 或空泛口号占位、事后再填，层级和断行都会跟着失控。

避开"AI 模板脸"：紫蓝渐变 + 居中大标题 + 三张等宽卡片 + 全站 Inter + emoji 当图标 + 处处圆角阴影。这些不是禁止，而是如果用了，要能说出为什么它服务于概念。

## 2. 实现时的底线

- 用语义化 HTML，设计令牌（颜色、字号、间距、圆角、缓动曲线）集中定义为 CSS 变量，保证全站一致。
- 动效优先用 `transform` / `opacity`，配合自定义缓动（如 `cubic-bezier(0.22, 1, 0.36, 1)`），时长通常 200–700ms；必须尊重 `prefers-reduced-motion`。
- 所有可交互元素都有 hover、focus-visible、active 状态；键盘可达；文本对比度至少 WCAG AA。
- 移动优先，至少在 375 / 768 / 1280 / 1920 四个宽度下都成立；不能出现横向滚动。
- 图片给出尺寸避免布局抖动；字体用 `font-display: swap`；首屏不要被重型动画库拖慢。

### 技术选型与高级媒介

先读 [references/stack.md](references/stack.md)，选择能表达概念的最小技术栈。静态 HTML 已经够用时，不要为了显得高级而引入框架。需要连续场景时，再读 [references/scroll.md](references/scroll.md)；概念是空间或材质时，按需读 [references/webgl.md](references/webgl.md)；视频是内容和签名时刻时，读 [references/video.md](references/video.md)。只有当“一段连续镜头就是页面概念”时，才读 [references/scroll-scrub.md](references/scroll-scrub.md)。这些参考都要求静态内容、键盘操作、移动端版本和 reduced-motion 降级先成立。

滚动、动画和 WebGL 使用一个渲染循环。视频使用 poster 作为首屏候选，不把自动播放声音或滚轮劫持作为设计手段。高级媒介是概念的表达方式，不是额外的视觉装饰。

### 动效设计规范

动效必须服务于内容概念和阅读顺序。默认采用“一个签名动效 + 少量入场/微交互”的结构，不要把所有元素都做成淡入，也不要为了展示技术而加入重型动画库。

- 入场优先使用 `transform`、`opacity` 和 `clip-path`，常用时长 180–700ms，统一使用项目自己的缓动令牌；首屏核心内容不得长期保持 `opacity: 0`。
- 每个页面选择一个签名动效：例如咖啡页面的曲线绘制、建筑页面的网格/坐标揭示、音频页面的波形或标签切换、作品集页面的评分变化。其余动效应保持克制。
- 超过 5 秒的循环、打字、标签自动切换和录音演示必须有可见的暂停/播放控件；悬停、键盘聚焦、页面隐藏和元素离屏时停止非必要播放。
- 必须实现 `prefers-reduced-motion: reduce`：直接显示信息内容，停止连续动画，清除错峰延迟；如果使用 `requestAnimationFrame` 或计时器，还要在脚本中监听 `visibilitychange` 和 `IntersectionObserver`。
- 指针跟随和背景循环只用于局部签名效果，使用 `requestAnimationFrame` 合帧和 `transform`，避免持续触发布局；不要让装饰动效抢过标题和 CTA。

可直接套用的模式、参数和降级模板见 [references/motion-patterns.md](references/motion-patterns.md)。高级媒介的技术边界见 [references/stack.md](references/stack.md)、[references/scroll.md](references/scroll.md)、[references/webgl.md](references/webgl.md)、[references/video.md](references/video.md) 和 [references/scroll-scrub.md](references/scroll-scrub.md)。

## 3. 完成后：渲染—自检—优化循环

**一定要看真实渲染结果，而不是只读代码。** 很多问题（拥挤、失衡、对比度不足、断行难看）只在像素层面才看得出来。

### 先用脚本，再用眼睛

skill 自带截图和审计脚本（需要 Node 22+ 和本机的 Chrome / Edge / Chromium）：

```bash
node <skill目录>/scripts/shoot.mjs <页面URL或HTML文件> --audit --review --reduced-motion --keyboard --sections "#work,.pricing" --out shots/r1
```

- `shoot.mjs`：一次截完 375 / 768 / 1440 / 1920 四个宽度的首屏，以及 `--sections` 指定的区块（加 `--full` 还会截整页）。它会等页面加载、字体就绪、入场动画结束，避开"空白页""内容发灰"之类的截图假象。
- `--audit` 会在每个宽度运行 `scripts/audit.js`。它自动报告以下问题，结果存为 `audit.json`：
  - 横向溢出、文字对比度、点击区尺寸；
  - 中文字体回退、标题孤字；
  - 图片缺尺寸或 alt、缺少减弱动效规则；
  - 首屏内容停在 opacity 0、占位文案；
  - h1/main/lang/title/description/viewport；
  - 加载时的 JS 报错和资源 404。
- `--reduced-motion`：开启 `prefers-reduced-motion: reduce` 后重新加载并滚动全页，截出 `<宽度>-reduced.png`，报告停在 opacity 0 的内容和仍在运行的无限动画。
- `--keyboard`：用真实的 Tab 按键遍历前 40 个焦点，报告没有 outline / box-shadow 的焦点和落在不可见元素上的焦点。只靠背景色或下划线表现焦点的元素也会被列出来，修改前先看截图确认。
- `--perf`：在每个宽度采集 LCP、CLS、页面体积和字体体积，超过阈值时报警（阈值可以用 `--max-lcp` 等参数调整）。数据来自不限速的本地测量，只能用来发现明显问题，不等于真实用户的指标。
- `--axe`：运行 axe-core 无障碍扫描（需要 `npm install axe-core` 或 `--axe-source`）。
- `--review`：额外存两种用来评审的截图。
  - `<宽度>-squint.png`：模糊加灰度后的首屏。只剩下块面、明暗和位置，正好用来判断视觉层级——第一眼落在哪里，有没有两个元素在抢。看原图时大脑会自动读文字，反而看不出层级问题。
  - `<宽度>-overview.png`：整页缩到一屏能看完的缩略图。用来看区块之间的留白节奏是否有变化，以及页脚有没有明显比首屏潦草（评委会一直滚到底）。
- 除截图外，所有结果都会汇总进 `report.json`。
- 用不了脚本时（例如没有本地 Chrome），把 `audit.js` 的全部内容放进任意浏览器工具的 JS 控制台执行，最后一个表达式就是报告；截图改用手头的浏览器工具。两者都不可用时，告诉用户这一点，改为逐条对照代码审查。

**分工**：audit 报的 error、reduced-motion 下停住不显示的内容、axe violation 先全部修掉，它们是客观缺陷，不需要讨论，也对应 [award-criteria.md](references/award-criteria.md) 里的红线；warning 逐条判断，确认是有意为之的可以保留，但要说明理由。截图交给你判断脚本做不到的事情：构图、层级、概念是否贯穿、有没有模板感。

### 找一个独立评委

自己写的页面自己打分，很容易因为"知道想做什么"而以为已经做到了。所以每轮打分时，另外开一个子 agent 做独立评审，只给它三样东西：

- 截图（包括 squint 图和 overview 图）；
- 1.2 的概念翻译表；
- [references/award-criteria.md](references/award-criteria.md) 的锚点和红线。

**不要给它代码**，它要看的就是用户能看到的东西。让它按九个维度打分并写出证据，然后和自评对比：差 1.5 分以上的维度要重新检查，通常是自评偏高。有条件时，让它直接指出"第一眼落在哪里"和"遮住 logo 后像不像模板"。

### 每一轮

1. **截图 + 审计**：运行上面的命令，每轮换一个输出目录（`shots/r1`、`shots/r2`），这样能对比前后变化，交付时也能展示改了哪里。页面有交互（悬停、拖动、切换）时，再用浏览器工具实际操作一遍。
2. **逐维度打分**：读取 [references/review-checklist.md](references/review-checklist.md)，结合 audit 结果和截图，对九个维度各打 1–10 分。分数按 [references/award-criteria.md](references/award-criteria.md) 的锚点给，每个分数都要附证据（哪张截图、哪个区域或哪条 audit 结果），没有证据最高 7 分；然后算出加权总分。为每个低于 9 分的维度写出**具体的、可执行的**问题（"标题行高 1.5 太松，展示字号应收到 1.05"，而不是"排版可以更好"）。清单里标 ⚠ 的"常见坑"中，脚本查不到的部分要人工逐条检查；清单末尾的"渲染验证的注意事项"也要读，截图里看到的异常可能只是测试环境造成的假象。
3. **按影响排序、批量修改**：先修 audit error 和影响整体印象的大问题（层级、构图、配色），再修细节（间距、过渡、对齐）。**一轮里把发现的问题集中改完，再进入下一轮**，不要改一处截一次图。

### 迭代预算

自检很有价值，但每一轮都有成本，要把力气花在用户真正关心的地方：

- **默认 2 轮，最多 3 轮。** 第 3 轮只修上一轮新引入的问题，或者仍然低于 8 分的维度。
- **概念不行就重构，别打磨。** 第 1 轮结束时，如果原创性或视觉层级低于 7 分，第 2 轮直接重做首屏构图或签名时刻（回到 1.2 的翻译表），而不是修间距和细节。
- 用户只要一张效果图、一个快速原型，或者明确说"别太久"时：做 1 轮完整自检，只修 audit error 和最明显的视觉问题。
- 用户要求精益求精、打磨到极致时，可以超过 3 轮，但每一轮都要说清楚这轮在改什么。

**何时停止**（在预算之内）：
- audit 没有 error，剩下的 warning 都确认是有意为之；
- 没有触发任何红线，加权总分 ≥ 8.5 且没有维度低于 8，剩下的意见只是口味偏好，不是缺陷；
- 最近一轮截图里找不到能明确指出的问题。

预算用完但还没达标时，就停下来交付，并如实列出还差在哪里。受限于条件的问题（比如缺少真实图片素材、品牌字体未授权）也记下来，写进交付说明，不要无限循环。

## 4. 交付时告诉用户

简短说明：
- 设计概念和关键取舍（字体、色彩、签名时刻）；
- 自检进行了几轮，每轮主要改了什么，最终各维度得分、加权总分和 audit 结果；
- 如果还有提升空间，列出**影响最大的三项修改**，并说明每项预计能让哪个维度提高多少；
- 仍可进一步提升但需要用户提供的东西（真实文案、摄影、品牌资产等）。