responsive-design

responsive-design 技能概览

responsive-design 技能可以帮助 agent 针对自适应界面输出现代、可落地的实现建议，涵盖 container queries、fluid sizing、CSS Grid、Flexbox 以及 mobile-first 断点策略。它尤其适合正在构建真实 UI 布局、设计系统组件、dashboard、卡片、导航或数据密集型视图的场景：这些界面需要在不同屏幕尺寸下稳定工作，而不是依赖一套脆弱、按设备硬编码的 CSS。

responsive-design 技能适合谁

如果你的需求不只是“让它适配手机”，那就适合使用这个 responsive-design 技能。它很适合前端工程师、需要深入到实现细节的 UI 设计师，以及希望获得组件级响应式方案的 agent 用户，而不是只拿到一堆泛泛而谈的 media query 建议。

它真正帮你完成的工作是什么

这个技能真正解决的问题，是把一个模糊的布局目标转成一套可执行的响应式实现策略：哪些地方应该做 fluid，哪些地方应该设断点，什么时候该用 container queries 而不是 viewport queries，以及怎样让组件在不同上下文中依然可复用。

这个技能与普通提示词有什么不同

普通提示词常常会产出一些过时建议，比如按设备型号设断点、堆很多 media query。responsive-design 技能则聚焦于仓库中整理出来的更新 CSS 模式，尤其包括：

• 以内容变化驱动、mobile-first 的断点策略
• 面向可复用组件的 container queries
• 基于 clamp() 的流式字体与间距
• 将 viewport 层面的布局问题与组件层面的适配问题分开处理的布局思路

安装前最值得确认的点

如果你的输出目标是 CSS、组件规范或 UI 实现指导，这个技能会很合适。如果你只想要视觉稿、no-code 工具操作说明，或者只关注框架抽象而不关心底层 CSS 决策，那它的帮助就会有限。这个仓库本质上是参考资料驱动型内容，它的价值主要来自 references/ 中的模式和示例，而不是自动化脚本。

如何使用 responsive-design 技能

responsive-design 安装方式与使用背景

从仓库根目录的 skill collection 安装：

npx skills add https://github.com/wshobson/agents --skill responsive-design

由于上游 skill 本身不附带脚本或框架绑定，安装的意义主要是让你的 agent 能调用这套指导内容。你可以把它理解为一个“文档 + 模式库”型技能，而不是一个接收严格输入、直接生成代码的工具。

先读这些文件

建议按这个顺序阅读以下文件：

1. plugins/ui-design/skills/responsive-design/SKILL.md
2. plugins/ui-design/skills/responsive-design/references/container-queries.md
3. plugins/ui-design/skills/responsive-design/references/fluid-layouts.md
4. plugins/ui-design/skills/responsive-design/references/breakpoint-strategies.md

这个阅读顺序很重要：先看核心 skill 了解边界和适用范围，再看 references 补足真正影响输出质量的实现细节。

这个技能需要你提供哪些输入

当你提供以下信息时，responsive-design 技能效果最好：

• 组件或页面类型
• 布局约束
• 目标屏幕场景
• 响应式应基于 viewport、container，还是混合方案
• 设计系统 token 或断点约定
• 浏览器支持要求

较弱的输入：
“Make this responsive.”

更强的输入：
“Create a responsive card grid for a dashboard. Cards must work in a full-width page and in a narrow sidebar. Use container queries where component context changes, fluid spacing and type, and keep breakpoints aligned to our sm/md/lg token scale unless content forces a different threshold.”

如何把模糊需求变成高质量提示词

一个高质量的 responsive-design usage 提示词，通常包含五个部分：

1. UI 对象：card list、nav bar、pricing table、form、data table
2. 行为变化：stack、wrap、collapse、resize、reorder、reveal
3. 约束来源：viewport、父容器、内容宽度
4. 系统规则：token scale、grid 规则、最小点击尺寸、无障碍需求
5. 输出形式：CSS 示例、实现方案、断点依据、重构建议

示例提示词：

“Use the responsive-design skill to propose a responsive strategy for a product comparison table. Prioritize small screens first, avoid horizontal overflow where possible, use content-based breakpoints, and explain whether container queries or viewport media queries should control each part. Include sample CSS for typography, spacing, and layout transitions.”

什么时候应该要求使用 container queries

当组件需要根据“它被放在什么位置”来适配，而不只是根据浏览器宽度来变化时，就应该考虑 container queries。对于可复用卡片、侧边面板、widget、嵌入式模块以及设计系统组件，这一点尤其重要。

如果你的组件会出现在多个父级布局里，仓库中的 references/container-queries.md 是最值得优先看的文件。里面包含了实用语法、named containers，以及浏览器支持说明。

什么时候该优先考虑 fluid layouts，而不是继续加断点

如果你的 UI 问题主要在于文字、间距或宽度需要平滑缩放，那就应该先把 agent 引导到 fluid 技术上，而不是一上来就增加更多断点。references/fluid-layouts.md 很适合这类场景：你希望减少生硬的断点跳变，改用 clamp()、相对单位和 intrinsic sizing 实现更自然的缩放。

这通常会改善：

• 标题和正文文本
• 区块间距
• 卡片尺寸
• 在真正“跳变”前应先自然伸缩的 grid

如何更好地使用断点策略建议

这个仓库明显更偏向“由内容驱动、mobile-first”的断点思路，而不是按设备目录来分段。实际使用时，应让技能按布局压力来解释每个断点的必要性：例如行长过长、卡片过挤、表格溢出、导航换行、触控目标太小等。

如果你的团队已经在用 Tailwind 或 Bootstrap 的断点 token，也请明确告诉它。references 中包含常见尺度，这有助于技能把现代策略映射到你们现有系统中，而不是随意编造一组数值。

真实项目中推荐的工作流

一个实用的 responsive-design guide 工作流如下：

1. 先描述组件本身，以及它在小尺寸和大尺寸下的失效方式。
2. 先要布局策略，再要代码。
3. 明确哪些部分应该 fluid、哪些应该 snap、哪些需要 reflow。
4. 只有在策略合理之后，再请求示例 CSS。
5. 用你的真实容器宽度测试结果，而不是只看浏览器预设尺寸。
6. 如果第一轮输出太泛，就补充截图、DOM 结构或现有 CSS 继续迭代。

相比一开始就直接要求最终 CSS，这套顺序通常能得到更好的结果。

最适合要求的输出形式

你可以让这个技能按以下形式输出：

• 响应式实现计划
• 断点依据表
• CSS 起步模式
• 组件重构策略
• 现有布局审查
• “container query vs media query” 决策建议

这些形式比“给我一份响应式代码”更能逼出清晰决策。

提升输出质量的实用技巧

想获得更好的 responsive-design for UI Design 效果，可以这样做：

• 当布局关系重要时，附上当前 HTML 结构
• 说明内容长度是否变化很大
• 提前说明最小可读字号和最小交互目标尺寸
• 告诉 agent 是否允许调整内容顺序
• 如果有旧浏览器约束，在它提出大量 container-query 方案前就先说清楚

否则，这个技能可能会选择技术上很现代、但并不适合你支持矩阵或组件架构的方案。

responsive-design 技能 FAQ

responsive-design 技能对新手友好吗？

友好，但前提是你已经懂基础 CSS。这个技能的特点是“概念现代”，而不是“新手教程导向”，所以它更适合能读懂 CSS、但希望做出更好响应式决策的用户。新手当然也能用，只是需要接受其中会出现 container queries、intrinsic sizing、fluid scales 这类术语。

这个技能会生成特定框架的代码吗？

不是它的主要方向。仓库内容更聚焦于 CSS 模式本身。你当然可以要求它适配 React、Vue、Tailwind 或 plain CSS，但它的核心价值在于响应式策略，而不是框架集成细节。

responsive-design 比普通 UI 提示词更好吗？

通常是的，尤其当“响应式”本身就是任务核心时。普通提示词很容易回到老一套断点习惯，或者只给出浅层的“移动端改成堆叠布局”建议。responsive-design skill 则为 agent 提供了一套更有立场、也更符合当下实践的布局决策语言。

什么情况下不该用 responsive-design？

如果你的任务主要是以下类型，就可以跳过它：

• 视觉品牌表达
• 静态 mockup 生成
• 以动画为主的交互设计
• 与布局无关的框架搭建
• 不涉及自适应行为决策的像素级还原

另外，如果你的团队无法使用现代 CSS 特性，仍需要 IE 时代那套兼容模式，它也不是理想选择。

它会覆盖浏览器兼容性问题吗？

会涉及一部分。references 会提到现代浏览器支持情况，尤其是 container queries，也隐含了 graceful fallback 的思路。但它不是一个专门做兼容性矩阵的 skill。如果浏览器支持对你很关键，请在提示词中明确写出最低支持浏览器。

这个技能能帮助设计系统建设吗？

可以。它很适合用于制定断点理念、与 token 对齐的间距和排版规则，以及组件在不同容器中的可复用行为。特别是在设计系统希望减少页面级 hack、提升组件可移植性时，它会很有价值。

如何把 responsive-design 技能用得更好

给 responsive-design 技能提供真实约束

质量提升最大的来源，就是约束条件。尽量提供真实宽度、token 名称、内容样例和 UI 状态。
“Responsive dashboard card” 太泛；
“card used in 320px sidebar and 1200px main grid with long titles and two actions” 才足够可执行。

不要只要代码，要它先做决策

更好的提示词是：
“Use the responsive-design skill to decide which parts should use fluid sizing, which need breakpoints, and where container queries are justified.”

这会比下面这种提示词产出更强的推理：
“Write responsive CSS.”

做重构时，把现有 CSS 一起给它

如果你已经有布局代码，把当前 CSS 贴出来，再让技能帮你简化。这能帮助它识别并移除不必要的 media query，找出脆弱的宽度假设，并在合适时用具备组件上下文感知的规则替代纯 viewport 逻辑。

常见失败模式要重点留意

第一版输出仍然可能不够好，常见情况包括：

• agent 在没有内容证据的情况下臆测断点
• 该用 viewport 规则更简单的地方却用了 container queries
• 加了 fluid typography，却没有设置最小/最大边界
• 布局变化忽略了无障碍或阅读舒适度
• 示例看起来优雅，但与你的 DOM 结构并不匹配

这些问题都能修正，前提是你要求它给出依据，并把每条规则都绑定到具体的 UI 问题上。

初稿出来后，用迭代提示词继续打磨

好的后续提示词包括：

• “Reduce unnecessary breakpoints and explain what can be fluid instead.”
• “Refactor this so the component works in both narrow sidebar and wide content areas.”
• “Add fallbacks for teams that cannot rely fully on container queries.”
• “Audit this layout for overflow, cramped text, and awkward wrap points.”

相比从头要求一次性重写，这类 follow-up 往往更能提升实际落地效果。

不要只按屏幕尺寸验收，要按组件上下文验证

responsive-design 技能的一个核心洞察是：很多失败，并不是因为 viewport 宽度没测，而是因为只测了 viewport 宽度。要改善结果，应该检查同一个组件在这些场景中的表现：

• 完整页面内容区
• sidebar
• modal
• 密集型 dashboard grid
• 嵌入式营销区块

如果组件会随着容器变化而表现不同，请一开始就告诉技能，这样它才能选对响应式机制。

把 reference 文件当作提示词锚点来用

当你想获得更深入的输出时，可以直接点名仓库里的 reference：

• references/container-queries.md：适合组件级响应式
• references/fluid-layouts.md：适合平滑缩放
• references/breakpoint-strategies.md：适合 mobile-first 断点决策

这是让 agent 给出更扎实 responsive-design usage 的最简单办法之一，比起泛泛的前端建议更有依据。

用更明确的验收标准提升结果

可以要求这个技能朝具体目标优化，例如：

• 更少的 media query
• 在指定宽度以下不出现水平溢出
• 更可读的行长
• 跨容器尺寸可复用的组件
• 与 token 对齐的间距和排版
• 断点之间尽量少的布局跳变

清晰的验收标准，会让 responsive-design 技能在生产级 UI 工作里更实用。