award-level-web-design git:20261013.551b1afA

Immutable. This exact content never changes and is served at /api/v1/blob/ce0ad824af5c6adc.

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

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

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

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

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

先花几分钟想清楚，再写代码。用两三句话写下（可以直接告诉用户）：

- **概念**：这个页面的一句话创意是什么？（例："像一本慢慢翻开的旧杂志""工业仪表盘般精确冷静"）。概念决定后面所有取舍。
- **字体方案**：一个有性格的展示字体 + 一个高可读的正文字体。中文页面同样需要考虑中文字体与西文字体的搭配和字重。
- **色彩方案**：一个主色调 + 中性色阶 + 最多一个强调色，用 CSS 变量定义。
- **版式骨架**：网格（例如 12 栏）、间距刻度（例如 4/8 的倍数）、字号比例（例如 1.25 或 1.333 的模数比例）。
- **签名时刻**：至少一处让人记住的设计（独特的首屏构图、一个精心编排的滚动叙事、一个巧妙的交互），这是原创性的来源。

避开"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`；首屏不要被重型动画库拖慢。

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

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

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

skill 自带两个脚本（需要 Node 22+ 和本机的 Chrome / Edge / Chromium）：

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

- `shoot.mjs`：一次截完 375 / 768 / 1440 / 1920 四个宽度的首屏，以及 `--sections` 指定的区块（加 `--full` 还会截整页）。它会等页面加载、字体就绪、入场动画结束，避开"空白页""内容发灰"之类的截图假象。
- `--audit` 会在每个宽度运行 `scripts/audit.js`，自动报告**横向溢出、文字对比度、点击区尺寸、中文字体回退、标题孤字、图片缺尺寸、缺少减弱动效规则**，结果存为 `audit.json`。
- 用不了脚本时（例如没有本地 Chrome），把 `audit.js` 的全部内容放进任意浏览器工具的 JS 控制台执行，最后一个表达式就是报告；截图改用手头的浏览器工具。两者都不可用时，告诉用户这一点，改为逐条对照代码审查。

**分工**：audit 报的 error 先全部修掉，它们是客观缺陷，不需要讨论；warning 逐条判断，确认是有意为之的可以保留，但要说明理由。截图交给你判断脚本做不到的事情：构图、层级、概念是否贯穿、有没有模板感。

### 每一轮

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

### 迭代预算

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

- **默认 2 轮，最多 3 轮。** 第 3 轮只修上一轮新引入的问题，或者仍然低于 9 分的维度。
- 用户只要一张效果图、一个快速原型，或者明确说"别太久"时：做 1 轮完整自检，只修 audit error 和最明显的视觉问题。
- 用户要求精益求精、打磨到极致时，可以超过 3 轮，但每一轮都要说清楚这轮在改什么。

**何时停止**（在预算之内）：
- audit 没有 error，剩下的 warning 都确认是有意为之；
- 八个维度都 ≥ 9 分，剩下的意见只是口味偏好，不是缺陷；
- 最近一轮截图里找不到能明确指出的问题。

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

## 4. 交付时告诉用户

简短说明：
- 设计概念和关键取舍（字体、色彩、签名时刻）；
- 自检进行了几轮，每轮主要改了什么，最终各维度得分和 audit 结果；
- 仍可进一步提升但需要用户提供的东西（真实文案、摄影、品牌资产等）。