企业官网建设流程全解析

使用 impeccable adapt 完成 iOS / Android 原生界面适配：从重排版到重塑体验的完整指南

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

本文导读：impeccable adapt是 Impeccable 设计技能体系中负责跨上下文适配的命令，而 skill/reference/adapt.native.md 是其针对原生平台的专项指南——当目标项目是 iOS、Android 或跨端（adaptive）应用时，适配工作会自动路由到该文档。本文围绕这份原生适配指南展开，覆盖"先评估挑战、再选择策略、最后实现与验证"的完整流程，结合 iOS / Android 平台规范、命令路由机制与源码实现，帮助你掌握如何把一个已有原生设计迁移到新设备类型、方向、平台或来源，并最终通过impeccable polish收尾。读完你将能独立完成 Phone→Tablet、横竖屏、折叠屏、iOS↔Android 以及 Web→Native 四类典型适配，并学会用平台验收标准检验成果。

一、什么是"原生适配"：核心是重想体验，而不是缩放像素

adapt命令在 Impeccable 的命令表中被定义为："Adapt designs to work across different screen sizes, devices, contexts, or platforms. Implements breakpoints, fluid layouts, and touch targets."（见 crates/context/src/command-metadata.json）。而在 skill/SKILL.src.md 的命令路由表中，adapt有一个明确的原生变体：

路由规则是：原生平台（iOS / Android / adaptive）走adapt.native.md，Web 平台（含移动端网页）走adapt.md。这一路由在源码中也有印证——crates/context/src/context_cli.rs 中对平台值"adaptive"的解析会展开为["ios", "android"]两个平台参考。

adapt.native.md开篇就点明了这门手艺的核心命题：

The trap is treating adaptation as scaling. The job is rethinking the experience for the new context.

把适配当成缩放，是最常见的陷阱。原生适配的真正工作，是在目标平台约定（iOS 的 HIG / Android 的 Material Design 3）之内，为新的上下文重新设计体验。文档同时给出了一条重要流程约定：在开始规划之前，如果 Setup（impeccable context）尚未加载目标平台参考，应当先阅读对应的 skill/reference/ios.md 或 skill/reference/android.md。

原生适配与 Web 适配的分界

Web 版指南 skill/reference/adapt.md 强调响应式断点、srcset、容器查询等 Web 手段；而原生版完全不在这个轨道上——它不谈 CSS 媒体查询，而是谈size classes（iOS）/ window size classes（Android）、安全区、系统导航与平台控件。这正是"原生适配"区别于"响应式网页"的根本：结构切换由系统级尺寸类驱动，而不是由像素断点驱动。

二、评估适配挑战：先回答三个问题

adapt.native.md要求正式动手前完成一次结构化的挑战评估，围绕三个维度：

1. 源上下文（Source context）：它原本为谁设计？做了哪些假设？——是仅手机？仅竖屏？单一平台的惯用表达？还是一个网站？
2. 目标上下文（Target context）：目标设备类别（手机、平板、折叠屏）、方向、平台，以及使用姿态——单手行走时使用，还是双手稳定使用？
3. 什么会坏（What breaks）：装不进目标的导航？只是拉伸而不是重构的布局？在目标平台根本不存在的交互或控件（如悬停、桌面级右键菜单）？

这三个问题的答案直接决定后续策略的选择。一个典型的反面教材是：把为竖屏手机设计的列表页直接横向拉伸到 iPad 上——布局没有坏在"像素不够"，而是坏在"结构没有为宽屏重新思考"。

三、适配策略：四类典型场景的完整打法

3.1 Phone → Tablet（iPad / 大屏）：重构，不要拉伸

这是原生适配中最常见、也最容易被做成"失败模式"的场景。核心原则只有一句：Restructure, don't stretch.被放大过的手机 UI 铺在平板上，是典型的 slop 产物。正确做法是：

• 用尺寸类切换结构：iOS 用 size classes，Android 用 window size classes，而不是按设备型号写死分支。
• 导航改变形态：iPhone 的 Tab bar 在 iPad 上可以保留、也可以演变为侧边栏（sidebar）；Android 的底部导航栏在展开宽度下应变成 navigation rail（导航栏/抽屉）。
• 用足宽度：分屏视图 / master-detail（列表 + 详情并排）、多列网格、弹窗（popover）取代手机上的 sheet。
• 把多任务当成一种"尺寸"，而不是边缘情况：iPad Split View 与 Android 多窗口可能把平板塞成手机宽度——由尺寸类驱动的布局天然同时处理这两种情况，不需要额外适配。

3.2 方向（Orientation）与折叠屏

• 横屏要重构而非裁切：侧边并排的面板、重新布置的控件都是正当做法；绝不裁剪内容，也绝不 letterbox（信箱式黑边）。只有任务真正依赖特定方向时才锁定方向。
• Android 折叠屏：通过 window size classes 响应姿态（posture）与铰链；折叠态、展开态、桌面式（tabletop）三种形态都要测试。

3.3 平台对平台（iOS ↔ Android）：翻译惯用法，而不是移植控件

adapt.native.md给出了一张关键的惯用法对照表，这是"翻译"而不是"移植"的依据：

做法是：在目标平台的词汇表里重建导航和控件；品牌的表现层（调色板意图、字体强调、动效个性）则通过目标平台的主题系统（theming system）承载过来。也就是说，品牌要保留的是"表达层"，而不是"控件的形状"。

3.4 Web → Native（移植网站 / Web 应用）

这一步的动作是Reconform, don't reflow（重新对齐平台规范，而不是单纯重排）：

• 用平台的导航模型替换网页导航；
• 用平台控件替换 HTML 形状的控件；
• 用触摸优先的交互替换悬停型暗示；
• 用 Dynamic Type / sp 替换 px 字体。

完成替换后，把结果整体按目标平台的完整参考（ios.md / android.md）再过一遍——平台参考里的 slop test（见下文第四节）就是验收标准。

四、承载品牌与验收基准：平台参考中的 slop test

adapt.native.md要求适配过程中遵守目标平台约定，而这些约定的具体内容沉淀在 skill/reference/ios.md 与 skill/reference/android.md 两份平台参考中。每份参考都定义了各自的slop test（劣质设计检测标准），可作为适配验收的直接判据：

• iOS slop test："一个熟练的 iPhone 用户会信任这个 App，还是在非规范控件前迟疑？"最常见的穿帮信号是"从网站移植过来"的痕迹——重新发明的导航栏、自定义返回手势、网页形状的按钮、依赖悬停的交互。默认使用平台组件，除非有用户会感谢你的理由才偏离。
• Android slop test："一个熟练的 Android 用户会信任这个 App，还是被非规范组件绊倒？"最常见的穿帮是"穿了 Android 皮肤的 iOS 应用"——照搬 iPhone 的底部导航、无视系统 Back 手势的返回箭头、Cupertino 形状的开关和对话框。Material 3 是规则书，通过它来承载品牌。

两份参考还共同规定了一条对适配至关重要的规则：原生平台上，visitor mode（访客模式）会收窄可覆盖的表达范围——HIG / Material Design 3 在每种模式下都管理结构、导航与交互，品牌只通过平台留下的开放层（tint、字体、动效、内容 / 颜色角色、类型刻度、形状、动效）表达。这也解释了为什么"翻译惯用法"比"移植控件"更符合平台语义。

五、实现与验证：从尺寸类到真机

5.1 用尺寸类驱动结构，永不按设备型号判断

实现阶段的硬性约束（adapt.native.md原文要点）：

• 结构由 size classes / window size classes 驱动，绝不使用设备型号检查（device-model checks）。判断"是不是 iPad / 是不是折叠屏"应当来自系统给出的尺寸环境，而不是机型字符串。
• 每种新配置都要尊重安全区与窗口 inset：刘海（notch）、铰链（hinge）、状态栏、键盘都算。
• 先模拟器求广度，再真机求真相：每个发布平台至少一台手机 + 一台平板，双方向，支持分屏的平台要测分屏。

5.2 平台级验证命令（来自平台参考）

iOS 侧 skill/reference/ios.md 的 Verifying the build 明确：截图必须来自模拟器（Simulator），绝不能用浏览器：

# 在模拟器中构建运行后截图 xcrun simctl io booted screenshot <path> # 多台模拟器同时运行时，用 UDID 替代 booted（display name 可能重名，UDID 不会） xcrun simctl list devices booted # 深色模式验收 xcrun simctl ui booted appearance dark

同时要求在验收中加入Dark Mode 与大号 Dynamic Type——一次大字号检查能暴露固定布局下被截断的文字；并诚实标注证据来源（模拟器给出广度，姿态、手势、性能需要真机）。

Android 侧 skill/reference/android.md 则要求截图来自模拟器或连接的真机：

# 构建安装后截图 adb exec-out screencap -p > <path> # 多设备时用 -s <serial> 指定目标 # 深色主题验收 adb shell cmd uimode night yes # 字体缩放验收（1.3 倍，结束后恢复 1.0） adb shell settings put system font_scale 1.3

同样要求"模拟器给广度，姿态、刷新率、性能需要硬件"。

5.3 原生平台验证的深度要求

原生适配的验证粒度比 Web 更高：skill/reference/polish.md 在收尾阶段要求按平台参考的 Verifying the build 在模拟器/模拟器/硬件上覆盖发布的全部设备类别；skill/reference/ios.md 还强调 iOS 上 Edge-swipe back 是肌肉记忆，永远不要禁用或覆盖左缘返回手势；Android 侧则要求System Back 始终可用（尊重预测式返回手势与返回按钮），并使用 window insets 处理状态栏、导航栏、显示开孔与 IME（键盘）inset。

六、收尾：交给impeccable polish

当适配在每个上下文中都"感觉原生"之后，adapt.native.md明确要求交给impeccable polish做最终一轮：

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

polish是"精修而非隐式重设计"（见 skill/reference/polish.md）：它保留既有视觉世界、内容与行为，按"流程与层级 → 布局与字体 → 色彩与图片图标 → 交互与状态 → 内容与代码"的顺序修复漂移，并以完整的路径走查（原生平台上为手机/平板两种尺寸类、两种支持方向）作为验收收尾。

七、绝对红线：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）。

八、实战速查：一条完整适配链路

综合本指南，一次规范的 native 适配在 Impeccable 中的完整链路是：

1. 确认路由：项目平台为ios/android/adaptive（PRODUCT.md 的## Platform字段），命令路由到 skill/reference/adapt.native.md；若尚未加载目标平台参考，先读 skill/reference/ios.md 或 skill/reference/android.md。
2. 评估挑战：回答"源上下文 / 目标上下文 / 什么会坏"三问（见第二节）。
3. 选择策略：按第四节的四类场景对号入座，用平台惯用法对照表做"翻译"。
4. 实现：由 size classes / window size classes 驱动结构，尊重安全区与窗口 insets。
5. 验证：模拟器/模拟器截图求广度（iOS 用xcrun simctl、Android 用adb），真机求真相，深色模式与动态字号（Dynamic Type / 字体缩放）必须纳入验收。
6. 收尾：交给impeccable polish做最终质量通过，并以本节 NEVER 清单做终检。

参考文档与源码延伸：skill/reference/adapt.native.md（本文主体）、skill/reference/adapt.md（Web 版适配对照）、skill/reference/ios.md 与 skill/reference/android.md（平台规范）、skill/SKILL.src.md（命令路由与 Setup 流程）、crates/context/src/command-metadata.json（adapt命令描述）、crates/context/src/context_cli.rs（adaptive平台解析为 iOS + Android）。

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