
impeccable 的 adapt 命令从响应式断点到多设备体验重构的完整实践指南【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本文以 impeccable 设计系统的adapt技能参考文档skill/reference/adapt.md为主体骨架结合仓库中的技能清单skill/SKILL.src.md、命令元数据skill/scripts/command-metadata.json与配套参考文件系统讲解如何把一个既有设计正确适配到新的设备、屏幕尺寸、平台或使用场景。读完你不仅掌握断点、媒体查询、触控目标、安全区等技术手段更能理解 impeccable 反复强调的第一原则——适配adaptation是重新思考新上下文中的体验而不是缩放像素scaling pixels。一、定位adapt 在 impeccable 命令体系中的角色在 impeccable 的技能模型中adapt属于Fix修复类别的命令其职责是为不同设备与屏幕尺寸进行适配与polish收尾质量、audit技术审计、optimize性能等相邻命令互为补充。它在 skill/SKILL.src.md 的命令表中被登记为adapt [target]| Fix | Adapt for different devices and screen sizes命令元数据文件 skill/scripts/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 等具体的目标形态。Web-only 路由规则adapt的 Web 参考仅适用于 Web含移动端 Web。如果项目是 iOS / Android / 自适应原生的则必须改读原生变体 skill/reference/adapt.native.md。这一点在参考文档开头即被强制声明仓库中该文档的多个镜像副本.opencode/、.claude/、.cursor/、plugin/、skill/等目录下的skills/impeccable/reference/adapt.md保持同一内容说明这是一条全局生效的约定而非局部建议。原生适配的核心思路是把结构交给size classes / window size classes驱动、绝不依赖设备型号判断并翻译translate而非移植transplant平台习语——例如 iOS 的 Tab bar 对应 Android 的 Navigation bar/rail/draweredge-swipe back 对应 Predictive Back。此外adapt文档开头标注了Additional context needed: target platforms/devices and usage contexts意味着执行前必须向用户确认目标平台、设备与使用语境这是 impeccable 所有命令先评估、再动手纪律的一部分。二、第一步评估适配挑战Assess Adaptation Challenge在动手前先弄清楚要适配什么、为什么适配、适配成什么样。参考文档要求依次完成三项评估1. 识别源上下文source context它最初为谁而设计桌面 Web移动 App隐含了哪些假设大屏、鼠标输入、快速网络在当前上下文中哪些表现良好2. 理解目标上下文target context逐一回答以下维度维度关键问题设备Device手机、平板、桌面、电视、手表还是打印输入方式Input method触摸、鼠标、键盘、语音、手柄屏幕约束Screen constraints尺寸、分辨率、横竖屏方向网络Connection高速 Wi-Fi、慢速 3G、还是离线使用语境Usage context移动中 vs 桌前、快速一瞥 vs 专注阅读用户预期User expectations用户在该平台上期待什么样的交互3. 识别适配挑战什么放不下内容、导航、功能什么不工作触屏上的 hover、过小的触控目标什么不合时宜把桌面模式搬到手机、或反过来需要格外注意源文档中把识别挑战标为CRITICAL适配是为新的上下文重新思考体验并非像素缩放。三、第二步制定按上下文分化的适配策略Plan Adaptation Strategy参考文档为五类典型上下文给出了差异化策略。设计适配时不能照抄单一模板而要因上下文施策。移动端适配桌面 → 手机布局多列改单列、并排改垂直堆叠、固定宽度改全宽组件、顶部/侧边导航改底部导航交互触控目标最小44×44px不得依赖 hover适合处使用滑动手势列表、轮播用底部弹层bottom sheets替代下拉菜单拇指优先设计控制在拇指可达范围内加大点按区域与间距内容渐进披露progressive disclosure不要一次全展示主内容优先次要内容收进 tab/手风琴文案更短更凝练字号不小于 16px导航汉堡菜单或底部导航降低导航复杂度吸顶 header 提供上下文在导航流中保留返回按钮。平板适配混合方案布局双栏而非单栏或三栏侧边面板放次要内容主从master-detail视图列表 详情按横竖屏方向自适应交互同时支持触摸与指针触控目标仍为44×44px但允许比手机更密集的布局侧滑抽屉导航合适处使用多列表单。桌面适配手机 → 桌面布局用多栏利用横向空间侧边导航常驻可见多信息面板同屏呈现采用固定宽度配合max-width约束不要拉伸到 4K交互hover 呈现附加信息键盘快捷键右键上下文菜单合适的拖放Shift/Cmd 多选内容前置展示更多信息减少渐进披露多列表格更丰富的可视化更详细的描述。打印适配屏幕 → 打印布局在逻辑节点处插入分页移除导航、页脚与交互元素黑白或受限用色为装订留出合适页边距内容展开被缩短的内容显示完整 URL、被隐藏的章节加页码、页眉页脚包含元数据打印日期、页面标题图表转为打印友好版本。邮件适配Web → Email布局窄宽最大 600px只允许单栏行内 CSS不能依赖外部样式表基于表格的布局保证邮件客户端兼容性交互大而醒目的 CTA按钮而非文本链接不要依赖 hover不可靠复杂交互用深链跳转到 Web 应用完成。四、第三步系统化落地适配改动Implement Adaptations断点的选择断点应服务于内容而非设备型号清单手机320px–767px平板768px–1023px桌面1024px或者使用内容驱动断点——在布局真正断裂的地方插入断点。布局适配技术栈技术用途CSS Grid / Flexbox让布局自动重排reflowContainer Queries基于容器而非视口做适配clamp()在最小与最大值之间实现流式尺寸媒体查询media queries为不同上下文加载不同样式display 属性按上下文显示/隐藏元素触控适配触控目标增大到44×44px起步交互元素之间加大间距移除依赖 hover 的交互增加触控反馈波纹、高亮考虑拇指热区底部比顶部更易触达。内容适配谨慎使用display: none资源仍会被下载渐进增强核心内容优先大屏再叠加增强;屏外内容懒加载响应式图片srcset、picture元素。导航适配移动端把复杂导航收敛为汉堡菜单/抽屉移动 App 使用底部导航栏桌面端保持常驻侧边导航小屏上用面包屑维持位置感。文档划出的两条红线IMPORTANT一定要在真实设备上测试。DevTools 设备模拟虽有帮助但并不完美。NEVER 清单不得在移动端隐藏核心功能重要就得让它可用不得假定桌面 高性能设备考虑可访问性与老旧机器不得在不同上下文间使用不同信息架构会造成困惑不得违背平台的用户预期不得忘记手机/平板的横屏不得盲目使用通用断点应使用内容驱动断点不得在桌面端忽略触控许多桌面设备支持触控。五、第四步验证适配成果Verify Adaptations参考文档要求跨上下文做系统测试并明确列出验证矩阵真实设备在真机手机、平板、桌面上测试不同方向横屏与竖屏都要测不同浏览器Safari、Chrome、Firefox、Edge不同操作系统iOS、Android、Windows、macOS不同输入方式触摸、鼠标、键盘边界情况极窄屏320px、极宽屏4K慢速网络在限速网络下测试。验证通过的标准是适配在每个上下文里都感觉像原生设计。此时应把手稿交给/impeccable polish做最后的收尾——skill/reference/polish.md 明确 polish 是精修而非隐晦的重设计会保留现有视觉世界、内容与行为只在最窄的正确层级修复偏离missing token / one-off implementation / conceptual mismatch / local defect这与 adapt 阶段只做上下文重构的边界天然衔接。六、响应式设计的深度参考随文内联原 responsive-design.md参考文档说明其下方内容原本是独立的responsive-design.md现已内联使 adapt 流程在一处拥有完整的响应式深层参考。这八条是实践中反复验证过的准则。1. 移动优先写法要对从手机的基础样式开始用min-width查询逐层叠加复杂度。反过来的桌面优先max-width会让移动端先加载不必要的样式。2. 断点由内容驱动不要去追逐设备尺寸表让内容告诉你该在哪里断从窄屏开始拉伸直到布局破损处添加断点。通常三个断点640 / 768 / 1024px就够用。无断点的流式取值交给clamp()。3. 检测输入方式而不只是屏幕尺寸屏幕尺寸并不能告诉你输入方式。带触摸屏的笔记本、带键盘的平板都是反例。请使用 pointer 与 hover 查询/* 精细指针鼠标、触控板 */ media (pointer: fine) { .button { padding: 8px 16px; } } /* 粗糙指针触摸、触控笔 */ media (pointer: coarse) { .button { padding: 12px 20px; } /* 更大的触控目标 */ } /* 设备支持 hover */ media (hover: hover) { .card:hover { transform: translateY(-2px); } } /* 设备不支持 hover触摸 */ media (hover: none) { .card { /* 无 hover 态——改用 active */ } }关键不要依赖 hover 承载功能触屏用户无法 hover。4. 安全区处理刘海屏现代手机带有刘海、圆角与 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); } /* 带兜底值 */ .footer { padding-bottom: max(1rem, env(safe-area-inset-bottom)); }同时必须在 meta 标签开启viewport-fitmeta nameviewport contentwidthdevice-width, initial-scale1, viewport-fitcover5. 响应式图片一次性做对带宽度描述符的srcsetimg 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告诉浏览器图片在页面上会显示多宽浏览器根据视口宽度与设备像素比DPR选择最优文件。用于艺术指导的picture元素——当需要不同裁切/构图而非仅仅不同分辨率时picture source media(min-width: 768px) srcsetwide.jpg source media(max-width: 767px) srcsettall.jpg img srcfallback.jpg alt... /picture6. 布局适配的常见模式导航三段式移动端汉堡 抽屉平板紧凑横向桌面带完整文字的导航表格转卡片移动端用display: block配合data-label属性把表格转成卡片渐进披露用details/summary收纳可在移动端折叠的内容。7. 测试别只信 DevToolsDevTools 设备模拟对布局有用但会漏掉真实的触摸交互、真实的 CPU/内存约束、真实网络延迟形态、字体渲染差异、浏览器 chrome/键盘弹出形态。至少各测一台一台真 iPhone、一台真 Android、相关时测一台平板。廉价 Android 手机暴露的性能问题在模拟器上永远看不到。8. 需要回避的做法桌面优先设计用设备探测代替特性探测拆分维护移动端/桌面端两套代码库忽略平板与横屏假定所有移动设备都性能强劲。七、仓库里的相关证据adapt 如何在运行环境中被约束把adapt文档放回仓库运行环境可以看到它并不是孤立的一张纸而是与多条运行时规则咬合命令路由约束技能清单的 Routing 规则见 skill/SKILL.src.md说明无参数时读 skill/reference/routing.md 呈现上下文菜单显式或清晰隐含命令时装载对应参考文档。同时 routing 明确指出live与打包的detect.mjs仅限 Web若setup.platform为ios/android/adaptive则不应以两者领路——这正是 adapt 分为 webadapt.md与 nativeadapt.native.md两个变体的运行依据。设置会话会话开始时运行一次context.mjs装载 PRODUCT.md、DESIGN.md 与对应 surface brief并在平台为ios/android/adaptive时自动加载原生平台参考。因此执行 adapt 前应先确保上下文文件就绪。检测器联动routing 建议在scan.targets非空且项目非原生时先运行打包的detect.mjs做本地文件检测命中视口/溢出等家族问题时可把adapt纳入决策而在编辑后hooks 会在 UI 文件变更后自动重跑检测器并反馈发现可参见 skill/reference/hooks.md。反模式测试资产仓库 tests/fixtures/antipatterns 目录沉淀了大量与视口/布局适配相关的反模式样例例如first-viewport-column-overflow.html、clipped-overflow-container.html、body-text-viewport-edge.html、undersized-ui-text.html用于验证检测器与审计对适配问题的识别能力——这些夹具从侧面印证了adapt所打击的正是这类换上下文后布局/触控目标断裂的问题家族。八、一句话总结adapt的价值不在于会写几行媒体查询而在于先回答目标上下文是谁、原设计带有哪些隐含假设、两者冲突在哪再用断点、流式布局、触控目标、安全区与响应式图片等工具箱逐项重构体验最后在真实设备上完成验证并交接给polish。始终记住文档开头那句断言——The trap is treating adaptation as scaling. The job is rethinking the experience for the new context.陷阱是把适配当作缩放真正的任务是为新上下文重新思考体验。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考