Impeccable 原生设计适配指南adapt.native 如何将 iOS/Android 设计跨设备、跨方向与跨平台重构【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable本文围绕 Impeccable 技能库中的原生适配参考 adapt.native.md 展开讲清楚在ios/android/adaptive平台上把一个既有的原生设计搬到新上下文另一类设备、另一种屏幕方向、另一个操作系统甚至从 Web 移植而来时的完整方法论从“源/目标上下文 破坏点”三步评估到手机→平板、方向与折叠屏、iOS↔Android 双平台互转、Web→Native 四类适配策略再到基于 size class 的实现要求与“模拟器覆盖广度、真机验证真相”的验收流程。读完你应能独立判断一次原生适配属于哪一类挑战选对重构策略并给出可落地的验证方案。一、adapt 命令的双路由Web 版与原生版分道扬镳在 Impeccable 的命令体系中adapt [target]属于 Fix 类命令命令表见 SKILL.src.mdadapt [target]| Fix | Adapt for different devices and screen sizes | reference/adapt.md · native: reference/adapt.native.md命令元数据中对其定位是“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.”见 command-metadata.json关键的路由规则写得很明确adapt.md 开篇就声明其只覆盖Web含移动 Web而“Native platforms (ios/android/adaptive) route to adapt.native.md instead; if the project is native, switch to it now.” 也就是说一旦context.mjs在 Setup 阶段记录的项目平台是ios、android或adaptive适配工作流就会切换到本文的主角——adapt.native.md。这份参考开篇给出两个前提额外上下文需求Additional context needed目标平台/设备与使用场景。没有“目标端是什么、用户怎么拿设备”这两条信息适配无从谈起核心警示把适配当成缩放scaling是陷阱。“The job is rethinking the experience for the new context”——任务是为新上下文重新思考体验而不是把像素放大缩小。它还要求在规划之前如果 Setup 阶段还没读过目标平台的参考文档必须先读 ios.md 或 android.md因为一切适配都发生在目标平台的平台约定之内。二、评估适配挑战源上下文、目标上下文、破坏点文档将评估阶段压缩为三个问题构成适配前的强制检查清单Source context源上下文这个设计原本是为什么设计的做了哪些假设只针对手机只针对竖屏只用了某一个平台的惯用法idioms还是一个网站Target context目标上下文目标设备类别phone、tablet、foldable、屏幕方向、平台以及使用姿态usage posture——单手在途操作还是双手静置操作。What breaks什么会坏哪些导航不适合目标端哪些布局只是被拉伸而非重构哪些手势或控件在目标端根本不存在第三步尤其值得展开。它把常见的适配失败模式直接点名了导航形态不匹配——例如把手机底部 Tab 原样留在平板上这正是 android.md 明令禁止的 “Never ship a phone bottom-bar untouched on a tablet”布局“stretch instead of restructure”——被拉伸的布局而非被重构的布局是手机 UI 上平板的第一失败模式手势/控件不存在——例如依赖 iOS 边缘滑动返回但目标平台只有 Predictive Back或 Web 时代的 hover 交互在触控端没有对应物。三、四类适配策略3.1 手机 → 平板iPad / 大屏文档给出的四条策略核心词是Restructure, dont stretch重构而非拉伸用 size class 切换结构iOS 使用 size classesAndroid 使用 window size classes 来驱动结构变化而不是判断设备型号。导航改变形态iPad 上 Tab bar 可以保留也可以变成侧边栏sidebarAndroid 的 navigation bar 在扩展宽度expanded width下变为 rail导航栏或 drawer抽屉。这一要求与 android.md 中 “Navigation bar (bottom, 3–5 destinations) on compact width; navigation rail or drawer on expanded width” 的规则互相印证。利用宽度split view / master-detail列表详情并排、多列网格手机上用 sheet半屏弹层的场景在平板上改用 popover。多任务是尺寸问题不是边界情况iPad Split View 和 Android multi-window 随时可能把一个手机宽度的窗口交到你手上——只要布局由 size class 驱动这两种情况“for free”地被同时处理。3.2 屏幕方向与折叠屏横屏要重构而非裁剪并排面板side-by-side panes、控件重新定位“never clip or letterbox”——绝不允许裁剪内容或留黑边。锁定方向是高门槛操作只有任务真正需要时才锁定方向后文红线清单中再次出现不得用锁方向来逃避布局 bug。折叠屏Android通过 window size classes 对 posture形态与 hinge铰链状态做出反应测试时必须覆盖folded折叠态、unfolded展开态、tabletop桌面半开态三种姿态。3.3 平台 → 平台iOS ↔ Android翻译惯用法绝不移植原文给出了一句总纲“Translate idioms; never transplant them”翻译惯用法绝不整株移植。对照表完整如下iOSAndroidTab barNavigation bar / rail / drawerEdge-swipe back, back chevronPredictive Back gesture / buttonSwitch, segmented control, system pickersMaterial switch, chips, Material pickersAction sheetBottom sheet / Material dialogSF Symbols, SF Pro, Dynamic TypeMaterial Symbols, Roboto, sp scalingSemantic system colors, materialsMaterial color roles, tonal elevationSystem push/sheet transitionsContainer transform, shared-axis, fade-through这张表里的每一项都能在两份平台参考文档中找到对应条款例如“SF Symbols, SF Pro, Dynamic Type” ↔ ios.md 的“SF Symbols 图标、San Francisco 承载 UI、Dynamic Type 系统文本样式禁止硬编码字号11 pt 下限、Body 17 pt”“Material Symbols, Roboto, sp scaling” ↔ android.md 的“Roboto 为系统字体、sp 单位而非固定 px”“Semantic system colors, materials” ↔ ios.md 的“语义系统色自动适配 Dark Mode 与高对比度raw hex 在那里会失效”“Material color roles, tonal elevation” ↔ android.md 的“角色 token 自动解析亮/暗主题禁用任意 drop shadow”。动效一行也直接对应 android.md 的 “Material motion patterns: Container transform, shared-axis, fade-through, with standard easing and durations”。跨平台时品牌如何处理文档的答案是在目标平台自己的词汇表里重建导航与控件品牌只迁移表达层expressive layer——配色的意图palette intent、字体的强调type accent、动效的性格motion personality并且必须通过目标平台的主题系统targets theming system去落地。这与 android.md 的 “brand expresses through Materials theming (color roles, type scale, shape, motion)” 以及 ios.md 的 “brand expresses through the layer the platform leaves open (tint, type, motion, content)” 完全一致品牌走主题通道结构与交互让位给平台规则。3.4 Web → Native移植网站或 Web 应用策略词是Reconform, dont reflow重新塑形而非重排。四步替换Web 导航 → 平台的导航模型HTML 形态的控件 → 平台原生控件hover 交互 → 触控优先的交互px 字号 → Dynamic TypeiOS/ spAndroid。之后的验收标准被直接锚定到平台参考文档把移植结果当作全新的原生项目完整套用对应平台参考ios.md 或 android.md并且——“the slop test there is the acceptance bar”——该平台的 slop test“像不像套皮移植”的检测就是验收线。ios.md 的 slop test 是“熟练 iPhone 用户是否会信任这个 App还是会在不符合规范的控件前停顿”其典型破绽正是 “reinvented navigation bars, custom back gestures, web-shaped buttons, hover-dependent affordances”——这恰好就是 Web 移植最容易踩中的全部四类坑。四、实现与验证size class 驱动、安全区、双端真机4.1 三条实现铁律文档的 Implement Verify 一节给出三条硬性要求结构由 size classes / window size classes 驱动永远不要做设备型号判断never from device-model checks。这是整篇文档最重要的工程决策只有 size class 才能同时覆盖旋转、Split View、多窗口、折叠屏展开/折叠等一切“同一设备的不同窗口形态”。每一种新配置下都尊重 safe areas 与 window insets刘海notch、铰链hinge、状态栏、键盘。对应 ios.md 的 “Lay out inside the safe-area insets. No controls under the notch, Dynamic Island, home indicator, or rounded corners” 与 android.md 的 “Edge-to-edge with window insets... content never hides behind system bars or the keyboard”。测试策略是“模拟器管广度真机管真相”simulators for breadth, real hardware for truth每个已发布的平台至少一台手机 一台平板两个方向支持分屏就测分屏。4.2 验证的具体手段来自平台参考的补充adapt.native.md 本身只规定“测什么”而“怎么采证”由两份平台参考给出可直接执行的命令适配完成后应按目标平台执行iOSios.md “Verifying the build”截图必须来自 Simulator 而非浏览器xcrun simctl io booted screenshot path多台模拟器运行中时用xcrun simctl list devices booted拿 UDID 替换bootedDark Mode 与 Dynamic Type 必须纳入本轮验证——xcrun simctl ui booted appearance dark切换外观再用大号 Dynamic Type 检查固定布局藏住的截断。Androidandroid.md “Verifying the build”截图来自模拟器或连接设备adb exec-out screencap -p path多设备时加adb -s serial暗色主题与字体缩放必须验证——adb shell cmd uimode night yes切主题adb shell settings put system font_scale 1.3验证后恢复1.0抓出固定布局藏住的标签截断。两份文档还有一条共同的“硬件诚实性”条款模拟器/仿真器提供广度但姿态posture、手势、刷新率与性能必须靠真机确认——“Say which one produced the evidence”说明证据由谁产生。这也正是 adapt.native.md 红线“Trust simulators alone”的具体含义折叠屏姿态、边缘滑动/预测返回手势、性能表现模拟器都替代不了。4.3 收尾交接给 polish当适配在每个上下文中都“feels native”时文档指定了下一步交接给polish命令做最终一轮。polish.md 明确其职责边界“Polish is refinement, never concealed redesign”并要求在原生平台上“the shipped device classes on the simulator, emulator, or hardware, captured per the platform references Verifying the build section”——即适配阶段建立的“多设备类 × 双方向 × 分屏”证据基线正是 polish 收集证据时的既定要求。五、红线清单五条 NEVER原文档以加粗 NEVER 收尾这五条是整篇方法论的负面边界建议在团队评审时逐条对照不得把拉伸的手机布局直接上平板不得把一个平台的控件或导航移植到另一个平台不得在小设备上隐藏核心功能“if it matters, make it work”不得用锁定屏幕方向来逃避布局 bug不得只信任模拟器姿态、手势与性能需要真机。前三条对应三类最常见的交付事故假适配、套皮移植、功能阉割后两条对应两类过程事故用锁屏掩盖横屏问题、用模拟器截图冒充完整验证。六、适用范围与限制本文适用前提是项目已被 Impeccable 识别为原生平台ios/android/adaptiveSetup 阶段由context.mjs载入平台参考Web 项目的适配应走 adapt.md其中含 Web 侧完整的断点、clamp()、pointer/hover 查询、safe-areaenv()等实操参考。adapt.native.md 本身是方法论与验收标准文档不含可执行脚本其命令入口是adapt [target]参数提示[target] [context (mobile, tablet, print...)]见 command-metadata.json截图与主题切换的具体命令则沉淀在 ios.md 与 android.md 的 “Verifying the build” 小节。参考文档中的 ios.md / android.md 内部链接在仓库中的真实位置分别是 skill/reference/ios.md 与 skill/reference/android.md本技能在仓库中同时存在于源目录 skill/reference/ 与插件打包目录 plugin/skills/impeccable/reference/两者内容一致。核心结论Impeccable 的原生适配流程把“适配”从像素问题重新定义为结构问题——先用“源/目标/破坏点”三问定位挑战再按四类迁移路径设备类、方向/折叠、跨平台、跨形态选择重构策略最终以 size class 驱动结构、safe area 兜底布局、双端真机采证并以平台 slop test 作为验收线。这套流程的最大价值在于给出了一条可审计的决策链每一步“为什么这样改”都能回溯到平台参考文档中的具体条款。【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考