responsive-design

响应式设计

当任务是确定出现问题的响应式界面、选择最小可行的适配方案包，并留下简短的策略与验证说明时，请使用此技能。

这项工作不是罗列通用 CSS 方案、粘贴框架代码片段，也不是包揽所有相关的前端工作。

此技能应：

1. 首先对响应式问题分类，
2. 选择一个主要的响应式方案包，
3. 明确区分视口与容器的职责，
4. 将密集数据和媒体场景与通用布局建议分开，
5. 确保重排与验证事项清晰可见，
6. 如实分流相关的前端工作。

请先阅读以下支持文档：

• references/intake-packets-and-route-outs.md
• references/layout-decision-checklist.md
• references/handoff-boundaries.md

何时使用此技能

• 团队表示“这个页面在移动端会出问题”，但实际出现问题的响应式界面尚不明确。
• 仪表板、导航、表单、卡片网格、定价页面、表格或嵌入内容需要先确定响应式策略，再添加更多断点。
• 需要判断修复应归属于视口布局规则、容器查询、固有布局、响应式媒体处理，还是验证／重排后续工作。
• 发布准备检查发现溢出、换行、密度或缩放／重排问题，需要有人整理一个范围明确的方案包，而不是讲解一大堆 CSS。
• 请求混合了页面级适配、组件复用和密集数据方面的压力，需要在实施前进行分流。

何时不使用此技能

• 主要任务是设计可复用基础组件／插槽／变体 API，或确定组件族的归属 → design-system
• 主要任务涉及键盘／焦点行为、语义、标签、对比度、减少动态效果，或以无障碍改进为主 → web-accessibility
• 主要任务涉及断点治理、令牌策略或跨产品的响应式标准 → design-system
• 主要任务是在多个维度上进行广泛的 UI 评审、完善、启发式检查或发布准备审计 → web-accessibility
• 主要任务涉及 React 水合、重复渲染开销或客户端边界的性能行为 → react-best-practices
• 响应式策略已经明确，任务只是实施；此时应直接实施，而不是重新运行分流流程

说明

第 1 步：确定响应式任务的范围，再讨论 CSS

首先收集最少量的需求信息。

responsive_intake:
  surface: page-shell | nav | form | table | dashboard | card-grid | media-embed | component-slot | mixed | unknown
  workflow_type: bug-fix | refactor-plan | launch-readiness | review-follow-up | design-handoff | unknown
  primary_packet: page-layout | component-slot | dense-data | media-behavior | verification-reflow | mixed | unknown
  pressure_source: viewport-width | parent-container | content-density | localization-copy | zoom-reflow | mixed | unknown
  signal_source: bug-report | screenshot | browser-resize | qa-review | design-review | a11y-review | mixed | unknown
  confidence: high | medium | low

规则：不要一上来就说“再加一个断点”。首先标明出现问题的响应式界面。

第 2 步：准确选择一个主要的响应式方案包

使用 references/intake-packets-and-route-outs.md 中的分流流程。

主要方案包：

1. page-layout
2. component-slot
3. dense-data
4. media-behavior
5. verification-reflow

请选择对当前决策影响最大的方案包。其他事项应列为后续工作，而不是并列的责任项。

第 3 步：明确列出不变原则

以下规则适用于所有答复：

• 移动优先仍是交付功能最安全的基线
• 若能干净利落地解决问题，固有布局优于不断增加断点
• 视口规则负责页面外壳的变化；容器规则负责可复用插槽的适配
• 断点应反映内容所承受的压力，而不是设备品牌名称
• 密集表格／工具栏属于特殊场景，通常需要明确选择回退方案
• 响应式媒体需要有意识地考虑 srcset／sizes／宽高比，而不只是设置 width: 100%
• 缩放／重排和长文案压力属于验证要求，不应事后才考虑

第 4 步：整理响应式策略方案包

按以下结构返回：

# Responsive Strategy Packet

## Scope
- Surface:
- Workflow type:
- Primary packet:
- Confidence: high | medium | low

## Current signal
- Main symptom:
- Pressure source:
- What is already known:
- What still needs direct verification:

## Recommended first slice
1. ...
2. ...
3. ...

## Layout decisions
- Mobile-first baseline:
- Intrinsic layout rules:
- Viewport query layer:
- Container-query usage:
- Dense-data / media fallback:

## Verification plan
- Narrow-width checks:
- Zoom / reflow checks:
- Overflow / wrapping checks:
- Content-density / localization checks:

## Ownership and route-outs
- Primary owner:
- Adjacent skills / teams:

步骤 5：使用数据包，而不是冗长的 CSS 教程

从 references/intake-packets-and-route-outs.md 获取数据包。

数据包规则：

• page-layout → 页面框架、导航栏／侧边栏变化、网格列、间距密度、视口断点
• component-slot → 会随父级宽度变化的可复用卡片／面板／模块行为；容器查询或内在组件规则
• dense-data → 表格、工具栏、筛选栏、仪表板，以及有意选择的回退方案，例如摘要、展开内容或水平滚动
• media-behavior → 图像／视频／嵌入内容尺寸、srcset / sizes、宽高比、裁剪策略和艺术指导边缘情况
• verification-reflow → 发布前的缩放、重排、溢出、长标签、本地化，以及截图与手动检查的后续验证

步骤 6：将机制选择与职责归属分开

每个重要回答都使用以下区分：

• 机制 — 内在布局、视口查询、容器查询、响应式媒体规则、回退呈现方式
• 职责归属 — responsive-design、design-system、web-accessibility、design-system、web-accessibility 或 react-best-practices

如果请求始于截图、QA 备注或“移动端坏了”的报告，请明确说明：截图是信号材料，而不是最终的响应式策略。

步骤 7：明确转交相邻工作

当问题涉及多个边界时，使用以下转交方式：

如果实际工作是……	转交给……
可复用基础组件 API、变体泛滥、插槽归属、组件结构	design-system
语义、键盘／焦点、标签、对比度、动效或以无障碍为重点的整改	web-accessibility
共享断点令牌、全系统密度规则、跨产品前端标准	design-system
全面的发布就绪 UI 评审、层级、润色或启发式评审	web-accessibility
水合、重复渲染开销、客户端边界成本或运行时性能	react-best-practices

输出预期

此技能给出的优质回答应当：

1. 确定主要响应式数据包；
2. 推荐一种范围明确的适配策略；
3. 指出仍需进行的手动验证；
4. 避免将框架辅助工具视为完整策略；
5. 将更广泛的前端职责归属问题转交出去，而不是自行承担。

示例

示例 1：仪表板在移动端溢出

输入

我们的仪表板筛选栏和数据表格在移动端只能通过水平滚动查看。请帮我们修复响应式行为。

输出方向

• 选择 dense-data
• 保留移动优先的页面框架，但为表格／工具栏设计明确的回退方案
• 包含缩放／重排验证和长标签检查
• 如果问题主要转为无障碍整改，则转交给 web-accessibility

示例 2：在多个插槽中复用的卡片

输入

同一张卡片会出现在侧边栏、信息流和双列网格中。我们应该使用容器查询，还是增加更多视口断点？

输出方向

• 选择 component-slot
• 说明为何父级容器宽度是主要影响因素
• 建议在卡片框架边界使用容器查询或内在布局
• 如果组件结构本身有问题，则将基础组件／API 的重新设计转交给 design-system

示例 3：发布前的定价页面

输入

请在发布前评审这个定价页面。卡片在移动端显得拥挤，首屏内容的换行也很糟糕。

输出方向

• 仅针对布局适配部分使用 responsive-design
• 为页面布局和密集的移动端区块生成一个数据包
• 将更广泛的层级／CTA／润色评审转交给 web-accessibility
• 除非无障碍整改成为首要问题，否则将其单独处理

示例 4：全系统断点争论

输入

我们各团队在不同产品中都使用不同的断点和间距规则。responsive-design 是合适的技能吗？

输出方向

• 说明统一的断点和设计令牌治理属于更广泛的 design-system 工作
• 将 responsive-design 的范围限定在跨产品标准之外
• 避免仅因治理类请求就触发该技能

示例 5：缩放与重排失败

输入

这个表单在 400% 缩放时仍然会出问题，键盘用户也会丢失上下文。我们应该继续在 responsive-design 中修复吗？

输出方向

• 如果布局归属仍不明确，优先选择 verification-reflow
• 明确纳入缩放和重排验证
• 将键盘和焦点修复工作分配给 web-accessibility
• 拆分工作，而不是强行让一个技能负责所有内容

最佳实践

1. 从失效的响应式界面着手，而不是从语法技巧入手。
2. 在添加新的断点之前，优先使用内在布局。
3. 明确视口和容器的归属。
4. 将表格、工具栏和密集型仪表板视为值得单独处理的特殊情况。
5. 将屏幕截图和设备模式检查视为输入，而非完成证明。
6. 如实进行验证：缩放、重排、长文本和溢出仍然很重要。
7. 如果不确定，就明确分配相邻的前端工作，而不是扩大此技能的范围。

参考资料

• MDN：响应式设计
• MDN：使用媒体查询
• MDN：容器查询
• MDN：响应式图片
• web.dev：学习响应式设计
• W3C WAI：理解重排