SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场web-design-reviewer

web-design-reviewer

设计与创作

查看项目

更新于 10-15 15:18

技能介绍

用途

Web Design Reviewer 是一项用于对网站设计质量进行可视化检查与验证的技能，能够识别设计问题并在源代码层面进行修复。

它适用于以下范围：

  • 静态站点（HTML/CSS/JS）
  • SPA 框架，如 React / Vue / Angular / Svelte
  • 全栈框架，如 Next.js / Nuxt / SvelteKit
  • CMS 平台，如 WordPress / Drupal
  • 任何其他 Web 应用

前提条件

必需条件：

  • 目标网站必须正在运行，例如本地开发服务器（如 http://localhost:3000）、预发布环境或生产环境（用于只读评审）
  • 必须具备浏览器自动化能力：截图捕获、页面导航、DOM 信息获取
  • 需要访问源代码（在进行修复时）
  • 项目必须存在于工作区内

工作流程

整体流程分为四步，并在发现问题时循环：步骤 1 信息收集 → 步骤 2 可视化检查 → 步骤 3 问题修复 → 步骤 4 重新验证；若仍有问题则回到步骤 2，否则生成完成报告。

步骤 1：信息收集

1.1 URL 确认：如果未提供 URL，询问用户提供要评审的网站 URL（例如 http://localhost:3000）。

1.2 了解项目结构：在进行修复时收集框架（React / Vue / Next.js 等）、样式方式（CSS / SCSS / Tailwind / CSS-in-JS 等）、源文件位置（样式文件与组件位置）、评审范围（仅特定页面或整个站点）。

1.3 自动项目检测：尝试从工作区文件自动检测，检测目标包括 package.json（框架与依赖）、tsconfig.json（TypeScript 使用）、tailwind.config（Tailwind CSS）、next.config（Next.js）、vite.config（Vite）、nuxt.config（Nuxt）、src/ 或 app/（源目录）。

1.4 识别样式方式：纯 CSS（.css 文件，编辑全局 CSS 或组件 CSS）、SCSS/Sass（.scss、.sass，编辑 SCSS 文件）、CSS Modules（.module.css，编辑模块 CSS 文件）、Tailwind CSS（tailwind.config.*，编辑组件中的 className）、styled-components（代码中的 styled.，编辑 JS/TS 文件）、Emotion（@emotion/ 导入，编辑 JS/TS 文件）、其他 CSS-in-JS（内联样式，编辑 JS/TS 文件）。

步骤 2：可视化检查

2.1 页面遍历：导航到指定 URL、捕获截图、获取 DOM 结构/快照（如可能），如存在其他页面则通过导航遍历。

2.2 检查项按类别划分：

布局问题：元素溢出（内容从父元素或视口溢出，高严重度）、元素重叠（元素意外重叠，高）、对齐问题（网格或弹性布局对齐问题，中）、间距不一致（内边距/外边距不一致，中）、文本裁剪（长文本未正确处理，中）。

响应式问题：非移动友好（小屏幕布局破裂，高）、断点问题（屏幕尺寸变化时过渡不自然，中）、触摸目标（移动端按钮过小，中）。

无障碍问题：对比度不足（文本与背景对比度低，高）、无焦点状态（键盘导航时无法判断状态，高）、缺少 alt 文本（图片无替代文本，中）。

视觉一致性：字体不一致（混用字体系列，中）、颜色不一致（品牌色不统一，中）、间距不一致（相似元素间距不统一，低）。

2.3 视口测试（响应式）：在移动端 375px（代表 iPhone SE/12 mini）、平板 768px（iPad）、桌面 1280px（标准 PC）、宽屏 1920px（大显示器）进行测试。

步骤 3：问题修复

3.1 问题优先级：P1 立即修复（影响功能的布局问题）、P2 接下来修复（降低用户体验的视觉问题）、P3 如有可能则修复（轻微视觉不一致）。

3.2 定位源文件：可通过选择器搜索（按类名或 ID 搜索代码库，使用 grep_search 探索样式定义）、组件搜索（根据元素文本或结构识别组件，使用 semantic_search 探索相关文件）、文件模式过滤（样式文件 src//*.css、styles//；组件 src/components/**/；页面 src/pages/、app/）。

3.3 应用修复。框架特定的修复指南参见 references/framework-fixes.md。修复原则：最小改动（只做解决问题所需的最小更改）、尊重现有模式（遵循项目现有代码风格）、避免破坏性更改（注意不影响其他区域）、添加注释（在适当位置添加注释说明修复原因）。

步骤 4：重新验证

4.1 修复后确认：重新加载浏览器（或等待开发服务器 HMR）、对修复区域截图、对比修复前后。

4.2 回归测试：验证修复未影响其他区域、确认响应式显示未破坏。

4.3 迭代决策：若仍有问题则返回步骤 2，若无则进入完成报告。迭代限制：若某个具体问题需要超过 3 次修复尝试，咨询用户。

输出格式

评审结果报告包含：摘要（目标 URL、框架、样式方式、测试视口、检测到的问题数、已修复的问题数）、检测到的问题（按优先级列出标题、页面、元素、问题描述、修复文件、修复详情、修复前后截图）、未修复的问题（如有，列出原因与建议操作）、建议（未来改进建议）。

所需能力

  • 网页导航（访问 URL、页面跳转）：必需
  • 截图捕获（页面图像捕获）：必需
  • 图像分析（视觉问题检测）：必需
  • DOM 获取（页面结构获取）：推荐
  • 文件读写（源代码读取与编辑）：修复时必需
  • 代码搜索（项目内代码搜索）：修复时必需

参考实现

推荐使用 Playwright MCP 作为本技能的参考实现，对应工具：浏览 browser_navigate、快照 browser_snapshot、截图 browser_take_screenshot、点击 browser_click、调整尺寸 browser_resize、控制台 browser_console_messages。

配置示例（MCP 服务器）：

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest", "--caps=vision"]
    }
  }
}

其他兼容的浏览器自动化工具：Selenium（广泛的浏览器支持、多语言支持）、Puppeteer（专注 Chrome/Chromium、Node.js）、Cypress（易于与 E2E 测试集成）、WebDriver BiDi（标准化的下一代协议）。只要提供必要能力（导航、截图、DOM 获取），工具选择灵活。

最佳实践

推荐做法：始终在修复前保存截图；一次只修复一个问题并逐一验证；遵循项目现有代码风格；重大更改前与用户确认；详尽记录修复细节。

不推荐做法：未经确认进行大规模重构；忽视设计系统或品牌指南；忽视性能的修复；一次修复多个问题（难以验证）。

故障排查

问题：找不到样式文件。检查 package.json 中的依赖；考虑 CSS-in-JS 的可能性；考虑构建时生成的 CSS；询问用户样式方式。

问题：修复未生效。检查开发服务器 HMR 是否工作；清除浏览器缓存；若项目需要构建则重新构建；检查 CSS 特异性问题。

问题：修复影响其他区域。回滚更改；使用更具体的选择器；考虑使用 CSS Modules 或作用域样式；咨询用户确认影响范围。