Frontend Design Review

---
name: frontend-design-review
description: 代码已经跑起来后（阶段 7 迭代微调）的设计评审横切——用户看到具体页面涌现审美反馈时使用：三段式追问（定位→对标→量化）把"感觉不对"翻译成可执行改动项，"选择题化"让用户做选择题而不是填空题，参数外显 Tweaks 让不确定的参数暴露成可调旋钮，所有修正反写回 design.md。覆盖 design-review（视觉对标）、design-content（文案与信息层级）、design-harden（边缘状态加固）三种子模式。**仅用于代码已生成后**——代码前的"感觉"引导走 frontend-interview-dualround 的后轮采访；纯调研走 frontend-design-research；写 design.md 走 frontend-design-writer。
---

<!-- PACKAGED_KNOWLEDGE_START -->
## Packaged Knowledge Snapshot

This packaged copy includes local note snapshots for portability.
When the original Obsidian absolute path is unavailable, use the packaged snapshot instead:

- `/Users/kunkun/note/01-AI工程/AI设计与前端/01-认知框架/AI前端设计认知框架.md` -> `references/packaged-knowledge/AI前端设计认知框架.md`
- `/Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/从参考案例复刻高级感：量化工作流.md` -> `references/packaged-knowledge/从参考案例复刻高级感：量化工作流.md`
- `/Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/参数外显与判断外显：评审的两条姊妹机制.md` -> `references/packaged-knowledge/参数外显与判断外显：评审的两条姊妹机制.md`
- `/Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/审美是隐性认知，追问是唯一的解压工具.md` -> `references/packaged-knowledge/审美是隐性认知，追问是唯一的解压工具.md`
<!-- PACKAGED_KNOWLEDGE_END -->

# Frontend Design Review

## 这个 skill 在做什么

把用户的"感觉不对"翻译成可执行的具体改动项。核心手法是**三段式追问 + 选择题化 + 参数外显 Tweaks**：AI 负责量化和出选项，用户只负责给感觉和做选择。

审美判断本质是隐性认知——用户自己也说不清，但一看到就知道对不对。要求用户一次性把所有审美标准讲清楚，是在要求一件物理上不可能的事。解压隐性认知的唯一工具是追问。

## 在阶段化流程里的位置

本 skill 严格绑定**阶段 7 迭代微调**（见 [[AI前端设计认知框架]]）。硬边界：

- **代码已生成**才进本 skill——阶段 6 之前用户看不到具体实现，不会涌现真实审美反馈
- **代码前**想引导用户定方向用 `frontend-interview-dualround`（产品设计师视角的双轮采访），不是本 skill

和老版的差异：老版三段式追问曾被当作"通用追问方法论"同时用在代码前和代码后——2026-04-21 重构后明确分工：代码前用 dualround 建立目标和边界，代码后用本 skill 做纠偏。

## 何时进入本 skill

**要进**：
- 用户看到前端实现说"感觉不对" / "差点意思" / "不够高级" / "不对但说不出来"
- 用户要求"review 一下这个页面" / "帮我评审前端"
- 前端实现一轮探索完成，进入阶段 7 精调
- 用户说"文案像 AI 写的" / "信息层级不对" / "边缘状态没覆盖"
- 前端设计剧本阶段 7 自动路由到本 skill

**不要进**：
- 还在调研阶段（没代码可评审）→ 走 `frontend-design-research`（阶段 2）
- 代码前想把用户的模糊诉求拔清楚 → 走 `frontend-interview-dualround`（阶段 1 前轮 / 阶段 3 后轮）
- 还没有 design.md 可对标 → 走 `frontend-design-writer`
- 纯功能 bug（按钮不工作、API 报错）→ 走调试排查剧本
- 用户已经给出明确改动指令（"把标题改成 32px"）→ 直接改

## 知识库依赖

| 文件 | 用途 | 何时读 |
|------|------|--------|
| `/Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/审美是隐性认知，追问是唯一的解压工具.md` | 三段式追问完整方法论 + 选择题化模式 + 高级感维度拆解 | **启动必读** |
| `/Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/参数外显与判断外显：评审的两条姊妹机制.md` | 参数外显 Tweaks 协议（把不确定参数暴露为可调旋钮） | **启动必读** |
| `/Users/kunkun/note/01-AI工程/AI设计与前端/02-执行方法/从参考案例复刻高级感：量化工作流.md` | DOM 量化测量法、浏览器工具陷阱 | 需要和参考站做 DOM 对比时读 |
| `/Users/kunkun/note/01-AI工程/AI设计与前端/01-认知框架/AI前端设计认知框架.md` | 阶段 7 反馈驱动迭代机制、两类项目（展示型/工具型）的评审重点 | 启动时扫一遍阶段 7 段落 |

启动时拉前两份，其他按需读。

## 核心分工

| 角色 | 负责 | 不负责 |
|------|------|--------|
| **用户** | 感觉判断（"这里不对"、"这个好"、"那个糟"） | 说清楚为什么、提供参数、写标准 |
| **AI** | 把感觉追问成具体维度 + 参数 + 可执行改动 | 自己判断什么好看 |

**感觉是用户的活，量化是 AI 的活。** 不要让用户写像素值，也不要让 AI 自己判断审美。

## 步骤 0：判断评审模式

根据用户的描述或当前阶段，选择进入哪种模式。一次评审可以切换模式。

| 模式 | 触发信号 | 重点 |
|------|---------|------|
| **design-review** | "感觉不对" / "不够高级" / "review this page" / "和 DESIGN.md 对一下" | 视觉对标 DESIGN.md + 参考站 |
| **design-content** | "文案像 AI 生成的" / "信息层级不对" / "utility copy check" | 文案、信息架构、阅读节奏 |
| **design-harden** | "加固" / "check edge cases" / "mobile version" / "motion check" | 边缘状态、响应式、动效正确性 |

不确定时默认 **design-review**。

---

## 步骤 1：定位（Where）

从用户的"不对"开始，先缩小范围。

**好的追问**：
- "是整体不对还是某个 section 不对？"
- "你视线第一眼落在哪里？那个地方对不对？"
- "最不对的地方能截图框一下吗？"
- "如果满分 10 分，现在打几分？最差的部分打几分？"

**坏的追问**（避免）：
- "具体哪里不对？"（太开放，用户答不了）
- "是字体问题吗？"（过早窄化，可能漏掉真正原因）
- "你觉得应该改什么？"（把量化工作推给用户）

**定位的目标**：从"整体感觉不对"收窄到"某个 section / 某个元素 / 某个维度"。

---

## 步骤 2：对标（Against What）

知道哪里不对后，找到用户心里的参照物。

**好的追问**：
- "和参考站的哪个地方对比起来不对？"
- "你心里理想的它应该像什么？能指个具体例子吗？"
- "你觉得它更像 A 还是 B？"（给出两个具体参考截图或 URL）
- "DESIGN.md 里的约束是这样写的：[读出来]，你觉得现在的实现离这个约束差多远？"

**坏的追问**（避免）：
- "你希望它是什么风格？"（要求用户生成二阶描述——抽象的形容词）
- "能形容一下理想状态吗？"（要求用户组织语言描述视觉——隐性认知做不到）

**对标的目标**：找到一个可比较的锚点（参考站的某个区段 / DESIGN.md 的某条约束 / 之前某版截图）。

---

## 步骤 3：量化（How Much）— 选择题化

知道哪里不对 + 和什么比之后，AI 测量当前状态，给出 2-3 个量化选项让用户选。

**选择题化模式**（本 skill 的标志性手法）：

当用户说"布局太松散"时：
```
AI：我量了下当前布局：
- 容器宽 896px（视口 1728 的 52%）
- 段间距 112px
- 标题到正文 48px

你觉得应该：
A) 容器收到 768px，段间距减到 56px（收紧约 30%）
B) 容器保持，只减段间距到 56px（只收竖向）
C) 容器收到 640px，段间距减到 40px（大幅收紧，类似 Dragonfly）

更接近哪个？
```

**好的追问**：
- "字号要大 2 档还是 3 档？（26 → 34 还是 26 → 40）"
- "这段文字应该占屏幕左右多少？大约一半还是三分之二？"
- "动效触发时机比现在早一点还是晚一点？"
- 所有选项必须**带具体参数**，不是"大一点""小一点"

**坏的追问**（避免）：
- "字号应该是多少？"（用户不是设计师，给不出像素数）
- "你觉得合适的比例是？"（太抽象）
- "应该怎么改？"（把全部工作推给用户）

**量化的目标**：从选择中得到一个可执行的改动项（具体参数 + 改动范围）。

---

## 步骤 3.5：参数外显 Tweaks（替代"直接定死"）

当某个参数用户没把握时，不要让用户做一次性拍板，也不要 AI 自己定死——把不确定参数暴露成**可调旋钮**让用户连续调几轮再收敛。

典型例子：用户说"hero 标题字号感觉不对"但说不清要 48 还是 64。

```markdown
## Tweak T01：Hero 标题字号
当前：48px
候选区间：[40px, 56px, 64px, 72px]
调整方式：我把四个值各实现一版给你看，你选；或者你给一个你心里的词（"更沉""更炸"），我映射成参数
反写：确认后写回 design.md §3 Typography 的 Display XL
```

Tweaks 的核心约束：
- **参数明码**——给具体数值区间，不写"再大一点"
- **映射协议**——用户说"更沉/更炸"这类感觉词时，AI 要明确映射到哪个参数维度
- **收敛必反写**——Tweak 定版后必须反写回 design.md，不能只留在对话

完整 Tweaks 协议见 [[参数外显与判断外显：评审的两条姊妹机制]]。

## 步骤 4：生成差距清单

完成一轮或多轮追问后，整理所有发现为差距清单：

```markdown
## 评审差距清单 — [日期]

### P0（必须改，影响整体品质）
- [ ] Hero 标题字号 48px → 64px，匹配 DESIGN.md §3 Display XL 定义
- [ ] 段间距 112px → 56px，匹配参考站 Dragonfly 的节奏

### P1（应该改，提升细节）
- [ ] CTA 按钮 radius 8px → 4px，匹配 §4 Components 的 sharp 约定
- [ ] 文案"了解更多"→"查看项目详情"，具体化 CTA

### P2（可选改进）
- [ ] 背景 #0A0A0A → #000000，纯黑匹配 §2 Color 定义
```

每一条改动必须是**可执行的**（有具体参数），不是"再好看点"。

---

## 各模式 Checklist

### design-review（视觉对标）

- [ ] 第一屏有唯一主视觉焦点（不是三个同等大的东西）
- [ ] 品牌或产品身份足够明确（遮住 logo 能认出是谁吗）
- [ ] 整体结构一眼能扫懂（F 型 / Z 型 / 叙事型）
- [ ] 没有滑向套路 hero + 默认字体 + 卡片栅格
- [ ] 文案像真实产品语言，不像 prompt 生成物
- [ ] 动效在增强层级，不是制造噪音
- [ ] 配色与 DESIGN.md §2 的 token 一致
- [ ] 字体层级与 DESIGN.md §3 的 hierarchy 表一致
- [ ] 间距节奏与 DESIGN.md §5 的 spacing scale 一致
- [ ] 和主参考站同屏对比，气质差距在可接受范围

### design-content（文案与信息层级）

- [ ] 标题是事实陈述不是夸张（"高效管理" vs "管理效率提升 300%"）
- [ ] CTA 具体化（"查看方案详情" vs "了解更多"）
- [ ] 标签和分类词准确反映内容
- [ ] 错误提示有用且友好（告诉用户怎么修，不只说"出错了"）
- [ ] 空状态有引导（不是白屏）
- [ ] 数字和度量有单位和上下文
- [ ] 信息密度适合目标读者（新手 vs 专业用户）
- [ ] 阅读节奏：标题→正文→CTA 的视觉权重递减

### design-harden（加固与边缘状态）

- [ ] loading / empty / error / success / partial 五种状态都有对应 UI
- [ ] 所有 breakpoint 下布局不崩（Mobile Small → Large Desktop）
- [ ] 展示型核心动效双向性正确（滚回去会逆放，不是定住不动）
- [ ] 没有 `whileInView` + `once: true` 用于核心动效
- [ ] 长文本不溢出（标题 30 字以上、正文 500 字以上）
- [ ] 零数据状态（0 个项目、0 条记录）有引导
- [ ] 大数字不破版（价格 999,999、列表 1000+ 条）
- [ ] 图片加载失败有 fallback
- [ ] 移动端触摸目标 ≥ 44px
- [ ] 真实数据（不是 Lorem ipsum）跑过一遍

---

## 与参考站的 DOM 对比

当用户说"和参考站差太远"时，启动 DOM 对比流程：

1. 用浏览器工具打开参考站和当前实现
2. 对关键元素跑 `getComputedStyle` + `getBoundingClientRect` 对比
3. 列出差异表：

```
| 维度 | 参考站 | 当前实现 | 差距 |
|------|--------|---------|------|
| Hero 字号 | 72px | 48px | +24px |
| 容器宽 | 1320px (82.5% vw) | 896px (52% vw) | +30% vw |
| 段间距 | 60px | 112px | -52px |
```

4. 差异表直接转化为改动项，用选择题化让用户确认哪些要跟、哪些要保持

---

## 完成标准

- [ ] 差距清单已生成，每项都是可执行的具体修改（有参数，不是"再好看点"）
- [ ] 差距清单按 P0/P1/P2 排序
- [ ] 用户确认改动优先级
- [ ] P0 项全部执行后，用户确认"方向对了"
- [ ] **所有确认的修正反写回 `knowledge/design-docs/design.md`**——Tweak 定版、token 改动、动效调整都必须反写，不能只留在对话里

## 与其他 skill / 剧本的边界

| 场景 | 走谁 |
|------|------|
| **已定稿项目的二开 / 增量扩展**（本 skill 会被 iteration-planner 的 T1/T2/T3 各档在阶段 7 统一调用） | `frontend-iteration-planner`（场景 C 入口） |
| 代码前用户诉求模糊，想拔清楚架构/文案调性 | `frontend-interview-dualround`（前轮/后轮采访） |
| 还没有代码实现，在阶段 2 调研 | `frontend-design-research` |
| 还没有 design.md，没有评审基准 | `frontend-design-writer` |
| 评审完发现主语言本身定错了 | 回到 `frontend-design-research` 步骤 1 重新收敛主语言 |
| 评审完发现动效采访不充分 | 回到 `frontend-design-research` 动效采访段 |
| 评审完发现视觉方向本身不对 | 回到 `frontend-visual-reference`（阶段 4）重跑 Moodboard |
| 评审完差距清单确认了，要改代码 | 开发实现剧本 |
| 纯功能 bug、API 报错 | 调试排查剧本 |
| 阶段 6 反 slop 硬禁令扫描 | `frontend-anti-slop-gate`（横切常驻） |