企业官网建设流程全解析

Impeccable 原生设计适配实战：用 iOS / Android 平台惯例重构体验而非缩放像素

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable

关联文档：plugin/skills/impeccable/reference/adapt.native.md

Impeccable 的adapt命令面向"把一个既有设计迁移到新上下文"这一高频场景：设备类别变了、方向变了、平台换了、或源头是网站。本文聚焦其原生分支adapt.native.md——它专门处理ios/android/adaptive三类原生项目的适配工作，核心信条只有一句话：适配是重新思考体验，不是缩放像素。读完本文，你将掌握从"评估适配挑战"到"分场景制定策略"，再到"用尺寸类驱动结构、尊重安全区、双端验证"的完整可执行方法，并能借助仓库中配套的平台参考与验证命令，把跨设备、跨平台、Web 转原生的适配做到"在每种上下文里都显得天生长在那里"。

一、这个文档在 Impeccable 技能体系中的位置

Impeccable 是一个面向 AI 设计工作流（也即其项目描述所言 "The design language that makes your AI harness better at design"）的技能包。在 SKILL.md 的 Commands 表中，adapt [target]属于Fix（修复）类命令，其官方定义为"Adapt for different devices and screen sizes"，且明确标注了路由规则：

native:reference/adapt.native.md

也就是说，当目标平台是ios/android/adaptive时，adapt命令会路由到原生参考文档；Web（含移动端 Web）则走 adapt.md。原生变体开篇即声明：在制定方案前，必须阅读目标平台的参考文档——即 ios.md 或 android.md——除非 Setup 阶段已经加载过。

平台判定来自 init.md 中记录的PRODUCT.md平台假设：web、ios、android或adaptive（"一个真正按操作系统自适应设计语言的产品"）。注意其明确边界：移动端 Web 仍属于web；"套壳网站的原生包装并不会让它的设计语言变成原生"。当平台是ios/android/adaptive时，init 会自行加载对应平台参考；adaptive则需同时加载两者。

二、第一步：评估适配挑战（Assess Adaptation Challenge）

动手前必须先回答三个问题，任何跳过这一步的适配都会退化成"机械放大"：

1. 源上下文（Source context）：这个设计当初为谁而做？它做了哪些隐含假设？——仅手机？仅竖屏？只遵循某一平台的惯用表达？它本质上是一个网站？
2. 目标上下文（Target context）：目标设备类别是什么（手机、平板、折叠屏）？方向如何？平台是什么？使用姿态是什么——单手赶路场景，还是双手放松使用场景？
3. 什么会坏（What breaks）：哪些导航在目标设备上放不下？哪些布局被拉伸而不是被重构？哪些手势或控件在目标平台上根本不存在？

这组问题与 adapt.md 中 Web 版的"源上下文 / 目标上下文 / 适配挑战"三问同构，但原生版把考察重心放在设备类别、方向、平台惯用语上——因为原生平台的适配难点从来不是 CSS 断点，而是交互范式与系统约束的迁移。

三、四大适配策略（Adaptation Strategies）

3.1 手机 → 平板（iPad / 大屏）

平板适配的第一戒律是"重构，不要拉伸"（Restructure, don't stretch）。把手机 UI 等比放大铺在平板上，是适配失败的标准形态。正确做法是：

• 用尺寸类（iOS 的 size classes）或窗口尺寸类（Android 的 window size classes）来切换整体结构，而不是依赖设备型号判断。
• 导航改变形态：iPhone 的 Tab bar 在 iPad 上保留或演化为侧边栏；Android 的导航栏（navigation bar）在加宽宽度上变成导航 rail（侧栏）或 drawer（抽屉）。
• 用足宽度：采用 split view / master-detail（列表 + 详情并排）、多列网格；手机上用 sheet 的地方，平板上改用 popover。
• 多任务是一个尺寸，不是边界情况：iPad Split View 和 Android 多窗口会把"平板"塞成"手机宽度的窗口"，而尺寸类驱动的布局会免费同时处理好这两者。

与之对应的底层约束来自 ios.md（"Tab bar for 2–5 top-level sections（承载区段，而非动作）……无自定义全局导航，无混合隐喻"）和 android.md（"导航栏（底部，3–5 个目的地）用于紧凑宽度；扩展宽度用导航 rail 或 drawer。绝不要把手机底部栏原样搬上平板"）。

3.2 方向与折叠屏（Orientation & foldables）

• 横屏要做结构重构（并排窗格、重新定位控件），绝不裁剪或加黑边（letterbox）；只有当任务真正需要时才锁定方向。
• 折叠屏（Android）：通过窗口尺寸类响应姿态与铰链；必须在折叠、展开、桌面式（tabletop）三种状态都测试。

3.3 平台 → 平台（iOS ↔ Android）

核心方法论是"翻译惯用语，绝不移植惯用语"（Translate idioms; never transplant them）。文档给出了一张关键对照表，这是跨平台适配最直接的落地清单：

实施要点：用目标平台的词汇表重建导航与控件，同时把品牌的表达层（palette intent 调色板意图、type accent 字体强调、motion personality 动效个性）通过目标平台的主题系统带过去。这与两端平台参考的"slop test"（劣质感测试）相呼应——ios.md 称之为"从网站移植过来的迹象"（自定义导航栏、自定义返回手势、Web 形状按钮、依赖 hover 的交互）；android.md 则点名"穿着 Android 皮肤的 iOS 应用"（照搬 iPhone 的底部导航、无视系统返回手势的返回箭头、Cupertino 形状的开关和对话框）是 Android 最常见的 slop。

3.4 Web → 原生（移植网站或 Web 应用）

"重新符合规范，而不是重新流动"（Reconform, don't reflow）：

• 用平台自身的导航模型替换 Web 导航；
• 用平台控件替换 HTML 形状的控件；
• 用触摸优先的交互替换 hover 类提示；
• 用Dynamic Type / sp替换 px 字号。

完成后，把结果整体过一遍完整的平台参考，该平台的 slop test 就是验收标准。

四、实施与验证（Implement & Verify）

4.1 结构由尺寸类驱动，绝不由设备型号驱动

文档的硬性要求：从尺寸类 / 窗口尺寸类驱动结构，绝不做 device-model 检查。这在两端平台参考中都有配套工具链：

• iOS（ios.md）：安全区（safe area）内布局，控件不得进入刘海、灵动岛、Home 指示条或圆角区域；系统导航栈 + sheet；边缘滑动返回必须存活，永不禁用或覆盖。
• Android（android.md）：edge-to-edge 配合窗口 insets——状态栏、导航栏、显示切割（display cutout）、IME 键盘 insets 都要处理，内容永不躲在系统栏或键盘后面；系统返回永远可用，尊重预测性返回手势。

4.2 每种新配置都要尊重安全区与窗口 insets

文档要求在每一种新配置（刘海、铰链、状态栏、键盘）下都尊重安全区与窗口 insets。这与两个平台参考的验收流程一致，同时也呼应 Web 侧 adapt.md 中的env(safe-area-inset-*)与viewport-fit=cover处理——但原生侧不是 CSS 技巧，而是系统级 insets 的硬约束。

4.3 模拟器求广度，真机求真相

文档给出明确的测试组合：每个发布平台至少一台手机和一台平板，两种方向，支持的平台做分屏测试。两端平台参考给出了可直接复制的验证命令：

• iOS（ios.md）：截图必须来自模拟器而非浏览器——xcrun simctl io booted screenshot <path>（多台模拟器时用xcrun simctl list devices booted取 UDID 替换booted）；深色模式与动态字体必须纳入测试——xcrun simctl ui booted appearance dark，并在大号 Dynamic Type 下检查截断。同时强调"模拟器给广度；姿态、手势与性能需要真机，并说明证据来自哪一端"。
• Android（android.md）：截图来自模拟器或真机——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）用于暴露固定布局掩盖的裁切。同样强调"模拟器给广度；手势、刷新率与性能需要真机"。

其他原生硬指标也值得在验证时对照：iOS每个可点控件 44×44 pt 起、正文 17 pt、11 pt 下限、SF Pro 承担 UI 而品牌字只出现于展示性时刻、语义系统色 + 一种 tint 色驱动交互、系统材质而非手搓玻璃拟态；Android触摸目标 48×48 dp 起、相邻至少 8 dp、sp 而非固定 px、Material 色彩角色与 tonal elevation、Material 3 组件与动效模式（container transform / shared-axis / fade-through）、遵循系统"移除动画"设置。这两组数字都是文档中"翻译惯用语"策略的量化锚点。

五、完成后的交接：交给 polish 做终审

文档明确规定了适配的收尾动作：

When the adaptation feels native to each context, hand off to/impeccable polishfor the final pass.

即当适配在每种上下文中都显得原生时，交接给/impeccable polish做最终一轮打磨。这与 polish.md 的定位一致——polish 是"精修，绝非暗度陈仓的重新设计"，它会保留现有视觉世界，只做缺陷分类（missing token / one-off implementation / conceptual mismatch / local defect）与最小正确层面的修复；其验证清单明确包含"原生平台在两种方向下测试手机与平板的尺寸类"，恰好是adapt.native.md产出物应达到的验收口径。两条参考由此形成闭环：adapt负责跨上下文的迁移与重构，polish负责迁移后的系统一致性与质量收口。

六、NEVER 清单：适配的五条红线

adapt.native.md以一张禁令清单收尾，任何一条被触碰都意味着适配失败：

• 不要把拉伸的手机布局发布到平板上（Ship a stretched phone layout on a tablet）；
• 不要把某一平台的控件或导航移植到另一平台（Port one platform's controls or navigation onto the other）；
• 不要在小屏设备上隐藏核心功能——"如果它重要，就让它能用"（Hide core functionality on smaller devices）；
• 不要为了绕开布局 bug 而锁定方向（Lock orientation to dodge a layout bug）；
• 不要只信模拟器——姿态、手势和性能都需要真机（Trust simulators alone）。

前三条与 ios.md、android.md 的 slop test 相互印证，后两条则与两端平台参考"Verifying the build"章节的"模拟器给广度，真机给真相"原则完全一致。把这条清单贴在每一次原生适配的验收之前，就守住了"适配 ≠ 缩放"这条方法论的生命线。

延伸阅读：想了解 Web（含移动 Web）侧的适配，可对照阅读 adapt.md；进行原生适配前务必先读目标平台参考 ios.md 与 android.md；adaptive（跨 OS 自适应设计语言）项目需同时遵循两者。平台判定与PRODUCT.md的写入规则见 init.md，adapt命令在技能命令体系中的完整定位见 SKILL.md。

【免费下载链接】impeccableThe design language that makes your AI harness better at design.项目地址: https://gitcode.com/GitHub_Trending/im/impeccable