一個 checkpoint 先被畫好了：Shopify 回到 Swift 與 Kotlin，是一套被設計過的遷移介面

（本文回顧的事件日期為 2026 年 9 月 11 日前後，Shopify 於當時公布遷移細節。）

先看一組數字：iOS 端某項載入時間從 3200 毫秒降到 2466 毫秒，Android 端從 4433 毫秒降到 2233 毫秒。數字本身不稀奇，稀奇的是產出這組數字的方式。Shopify 這次把旗下 App 從 React Native 遷回 Swift 與 Kotlin，前後只花了十二週，而且起點是一位工程師花一週做出的概念驗證。這件事真正值得看的，向來不是「原生比跨平臺快」這種結論，而是 Shopify 為了讓 AI 能搬動一整個 App，先設計了一套叫 Helix 的系統。

六年前的那句口號，和六年後的回頭

時間拉回六年前，Shopify 當時高調宣布「React Native is the Future of Mobile at Shopify」，把 Shopify Mobile、Shop、Point of Sale、Inbox 等核心應用陸續遷到 RN，甚至深度參與生態，做出了 FlashList、Restyle、React Native Skia 這些如今 RN 開發者繞不開的專案。去年他們還發過《Five years of React Native at Shopify》，裡面的成績單相當體面：頁面 P75 載入時間低於 500 毫秒，Crash-free Sessions 超過 99.9%，雙端功能一致性問題基本消解。去年底，Shopify Mobile 和 POS 才剛完成 RN New Architecture 的大規模遷移。

不到一年，方向整個調頭。而按照 Shopify 自己的說法，這次回遷的原因並非 RN 效能不達標。舊數據擺在那裡，效能從來不是這齣戲的主角。主角是 Helix，以及它背後對「AI 怎麼參與工程」的一整套設計判斷。這種「同一個技術決策在六 年內兩次高調反轉」的節奏，與我們先前談過的情懷介面為何在玩家面前失效有相似的結構：真正決定成敗的，從來是介面背後那套被設計出來的流程，而非口號本身。

先失敗一次：把 Repo 直接丟給模型

Shopify 的起點是一次失敗。他們最初的做法非常直白：把 React Native 的 Repo 交給 Claude、Codex 一類的 Coding Agent，然後下一句指令，把這個 App 改寫成 Swift 和 Kotlin。結果拿到的程式碼差到無法維護、無法發佈。就算先讓模型分析程式碼、生成規格、拆解任務再動手，產出依然是同一種結局的變體。

這個失敗值得停下來看。它說明模型的能力邊界並不在「寫不出 Swift」，而在「沒有回饋迴路時，錯誤會安靜地累積」。一段程式碼在被審查之前，品質是不可見的；審查粒度越粗，不可見的時間越長，累積的錯誤就越難回溯。Shopify 從這次失敗裡讀出的結論，後來被具體化成 Helix 的形式語言：checkpoint。

checkpoint 是一種排版

Helix 的操作方式是這樣：開發者指定一個頁面，系統先讀取現有的 React Native 實作，把遷移工作拆成許多幾分鐘內就能審完的小片段。每一個 checkpoint 必須完成幾件事，對應功能被實作、自動測試證明行為正確、與正在運行的舊 App 做視覺比較、通過兩輪對抗式程式碼審查，最後由開發者正式審查後才能提交，然後才輪到下一個 checkpoint。

把這串流程攤開看，它其實是一種排版設計。就像一份文件的好壞取決於段落怎麼切、讀者在哪裡被允許停下來消化，一個遷移專案的好壞取決於工作怎麼被切成可讀的單位。checkpoint 太大，錯誤會在裡面藏身；太小，審查本身會淹沒開發者。Shopify 選的粒度是「幾分鐘內 Review 完」，這個時間尺度本身就是設計決策，它同時約束了片段的複雜度與人的注意力。

更關鍵的是回饋的流向。每一次審查得到的修正意見，會進入後續的執行過程，所以遷移越往後，系統整體能承擔的工作越多。這套機制不要求模型一次寫對，它被明確設計成「錯誤可以出現，但必須盡可能被 AI 自己發現，而且錯誤不能越過 checkpoint」。這句話換個角度讀，就是Shopify 把系統的信任邊界畫在 checkpoint 上，而不是畫在模型身上。

這種把散落的重複勞動重新收攏成一套乾淨介面的思路，和 切面編程如何把散落邏輯重新排版 是同一種設計直覺，只是這次被排版的對象從程式碼換成了工作流程本身。

十二週，和一場不回頭的重構

流程定了，執行反而顯得簡單。團隊先做了一次概念驗證，一位工程師花一週讓 Coding Agent 根據現有 RN 應用重建出 SwiftUI 版本。專案隨後擴大到六人，從 PoC 到新的 Swift/Kotlin 版 Shop App 正式上架 App Store 和 Google Play，全程十二週。

值得注意的是，Shopify 完全沒有考慮新舊代碼長期共存。它選的是完全獨立的重構，舊 App 照常運行，新 App 在另一側長出來，長成了再替換。這個選擇和 checkpoint 的粒度設計是一體的：因為每個片段都有測試與視覺比對兜底，重構才敢不設過渡期。共存架構的代價是雙倍維護與介面妥協，而 Helix 用審查密度換掉了這份代價。

結果端，除了開頭那組載入時間的改善（iOS 約 23%，Android 約 50%），原本長期維持 99.5% 以上 Session Stability 的 Shop App，原生版本上線後提高到了 99.95% 以上。

有手就行的幻覺

回到標題裡那句質疑。把 Repo 丟給模型、下一段指令、等一個原生 App 誕生，這條路 Shopify 自己已經走過，走進去的名字叫失敗。同一個需求直接讓 AI 寫兩次，在沒有一套好用的 Harness 環境時，結果只是多一倍的 Bug 量。Helix 的價值不在模型變聰明了，在於它把「模型會出錯」當成設計前提，然後圍繞這個前提去安排錯誤被發現的位置、被攔下的關卡、被人審視的節奏。

checkpoint 怎麼切，Flow 和 Harness 怎麼互動，雙端怎麼被約束在同一套規則體系裡，這些才是 Shopify 這次遷移真正交付的東西。至於 Swift 和 Kotlin，更像是這套系統跑通之後順手收下的獎品。工具換了語言，工程換了皮，決定成敗的那層設計，從來都在模型夠不到的地方。