
Impeccableadapt全指南把适配从缩放像素重构为面向新场景的体验再设计【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccableImpeccableThe design language that makes your AI harness better at design将网页跨屏适配沉淀为一个可执行的命令流程adapt。本文以技能参考文档 adapt.md 为骨架完整讲解它的评估 → 规划 → 实施 → 验证工作流、移动/平板/桌面/打印/邮件五类目标场景的策略矩阵以及文档内嵌的响应式设计深度参考并结合仓库源码说明命令的触发条件、原生平台路由与质量验证机制。读完你将掌握一套可直接照做的多端适配方法论与配套 CSS 技术栈断点、容器查询、clamp()、pointer/hover特性检测、安全区、响应式图片等。1.adapt命令在 Impeccable 技能体系中的定位在 Impeccable 的 22 个命令中adapt属于Fix修复类别职责是针对不同设备与屏幕尺寸适配现有设计。技能入口文档 SKILL.src.md 的命令表这样登记它adapt [target]— Fix — Adapt for different devices and screen sizes — reference/adapt.md · native: reference/adapt.native.md命令元数据文件 command-metadata.json 则明确了它的触发语义与参数形态adapt: { description: Adapt designs to work across different screen sizes, devices, contexts, or platforms. Implements breakpoints, fluid layouts, and touch targets. Use when the user mentions responsive design, mobile layouts, breakpoints, viewport adaptation, or cross-device compatibility., argumentHint: [target] [context (mobile, tablet, print...)] }也就是说当用户提到响应式设计、移动端布局、断点、视口适配、跨设备兼容时模型应加载并执行adapt参数既可以是目标文件/路由[target]也可以是期望的目标场景[context]如 mobile、tablet、print。1.1 Web 专属守卫原生平台另有路由adapt.md开头就声明了一条硬性边界Web onlymobile web 包含在内。原生平台ios/android/adaptive应改走 adapt.native.md如果项目是原生的立即切换。仓库根目录的 CLAUDE.md 进一步解释了这套路由机制命令的 native 变体reference/command.native.md在 Web 与原生平台分歧过大、无法共享一个文件时才会存在其 Web 版本会携带一行web-only守卫把误入的原生读者重定向走。adapt.native.md就是这样的变体之一另一个是audit.native.md覆盖 ios / android / adaptive 三种平台取值每次为这些命令补充内容时需要同时维护两个文件。从技能文档看平台取值由PRODUCT.md的## Platform段记录缺失时默认web——因此大多数静态网页 / SPA 项目都会正确命中本文描述的 Web 流程。另外CLAUDE.md 还明确 live 模式、detectCLI 与设计 hook 均为 Web-only原生项目会跳过这类浏览器驱动的工具这也侧面印证adapt 的 Web 变体是整个网页设计语言能力的核心出口之一。1.2 入口正文的两条信息adapt.md在首行提供了附加上下文请求target platforms/devices and usage contexts——即执行前必须明确目标平台 / 设备 / 使用场景。正文第一句则点明了整个命令的世界观这也是本文反复强调的主线The trap is treating adaptation as scaling. The job is rethinking the experience for the new context.陷阱是把适配当成缩放真正的任务是围绕新场景重新思考体验。2. 第一步评估适配挑战Assess Adaptation Challenge动手改代码之前先回答三组问题弄清要从哪里来、到哪里去、路上有什么坑。① 识别源上下文当前设计为什么而做原本为哪种形态设计桌面 Web移动 App隐含了哪些假设大屏幕、鼠标输入、高速网络……在当前上下文里哪些已经工作得很好② 理解目标上下文要去哪里设备手机、平板、桌面、电视、手表、还是打印输入方式触摸、鼠标、键盘、语音、还是游戏手柄屏幕约束尺寸、分辨率、方向横/竖屏网络高速 Wi-Fi、慢速 3G、还是离线使用场景通勤路上 vs 工位桌前、快速一瞥 vs 专注阅读用户预期用户在这个平台上期待什么③ 找出适配的难点什么放不下内容、导航、功能什么行不通触摸屏上的 hover、过小的点击目标什么不合适移动端套桌面模式、桌面端套移动模式关键红线适配是面向新场景的体验再设计而不是把像素等比缩放。这一个判断决定了后面所有策略的取舍方向。3. 第二步规划适配策略——五类目标场景的策略矩阵adapt.md为五个典型目标场景分别给出了 Layout布局、Interaction交互、Content内容、Navigation导航四个维度的策略。下表是它们的浓缩版本后文各小节给出可直接落地的细节。场景布局要点交互要点内容要点导航要点桌面 → 移动单列、垂直堆叠、通栏组件44×44px 最小触控目标、滑动手势、底部弹层、拇指优先渐进披露、优先主内容、文字更短、16px 最小字号汉堡菜单 / 底部导航、降低复杂度、粘性头部平板混合双列、侧栏承载次要内容、主从视图列表详情、随横竖屏变化同时支持触摸与指针、触点略大但布局可更密、侧滑抽屉、多列表单介于两者之间按需展开抽屉式导航移动 → 桌面多列、充分利用横向空间、常显侧栏、多信息面板同屏、有限宽hover 补充信息、快捷键、右键菜单、拖放、Shift/Cmd 多选前置展示更多信息、宽列表格、更丰富的可视化侧栏常驻屏幕 → 打印逻辑分页、移除导航页脚与交互元素、黑白色或受限色彩、预留装订边距—展开被截断内容完整 URL、加页码页眉页脚、元信息、图表打印版移除导航Web → 邮件600px 上限、单列、行内 CSS、表格布局客户端兼容大而醒目的 CTA 按钮、不做 hover、复杂交互深链回 Web 应用精简、图文合比例单列纵向3.1 Mobile Adaptation桌面 → 移动布局单列取代多列、纵向堆叠取代并排、通栏组件取代固定宽度、底部导航取代顶部/侧边导航。交互触控目标≥ 44×44px且不依赖 hover列表与轮播适当使用滑动手势用底部弹层Bottom Sheet替代下拉拇指优先——控件要落在拇指可达范围内加大点击区与间距。内容渐进披露不要一次全部展示优先呈现主内容次要内容收进标签页/手风琴文案更短更精炼正文字号16px 起步。导航汉堡菜单或底部导航削减导航复杂度粘性头部保持上下文返回按钮融入导航流。3.2 Tablet Adaptation混合策略平板既不是大号手机也不是小号桌面布局双列为主既非单列也非三列侧栏放次要内容主从视图列表 详情联动根据横竖屏切换布局。交互同时支持触摸与精确指针保持 44×44px 触控目标但允许比手机更密的布局使用侧滑抽屉导航适当时采用多列表单。3.3 Desktop Adaptation移动 → 桌面布局多列并充分使用横向空间侧栏导航常显多个信息面板同屏展示用 max-width 约束宽度别在 4K 屏上无限拉伸。交互用 hover 提供附加信息提供快捷键右键上下文菜单有意义的拖放支持 Shift/Cmd 多选。内容减少渐进披露、把更多信息前置数据表格可以有很多列更丰富的可视化与更详细的描述。3.4 Print Adaptation屏幕 → 打印布局在逻辑节点处分页移除导航、页脚与一切交互元素转黑白或严格限制色彩为装订预留边距。内容把被截断的内容展开如展示完整 URL、隐藏章节添加页码、页眉页脚打印日期与标题等元信息图表转成适合打印的形态。3.5 Email AdaptationWeb → 邮件布局宽度上限约600px只做单列CSS 全部行内化邮件客户端不支持外部样式表用表格布局保证客户端兼容。交互用醒目的大号按钮 CTA 而非文本链接不做 hover不可靠复杂交互深链回 Web 应用。4. 第三步系统化实施适配Implement Adaptations规划完成后再动手按断点、布局、触摸、内容、导航五个技术面系统推进。4.1 响应式断点怎么选常见三段式参考移动端 320–767px、平板 768–1023px、桌面 1024px更推荐内容驱动断点拉到设计断裂的地方再设断点而不是盲从设备尺寸。4.2 布局适配技术选型CSS Grid / Flexbox让布局自动 reflowContainer Queries基于容器而非视口适配组件级复用的关键clamp()在最小与最大值之间做流式fluid尺寸Media Queries为不同上下文提供不同样式Display 属性按上下文显示/隐藏元素。4.3 触摸适配触控目标提升到44×44px 以上加大交互元素间距移除依赖 hover 的交互增加触摸反馈水波纹、高亮考虑拇指热区——屏幕底部比顶部更容易够到。4.4 内容适配谨慎使用display: none隐藏的元素仍会下载渐进增强核心内容先行增强效果留给大屏屏外内容懒加载响应式图片srcset、picture。4.5 导航适配复杂导航在移动端收敛为汉堡菜单 / 抽屉移动 App 用底部导航栏桌面端侧栏导航常驻小屏用面包屑维持上下文。重要提醒一定要在真实设备上测试。DevTools 的设备模拟有用但不完美。4.6 实施阶段的永不清单NEVER在移动端隐藏核心功能——功能如果重要就让它工作NEVER默认桌面设备性能强大——请考虑无障碍需求与老旧设备NEVER在不同上下文使用不同的信息架构——会令用户困惑NEVER违背用户对平台的预期——移动用户期待移动端模式NEVER忘记移动端/平板的横屏方向NEVER盲用通用断点——用内容驱动断点NEVER忽略桌面端的触摸——许多桌面设备带触摸屏。5. 内嵌深度参考响应式设计的正确写法adapt.md的 Reference Material 段落说明以下内容原先是独立的responsive-design.md如今内联在 adapt 流程里让适配动作自带一套完整的响应式设计手册。5.1 Mobile-First从窄到宽地写先写移动端基础样式再用min-width查询逐层叠加复杂度。反模式是 desktop-firstmax-width那会让移动端用户先加载一堆用不到的大屏样式。5.2 断点内容驱动够用就好不要追逐设备尺寸——让内容告诉你哪里该断从窄开始拉伸直到设计出现断裂就在那里加断点。通常三个断点足够640 / 768 / 1024px。能用clamp()做流式取值的地方就不必上断点。5.3 检测输入方式而非只看屏幕宽度屏幕尺寸说明不了输入方式触摸屏笔记本、带键盘的平板都是反例。用pointer与hover媒体查询做特性检测/* Fine pointer (mouse, trackpad) */ media (pointer: fine) { .button { padding: 8px 16px; } } /* Coarse pointer (touch, stylus) */ media (pointer: coarse) { .button { padding: 12px 20px; } /* Larger touch target */ } /* Device supports hover */ media (hover: hover) { .card:hover { transform: translateY(-2px); } } /* Device doesnt support hover (touch) */ media (hover: none) { .card { /* No hover state - use active instead */ } }关键不要把功能建立在 hover 之上——触摸用户无法 hover。5.4 安全区Safe Areas处理刘海屏现代手机有刘海、圆角与 Home 指示条必须用env()处理body { padding-top: env(safe-area-inset-top); padding-bottom: env(safe-area-inset-bottom); padding-left: env(safe-area-inset-left); padding-right: env(safe-area-inset-right); } /* With fallback */ .footer { padding-bottom: max(1rem, env(safe-area-inset-bottom)); }同时在 meta 标签中启用viewport-fitmeta nameviewport contentwidthdevice-width, initial-scale1, viewport-fitcover5.5 响应式图片两种正确姿势①srcset宽度描述符——同一构图的不同分辨率img srchero-800.jpg srcset hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w sizes(max-width: 768px) 100vw, 50vw altHero image 原理srcset列出可用图片及其实际宽度w描述符sizes告诉浏览器这张图将要显示的宽度浏览器综合视口宽度与设备像素比挑选最合适的文件。②picture元素——艺术指导art direction需要不同裁切/构图时picture source media(min-width: 768px) srcsetwide.jpg source media(max-width: 767px) srcsettall.jpg img srcfallback.jpg alt... /picture5.6 布局适配常见模式导航三段式移动端汉堡 抽屉、平板端水平紧凑、桌面端带文字标签的完整导航表格转卡片移动端用display: block加data-label属性把表格重排成卡片渐进披露移动端可用details/summary收纳可折叠内容。5.7 测试别只信 DevToolsDevTools 设备模拟对布局有用但会漏掉真实的触摸交互真实的 CPU / 内存限制真实的网络延迟特征字体渲染差异浏览器 UI / 键盘弹出的真实占位。至少要在以下设备上测一台真实 iPhone、一台真实 Android相关时再上一台平板。廉价的 Android 手机会暴露你在模拟器上永远看不到的性能问题。6. 第四步跨上下文验证与收尾交付Verify Adaptations适配完必须跨上下文彻底测试真实设备实际手机、平板、桌面不同方向竖屏与横屏都要测不同浏览器Safari、Chrome、Firefox、Edge不同操作系统iOS、Android、Windows、macOS不同输入方式触摸、鼠标、键盘边界情况极小屏320px、极大屏4K慢速网络在限速网络上测试。当适配在每种上下文里都感觉原生时就把工作移交给/impeccable polish做最终收尾。在仓库中对应的执行入口是 polish.md注意.cursor技能副本中对应引用位于 polish.md 旁运行时按{{command_prefix}}impeccable polish调用。7. 适配质量如何被验证仓库中的响应式防线adapt不是孤立的改完就算仓库围绕响应式与适配质量建有多层验证证据可在实施与验收时对照自查。7.1audit中的响应式评分维度audit.md 作为技术质量审计参考把响应式缺陷列为明确的检查项固定宽度硬编码宽度导致移动端破碎、横向滚动窄视口内容溢出、缺少断点没有移动/平板变体。它还给出一套 0–4 的响应式评分口径0 Desktop-only移动端直接破碎1 严重问题有断点但大量失败2 部分可用移动端能用但有毛边3 良好响应式偶发触控目标或溢出问题4 优秀流式、全视口、触控目标达标。其中移动端全程触控目标过小44px被单列为一条典型缺陷——与adapt.md反复强调的 44×44px 下限完全呼应。因此执行adapt前后可顺手跑一次audit用同一套口径量化适配是否真正完成。7.2 自动化检测夹具让溢出可复现adapt.md指出的视口溢出类问题在仓库中沉淀为可回归的检测夹具fixture。例如 tests/fixtures/antipatterns 目录下的 body-text-viewport-edge.html 与 first-viewport-column-overflow.html分别对应正文贴视口边缘与首屏列溢出两类适配缺陷的样本。围绕这些样本仓库的检测器会在浏览器getComputedStylegetBoundingClientRect与 jsdomparseFloat(style.width)两条适配路径上同时断言防止某一条路径通过、真实页面却静默失效的漏检机制说明见 CLAUDE.md 与 AGENTS.md。这对实战的启示很直接断点与视口相关的修改最好配套一个最小复现样本做回归否则很容易出现本地缩窗口没事、真机溢出的适配回退。8. 收尾清单与心智模型adapt.md在全文末尾用一条 Avoid 清单收束了常见反模式同时这也是判断适配是否做对的快速自查表避免Desktop-first 设计用设备检测UA sniffing替代特性检测pointer/hover/env维护分开的移动端/桌面端两套代码库无视平板与横屏假设所有移动设备都很强大。最后用一句话把整个流程串起来先评估源与目标上下文的差异第 2 节→ 按场景矩阵制定策略第 3 节→ 用内容驱动断点与特性检测系统性实施第 4 节→ 借助响应式设计手册把细节写对第 5 节→ 在真实设备上多端验证并交给 polish第 6 节——全程记住那条贯穿始末的原则适配是把体验针对新场景重新思考而不是把像素重新缩放。如果你所在的项目在 Impeccable 的PRODUCT.md中声明为ios/android/adaptive原生平台请改读 adapt.native.md.cursor技能副本对应 adapt.native.md那里的原生适配约定与本文的 Web 约定互补但不混用。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考