关于 antislop-layoutmobile
antislop-layoutmobile 是面向 AI 编码 Agent 的响应式布局技能,在跨屏幕宽度构建或修改布局时与 antislop.md 配合使用。它强调有规划的布局重排,涵盖断点、尺寸、网格、溢出和触控目标。
主要功能
- 01依据内容设置断点
- 02响应式尺寸与排版
- 03网格重排与堆叠规则
- 04防止溢出的指导
- 05触控目标尺寸与间距
适用场景
- 01将桌面布局适配到手机
- 02检查不同视口宽度下的布局
- 03发现移动端溢出与拥挤控件
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ miqdadbadjuber/ anti-slop --skill antislop-layoutmobile安装后在 Claude Code 中输入/antislop-layoutmobile确认已加载。
详细介绍
antislop-layoutmobile
Anti Slop:面向 AI 编码 Agent 的规则。移动端布局技能
属于 antislop 系统。请与
antislop.md(核心)一同阅读。本技能深入讲解响应式布局:布局如何在不同屏幕尺寸间重排,从手机适配到桌面端。内容涵盖断点、缩放、网格、溢出、点击目标和导航。本文引用核心规则编号,不重复也不重新编号。任务涉及构建或编辑需要适配任意屏幕宽度的布局时,请加载本技能。
如何使用本技能
- 只要任务涉及移动端或响应式布局,就与
antislop.md一同加载。核心文档涵盖机制(目的测试、三个层级、交付关卡);本技能深入讲解移动端布局。 - 每个条目结构相同:说明(模式)、原因(为何看起来粗制滥造)、修正(应采取的做法),并注明适用的核心规则 R-XX。
- 本技能背后的原则:**移动端布局是另一种布局,而不是缩小后的桌面端布局。**它必须重新排布:有意地重新堆叠、缩放和排序。以下每种模式都说明了布局未能重新排布的情况。
- 核心文档中的交付关卡仍是最终关卡。本文件末尾的“移动端布局技能检查清单”是移动端专用补充项,应与其一同执行。
断点
仅适用于桌面端的布局
- **说明:**所有屏幕都使用同一种布局状态;移动端视图只是被挤进手机屏幕的桌面端布局。
- **原因:**R-03 要求移动端布局必须完善,而非事后补救。只会缩小的页面根本没有移动端设计:原本并排显示的卡片会重叠,为宽屏设计的文本会挤在狭窄的屏幕中。
- **修正:**在内容开始无法正常显示的断点处定义真正的移动端状态。移动端布局应重新排布:列改为纵向堆叠、尺寸缩小,并在内容需要时调整顺序。如果移动端视图只是缩小后的桌面端视图,布局就还没有完成。
根据设备列表设置断点
- **说明:**断点按手机宽度命名(375px、414px、768px),设置的原因是“这就是 iPhone 的尺寸”,而不是内容在此处出现问题。
- **原因:**设备宽度会随年份和型号变化。断点应该设在布局无法维持正常显示的位置;强行匹配设备列表,会让布局跟着规格表走,而非根据内容设计(R-03)。
- **修正:**在内容实际出现问题的位置设置断点:例如某一列变得难以阅读,或一行卡片变得过窄。缩小视口并观察布局从何处开始变化,然后在那里设置断点。
最后才设计移动端样式
- **说明:**移动端规则只是作为末尾覆盖样式补上:一份很长的桌面端样式表,最后附上一个只修复一两处问题的小型媒体查询。
- **原因:**覆盖样式补丁不等于移动端设计。它只修复已报告的问题,却留下下一个问题,而且基础样式仍然是针对宽屏调整的(R-03)。
- **修正:**把移动端视为经过专门设计的状态,而不是覆盖样式。为窄视口单独设计合适的尺寸和堆叠方式,并在该视口下检查整个布局,而不只是打过补丁的位置(R-35)。
双状态布局
- **判断依据:**布局恰好只有两种状态:一个断点以下为单列堆叠,断点以上为宽屏多列网格,中间没有任何定义。因此,平板或小型笔记本电脑的屏幕宽度会继承最接近的状态:要么是被拉得离谱宽的手机堆叠布局,要么是被挤进远小于预期画布的桌面网格。
- **原因:**页面的宽度是连续变化的,而 R-03 要求页面在每种宽度下都能正常呈现,而不只是两个选定的断点。两种状态会让整个中间宽度范围(约 600 到 1024 px,平板和小型笔记本电脑常见的宽度)沦为意外:内容既没有按设计堆叠,也无法在适配的网格中排列。布局只有在两个样例宽度下看起来像是经过设计的,在两者之间则处处失调。
- **修复方法:**在内容开始无法正常呈现的宽度定义真正的布局状态,状态数量按内容需要设置。典型的重排有三种状态,而不是两种:单列;卡片作为单列过宽时切换为两列网格;只有在确实放得下时才切换为完整的多列网格。拖动视口检查整个宽度范围,而不是只检查两个宽度就认为完成了(R-35)。
缩放与尺寸
所有元素都按桌面尺寸设置
- **判断依据:**内边距、间距、主视觉区高度和卡片尺寸从桌面端沿用到移动端,导致每个区块在手机上看起来都被放大了。
- **原因:**为 1440px 画布设置尺寸的元素,在 375px 画布上会显得过于突出。在桌面端看起来大气的设计到了移动端就变得过大:什么都放不下,布局没有呼吸感,页面仿佛是为手边没有的屏幕设计的(R-03)。间距和字号应遵循设计节奏(R-05),而移动端的节奏应更紧凑。
- **修复方法:**为移动端设置自己的尺寸级别:更小的字号比例、更紧凑的区块内边距、更小的间距。点击目标应保持最小尺寸(参见“点击目标”),其余元素则应在断点处按设计意图缩小。
固定像素字号
- **判断依据:**字号使用固定的 px,在桌面端和移动端之间从不变化,因此标题和正文在手机上仍显得过大。
- **原因:**不随视口变化的字号,就是只针对一种屏幕设置的字号。R-03 要求移动端布局能正常呈现,R-06 则要求排版提升可读性。占满手机屏幕宽度的标题,或为宽屏行长设置的正文大小,都会破坏这两项要求。
- **修复方法:**使用流式字号(
clamp()),使字号随视口缩放;或者在断点处设定更小的字号级别。在窄屏宽度下检查效果(R-35),不要只看桌面预览。
100vh 区块
- **判断依据:**主视觉区和区块高度设为
100vh,导致区块占满整个手机屏幕,并把其他内容推到首屏以下。 - **原因:**为桌面显示器设计的全视口区块,在手机上会变成巨大的色块;而且
100vh会计入浏览器界面高度,因此在移动浏览器中会超出可视区域。它不是引导用户进入页面,而是占据了整个布局(R-03)。 - **修复方法:**让区块按内容自动调整尺寸(
auto);如果确实需要区块铺满高度,则使用动态视口单位(dvh)。首屏以下的内容不应因为视口单位而意外移位。
过大的空白内边距
- **判断依据:**桌面端尺寸的区块内边距(96px、128px)在移动端仍保持不变,导致手机上的区块之间出现高大的空白。
- **原因:**为大画布调整的内边距在小画布上会变成浪费的垂直空间。用户需要在空白中不断滚动,R-05 所要求的节奏也变成了区块之间的空洞。
- **修复方法:**在断点处将区块内边距缩小到适合移动端的级别(约为原来的一半或更小),并检查页面滚动时的内容密度是否自然,而不是处处留有大片空白。
网格与堆叠
无法折叠的列
- **判断方法:**多列网格在手机上仍保持并排布局,导致列宽缩小、文本换行混乱,元素相互碰撞。
- **原因:**网格预设了可用宽度。当视口变窄而网格没有重新堆叠时,每列只剩一小条空间,文本变得难以阅读,卡片也会重叠(R-03)。这就是碰撞故障:桌面端的并排布局在手机端变成一团。
- **修复方法:**在断点处将网格折叠为单列,并让内容重新流动。并排布局变为纵向堆叠,每个项目重新获得完整宽度。在窄屏宽度下再次验证(R-35)。
固定宽度网格
- 判断方法:
grid-template-columns使用固定 px 值,或网格区域无法重新流动,导致视口缩小时网格仍保持僵硬。 - **原因:**固定 px 轨道不会考虑视口宽度;它会保持原宽度,造成溢出或碰撞。这种布局只适用于一种画布,无法改变形状(R-03)。
- **修复方法:**使用
minmax()、auto-fit和auto-fill设置轨道大小,让列随内容缩小和换行,并定义能在断点处折叠的网格区域。网格默认应保持流动,仅在有意设置固定尺寸时才保持僵硬。
强制使用 12 列网格
- **判断方法:**将 12 列网格强行套用到只需要一列或两列的手机内容上,导致跨度显得随意,布局计算也与设计相冲突。
- **原因:**12 列系统适用于内容列较多的宽屏画布。强行用在手机上,会让每个元素都成为用户看不见的网格中的一部分,结果是让内容迁就网格,而不是让网格适应内容(R-03)。
- **修复方法:**让列数适应内容。手机上的内容通常需要一列,最多两列;只有在布局确实需要并排显示那么多内容时,12 列跨度才有意义。
溢出
横向滚动泄漏
- **判断方法:**某个元素宽于视口,导致页面可以横向滚动,例如表格、代码块、图片或无法断开的长字符串。
- **原因:**横向滚动违背了手机端的预期。用户看不到页面在哪里结束,布局也会明显溢出屏幕(R-03)。这是最常见的溢出问题,因为问题元素在桌面端预览时位于屏幕外,往往要等到手机打开页面后才会被发现。
- **修复方法:**找出宽于视口的元素(需要重新流动布局或滚动容器的表格、需要换行的代码块、使用
max-width: 100%的图片),然后限制其范围或让其重新流动。在最窄的目标宽度下验证整个页面没有横向滚动(R-35)。
overflow: hidden 裁切
- **判断方法:**容器上的
overflow: hidden在窄屏宽度下裁切内容,隐藏文本或控件,而不是让它们适应空间。 - **原因:**裁切是在掩盖故障。容器因布局无法容纳内容而将其截断时,用户会失去信息和交互能力(R-03)。此问题中有关缩放和调整文本大小的部分由
antislop-human介绍。 - **修复方法:**让内容重新流动,而不是裁切:允许容器扩展、让内容换行,或在断点处折叠容器。仅在设计意图就是裁切时才进行裁切(例如缩略图),绝不要因此隐藏内容。
固定宽度子元素
- **判断方法:**flex 或 grid 子元素使用固定 px 宽度或
min-width,在窄屏幕上超出父容器。 - **原因:**以绝对 px 值设定大小的子元素不会考虑父容器有多少空间。手机端父容器缩小,子元素却保持较宽,因而溢出容器和页面(R-03)。
- **修复方法:**使用相对单位设置子元素大小,并允许其换行(
flex-wrap、流动宽度、为 grid 子元素设置min-width: 0)。子元素应能随容器缩小,而不是维持桌面端尺寸。
点击目标
目标尺寸过小
- 表现: 按钮、链接和控件的尺寸小于约 44 x 44 px,用光标在桌面端很容易点击,用拇指却很难点中。
- 原因: 桌面端光标可以精准定位,拇指却不行。16px 的目标尺寸在手机上会让人烦不胜烦,也无法兑现 UI 在移动设备上可用的承诺(R-03)。
- 修复: 为交互目标提供至少 44 x 44 px 的触控区域,即使视觉元素更小,也要通过内边距或扩大点击区域来实现。在手机屏幕宽度下检查所有控件(R-35)。
目标间距过小
- 表现: 44px 的目标紧挨在一起,没有间隔,导致拇指点击时容易点错。
- 原因: 目标尺寸只有与目标间距结合起来才有意义。两个相互接触的大控件就像一个大控件:用户无法可靠地选中其中任何一个(R-03)。
- 修复: 相邻交互目标之间留出明显间距,至少留出几 px,最好确保手指按压区域不会重叠。间距是让目标易于点击的另一个关键因素。
仅支持悬停的交互
- 表现: 菜单、展开内容和工具提示仅在悬停时出现,触屏用户无法打开它们。
- 原因: 触摸屏上没有悬停。仅响应悬停的交互对移动端用户而言根本不存在,任何依赖这种交互的控件都会让用户无路可走(R-03)。
- 修复: 为每种仅支持悬停的交互提供点击方式:悬停时打开的菜单也应能通过点击打开,展开内容也应能通过点击显示,交互元素还应显示可见的
:active反馈,让点击操作得到响应。仅用触控操作 UI 进行测试(R-35)。
移动端导航
导航仍是桌面布局
- 表现: 桌面端顶部栏中的链接在移动端仍然并排显示,导致链接拥挤、换成两行,或超出视口。
- 原因: 桌面端导航是为宽屏设计的。在手机上仍保持一行,会变成拥挤不堪的链接,而它是移动端用户首先看到的内容(R-03)。导航最需要考虑重排:用户必须先找到去处,才能前往任何地方。
- 修复: 在断点处将导航折叠为移动端布局:主要目的地不多时使用底部导航,其余情况则使用菜单。让链接不再挤在一行中,并确保主要目的地只需拇指点击一次即可到达。在窄屏宽度下确认布局正常(R-35)。
只有汉堡图标
- 表现: 所有内容都藏在没有标签或提示的汉堡图标后面,用户可能意识不到菜单的存在,也不知道点击后会打开什么。
- 原因: 单独使用汉堡图标,意味着假设用户知道该图标的含义,也知道后面藏着一个菜单。移动端用户可能并不具备这些认知,而隐藏菜单可能是移动端用户浏览整个应用的唯一途径(R-03)。
- 修复: 让菜单易于发现:为汉堡图标添加标签(“菜单”),或让主要目的地保持可见,只隐藏次要目的地。如果某项重要内容只能通过菜单访问,就必须让这种访问方式显而易见。
底部导航遮挡内容
- 表现: 固定的底部导航栏覆盖内容,挡住列表的最后几项、最后一个按钮,或用户正在填写的表单。
- 原因: 固定栏会占用小屏幕上的实际空间。如果没有为其预留空间,内容就会滚动到它下面,用户无法访问被遮挡的部分,尤其是页面最底部的内容(R-03)。
- 修复: 为内容预留导航栏的高度:在页面上设置滚动内边距,并在设备需要时处理安全区域内边距,确保重要内容不会被它遮挡。在窄屏宽度下确认最后一项仍可访问(R-35)。
粘性导航占据屏幕空间
- **表现:**粘性页眉或高大的底部栏占据大量固定高度,导致手机屏幕总有很大一块被导航占用。
- **原因:**在小视口中,固定界面元素每占用一个像素,内容就少一个像素。高大的粘性页眉会让可视区域变成信箱式窗口,内容则只剩一小条(R-03)。
- **修复:**保持固定导航紧凑:尺寸要足够小,让内容仍占主导地位;并在适当情况下于滚动时折叠或缩小。导航应当存在,但不应成为屏幕的主要占用部分。
Layoutmobile 技能检查清单
当任务涉及移动端或响应式布局时,请与核心交付门禁一并执行以下检查。所有答案都必须是 是:
- 布局是否会重排为独立的移动端状态,而不是被挤压的桌面端布局?(R-03)
- 是否针对整个宽度范围定义了不同状态,而不只是手机和桌面端,以确保平板和小尺寸笔记本宽度下不会出现被拉伸的堆叠布局或拥挤的网格?(R-03、R-35)
- 尺寸(字体、内边距、间距、区块高度)是否采用移动端比例,而非直接沿用桌面端尺寸?(R-03、R-05)
- 多列网格是否会折叠并堆叠,而不是相互碰撞?(R-03)
- 是否没有横向溢出,也没有被裁切的内容?(R-03)
- 交互目标是否至少为 44 x 44 px,且彼此之间留有间距?(R-03)
- 仅支持悬停的交互是否有对应的点击操作,并提供可见反馈?(R-03)
- 导航是否会重排为移动端样式(底部导航或菜单),而不是被挤压的桌面端导航行?(R-03)
- 固定导航栏(底部导航、粘性页眉)是否不会遮挡内容,并且遵循安全区域?(R-03)
- 是否已在移动端断点下验证布局?(R-35)
评论
支持 Markdown