正在加载，请稍候
一家电商平台用 AI 在 12 周内把旗舰购物应用从 React Native 重写为完全原生。这不是「原生更香」，而是原生的人力成本被 AI 改写了——前提是你要有可复用的原生底座、可灰度的发布管道，以及能自动验证「改对了」的测试资产。
2026 年 9 月 10 日，Shopify 移动端负责人 Mustafa Ali 发文宣布：原生 Swift/Kotlin 是该公司移动端的未来。旗舰购物应用 Shop 从概念验证到原生版本上架，只用了 12 周。过去十年「跨平台省人力」这条前提，第一次被技术本身动了根基。
这不是随口表态，整条决策链都公开了。2020 年全押 React Native（RN），六年里六款应用都迁了过去；2025 年 1 月，Mustafa Ali 还写过「RN 的未来是光明的」。转折点是：该团队 2021 年就开始用 LLM 写软件，到 2025 年下半年，编码模型的能力让「一个功能在两端各写一遍」不再是两倍工作量——驱动 2020 年决策的核心假设变了。
Shop 应用是第一个迁移对象，官方复盘称团队借助 AI 把从 PoC 到商店上架的完整流程压进了 12 周（迁移复盘原文）。主应用（300+ 屏幕、主屏与锁屏小组件、Apple Watch 应用、Siri Shortcuts）年内发布，Point of Sale 与 Inbox 随后。开源侧同步收尾：React Native Skia 赞助延续到 2026 年底，FlashList 正寻找长期接管方，Restyle 年底后停止维护。
另一个细节：这次选的是 greenfield（从零重建）而非 brownfield（渐进迁移）。六年前迁 RN 时选的是渐进式，理由是重写要花好几年、还得停发新功能。判断为什么反转，就是本文主题。
2020 年选 RN 的三条理由今天仍成立：不必把同一功能写两遍、开发者能跨 iOS/Android/Web 流动、不用一直追功能对齐。变的是权重。
原文里有一句关键话：原生依然意味着在两套平台上构建和维护软件，这个成本并没有消失。真正改变的是，智能体能承担实现、翻译、测试和评审的大部分工作：agent 可以用 iOS 版本作参照去实现 Android 版本，反之亦然，平台间的对齐成本被共享的规格、测试与评审检查点大幅压低。
所以结论不是「原生更香」。官方主动承认自家 RN 应用很快（P75 屏幕加载低于 500ms）。真正的判断是：不是原生变香了，而是原生的人力成本被 AI 改写了。
同期几个公开案例给的是同一组信号：Bun 把 535,496 行 Zig 用 AI 重写成 Rust，涉及 1,448 个文件、64 个并行 agent，约两天完成主体改写；Asana 用 Codex 两周迁移 4,000+ 个 Enzyme 测试文件，成本约 1.2 万美元（人工估算约五年、约 600 万美元）；Airbnb 用 LLM 六周迁移 3,500 个组件测试文件（手工估算 1.5 个工程师年）（Bun 案例、迁移案例）。
三者的共同点值得划出来：它们能在数天到数周内完成，前提都是项目本身有一套可运行的测试资产——迁移目标是测试文件，或过程被测试牢牢约束。
RN 时代 Shopify 就一直在「原生最合适」的地方写原生：性能密集型逻辑、特定动画、长时间后台任务、主屏小组件这类专用 API。直接证据是，重建端侧 E2E 框架时它用 OpenCV 匹配 Polaris 设计系统的 SVG，让测试像用户一样「用眼睛」找元素（端侧 E2E 重建）。若你的「设计系统」只是散落各页面的 JS 主题对象、原生能力调用近零，那重写不是迁移，是从零起步。
12 周是「PoC 到上架」的完整周期，不是开发工时。官方给迁移定的验收标准是「让用户觉得就是一次普通更新」：登录态保留、推送不断、埋点事件与下游系统（如推荐）依赖的上下文一个不能丢。这意味着你得先有可控灰度比例、远程开关、小时级回滚的版本管道。国内还多一层：iOS 走 App Store 审核，Android 要过国内多家应用市场，两端能力往往不是同一套。
这是最易被低估、却最决定成败的一条。为支撑迁移，团队造了内部工具 Helix（Helix 介绍），核心是「小检查点 + 严闸门」：每个检查点必须依次过四道闸——行为验证（用 CLI 暴露与 App 相同的状态和动作跑集成测试，无需模拟器，循环很快）、UI 视觉一致性评审（模型扮演挑剔的设计评审，逐条列出差异、严重度与位置）、两轮对抗式代码评审；过了才由工程师签核进入下一个。撑住这一切的是端侧回归测试：最大的应用曾因旧方案只有 50% 稳定率，不得不把整个 E2E 套件从 PR 检查里撤掉，重建到 98% 才恢复成阻塞式 CI。Bun 是同一结论的另一种说法——一个两天完成的迁移，前提是「项目本身测试充分」。
官方自己把这条路堵死了。原文写道：把 LLM 直接指向 RN 代码库、「一发入魂」地重写行不通——即使先让它搜集信息、冻结成规格与任务文件再实现，最后也会得到一大堆无法维护、无法上架的代码。这一节干脆被命名为「Preventing slop」。
我见过也踩过这类坑，模式几乎一样：决定重写，先停新功能、集中人力全量开工，测试靠人肉点。前两周进度喜人。第三周，两端行为开始漂移，埋点事件名和字段对不上，下游推荐拿到的上下文缺失；灰度一开崩溃率上台阶，商店审核又因权限说明、隐私清单没跟上被驳回。停机、回滚、返工加起来，远超原本想省下的那点双端人力。Sentry 2021 年做 JS→TypeScript 迁移（1,100 个文件、9.5 万行、约 10 名工程师、1.5 年）之所以贵，Notion 的原生迁移之所以做了七年，都不是因为工程师不够快。重写的价格，是被测试资产和工具链决定的。
抛开立场，用四条可测量的指标对照。表中数字来自 Shop 应用官方复盘（同机型、同功能路径对比）：
| 硬指标 | 原生 Swift/Kotlin | React Native / Flutter | 混合（KMP / 原生外壳 + 跨平台子模块） |
|---|---|---|---|
| 启动延迟（冷启到首屏可交互） | iOS 2,466ms / Android 2,233ms | iOS 3,200ms / Android 4,433ms（+23% / +50%） | 外壳原生即可接近原生水平 |
| 包体（release 构建） | iOS 68MB / Android 184MB | iOS 67MB / Android 293MB（Android 大 109MB，+37.2%） | 视共享逻辑占比，通常居中 |
| 系统能力调用深度 | 框架层最少，小组件/手表/Shortcuts 是一等公民 | 需经桥接与第三方库，深度能力要写原生模块 | 逻辑共享、能力走原生，是折中 |
| 长期维护成本 | 两套代码，但 AI 已压低翻译与对齐成本 | 一套代码，但要持续跟框架与依赖升级（如 RN New Architecture） | 一套逻辑 + 两端适配层，复杂度在边界定义 |
两组补充数据：稳定性会话率从 99.5%+ 升至 99.95%+，等于崩溃会话减少 10 倍；Android release 构建时间下降约 75%，iOS 基本持平。
建议把验收口径直接写进验收单：启动延迟不劣于旧版、目标降幅 ≥20%；崩溃会话率 ≤0.05%（稳定性 ≥99.95%）；核心埋点事件名/数量/字段 100% 对齐；包体变化 ≤+5%（Android 目标负增长）；商店审核一次通过，不因权限或隐私清单被驳回。
如果你在 蓝曜炬辉（www.lanyaoai.com）这类交付节奏里做移动端，我们的建议很明确：先把测试资产补齐，再动刀。测试不是重写的配套工程，而是它能否成立的前提。
问：2026 年跨平台框架要凉了吗？
不是。官方承认自家 RN 应用可以很快（P75 屏幕加载低于 500ms），生态仍在演进。变化的是「共享代码=省一半人力」这条等式不再绝对成立，而不是跨平台技术失效。
问：只有两三个移动端工程师，还有必要回原生吗？
团队越小越要先看发布设施。灰度与回滚不稳定时，重写风险会被放大。务实路径是 Kotlin Multiplatform 或「原生外壳 + 跨平台业务子模块」的混合方案。
问：12 周重写是普遍水平吗？
不是。它是存量原生模块、成熟设计系统、端侧测试重建到 98% 稳定、自研 Helix 工具链四项条件同时成立才跑出来的。缺一项，周期都会显著拉长。
问：AI 代码迁移的验收怎么做？
三步：用特征测试固化旧行为，让「改对了」可被自动判定；做 UI 视觉一致性评审，差异必须可定位、可修复；对埋点做 golden 快照，保证事件名、数量、字段不变。