| 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 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（视觉对标）
design-content（文案与信息层级）
design-harden（加固与边缘状态）
与参考站的 DOM 对比
当用户说"和参考站差太远"时，启动 DOM 对比流程：
- 用浏览器工具打开参考站和当前实现
- 对关键元素跑
getComputedStyle + getBoundingClientRect 对比
- 列出差异表：
| 维度 | 参考站 | 当前实现 | 差距 |
|------|--------|---------|------|
| Hero 字号 | 72px | 48px | +24px |
| 容器宽 | 1320px (82.5% vw) | 896px (52% vw) | +30% vw |
| 段间距 | 60px | 112px | -52px |
- 差异表直接转化为改动项，用选择题化让用户确认哪些要跟、哪些要保持
完成标准
与其他 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（横切常驻） |
