根据设计简报和代码库进行结构化设计评审。检查视觉层次、一致性、响应式设计、可访问性和美学还原度。当用户希望进行设计评审、批评、QA验收、润色验收，或在构建后提到“review”时使用。
此技能对已构建的内容进行结构化设计评审，对照设计简报和所选美学理念进行评估。
关键——视觉截图捕获
每次设计评审都必须捕获运行中应用的截图。仅靠代码审查是不够的——你需要看到用户所看到的。请遵循下面第3步中的截图捕获协议。这是强制性的。
示例提示
- "Review what I just built"
- "Run a design critique on the landing page"
- "Check this against the brief"
- "Here's a screenshot. How does it look?" [粘贴截图]
- "QA pass before I ship this"
流程
-
阅读简报。 在
.design/<feature-slug>/DESIGN_BRIEF.md中查找当前功能的简报。如果.design/下存在多个功能文件夹，询问用户要评审哪个功能。如果.design/文件夹不存在，则回退到项目根目录下的DESIGN_BRIEF.md。如果两者都不存在，询问用户预期的设计方向。 -
探索已构建的代码。 检查所有创建或修改的组件、页面和样式文件。特别关注：
- 所有新增或修改的组件及其与现有组件的关系
- Token/变量使用情况：组件是使用共享 token 还是硬编码值？
- 应合并的重复组件
- 文件命名和组织：新文件是否遵循项目约定？
- 了解实际构建的内容，而非计划的内容。
-
捕获运行中应用的截图。
此步骤必须执行。不要跳过。不要仅依赖用户提供的截图。
截图工具优先级
按顺序尝试每个选项。使用第一个可用的：
- Playwright MCP（首选）。 检查
plugin-playwright-playwrightMCP 服务器是否可用。如果可用，使用它——它可以精确控制视口大小、全页捕获和文件命名。 - Cursor IDE 浏览器（第二选择）。 如果 Playwright MCP 不可用，使用
cursor-ide-browserMCP 服务器的browser_take_screenshot工具。它具有相同的核心功能。 - 询问用户（最后手段）。 如果 MCP 服务器和应用内浏览器都不可用，你必须要求用户手动提供截图。具体说明你需要的内容：
- "我没有浏览器工具。要完成视觉评审，我需要运行中应用的截图。请提供："
- 桌面宽度（1280px）的全页截图
- 平板宽度（768px）的全页截图
- 手机宽度（375px）的全页截图
- 深色模式变体（如适用）
- 任何你想评审的特定组件或交互状态
- 要求用户直接在聊天中粘贴/附加图片，或自行保存到
screenshots/文件夹。 - 不要跳过视觉评审。 等待用户提供截图后再继续检查清单。
截图保存位置
所有截图必须保存到功能
.design/目录下的screenshots/子文件夹中——即DESIGN_BRIEF.md和其他设计流程文件所在的同一文件夹。路径模式：
.design/<feature-slug>/screenshots/如果简报位于
.design/onboarding-flow/DESIGN_BRIEF.md，截图保存到.design/onboarding-flow/screenshots/。如果文件夹不存在则创建。如果
.design/文件夹不存在（遗留项目或独立评审），回退到项目根目录下的screenshots/文件夹。使用描述性文件名，编码捕获的内容：
.design/ └── onboarding-flow/ ├── DESIGN_BRIEF.md ├── DESIGN_REVIEW.md └── screenshots/ ├── review-homepage-desktop-1280.png ├── review-homepage-tablet-768.png ├── review-homepage-mobile-375.png ├── review-homepage-dark-mode-desktop-1280.png └── review-card-component-hover.png截图捕获协议
a. 导航到应用。 如果项目中没有明确说明（例如
http://localhost:3000），询问用户 URL。使用browser_navigate打开它。b. 捕获响应式断点。 至少为每个关键页面/视图捕获以下三个视口：
断点 宽度 × 高度 文件名后缀 手机 375 × 812 -mobile-375平板 768 × 1024 -tablet-768桌面 1280 × 800 -desktop-1280在每次截图前使用
browser_resize设置视口。使用browser_take_screenshot并设置fullPage: true捕获整个可滚动页面，并通过filename参数保存到screenshots/文件夹。Playwright MCP 示例序列（假设功能 slug 为
onboarding-flow）：1. browser_navigate → { url: "http://localhost:3000" } 2. browser_resize → { width: 1280, height: 800 } 3. browser_take_screenshot → { type: "png", filename: ".design/onboarding-flow/screenshots/review-homepage-desktop-1280.png", fullPage: true } 4. browser_resize → { width: 768, height: 1024 } 5. browser_take_screenshot → { type: "png", filename: ".design/onboarding-flow/screenshots/review-homepage-tablet-768.png", fullPage: true } 6. browser_resize → { width: 375, height: 812 } 7. browser_take_screenshot → { type: "png", filename: ".design/onboarding-flow/screenshots/review-homepage-mobile-375.png", fullPage: true }c. 捕获交互状态（相关时）。
- 按钮、卡片、链接的悬停状态
- 表单字段的聚焦状态
- 下拉菜单、模态框、菜单的打开状态
- 表单的错误/成功状态
- 加载和空状态
d. 捕获深色模式（如果项目支持）。 切换深色模式，并在文件名中添加
-dark-mode重复响应式断点捕获。e. 捕获特定组件。 如果评审聚焦于某个特定组件，使用
element和ref参数仅截图该元素。分析每张截图
捕获后，对照设计简报视觉分析每张截图。对于每张截图：
- 与简报的美学方向比较
- 检查视觉层次：最重要的元素是否最突出？
- 检查间距一致性：边距和内边距是否均匀且有意为之？
- 检查颜色：调色板是否匹配简报的方向？
- 检查排版：字体大小、粗细和间距在视觉上是否正确？
- 检查响应式适配：布局是否适当重组（而不仅仅是缩小）？
- 记录仅靠代码审查无法发现的渲染问题（字体加载失败、图片损坏、布局溢出、z-index 问题、border-radius 错误、颜色不匹配）
在评审输出中通过文件名引用特定截图，以便发现可追溯。
- Playwright MCP（首选）。 检查
-
运行下面的评审检查清单。 对于每个类别，记录哪些通过，哪些需要改进。要具体。引用确切的组件、文件、行号和截图文件名。
-
生成优先级改进列表。 按严重程度分组问题：
- 必须修复：功能损坏、可访问性失败、与简报的重大偏差。
- 应该修复：不一致、缺失状态、响应式问题。
- 可以改进：润色、动画优化、排版微调。
-
将评审保存为功能
.design/<feature-slug>/文件夹中的DESIGN_REVIEW.md（与DESIGN_BRIEF.md相邻）。如果.design/文件夹不存在，保存到项目根目录。包含一个“已捕获截图”部分，列出所有截图的路径。如果用户喜欢，也可以直接呈现评审内容。
评审检查清单
视觉层次
- 最重要的内容在每个页面/视图上是否最突出？
- 字体层级是否创建了清晰的优先级（标题、副标题、正文、说明文字）？
- 交互元素（按钮、链接、输入框）是否有足够的视觉重量，无需寻找即可发现？
- 是否有清晰的阅读顺序？能否追踪视线首先、其次、第三落在哪里？
一致性
- 间距值是否一致？对照已建立的尺度（4px/8px 基础或项目使用的其他尺度）检查内边距和边距。
- 颜色使用是否一致？检查相同的语义含义是否始终映射到相同的颜色（主要操作、错误、成功状态、禁用状态）。
- border-radius、阴影值和字体大小是否来自共享集合，还是存在一次性值？
- 类似组件是否看起来和行为相似？（例如，所有卡片、所有表单字段、所有同一类别的按钮。）
美学还原度
- 实现是否匹配简报中命名的理念？
- 看到这个的人是否能立即识别出预期的美学方向？
- 是否存在破坏美学的元素（在原本独特的界面中的通用组件、冲突的字体、不协调的颜色）？
- 细节水平是否与理念匹配？（极简设计不应有不必要的装饰。极繁设计不应有空旷、未完成的区域。）
组件质量
- 代码库中的现有组件是否正确显示，还是被重新实现了？
- 新组件是否遵循与现有组件相同的 API 模式（props、命名、文件组织）？
- 是否存在应合并的重复组件？
状态和交互
- 交互元素是否具有所有必要状态：默认、悬停、聚焦、激活、禁用？
- 表单字段是否有以下状态：空、已填写、错误、成功、禁用？
- 是否处理了加载状态？空状态？
- 过渡和动画是否匹配理念的运动指南？
- 每个用户操作是否有视觉反馈？
响应式行为
- 布局是否在手机（375px）、平板（768px）和桌面（1280px+）上正常工作？
- 组件是否适当适配？（不仅仅是缩小，而是在需要时重组。）
- 手机上的触摸目标尺寸是否足够（最小 44x44px）？
- 文本在所有断点下是否保持可读？没有太小文本，没有太宽行（最多 65-75 字符）。
可访问性
- 颜色对比度：文本/背景组合是否满足 WCAG AA（正文 4.5:1，大文本 3:1）？
- 键盘导航：每个交互元素是否可以通过键盘单独到达和激活？
- 焦点指示器：焦点环是否可见且样式一致？
- 语义 HTML：标题顺序是否正确？是否使用了地标（main、nav、header、footer）？表单标签是否关联？
- 屏幕阅读器：图片是否有替代文本？图标是否有标签？装饰性元素是否对辅助技术隐藏？
- 运动：是否有针对需要减少运动的用户的
prefers-reduced-motion媒体查询？
排版
- 字体是否实际加载？（检查 FOIT/FOUT 闪烁。）
- 行长度是否适合阅读（正文 45-75 字符）？
- 行高是否合适（正文 1.4-1.6，标题更紧凑）？
- 字体层级是否有意为之，还是存在任意大小？
深色模式
- 如果项目有深色模式 token，是否正确应用？
- 所有颜色值是否使用 CSS 变量（而不是不会切换的硬编码十六进制值）？
- 深色调色板是否对所选理念感觉有意为之，还是简单的反转？
- 阴影是否针对深色模式进行了调整（更暗、更透明）？
- 强调色在深色背景上是否保持足够的对比度？
- 是否有可用的切换机制或
prefers-color-scheme支持？
移动优先
- 布局是否以移动优先构建（使用
min-width媒体查询，而不是max-width）？ - 移动布局在 375px 下是否无需水平滚动即可工作？
- 导航是否针对移动端适配（不仅仅是溢出的桌面导航）？
- 触摸目标是否至少 44x44px？
- 移动端正文文本是否至少 16px？
输出格式
# 设计评审：[功能/页面名称]
对照：DESIGN_BRIEF.md
理念：[命名理念]
日期：[日期]
## 已捕获截图
| 截图 | 断点 | 描述 |
| -------------------------------------------- | ------------------ | --------------- |
| `screenshots/review-[page]-desktop-1280.png` | 桌面 (1280×800) | [显示内容] |
| `screenshots/review-[page]-tablet-768.png` | 平板 (768×1024) | [显示内容] |
| `screenshots/review-[page]-mobile-375.png` | 手机 (375×812) | [显示内容] |
> 所有截图位于 `.design/<feature-slug>/screenshots/`。
## 总结
[2-3 句关于整体质量和最大发现的描述。]
## 必须修复
1. **[问题]**：[具体描述，引用文件/组件]。参见 [`screenshots/[relevant-screenshot].png`]。_修复：[具体建议]。_
## 应该修复
1. **[问题]**：[描述]。参见 [`screenshots/[relevant-screenshot].png`]。_修复：[建议]。_
## 可以改进
1. **[问题]**：[描述]。_建议：[想法]。_
## 做得好的方面
[指出实现中最强的方面。这不是填充。设计师需要知道哪些应该继续保持。]
