前言
很多 iOS 项目都会遇到一种很难受的需求：
- 设计稿全部更新
- 页面要整体换新
- 但业务链路已经跑通
- 不能因为换 UI 把主流程改坏
这种需求看起来像“只是换皮”，但真正做起来，最容易变成“顺手重构业务”，最后把原本稳定的链路也一起带崩。
我最近在一个已经跑通主链路的 iOS 原生项目里，用 Codex 协作做了一轮这样的 UI 替换，最后总结出一个非常有效的方法：
先定风险边界，再按页面家族推进，最后做像素级收口。
这篇文章就把这套做法完整拆开说清楚。
为什么 UI 替换最容易失控
UI 替换最大的问题，不是页面本身难写，而是大家很容易在改 UI 的过程中顺手改这些东西：
- 页面入口
- 权限判断
- 状态机
- 返回链路
- 数据映射
- 结果生成
一旦这些东西和页面一起改，问题就来了：
- UI 问题和业务问题缠在一起
- 回归成本大幅上升
- 真机联调时很难定位到底是哪一层出了问题
所以我给这类需求的第一条原则是：
UI 替换阶段，优先改表现层，不顺手改已经跑通的主链路。
第一件事：先写 risk boundary
我现在做中等以上的 UI 改造，都会先写一份边界说明。核心不是“写文档本身”，而是强迫自己先回答这两个问题：
- 哪些东西可以改？
- 哪些东西绝对不能动？
例如一轮页面 UI 替换，可以这样收边界：
这一步非常重要。它的价值不在于“形式正规”，而在于后面每次想顺手改逻辑的时候，都能把自己拉回来。
第二件事：不要按 Figma 页面推进，要按页面家族推进
很多人收到 Figma 后的自然反应是：
- 先做首页
- 再做结果页
- 再做弹窗
- 再做 tabbar
但如果每个页面之间存在大量共用 UI，这种推进方式通常很低效。
更好的做法是按“页面家族”推进，比如：
- 首页家族
- 底部导航家族
- 授权/退出弹窗家族
- 结果页家族
这样做有两个好处：
第一，结构更稳定。
第二，同类 UI 更容易沉淀成共享组件。
第三件事：把 Figma 落地拆成“两阶段”
这是我这轮工作里最重要的体会之一。
阶段 1：结构落地
先完成这些事情：
- 页面层级搭出来
- 资源接上
- 状态能切换
- 交互入口能走通
这一轮的目标不是“完美还原”，而是先把页面真正做出来。
阶段 2：像素校准
然后根据真机截图去收这些细节：
- 上下左右间距
- 字体大小和字重
- 颜色
- 图标尺寸
- 视觉居中
- safe area / home indicator
- 弹窗层级
这一轮才是让页面“看起来对”的关键。
一个顺手但很值的动作：提前识别哪些 UI 值得跨页面复用
虽然这篇重点不是讲组件复用，但有一个动作我还是建议在 UI 替换早期就做：
- 哪些卡片只是出现在不同页面里
- 哪些 section 其实只是同一骨架换了内容
- 哪些样式以后大概率还会一起改
这一步不用一开始就把所有组件都抽出来，但至少要先识别出来。因为一旦你先各写一套，后面再回头统一，成本会比你想象的大很多。
这里最关键的不是“复用率”这三个字，而是：
- 页面结构可以不同
- 但卡片本身如果视觉一致，就应该尽量共享一套表现层实现
关于首页和结果页如何收敛成同一套风险卡、指标卡，我会在另一篇里单独展开。
我最后总结出的执行顺序
如果以后再做类似需求，我会继续按这套顺序来：
- 先写 risk boundary
- 再按页面家族拆任务
- 第一轮先做结构和状态
- 第二轮按真机截图做像素校准
- 相同 UI 尽量沉淀成共享组件
总结
UI 替换真正难的，不是“能不能把页面搭出来”，而是：
能不能在不破坏业务稳定性的前提下，把页面真正做对。
如果你也在做类似的 Figma 到 iOS UI 替换，我非常建议你优先建立这三件事：
- 边界意识
- 页面家族推进
- 两阶段交付
这比一上来盲写页面，稳定得多。
