<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>前端 on Trevor's Blog</title><link>http://mings.in/tags/%E5%89%8D%E7%AB%AF/</link><description>Recent content in 前端 on Trevor's Blog</description><generator>Hugo</generator><language>zh-CN</language><lastBuildDate>Tue, 15 Sep 2026 15:07:44 +0800</lastBuildDate><atom:link href="http://mings.in/tags/%E5%89%8D%E7%AB%AF/index.xml" rel="self" type="application/rss+xml"/><item><title>Shopify 从 React Native 退回原生：AI 编程时代，跨平台框架还香吗？</title><link>http://mings.in/posts/shopify-rn-native/</link><pubDate>Tue, 15 Sep 2026 15:07:44 +0800</pubDate><guid>http://mings.in/posts/shopify-rn-native/</guid><description>先说个数字：12 周。</description><content:encoded><![CDATA[<h2 id="一个-12-周的反悔">一个 12 周的&quot;反悔&quot;</h2>
<p>先说个数字：<strong>12 周。</strong></p>
<p>Shopify 的消费者应用 Shop，从概念验证到完全原生的生产版本，只花了 12 周。</p>
<p>而在这之前，Shopify 在 React Native 上投入了五年。</p>
<p>这不是个&quot;框架翻车&quot;的故事——Shopify 自己说得很清楚：<strong>React Native 并没有做错什么，它多年来一直很好地完成了任务。</strong> 直到 2025 年 1 月，公司还在公开聊 React Native 的未来规划。</p>
<p>那为什么突然推翻？</p>
<p>Shopify 工程总监 Mustafa Ali 给了一句话，我觉得是整件事里最值得琢磨的：</p>
<blockquote>
<p><strong>&ldquo;LLM 改变了我们 2020 年那个决策背后的核心假设之一。&rdquo;</strong></p>
</blockquote>
<h2 id="先把事实理清楚">先把事实理清楚</h2>
<p>Shopify 要做什么：</p>
<ul>
<li><strong>放弃跨平台方案，转向全原生开发</strong>（Swift + Kotlin）</li>
<li>消费者应用 Shop：已用 12 周完成原生重写并上线</li>
<li><strong>下一个是商家应用</strong>——300 多个屏幕，深度依赖 iOS 平台能力，这才是真正难啃的骨头</li>
</ul>
<p>有意思的是，Shopify 的态度并不&quot;悔婚&quot;。他们说 React Native 当年是正确选择，只是在新的条件下，账算不过来了。</p>
<p><strong>那条件变了什么？</strong></p>
<h2 id="核心变化ai-抹平了重复实现的成本">核心变化：AI 抹平了&quot;重复实现&quot;的成本</h2>
<p>跨平台框架的立身之本，其实就一句话：<strong>写一遍，跑两处。</strong></p>
<p>这个价值有一个前提假设——<strong>把同一件事在 iOS 和 Android 上各实现一遍，成本太高，不值得。</strong></p>
<p>Shopify 2020 年选 React Native，正是基于这个假设。</p>
<p>而到 2025 年底，他们发现情况变了：</p>
<blockquote>
<p>一个 Agent 可以看 iOS 上某功能怎么实现的，然后直接把 Android 版本写出来——反过来也一样。</p>
<p>工程师也可以去做自己并不熟悉的平台，因为 Agent 能承担掉大部分平台特定的工作。</p>
</blockquote>
<p><strong>看懂了吗？&ldquo;两端各写一遍&quot;的成本，被 AI 打下来了。</strong></p>
<p>当重复实现变得便宜，&ldquo;共享一份代码&quot;这件事省下的价值，自然就缩水了。</p>
<p>而一旦&quot;省人力&quot;不再是压倒性优势，原生的好处就重新浮现：<strong>性能、平台能力的完整访问、没有桥接层的弯路、能第一时间用上系统新特性。</strong></p>
<p>300 多个屏幕还深度依赖 iOS 平台集成——这种活儿用原生做，本来就比跨一层合适。</p>
<p><strong>以前不用原生是因为贵，现在没那么贵了。</strong></p>
<h2 id="但别急着鼓掌ai-重写远不是一键完成">但别急着鼓掌：AI 重写远不是&quot;一键完成&rdquo;</h2>
<p>如果你以为 Shopify 是&quot;把代码丢给 AI，12 周后拿到原生 App&rdquo;，那这份报道里最该看的部分你就错过了。</p>
<p><strong>他们第一次尝试，失败了。</strong></p>
<p>Shopify 最开始的做法很直接：把现有的 React Native 代码给 LLM，让它重写成原生。</p>
<p>结果——Mustafa Ali 用的词是 <strong>&ldquo;slop&rdquo;</strong>（垃圾）。加更多步骤也没解决问题。即使让模型先写规格文档和任务清单再动代码，产出的代码量依然大到工程师根本不想维护。</p>
<p><strong>这就是很多人对 AI 编程最大的误判：以为&quot;AI 能写&quot;等于&quot;AI 能交付&quot;。</strong></p>
<p>真正让项目跑通的，是他们为此专门建的一套系统，叫 <strong>Helix</strong>：</p>
<ul>
<li><strong>逐屏迁移</strong>：不试图一次重造全部，而是把每个屏幕拆成更小的块</li>
<li><strong>持续对照</strong>：一边迁移，一边跟现有 App 的行为做比对</li>
<li><strong>独立审查</strong>：单独的 Agent 先扫代码问题，再由人签核</li>
<li><strong>反馈闭环</strong>：把审查意见留存下来，让前面发现的问题能指导后续的迁移</li>
</ul>
<p>这个思路，和 Shopify CEO Tobi Lütke 在 X 上放的那句话是同一个逻辑——他当时说，因为工程师提交了审查不足的 Agent 生成代码，他&quot;正在考虑在 Shopify 禁用 Claude Code&quot;。</p>
<p><strong>连 Lütke 这种最激进的 AI 鼓吹者，都在守同一条线：Agent 的产出必须先自证，才能被人依赖。</strong></p>
<h2 id="一个没人预料到的新瓶颈">一个没人预料到的新瓶颈</h2>
<p>还有个细节特别真实，值得所有做移动端的人看一眼：</p>
<blockquote>
<p>Agent 可以在几秒钟内改完代码，但在移动模拟器里测试它，要花两倍的时间。</p>
</blockquote>
<p><strong>写代码快了，验证变慢了。</strong></p>
<p>这是 AI 编程时代最容易被忽略的错配——<strong>你的开发速度上去了，但你的验证带宽没变。</strong> 手速再快，测试环境不会跟着变快。</p>
<p>Shopify 的解法我觉得挺聪明：<strong>把业务逻辑从 UI 里剥出来</strong>，让 Agent 通过跑在桌面上的 CLI 直接跟 App 交互。</p>
<p>效果是：有些原本要几分钟的检查，现在毫秒级完成；同一个接口需要时也能驱动模拟器。</p>
<p><strong>注意这个解法本身——它又一次证明了&quot;架构清晰&quot;比&quot;工具先进&quot;更重要。</strong> 如果你的业务逻辑和 UI 糊在一起，任何 Agent 都救不了你的测试速度。</p>
<h2 id="同期还有个更夸张的案例">同期还有个更夸张的案例</h2>
<p>同一篇报道里提到另一件事，我觉得放一起看更有意思。</p>
<p>Bun 的创造者 Jarred Sumner（现在在 Anthropic）做了一次语言移植：用 <strong>64 个并行的 Claude 实例</strong>，把 JavaScript 运行时从 Zig 移植到了 Rust。</p>
<p>规模：约 <strong>100 万行代码</strong>。</p>
<p>耗时：<strong>11 天</strong>，单人监督。</p>
<p>API 成本：约 <strong>16.5 万美元</strong>。</p>
<p>合并前，现有测试套件在全部六个支持的平台上都通过了。</p>
<p>报道里那句话很戳人：<strong>一年前，这需要一个小组干好几个季度；现在，是一个人的 11 天冲刺。</strong></p>
<h2 id="但反着走的公司也有">但反着走的公司也有</h2>
<p>别急着下&quot;跨平台要完&quot;的结论。这不是一条单行道。</p>
<p>今年 5 月，开发者 Simon Willison 在博客里记过一次见闻——他遇到一位工程师，那家公司<strong>用编码 Agent 把原本分开的 iPhone 和 Android 两个 App，合并成了一个 React Native 应用。</strong></p>
<p>Willison 当时觉得奇怪：既然 Agent 让&quot;维护两套代码库&quot;变容易了，为什么还要费劲合并？</p>
<p>那位工程师的回答很实在：<strong>不怕被锁定。</strong> React Native 做了他们需要的事，如果将来情况变了，随时可以再迁回原生。</p>
<p>而 Shopify 现在做的，正是&quot;再迁回原生&quot;这个动作。</p>
<p><strong>所以真正变化的东西，不是&quot;哪个方向是对的&quot;，而是——迁移成本降低了，两个方向都变得可行了。</strong></p>
<p>以前一次技术选型是&quot;押注五年&quot;，因为推翻太贵。现在 12 周就能翻盘，选型从&quot;终身大事&quot;变成了&quot;阶段性决策&quot;。</p>
<p>这对工程师是好事，还是更累？我倾向于是好事——<strong>但它要求你的架构更干净，否则连迁都迁不动。</strong></p>
<h2 id="如果你正在纠结先问自己四个问题">如果你正在纠结，先问自己四个问题</h2>
<p><strong>1. 你的痛点是&quot;写两遍&quot;，还是&quot;两端不一致&quot;？</strong></p>
<p>前者 AI 能帮你缓解，后者还得靠架构解决。如果你的痛点其实是后者，跨平台的收益反而在上升——因为一致性是架构问题，AI 不替你解决。</p>
<p><strong>2. 你对平台能力的依赖有多深？</strong></p>
<p>像 Shopify 商家应用那样——300 多个屏幕、深度依赖 iOS 平台集成——原生带来的收益是实打实的。但如果你的 App 主要就是表单、列表、聊天，共享 UI 的代价完全可以接受。</p>
<p><strong>3. 你的业务逻辑和 UI 切干净了吗？</strong></p>
<p>Shopify 那条&quot;测试变慢&quot;的坑值得每个人警惕：<strong>如果逻辑和 UI 搅在一起，AI 帮你写得再快，验证也快不起来。</strong> 先把边界切干净，再谈用不用 AI。</p>
<p><strong>4. 你有能力管住 Agent 的产出吗？</strong></p>
<p>Shopify 建了 Helix 才跑通，第一次尝试直接产出 slop。如果你手上没有配套的审查流程和验证手段，&ldquo;让 AI 重写&quot;大概率就是给自己挖坑。</p>
<p><strong>这几个问题的答案，比&quot;哪个框架更流行&quot;重要得多。</strong></p>
<h2 id="那么回到问题跨平台框架还香吗">那么回到问题：跨平台框架还香吗？</h2>
<p>我的判断是——<strong>&ldquo;香&quot;的定义要变了。</strong></p>
<p><strong>第一，靠&quot;省人&quot;吃饭的框架，压力最大。</strong></p>
<p>如果你的框架核心卖点是&quot;一套代码两端跑，省一个团队&rdquo;，那 AI 正在直接侵蚀这个卖点。Shopify 就是个活样本。</p>
<p><strong>第二，但跨平台的价值从来不只&quot;省人&rdquo;。</strong></p>
<p>还有这些：跨端行为一致、发布节奏统一、团队认知负担低、业务逻辑不必写两遍还要保证不错位。</p>
<p><strong>AI 让&quot;写代码&quot;变便宜了，但没有让&quot;保证两端行为一致&quot;变便宜。</strong> 后者是架构问题，不是打字速度问题。</p>
<p><strong>第三，也是我最想说的：KMP 的路线，可能正好踩在这个变化的上风口。</strong></p>
<p>把现在的跨平台方案摊开看，其实分两派：</p>
<ul>
<li><strong>共享 UI 派</strong>（React Native、Flutter）：连界面都跨，省得最狠，但也最容易被&quot;AI 让原生变便宜&quot;这件事冲击</li>
<li><strong>共享逻辑派</strong>（Kotlin Multiplatform）：只共享业务逻辑，UI 各写各的原生</li>
</ul>
<p>Shopify 这次迁到的是 <strong>Swift + Kotlin</strong>——注意，<strong>是两个原生语言，其中一个是 Kotlin</strong>。</p>
<p>如果 AI 真的把&quot;平台特定实现&quot;的成本压下来了，那受益最少的恰恰是&quot;共享 UI&quot;；而&quot;共享逻辑 + 原生 UI&quot;这条路，既保住了业务逻辑单点维护的收益，又吃到了原生 UI 的红利。</p>
<p><strong>换句话说：AI 时代，&ldquo;共享什么&quot;比&quot;共享多少&quot;更重要。</strong></p>
<h2 id="我的结论">我的结论</h2>
<p>Shopify 这个案例最容易被误读成两种情况：</p>
<ul>
<li>误读一：<strong>&ldquo;React Native 不行了&rdquo;</strong> —— 不对，Shopify 自己都否认了</li>
<li>误读二：<strong>&ldquo;AI 无所不能，什么都能重写&rdquo;</strong> —— 也不对，他们第一次尝试就产出了一堆 slop</li>
</ul>
<p><strong>真实的情况更像是：AI 降低的是&quot;实现成本&rdquo;，而不是&quot;决策成本&quot;。</strong></p>
<p>什么该共享、什么该原生、架构怎么切分、验证怎么做——这些判断，AI 一点都没帮你省。Shopify 能 12 周跑通，靠的不是模型有多强，而是他们建了 Helix 那套流程去管住模型。</p>
<p><strong>所以跨平台框架还香吗？</strong></p>
<p>香。但香的理由正在从&quot;省人力&quot;，转向&quot;架构治理&quot;。</p>
<p>而选择哪个框架的答案，也正在从&quot;哪个省代码&quot;，变成——<strong>&ldquo;哪个更容易被 AI 和人都维护好&rdquo;。</strong></p>
<p>这两句话听起来很像，实际差得很远。</p>
<hr>
<p>你怎么看 Shopify 这个决定？你手上的项目，跨平台和原生的账算得过来吗？</p>
<p>欢迎评论区聊聊。</p>
<hr>
<p><em>参考资料：<a href="https://thenewstack.io/shopify-native-ai-agents/">Shopify spent years on React Native — then rebuilt everything in 12 weeks（The New Stack，2026-09-10）</a> · <a href="https://thenewstack.io/shopify-claude-code-agentsmd/">Shopify&rsquo;s CEO threatened to ban Claude Code（The New Stack）</a></em></p>
]]></content:encoded></item></channel></rss>