技能介绍

先解决什么

响应式布局的回归往往不是「某个断点坏了」这么简单，而是坏在两个断点之间的某个宽度上：导航在 960px 附近从汉堡菜单切回完整菜单、栅格在 760px 附近开始挤压、CTA 在 360px 处被挤出首屏。人工逐档截图要记录大量中间状态，容易漏掉过渡区间，也很难系统化地把 8 类问题都过一遍。

Responsiveness Check 把这件事变成一条可重复的流水线：在单一浏览器会话里按断点逐档调整宽度、截图、跑固定检查项，最后给出每个过渡发生的精确宽度和严重级别。

核心能力与工作流

浏览器工具探测。 按 playwright-cli → Playwright MCP → Chrome MCP 的优先级选择执行通道；没有可用工具时会先提示安装，再开始检测。

三种检查模式。

标准检查：8 个关键断点（320/375/768/1024/1280/1440/1920/2560），覆盖从手机到宽屏的设备谱系
扫描（Sweep）：从 320 到 2560 每 160px 一档共 15 个宽度，用于定位布局坏掉的精确宽度（开始前会确认，截图较多）
目标区间：用户指定范围后按 80px 递增

执行流程。 会话高度固定 900px，从最窄宽度起逐档：调整视口 → 等待 CSS 重排 → 截首屏 → 若下方有重要内容再滚动截图 → 执行 8 项布局检查 → 记录问题与严重度。相邻宽度会做对比，以识别过渡点。

8 项检查矩阵。 横向溢出、文本溢出（截断、重叠、字号 <12px）、导航过渡（汉堡菜单出现/消失的宽度是否正确、有无中间破损态）、内容堆叠顺序、图片/媒体缩放与比例、触控目标是否达到 44px、留白平衡、CTA 在首屏是否可见。

输出。 每类过渡标注精确宽度区间（例如导航在 ~960px 从 768 档切换到 1024 档），严重度沿用 Critical/High/Medium/Low，报告写入 docs/responsiveness-check-YYYY-MM-DD.md。

适用边界

它只解决布局随视口变化的问题。ARIA、语义 HTML、标题层级、色彩对比这类不随视口变化的通用无障碍检查不在本技能范围内，需要配合 ux-audit 使用。另一个硬性前提是环境里必须存在任一浏览器自动化工具；多 URL 检测时会为每个 URL 启动一个并行子代理（而非每个断点一个），各自跑完标准检查后合并成一份报告。