AI 能重写两端，小团队依然值得用 React Native

维护着一个 React Native 项目，突然看到 Shopify 把应用迁回 Swift 和 Kotlin，最容易冒出的念头大概是，下一版还要继续投这个框架吗？

尤其是老板又补了一句，AI 都能帮忙写两端了。

我觉得，对缺少原生开发经验、目前主要在交付常规业务页面的小团队，React Native 依然值得继续用。Shopify 的转向足以让我们重新算账，却还不足以替任何一个团队签下重写排期。决定迁移之前，最好拿一条真实业务流程，把它写出来、验完，再改一次。

第三步经常被漏掉。

9 月 10 日，Shopify 在官方工程博客宣布回到原生开发。它给出的理由很直接，编码 Agent 降低了两端分别实现的成本，原生平台能力的吸引力还在，于是技术选择发生变化。已经完成迁移并上架的是消费者应用 Shop，从概念验证到交付用了 12 周，其他应用还在后续计划中。

好家伙，12 周确实抓人。但拿这个周期直接估自己项目，容易漏掉它已经拥有的东西。

那个旧应用，其实是一份昂贵的答案

Shop 的迁移复盘写到，团队先让一名工程师花一周做原型，随后由六人核心团队搭原生基础和主要用户流程，中途还有业务团队加入验证边界情况。一周的原型没有达到生产可用状态。

这组信息比一句「AI 重写了整个应用」有用得多。

它不是从一份含糊需求起步。旧应用能运行，页面能打开，交互顺序能观察，代码里藏着多年形成的业务规则。Agent 有一个具体参照物，人也能指出哪里不一致。即使决定舍弃部分旧设计，团队也知道自己在舍弃什么。

想想一个假设场景，重建订单详情页。截图只告诉你按钮在哪里，没告诉你订单取消后能否再次付款、支付成功但页面没刷新时显示什么、网络恢复后重复请求该怎么处理。界面像了，业务还可能差得很远。

如果你的旧代码与产品说明各说各话，先要解决的就是谁说了算。让模型同时读它们，只会把尚未做出的产品决定藏进新代码里。等到验收发现两个平台各选一种解释，省下的输入时间又花回去了。

所以我愿意把这个旧应用看成迁移的参考答案，但它也可能带着旧错误。用户已经依赖的行为要保留，明确要修的缺陷则应该在迁移计划里单独写出来。否则新版本碰巧修了一个旧问题，也可能被测试误判成不一致。

这事儿有点绕，却很实际。复制行为与改进产品同时发生时，验收标准必须分清楚。否则每个差异都能被解释成「原生体验更好」，迁移就没有结束的那一天。

跑得更快，值得换吗

Shopify 公布了新旧版本的冷启动数据。这里的口径是从点击应用图标到首页初始内容可见。苹果端从 3200 毫秒降到 2466 毫秒，安卓端从 4433 毫秒降到 2233 毫秒。

厉害了，安卓这一项的改善确实直观。不过这是它们这次重建后的结果，我没有独立复测，也不能把它当作所有 React Native 项目迁移后的收益承诺。

对自己的产品，需要接着问，用户最难受的地方正好是启动吗？

假设你的应用打开后主要在等接口，切成 Swift 和 Kotlin 并不会让后端自动变快。如果最常见的投诉是搜索结果不准，重写列表渲染也可能没碰到主问题。把平台选择放在用户问题前面，项目很容易变成一次漂亮的技术装修。

反过来，如果产品长期依赖复杂手势、相机能力或紧贴系统的新功能，团队反复在适配层上投入，原生方案就值得认真试。这里没有万能分界线。可以从最近真正占用排期的工作出发，翻工单、看耗时，找出哪些麻烦来自框架边界，哪些只是业务本身复杂。

我更愿意看一张能追溯到工单的表，而不是听一句「跨平台性能有天花板」。后者太好说了，任何卡顿都能往里装。

还有一个比较上的公平问题。保留 React Native 的方案也应该允许合理优化，不能拿多年没人整理的旧页面，去和刚重做过的新页面比赛，然后把所有提升都记给语言。若两条路线都能达到业务要求，决定胜负的就还包括后面的维护成本。

第二次需求，才开始考团队

重写时，两端都有同一个旧版本可以照着做。重写结束以后，产品会继续变。

还是那个假设的订单页。下一版新增一个售后状态，需要更新展示、按钮、埋点和推送跳转。iOS 已合并，Android 还在处理异常分支，产品经理又改了文案。代码可以由 Agent 很快补齐，但「现在两端是否表达同一套规则」需要另一个证据。

共享代码原来替团队承担了部分同步工作。拆成两套实现以后，这份工作会进入需求、测试和发布流程。有人维护共同规则，有人看差异，有人判断能否放行。账单只是换了位置。

Shopify 的 Shop 复盘里，一个很值得看懂的细节是，他们对比的不只是截图，还包括事件名称、数量和字段，并区分时间戳这类自然变化的值。登录状态、推送和下游分析所依赖的信息，也属于连续性要求。

这张图对我最大的提醒是，验收对象比屏幕宽。

页面看起来一样，埋点少发一次，推荐和分析系统收到的世界就变了。模型说测试通过，可能只说明它写的那几条测试通过。它和实现来自同一个错误理解时，两边还挺容易互相证明。

坦率讲，我更担心小团队在这里吃亏。成员能审 JavaScript，却没有人能判断 Swift 的生命周期处理或 Kotlin 的状态管理是否合理，AI 写得越快，陌生代码积累得也越快。等线上问题出现，团队仍要能定位、修改并验证，不能把值班能力也寄托在下一轮对话上。

这不是要求人人精通两端。至少要明确，哪种问题谁能负责，哪些平台约束需要外部帮助，审不明白时是否允许停下来。这个能力可以逐步建立，但最好别在全量重写之后才发现缺人。

用一条业务流程，把争论变成证据

如果已经被这次迁移说动，我建议做一个有边界的试验。下面是给团队讨论用的模板，不是 Shopify 的内部流程，也不是我已经跑出的测试结果。

挑选一个会碰到真实数据、异常状态和导航的用户流程。纯展示页太容易给人信心，全量支付链路又可能把第一次试验拖得过重。用什么页面，取决于它能不能代表你最常交付的工作。

可以把这段任务说明交给编码助手，也留给审查的人。

目标流程：从订单列表进入详情，再返回原列表位置
参照版本：填写当前发布版本与对应提交
输入条件：正常订单、空结果、请求失败、登录过期
必须保持：状态含义、返回行为、事件名称和必要字段
允许改变：事先列明的布局与平台交互差异
执行边界：独立分支，不连接真实支付或改生产数据
验收产物：两端运行截图、行为测试、事件差异说明
未知事项：无法从现有代码确认的规则单独列出
追加任务：首次验收后，再增加一个订单状态
记录方式：分别记录实现、审查、测试和返工投入

这里没有「一键重写整个项目」。每项产物都对应一个待判断的问题。截图看表现，行为测试看规则，事件差异看系统之间的约定，未知事项交给有资格做产品决定的人。

两条路线的条件也尽量一致。保留 React Native 的方案可以用 AI，迁移原生的方案同样可以；共用一份验收标准，使用同样的设备和网络条件。你要比较的是技术路线，不能顺手把「用了新工具」的收益全算给其中一边。

验完第一版之后，再交给它一个真实的新需求。观察两端各改了什么、审查卡在哪里、测试是否能发现差异。这个小动作能暴露一次性翻译演示看不出来的问题，也更接近接下来每周会发生的工作。

记录投入时不用伪装精确。能计时就计时，不能计时就标明估算；模型费用另记，人工审查和等待时间也另记。别把「Agent 工作了多久」直接当成工程师省下的时间，因为它运行时人可能还在喂上下文、查差异或修环境。

如果试验显示原生实现解决了高频痛点，第二次改动依然顺畅，而且团队接得住审查和排障，扩大范围就有理由。如果只得到更漂亮的首屏，维护安排仍然空着，继续完善当前 React Native 项目也完全说得过去。

顺带一提，继续用框架也要留意依赖维护。Shopify 已在官方公告里分别说明 Skia、FlashList、Restyle 的后续安排，三者并不相同。项目若依赖它们，按实际用到的库检查维护说明，把必要升级纳入排期，比因为公司转向就立刻重写整套应用更具体。

我会继续盯这类迁移案例的后半程，尤其是第一次交付之后，团队怎样改需求、处理两端差异。重写的发布博客很热闹，维护的账本更接近我们的日常。

如果明天让你的项目试一个原生页面，你最想验证的是性能、开发速度，还是下一次需求来了能不能同时改对两端？