frontend-design-review

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

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。

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

Tweaks 的核心约束：

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

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

步骤 4：生成差距清单

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

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

### 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（横切常驻）