Shopify 迁回原生：LLM 动摇了跨端选型前提
Shopify 弃 React Native 迁回原生，Shop 应用 12 周重写上架：一次由 LLM 触发的选型重估，与用检查点机制防住 AI 代码垃圾的工程方案。
2020 年，Shopify 高调宣布 All-in React Native，五年后却宣布全线迁回 Swift 和 Kotlin，Shop 应用只用了 12 周就完成原生重写上架。促成转向的变量不是框架本身，而是编码模型——原文称之为「核心假设变了」。这可能是第一份把 LLM 写进技术选型成本账的公开工程决策材料。今天请到移动端架构师沈亦舟，一起算算这笔账，也看看评论区那些反对意见站不站得住。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 沈老师，这篇《Native is now the future of mobile at Shopify》我读完最大的感受是：它通篇没有贬低 React Native，反而反复确认 2020 年的选择是对的、框架至今依然优秀。那这轮回迁的真实理由到底是什么？
沈亦舟： 最值得注意的是论证结构。他们明确说自己的 RN 应用跑得很快，React Native 仍然是一个优秀的框架——排除法做完，剩下的触发器就是那句话：2020 年的决策建立在一个核心假设上，「同一功能做两遍就等于两倍工作量」，而编码模型把这个假设打穿了。所以他们没有停留在「哪个框架更好」的争论里，而是从第一性原理把移动端技术栈重新推演了一遍，结论是回到原生。
小听： 「一次编写、双端复用」几乎是所有团队上 RN 的第一理由。如果这个前提被动摇，具体是哪些环节变了？他们拿出了什么证据？
沈亦舟： 证据来自原型实验：他们用 LLM 把几个核心 App 的关键模块用 Swift 和 Kotlin 重建，效果好到超出预期。具体有三件事——智能体能拿 iOS 版本当参照实现 Android 功能，反过来也成立；不写移动端的开发者能快速上手另一个技术栈并做出有效贡献；双端一致性靠共享的规格说明、测试和评审检查点来维护，成本大幅下降。注意他们没有宣称双平台成本消失了——原生的「维护两套」还在，只是智能体消化了足够多的实现、翻译、测试和评审工作，让这个成本不再是 2020 年的决定性因素。
小听： 评论区有个高赞反对意见值得摆出来：原生意味着被 App Store 审核卡脖子，有人说现在审核动辄一周；而且原生做不了热更新，Web 技术栈能做到线上 bug 到修复上线不到一小时；再加上双端同步之外往往还有 Web 端，共享逻辑的价值不是白给的。这三笔账你怎么算？
沈亦舟： 审核时间这条，同帖就有人纠正了：最近几年 App Store 审核通常 24 小时内完成，「动辄一周」是很旧的印象。热更新确实是原生拿不到的能力，但它主要救小修小补，覆盖不了大版本迭代，而且这条代价在 2020 年的账本里同样存在。关键在于：这些代价当年都被计过价、被接受过，现在变的是计价公式本身——共享实现那一头贬值了，贴着平台走那一头增值了。
小听： 既然说到中间路线——评论区另一组人提到了 KMP，说 Kotlin Multiplatform 让跨平台第一次「真的能用」，不用再往原生壳里塞 WebView。但马上有人反问：KMP 默认你的团队愿意写 Kotlin。Shopify 为什么绕开这类方案，直接双线原生？
沈亦舟： 原文没有正面评价 KMP，但它给出的选型逻辑可以推过去：原生让团队「更贴近平台能力和第一方工具链」，代码与操作系统之间的框架层和依赖层更少。KMP 本质上仍要维护一层共享框架，共享的是逻辑层，UI 和平台能力照样要各自写。既然智能体已经能把业务逻辑按平台各自翻译一遍，共享实现剩下的价值就变小了；而「少一层抽象、贴近系统能力」的价值反而在变大——平台出新特性时，你不用等框架层跟进。
小听： 迁移策略上他们做了个反直觉选择：放弃渐进式改造，全量从零重写，Shop 应用从概念验证到原生版上架只用了 12 周。从 Joel Spolsky 那篇著名的反重写檄文开始，行业对 greenfield 一直有心理阴影。他们凭什么敢？
沈亦舟： 他们给了三个理由：智能体擅长以 RN 版本为参照在 Swift 和 Kotlin 里实现同一功能；从零重写摆脱了旧代码的历史约束，能按当下最优方式重建；原型证明这条路径的速度远超从前。还有一个容易忽略的结构性差异——当年迁 RN 是把没有参照物的原生大 App 渐进改造，这次反向迁移，线上 RN 版本就是现成的行为对照，风险结构完全不同。连 300 多个屏幕、带锁屏小组件、Apple Watch 应用和 Siri 快捷指令的主应用也在迁移，年内发布。至于 Shop 那 12 周，不只是模型能力强，背后是一整套工程系统在撑——这里面有个他们踩过的坑值得展开说。
小听： 对，「防止 slop」那一节我觉得是全文最实在的部分。他们写得很直白：把 LLM 指向 RN 代码库一次性重写行不通，哪怕先让模型收集信息、冻结成规格和任务文件再实现，产出的还是大量无法发布的不可维护代码。他们的解法叫 Helix，具体怎么运转？
沈亦舟： Helix 的核心是把重写拆成检查点：开发者把它指向某个屏幕，它读完 RN 代码后提出一串小而有序的工作切片，每个切片几分钟就能评审完。然后逐个推进，每个检查点要过四关——用测试证明行为正确、和运行中的应用做视觉比对、扛过两个对抗性代码评审、最后由人点头——才允许提交并进入下一个。不完美的产出在这个系统里根本走不到下一步。而且每次评审的反馈都会被记住，整个回路随着迁移推进越来越自主。
不完美就不许过站
小听： 另一个瓶颈他们也写得很直白：智能体改代码只要几秒，但要验证改动就得驱动模拟器，靠无障碍树和截图又慢又脆，经常要人盯着。模型再强，测不了自己的产出就白搭。他们怎么把反馈回路提速的？
沈亦舟： 他们的答案是改架构，不只是改工具：把业务逻辑和 UI 彻底解耦，让逻辑能在桌面端无头运行，再通过一个 CLI 暴露给智能体——检查应用状态、跨页面导航、执行操作，全程不碰模拟器，迭代从分钟级压到毫秒级。需要真实 UI 交互时，CLI 以远程模式连上模拟器，用命令直接驱动界面，不解析布局和无障碍树，E2E 测试也跟着提速。我认为这条对大多数团队最有迁移价值：就算你不打算迁原生，「为智能体设计可无头验证的架构」也值得抄。他们那句话其实说透了：模型再好，没法快速验证自己的工作，一切归零。
别让智能体排队等模拟器
小听： 开源库的去向也在讨论里：Skia 由 William Candillon 接手、分叉改名，原仓库最终归档；每周 200 万下载的 FlashList 保留关键兼容性修复，同时在找长期托管方；Restyle 直接进入维护倒计时。Shopify 本来是 RN 生态最大的贡献者之一，这个信号对生态意味着什么？
沈亦舟： 信号很清楚：头部玩家退场，生态的维护密度会下降，FlashList 这种基础设施级库的托管交接值得持续关注。评论区也有人预测，接下来一年会有很多大机构做同样的重估——方向我同意，但要补两句。一是 Shopify 敢下这个判断，前提是从 2021 年就开始积累的 AI 工程能力，别的团队照抄结论、不抄投入，容易翻车。二是原文自己都承认 RN 在 2020 年是正确选择，所以真正可复用的不是「原生还是跨端」的结论，而是方法：找到选型背后的承重假设，检查它是否仍然成立，用原型验证后再动手。
这场回迁最值得记下的，不是 Shopify 选了什么，而是他们敢于承认「当年对的决定，现在未必还对」，并用一整套检查点系统把 AI 的产能装进了工程纪律的笼子里。当写代码的成本坍缩，稀缺的不再是产出，而是对验证成本的控制权。本文观点仅代表访谈角色设定，原始讨论见参考链接。