Help us improve
Share bugs, ideas, or general feedback.
Translates "feels wrong" into actionable design changes via structured questioning, multiple-choice options, and exposed parameter tweaks. For post-implementation visual review only.
npx claudepluginhub kkunkunya/ai-frontend-design-kit --plugin ai-frontend-design-kitHow this skill is triggered — by the user, by Claude, or both
Slash command
/ai-frontend-design-kit:frontend-design-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- PACKAGED_KNOWLEDGE_START -->
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
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把用户的"感觉不对"翻译成可执行的具体改动项。核心手法是三段式追问 + 选择题化 + 参数外显 Tweaks:AI 负责量化和出选项,用户只负责给感觉和做选择。
审美判断本质是隐性认知——用户自己也说不清,但一看到就知道对不对。要求用户一次性把所有审美标准讲清楚,是在要求一件物理上不可能的事。解压隐性认知的唯一工具是追问。
本 skill 严格绑定阶段 7 迭代微调(见 [[AI前端设计认知框架]])。硬边界:
frontend-interview-dualround(产品设计师视角的双轮采访),不是本 skill和老版的差异:老版三段式追问曾被当作"通用追问方法论"同时用在代码前和代码后——2026-04-21 重构后明确分工:代码前用 dualround 建立目标和边界,代码后用本 skill 做纠偏。
要进:
不要进:
frontend-design-research(阶段 2)frontend-interview-dualround(阶段 1 前轮 / 阶段 3 后轮)frontend-design-writer| 文件 | 用途 | 何时读 |
|---|---|---|
/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 自己判断审美。
根据用户的描述或当前阶段,选择进入哪种模式。一次评审可以切换模式。
| 模式 | 触发信号 | 重点 |
|---|---|---|
| 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。
从用户的"不对"开始,先缩小范围。
好的追问:
坏的追问(避免):
定位的目标:从"整体感觉不对"收窄到"某个 section / 某个元素 / 某个维度"。
知道哪里不对后,找到用户心里的参照物。
好的追问:
坏的追问(避免):
对标的目标:找到一个可比较的锚点(参考站的某个区段 / DESIGN.md 的某条约束 / 之前某版截图)。
知道哪里不对 + 和什么比之后,AI 测量当前状态,给出 2-3 个量化选项让用户选。
选择题化模式(本 skill 的标志性手法):
当用户说"布局太松散"时:
AI:我量了下当前布局:
- 容器宽 896px(视口 1728 的 52%)
- 段间距 112px
- 标题到正文 48px
你觉得应该:
A) 容器收到 768px,段间距减到 56px(收紧约 30%)
B) 容器保持,只减段间距到 56px(只收竖向)
C) 容器收到 640px,段间距减到 40px(大幅收紧,类似 Dragonfly)
更接近哪个?
好的追问:
坏的追问(避免):
量化的目标:从选择中得到一个可执行的改动项(具体参数 + 改动范围)。
当某个参数用户没把握时,不要让用户做一次性拍板,也不要 AI 自己定死——把不确定参数暴露成可调旋钮让用户连续调几轮再收敛。
典型例子:用户说"hero 标题字号感觉不对"但说不清要 48 还是 64。
## Tweak T01:Hero 标题字号
当前:48px
候选区间:[40px, 56px, 64px, 72px]
调整方式:我把四个值各实现一版给你看,你选;或者你给一个你心里的词("更沉""更炸"),我映射成参数
反写:确认后写回 design.md §3 Typography 的 Display XL
Tweaks 的核心约束:
完整 Tweaks 协议见 [[参数外显与判断外显:评审的两条姊妹机制]]。
完成一轮或多轮追问后,整理所有发现为差距清单:
## 评审差距清单 — [日期]
### 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 定义
每一条改动必须是可执行的(有具体参数),不是"再好看点"。
whileInView + once: true 用于核心动效当用户说"和参考站差太远"时,启动 DOM 对比流程:
getComputedStyle + getBoundingClientRect 对比| 维度 | 参考站 | 当前实现 | 差距 |
|------|--------|---------|------|
| Hero 字号 | 72px | 48px | +24px |
| 容器宽 | 1320px (82.5% vw) | 896px (52% vw) | +30% vw |
| 段间距 | 60px | 112px | -52px |
knowledge/design-docs/design.md——Tweak 定版、token 改动、动效调整都必须反写,不能只留在对话里| 场景 | 走谁 |
|---|---|
| 已定稿项目的二开 / 增量扩展(本 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(横切常驻) |