下一步不是立刻写 iOS
Android 首版完成后，一个自然问题出现了：下一步要不要做 iOS 和 HarmonyOS？
表面看，这是一个技术选型问题：
- SwiftUI 怎么写；
- ArkUI 怎么写；
- KMP 要不要用；
- Compose Multiplatform 是否值得考虑；
- 哪些逻辑可以共享；
- 哪些能力必须平台原生实现。
但真正开始拆这个问题后，我发现更底层的难点不是某个页面怎么写，而是：我到底应该让 AI 按什么链路去迁移。
如果协作链路错了，写得越快，偏得越远。
第一版思路：用中文施工单做中转
我最初的想法很直观。
Android 已经是事实源，Windows 侧分析 Android 工程，生成一份 iOS 施工单；Mac 侧再让 AI 按施工单实现 SwiftUI。
大概是：
Android 已验证实现
↓
中文施工单
↓
SwiftUI 实现为了降低 AI 自由发挥，我试图把施工单写得很细：颜色、字号、间距、文案、布局、状态、跳转、边界，都尽量描述清楚。
但越写越发现不对。
施工单越长，它越像一份新的产品文档，而不是已验证实现的镜像。
二次翻译会制造偏差
问题最明显地出现在 Splash 这类看似简单的页面上。
Android 版本已经验证过，但迁移到 iOS 后仍然出现细节偏差：
- 文案不一致；
- 品牌胶囊结构变化；
- loading 表达不一致；
- 安全区处理不够准确；
- 装饰元素数量和位置漂移；
- 页面气质和 Android 母版不完全一致。
这些不是某一个 padding 差了几像素，而是链路问题。
原来的流程发生了两次翻译：
Android XML / View / drawable / state
↓
中文描述
↓
SwiftUI 代码第一次翻译会丢掉实现细节，第二次翻译会让 AI 重新理解。只要中间存在“转述”，漂移就很难完全避免。
更稳的方向：让 AI 面对结构化事实
跨端迁移不能只靠“把 Android 页面描述给 iOS AI 听”。
更合理的方向是把 Android 已验证实现拆成更结构化的事实：
- 页面层级；
- 文案；
- 颜色和字号 token；
- 间距；
- 图片和 drawable；
- 状态集合；
- 交互路径；
- 数据输入输出；
- 平台差异说明。
然后让目标平台实现围绕这些事实施工。
也就是说，施工单不应该是自由散文，而应该更像平台无关的页面规格。
KMP 也不是万能答案
讨论跨端时，很容易把问题推给 KMP。
KMP 确实能共享一部分 Kotlin 逻辑，但它不能自动解决所有跨端问题。
对「宝贝轻松记」这种 App 来说，需要拆清楚：
- 数据模型是否共享；
- Repository 边界如何设计；
- 录音、ASR、权限是否平台本地实现；
- UI 状态是否能抽象；
- 页面是否保持平台原生体验；
- 隐私弹窗、系统权限、文件路径这些差异如何处理。
如果没有先拆边界，KMP 可能从提效工具变成新的复杂度来源。
个人开发者更需要低漂移流程
公司可以靠团队、设计系统、自动化工具和多人 review 来吸收跨端偏差。
个人开发者没有这么厚的缓冲层。一个人同时推进 Android、iOS、HarmonyOS，如果每个平台都靠重新理解和重新实现，维护成本会很快失控。
所以跨端迁移前，我更应该先建立一条低漂移链路：
已验证 Android 实现
↓
结构化页面规格
↓
平台差异说明
↓
目标平台实现
↓
对照验收这样 AI 才不是在“凭感觉重写”，而是在明确边界里施工。
先重构链路，再开始写代码
这次停顿对我来说很重要。
它提醒我：跨端迁移最危险的不是我不会 SwiftUI 或 ArkUI，而是我用错误的方式组织 AI。
如果我把 AI 当成万能翻译器，它会把 Android 经验翻译成一堆看起来合理但细节漂移的页面。
如果我先把事实源、规格、边界和验收方式搭好，AI 才更像一个可以协作的目标平台工程师。
所以跨端迁移的第一步，不是立刻写 iOS。
第一步是先让链路变稳。