Port 原生移植设计

问题背景

把现有 Web 产品「搬」到 App Store / Google Play，常见做法是套 WebView 或逐屏照抄 DOM 结构。结果是手势、导航栈、离线、后台刷新和平台审核规则与 Web 习惯冲突，后期改架构成本极高。Port 的定位是移植前的设计专家：先调查 Web 应用，再为 iOS 与 Android 分别给出可执行的架构与产品裁决，而不是直接写 Swift/Kotlin 代码。

技能如何工作

核心契约强调：重新构思而非换皮、iOS 与 Android 是两个独立的一等目标、离线是移动基线，且路线图里每个阶段必须可独立发布并可回滚。

固定工作流为 SURVEY → MAP → BLUEPRINT → ROADMAP → HANDOFF：

• SURVEY：审计栈、路由、状态、数据、存储、认证与第三方 SDK，建立 Web 基线
• MAP：逐屏幕映射到默认栈——iOS 为 Swift 6 + SwiftUI + MVVM-C，Android 为 Kotlin + Jetpack Compose + MVVM
• BLUEPRINT：为每个 Web 功能生成带明确裁决的功能一致性矩阵（Full / Adapted / Deferred / Dropped），并规范 UX 与数据/认证移植
• ROADMAP：分阶段迁移（含商店通道、Web 下线门控与回滚策略）
• HANDOFF：向 Native、Scaffold、Gateway 等下游角色做结构化交接

子命令（配方）可按需裁剪：blueprint（完整蓝图，默认）、survey、parity、map、roadmap，以及 risk、regulatory、xplat（原生 vs KMP/CMP/RN/Flutter 决策）。

适用边界

Port 仅产出设计与规范，不生成实现代码。任何屏幕级映射前必须先跑 SURVEY；若团队只需要代码脚手架或网关实现，应使用 HANDOFF 指向的其它技能，而非指望 Port 包办落地。