---

description: Claude 可以快速生成和重构响应式 CSS，但可靠布局不能只套 768px、1024px 等设备断点。更稳妥的方法是先让内容约束决定布局状态，再用区间测试、结构断言与视觉回归验证修改。
tags: [Claude Code, 响应式设计, CSS, Playwright, 前端测试]

---

Claude 能写响应式布局，但断点应该由内容决定

让 Claude 生成一个“三列卡片在手机上变成单列”的页面并不难。你在 1440px 桌面和 390px 手机上各看一眼，效果都正常；上线后，导航却在 843px 开始换行，卡片标题被挤出边界，固定页脚又恰好盖住了按钮。

问题不一定是 Claude 写错了某条 CSS。更常见的原因是，我们把响应式设计误写成了几个设备预设：手机 390px、平板 768px、桌面 1024px。但页面不会只在这些宽度上运行，真正决定断点的也不是设备名称，而是内容何时失去可读性。

Anthropic 的响应式布局文章给出了一条很实用的 AI 工作流：先审计固定宽度和僵硬布局，再实施定向修改，最后用 Playwright 覆盖多种视口。要让这条流程真正可靠，还需要把“多种视口”进一步变成可验证的布局约束。Claude 可以加速找问题和改代码，验收标准仍要由页面的真实内容决定。

768px 只是一个数字，内容崩坏的位置才是断点

开发者习惯用 768px、1024px，是因为设计工具和 CSS 框架需要一套稳定约定。它们适合协作，却不天然适合每一块内容。

假设一个卡片容器要放三列，每列至少 280px，两条间隙各 24px。只算卡片，容器至少需要：

3 × 280px + 2 × 24px = 888px

如果页面还有左右内边距和侧栏，三列布局所需的视口宽度会更大。此时在 768px 或 1024px 机械切换，都可能与真实临界点错开。标题长度、字体加载、语言变化、缩放比例一变，临界点还会继续移动。

MDN 对媒体查询的建议很明确：不要围绕具体手机和平板尺寸设计全部断点，应在内容开始变得难读、侧栏被挤压或布局出现破坏的位置改变设计。

因此，断点不是“我要支持哪款设备”，而是“当前布局状态还能否满足约束”。三列放不下就退到两列；导航项开始换行就进入折叠状态；表单标签与输入框无法舒展时再改为纵向排列。

能自行伸缩的地方，先别急着增加媒体查询

现代 CSS 已经可以在不少场景下根据可用空间自动布局。每少一个人为断点，就少一组需要覆盖、覆盖后还可能互相冲突的样式。

卡片网格就是典型例子：

.cards {
  display: grid;
  grid-template-columns: repeat(
    auto-fit,
    minmax(min(100%, 18rem), 1fr)
  );
  gap: 1.5rem;
}

auto-fit 会根据空间自动决定列数，minmax() 则给每列设定可接受的最小值与可扩展上限。MDN 的 Grid 指南也使用 auto-fit 与 minmax() 展示“能放下几列就创建几列”的模式。这里不需要先猜一台平板究竟有多宽，浏览器会直接根据容器空间求解。

这并不意味着媒体查询已经过时。更实用的顺序是先判断问题属于哪一层：

如果一张卡片在主内容区和侧栏里需要呈现不同结构，它关心的是父容器宽度，而不是浏览器宽度。此时 Container Query 更贴近问题：组件根据自己所在容器的尺寸切换样式，复用时不必知道自己被放在页面哪个区域。

只有当变化确实属于页面级状态，例如主导航整体折叠、侧栏进入抽屉，或者需要响应用户的减少动态效果偏好时，媒体查询才是更直接的表达。

Claude 生成的 CSS，应被当成一个可运行假设

Claude.ai 很适合把文字需求快速变成语义化 HTML、移动优先样式和初始断点。Claude Code 还能读取多个样式表，找到固定宽度、绝对定位和互相覆盖的规则，再直接修改项目。

这比人工逐文件搜索快得多，但它拥有的首先是代码上下文。如果任务里没有真实页面、极端内容与运行结果，模型并不知道：

• 用户名可能有 40 个字符，德语按钮比中文按钮更宽；
• Web Font 加载后，导航文字会比回退字体多占一截空间；
• 页面既会出现在全宽路由，也会嵌进带侧栏的工作台；
• 软键盘和移动浏览器动态工具栏会改变可用高度；
• 某个横向滚动区域是产品设计，另一个横向溢出才是缺陷。

所以“请修复响应式布局”仍然太模糊。模型可能让所有元素加上 overflow: hidden，从截图上消掉滚动条，却顺手裁掉了用户必须看到的内容；也可能在每个常见宽度再补一条媒体查询，把暂时的现象压住，却让样式关系更难维护。

更稳妥的定位是：**Claude 负责把证据翻译成修改，并把修改交回浏览器验证。**一轮完成后，运行结果要重新进入下一轮，而不是由模型根据代码外观宣布成功。

这条闭环里，截图和测试不是最后补上的装饰。它们决定 Claude 在上一轮到底修对了问题，还是只把问题移到了另一个宽度。

五张设备截图，覆盖不了它们之间的危险区间

官方示例会在 320px、512px 等宽度验证无横向溢出，并生成覆盖 iPhone、iPad 与桌面的 Playwright 测试。这是很好的起点，但响应式错误经常发生在两个预设之间。

如果导航在 820px 正常，900px 也正常，却在字体与间距共同作用下于 843px 短暂换行，只测试设备预设就可能永远看不到它。测试策略需要分成三层：

1. 区间扫描：以固定步长覆盖支持范围，快速发现横向溢出、元素消失和错误状态；
2. 边界测试：对每个布局状态的临界点测试“前一像素、临界点、后一像素”；
3. 代表性截图：在单列、双列、三列、折叠菜单等语义状态各保留一张视觉基线。

下面这段 Playwright 测试不是完整质量体系，但能把“随便看几个设备”升级为最小的区间约束：

import { test, expect } from '@playwright/test';

const widths = Array.from(
  { length: 36 },
  (_, index) => 320 + index * 32,
);

for (const width of widths) {
  test(`dashboard has no page overflow at ${width}px`, async ({ page }) => {
    await page.setViewportSize({ width, height: 900 });
    await page.goto('/dashboard');

    const overflow = await page.evaluate(() =>
      document.documentElement.scrollWidth -
      document.documentElement.clientWidth
    );

    expect(overflow).toBeLessThanOrEqual(1);
  });
}

全局 scrollWidth 只能抓到非预期的页面级横向滚动，不能证明布局已经正确。页面若有设计允许的横向轮播，还要针对具体容器写断言；导航是否处在唯一正确状态、按钮是否被遮挡、文字是否被无意裁切，也需要各自的结构检查。

Playwright 支持设置视口和模拟设备，也能通过 toHaveScreenshot() 做页面或组件的视觉比较。但官方文档同时提醒，操作系统、浏览器版本、字体和硬件环境都会影响截图结果。因此，视觉基线应在稳定环境中生成和比较，不能把不同机器产生的像素差全部当成布局回归。

响应式验收要检查状态，不只检查有没有滚动条

“页面没有横向溢出”很容易自动化，也最容易制造虚假的安全感。一个响应式页面至少有三类不同证据：

证据	适合发现	单独看不到
DOM 与几何断言	溢出、遮挡、元素状态冲突、关键控件消失	视觉层级是否自然、换行是否难看
视觉回归截图	意外位移、尺寸变化、裁切、样式回归	菜单能否点击、焦点是否可达、语义是否正确
真机交互	触控感受、软键盘、动态工具栏、真实字体渲染	所有宽度与所有内容组合

三类证据解决不同问题，不能互相替代。自动化测试适合覆盖宽度范围，截图适合守住关键视觉状态，真机则用于浏览器模拟难以还原的交互与视口行为。

还要特别检查“修复”有没有通过隐藏内容来达成。移动端折叠导航可以改变呈现方式，但不能让核心入口消失；卡片从横排变竖排可以改变视觉顺序，却不应破坏键盘焦点顺序与文档语义；overflow: hidden 可以消除滚动条，但被裁掉的文字仍然是缺陷。

给 Claude 的任务，最好写成一份布局验收合同

如果任务只写“让 dashboard 适配移动端”，Claude 必须替你猜测支持范围、正确状态和修改边界。把这些判断写清楚，模型才可能执行闭环，而不只是交付一份看起来合理的 CSS。

目标：修复 /dashboard 在 320px～1440px 宽度内的响应式问题。

已知失败：
- 843px 时顶部导航换行并覆盖标题
- 512px 以下卡片产生页面级横向滚动
- 附上失败截图、DOM 路径和当前字体配置

布局约束：
- 320px～719px：单列卡片，导航折叠
- 720px～959px：双列卡片，侧栏进入抽屉
- 960px 以上：三列卡片，侧栏常驻
- 核心内容不得通过 display:none 或裁切隐藏

执行要求：
1. 先定位产生冲突的最小规则，不直接新增大量断点
2. 优先尝试 Grid、Flex 或容器查询等流体方案
3. 在支持区间内每隔 32px 检查页面级溢出
4. 对 719/720px、959/960px 分别测试边界两侧
5. 在三种布局状态运行结构断言并保存截图
6. 报告仍需真机确认的项目；测试失败时不要宣称完成

这份任务说明把审美要求之外的部分变成了可证伪条件。Claude 可以自行审计、修改和运行测试；一旦结果不满足约束，就有明确失败信号可以继续迭代。

断点数值也不应由提示词永久钉死。上例中的区间应来自设计状态和实际内容测试。若真实页面在 704px 就发生碰撞，应先调查布局约束，再更新断点与测试，而不是为了让测试变绿去隐藏异常。

真正值得自动化的，是从失败宽度到回归证据的闭环

Claude 确实能让响应式开发更快：它可以生成初始布局，解释 Grid 与 Flexbox 的取舍，跨样式表查找固定宽度，修改代码，再补上 Playwright 测试。它压缩了从发现现象到实施修复的距离。

但页面是否“适配”，不能由生成过多少媒体查询、通过多少设备预设来决定。下次遇到响应式问题，先问三件事：

1. 这个断点来自设备清单，还是来自内容真正开始崩坏的位置？
2. 这次修改让布局自然适应约束，还是又增加了一层覆盖规则？
3. 测试覆盖了布局状态和危险区间，还是只截了几张常见设备图？

可靠的响应式布局不追求猜中每一款设备。它先用流体规则减少需要猜测的地方，再把无法自动伸缩的变化定义成清晰状态，最后用浏览器证据验证这些状态之间没有裂缝。Claude 能把这套流程跑得更快，内容约束与测试结果才决定它是否真的完成。