Shopify迁回原生：AI没取代程序员，先取代了折中
Shopify 的工程博客宣布：移动端从 React Native 迁回 Swift 和 Kotlin 双原生。性能没出问题，框架也没翻车，出问题的是一个会计等式：AI agent 把「写两套代码」的成本打下来了，于是一套代码的必要性跟着塌了。我读完的第一反应是，这份博客其实在给过去十年的一个前提收尸。
一条工程博客，为什么值得多看五分钟
先把事情说清楚。Shopify 的移动团队在博客里把逻辑讲得很直白：当年选 React Native，是为了让一支团队同时服务 iOS 和 Android，省下一半人力。现在 agent 能并行承担双端的实现、翻译、测试和评审，这个理由消失了。省下来的那层抽象，只剩成本，没有收益。
这类新闻很容易被当成「某家公司的技术选型」，划过去就完了。但我建议停下来。因为 Shopify 拆掉的其实是一张账本，而这张账本支撑着过去十年很大一部分软件架构。
当年为什么选跨平台
跨平台框架的历史，说白了就是一部人力成本史。它向行业许诺过三次：
- 第一代，WebView 打包。Cordova 时代的口号是「会网页就能做 App」，代价是性能和体验全面让路。
- 第二代，桥接渲染。React Native 的口号是
learn once, write anywhere，让 JS 逻辑跑在原生控件上；Flutter 干脆自带渲染引擎，折中从「全面妥协」退到「大部分对齐」。 - 第三代，编译期共享。Kotlin Multiplatform 只共享业务逻辑，UI 老老实实各写各的。这是最诚实的姿态：承认 UI 省不了，只省逻辑。
三代的交割单各不相同，卖的东西从头到尾只有一样：省下那半份工资。
注意，用户从来没为「跨平台」付过钱。没有人下载 App 时会想「真好，它的代码和安卓版是同一份」。跨平台是纯供给侧的安排，它的全部合理性都建立在「工程师贵」这个事实之上。
AI agent 改写了哪一页账本
工程师还是贵。但「维护两套代码」这件事，边际成本正在塌方。
| 维度 | 跨平台方案 | AI 加持的双原生 |
|---|---|---|
| 初始开发 | 一套代码，起步快 | 两套并行生成，未必更慢 |
| 长期维护 | 抽象层升级、平台适配自己扛 | 各端独立演进，无桥接债 |
| 性能上限 | 被框架天花板压着 | 原生天花板 |
| 平台新特性 | 等框架适配 | 当天跟进 |
| 团队认知负担 | 一套技术栈 | 两套，但 agent 分担大头 |
这张表里最要命的是后两行。iOS 新系统发布当天，agent 就能读完 API 文档、给出迁移方案；框架社区还得等下一个版本。原本「一套技术栈」是跨平台最大的心理优势，等执行端外包给 agent 之后，人类团队真正要做的事变成定标准、做评审、扛产品判断。这些事，一套技术栈并不比两套更省。
折中从来不只是技术问题，它先是会计问题。账本换了一页，折中就该重新谈。
被推翻的不止一个决定
顺着这个思路往下想，会看到一排悬着的多米诺。
微服务当年为什么拆那么细？很大程度上为了让几十个团队互不阻塞地并行。BFF 层为什么存在？因为前端人力不够，需要一个给自己定制接口的缓冲带。低代码平台为什么在真正的工程团队里总上不了台面？它的收益公式同样是「专业开发者太贵」。
这些决策在当时都是对的。麻烦在于，它们的「对」锚定在一个人力成本假设上。假设变了，「对」就得重算。我猜未来两三年会陆续看到各种逆向迁移：拆细的合回来，抽象层拆掉，为了省人力做的妥协被一个个推翻。推动者未必是大厂，可能只是某个 CTO 在续约框架商业授权的那天突然想通：雇 agent 维护双端，比续这个抽象层便宜。
不是所有跨平台都会死
把话说满之前，先泼自己一盆冷水。有几类跨平台，理由跟人力成本无关，会活得好好的：
- Web 本身。浏览器是史上最成功的跨平台
runtime，它的存在理由是触达和链接，跟省钱没关系。 - 游戏引擎。Unity、Unreal 的跨平台是物理事实，没人愿意为每台主机手写渲染管线。
- 嵌入式与 IoT。跨芯片的移植层是刚需。
- Flutter 的 UI 一致性路线。有些产品就是需要三端像素级一致（想想银行和航空的 App），一致性本身就是需求。
所以更准确的判断是：死掉的不是跨平台，是「为了省人力而跨平台」这个动机。动机没了，建在动机上的东西会跟着松动。
康威定律的 AI 补丁
康威定律说，系统架构会长成组织沟通结构的形状。agent 进了团队之后，这句老话有了新读法：组织里多了一种不睡觉、不领社保、可以按需复制的成员。团队形状变了，架构自然要重新长。
以后看一家公司的技术选型，先别急着看它用什么框架。看它怎么配比人类和 agent。配比才是新的架构图。
重新算账的季节
收个尾。这件事最触动我的地方，跟 Shopify 的英明无关，跟 React Native 的失败也无关，而是我们这行做决策的方式被掀了一下桌：
- 技术选型的第一性问题，往往不在技术本身，在人力会计。
- agent 改变的与其说是「能不能写出好代码」，不如说是「什么样的妥协还值得做」。
- 手里所有「当年为了省人力」的决定，都值得拿新账本重算一遍。
- 重算的结果不必然倒向原生，也可能倒向更激进的抽象。方向不重要，重算这个动作才重要。
下次有人给你演示「一套代码，三端运行」，先别急着鼓掌。问一句：这笔账，是按人头算的，还是按 token 算的？