跨平台输的不是性能，是 agent 把写两遍打便宜了

Hello，我是飞飞。

这几天开发圈被 Shopify 一篇博客刷了屏。这家公司 2020 年把移动 app 全押 React Native。今年 1 月还在说这个框架未来光明、要继续投入。结果 9 月 10 号话锋一转：全部 app 迁回 Swift 和 Kotlin 原生。

很多人第一反应跟我一样，是不是 RN 翻车了？我把原文从头到尾读了一遍，官方在开头就把这条路堵死了：React Native 没有问题，我们的 RN app 很快。真正变的，是另外一件事。

写两遍的账变了

Shopify 当年选跨平台，理由摆出来人人都认。同一个功能不用写两遍，没有移动背景的开发者也能上手，不用天天追着两端功能对齐。这套账在人力时代完全成立，写两遍的成本高到没人愿意付。他们还专门提了一嘴，今年 1 月写那篇五年总结的时候，这个判断依然成立。RN 当时跑得好好的，今天也依然是个好框架。

变化发生在去年底。他们的原话是，LLM 改掉了 2020 年那个决定背后的一条核心假设。说人话就是，写两遍这件事，不再贵得吓人了。

他们先做了原型验证，发现 agent 拿着 iOS 版的实现当参考，能把 Android 版写出来，反过来也成立。这话不是嘴上说说，他们拿自家最大的几个 app 试过。工程师在不熟的平台也能干活，因为平台那部分脏活 agent 兜了。但原话里还跟着一句前提：原生专家仍然必不可少。维持两端一致的成本，也被共享的规格、测试和审查节点压了下去。

有个细节官方自己补了句实在话：原生意味着维护两套代码，这个成本没有消失，只是不再是决定性因素了。

这句话我盯着看了很久。与其说是认错，不如说是把账重算了一遍。天平两端，共享实现的好处被 agent 削小了，按平台写的好处一点没少。

12 周重写真的香吗

光说道理没用，看数字。他们的旗舰 Shop app，服务几亿买家，6 个工程师组成的核心小组，从原型验证到双商店上架，用了 12 周。

重写还是渐进，他们这次选了重写。行规里重写大 app 是大忌，2020 年迁 RN 时他们走的就是渐进式，因为推倒重来得停发新功能好几年。这次反过来直接推倒，理由是 agent 拿 RN 版当参考写原生很在行，重写还能甩掉历史包袱，原型显示重写速度远超从前。行规是人写的，成本变了，行规就该重估。

对比实验的结果更扎眼。Android 冷启动从 4433 毫秒降到 2233 毫秒，快了一半。会话稳定性从 99.5% 涨到 99.95%，崩溃少了 10 倍。Android 包体积砍掉 109MB，体积少了三分之一还多。构建时间降了 75%，原来等一杯咖啡，现在等一口。iOS 包体积基本没动，这份红利是 Android 独享的。Pixel 上滚动信息流能跑到 120 帧，官方还补了一句，几乎没做优化。

有个数字我觉得比成绩单更有意思。他们试过把整个 RN 代码库直接扔给模型，让它一键转原生，结果原文用了个词，slop，垃圾。一次成型跑出来的代码根本没法上线。

所以他们做了套系统叫 Helix。开发者指定一个页面，Helix 先把工作拆成一串小切片，每片必须过四道关：测试证明行为没变，和运行中的 app 做视觉比对，扛过两个专挑毛病的对抗审查 agent，最后人点头才能提交。

方案还有个防抵赖的细节：人工验收通过时，方案内容会被算进一个指纹，方案改一个字，之前的验收立刻作废。审的是哪版，写的就得是哪版。

还有条铁律值得记：迁移期间双端任何时刻都得功能对齐，以前靠共享代码库保证，现在靠开发流程硬卡。共享代码库散了，纪律不能散。

再往深一层，他们把业务逻辑跟界面彻底解耦，让 agent 通过命令行直接调业务逻辑，毫秒级迭代，绕开了模拟器那个改代码几秒、验证几分钟的死结。

所以香不香？香，但不是白捡的香。agent 把活干快了，验收那四道关一道没减。省下来的钱，全花在了确信上。

官方没写的那一半

通读全文你会发现，这篇复盘没有一个失败案例。成绩单很漂亮，流程很完整，可翻过车没有，一个字没提。

翻车史我倒是有，六月份我亲手验过一半这个判断。那会儿我用 agent 把 7600 行的 Java 老项目迁成 Kotlin，一个工作日上线。当时最值钱的反倒是我提前埋的那几道验证门，快只是顺带的好处：删旧代码前先让它交出 19 条黄金输出钉成断言，新版本任何一点行为漂移，测试立马变红。就这一道门，真抓出过编译器和老测试都发现不了的坑。

那场迁移我还干了两件笨事。105 个依赖一个一个对齐，连被构建工具偷偷抬上去的版本号都锁死。88 个路由导成清单，前后逐字节比对，客户端那头感知不到任何动静才算过关。最后拿真的数据库从头到尾冒烟一遍，又捞出两个藏得很深的 bug。你看，快是 agent 给的，敢上线是我自己一寸一寸验出来的。

坑也真的多。你要是也放手让 agent 干过活，这些场面应该眼熟。最吓人的一次，agent 把一个叫 isLiability 的字段悄悄并进了别的类。编译过，测试也绿，我把那段 diff 盯了两遍都没看出毛病。最后是流水线里一组专门唱反调的校验 agent 在报错时把它捞了回来。名字凭空消失这种事，靠肉眼是守不住的。

上周我写 Mistral 那篇，里面官方复盘的原话是，agent 碰到 bug，试几轮修复，然后停摆。那句 attempt a few fixes, and stall，跟我踩过的姿势一模一样。

把我的翻车史跟第一节那句「原生专家仍然必不可少」摆在一起，两边说的是同一件事：agent 能扛下重复实现，扛不下证明没写错。谁出的活谁自己审，等于没审。Helix 里那两个对抗审查 agent 加一个人工点头，翻译过来就是这个。

他们没写的失败案例，我猜他们也翻过，只是没写进复盘。我把我的摆在这儿，算替他们补上另一半。

那你该跟着迁吗

先别急。Hacker News 评论区里有个人泼了盆很清醒的冷水，他说 agent 能消灭双端开发，消灭不了双端发布。iOS 审核时长最近开始抽奖，同一周里有的 app 卡九天，有的八小时就过。web 技术的 app 还能不等审核直接热更新，线上 bug 一小时内修完，原生做不到。跨平台省的不只是开发那笔账，还有发布节奏这笔账，原文对后者一个字没回应。

所以我的判断分三种情况。

体验当门面的 app，性能、平台新能力、动画手感是命根子的，原生的价值回来了。这笔账重新划算。折叠屏 iPhone 一出来，多一端就是多一份活，这类团队尤其如此。

小团队、还在快速验证方向、依赖热更新快迭代的，跨平台依然成立，别被一篇大厂博客吓得推倒重来。

夹在中间的，可以看看另一条路。KMP 这套方案，业务逻辑共享一份，界面按平台各画各的。HN 上有句总结我很喜欢，说这算一种 token 优化，agent 不必再用 Swift 把逻辑重写一遍。

说白了，框架谁赢谁输还没定数，先定下来的是重复劳动这项资产在贬值。我自己是 Android 开发，看到这条新闻的心情挺微妙，我吃饭的这门手艺，正在被重新定价。这种感觉很具体。以前两个平台各养一队人，是行业默认的分工，现在这个默认被拆了，动手拆它的，是我们自己天天在用的那些 agent。

Shopify 主 app 有 300 多个屏幕，年内上线。Helix 和那套 agent 友好架构，他们说后面会写深文，我会蹲着。等它落地，正好验证一件事：重写大 app 的账，能不能一样漂亮。

你的 app 是原生还是跨平台的？如果 agent 真能把另一端写到能上线，你迁吗？评论区聊聊。