2020 年，Shopify 把行動 App 從原生換成 React Native，官方給的理由是不想把同一個功能寫兩次。 2026 年，Shopify 把同一支 App 換回原生——官方給的理由，還是不想把同一個功能寫兩次。
Shopify 把 React Native 換回原生
Shopify 2020 年那次遷移的三個理由，官方工程部落格寫得很白： 別把同一個功能寫兩次、讓工程師能夠跨平台工作、把追趕功能對等的時間省下來去做真正有價值的事。 六年後，2026 年 9 月，Shopify 又發了一篇部落格，標題是「Native is now the future of mobile at Shopify」，網址路徑直接叫 back-to-native—— 同一家公司、同一支 App，往反方向走。有意思的地方是官方給的解釋幾乎是鏡像的： 不是說 React Native 不好，而是說 coding agent 讓「寫兩次」的成本不再是原本那個成本了。 這句話值得攤開來檢查，因為它把一筆原本靠「工程師人力怎麼分配」算的帳， 換成了靠「agent 能不能勝任」算的帳——如果這筆帳真的成立，代表的東西遠比一家電商公司換了技術棧更大。
原文把轉折點釘在一個具體時間：到了 2025 年底，coding agent 已經不只是幫團隊把程式碼 寫得更快，而是讓他們開始懷疑，把軟體寫兩次是不是還真的等於雙倍工作量。 這句話本身帶著明顯的敘事性——把一個漸進的能力提升，包裝成一個特定時間點的頓悟， 這種說法比「我們持續觀察了一年多、逐步調整判斷」更適合寫成部落格文章的開場， 但也代表這個時間點本身值得存疑，而不是直接當成因果關係的起點。
省兩次工的算盤，兩個年份打出不同的答案
React Native 在 2020 年被 Shopify 採用時，理由清楚寫在部落格裡： 停止把同一個功能寫兩次、讓開發者能夠跨堆疊工作、少花時間追趕功能對等、多花時間交付價值。 這三條理由本質上是一種人力經濟學——同時維護一支 iOS 團隊加一支 Android 團隊， 比維護一支跨平台團隊貴，貴在每個功能都要寫、測、修兩次。這個邏輯撐了六年。
這三個理由當年寫下來的時候，背景是行動開發正在從「各平台各自一套原生團隊」的舊模式， 往「一套程式碼、多個目標」的新模式靠攏——React Native、Flutter 都在這股潮流裡搶市占。 Shopify 2020 年的選擇符合當時整個產業的判斷：與其為 iOS 和 Android 各養一支團隊， 不如壓注在一套跨平台方案上，把省下來的工程師時間，投入到能直接影響營收的功能上。
拖動分隔線比較 2020 與 2026 的理由 · 兩份各三條的清單
2020——為什麼換成 React Native
- 「Stop building the same features twice」
- 「Allow developers to work across the stack」
- 「Spend less time chasing feature parity and more time shipping value」
2026——為什麼換回原生
- 「coding models have gotten dramatically better」
- 「building the same feature in Swift and Kotlin no longer carries the cost it used to」
- 具體證據：Shop app 從 proof of concept 到上架，只花 12 週
兩份理由清單並排比較
2020 年三個理由全是人力分配問題，2026 年三個理由全是 agent 能力問題——同一家公司、同一句「別寫兩次」，撐它的邏輯整套換掉了。
把兩份理由並排看，措辭幾乎在互相回應——2020 年怕的是「同一個功能寫兩次」， 2026 年破的也是「同一個功能寫兩次」的成本，只是這次不是換技術棧省人力， 而是讓 agent 去做第二次那份工。差別在於，2020 年那三條理由裡沒有一條跟工具鏈或 AI 有關； 2026 年的答案完全建立在 agent 能力這一件事上。這代表如果 agent 這個前提不成立， 整個反轉的邏輯也站不住——值得往下拆。
12 週重建的 Shop app，算的是哪一種成本
Shopify 部落格給的具體證明，是 Shop app——不是旗艦的 Shopify app （原文說 Shopify app 才是「our biggest」那一支），而是原文說 「regularly at the top of the list in the shopping category in the app stores」、 也是第一個完成搬遷的 App。文章寫的是：在 AI 輔助下， 團隊從 proof of concept 走到重建完成、正式上架，只花了 12 週。 這個數字被放在文章很前面，顯然是想拿來當作「agent 經濟學」成立的證據。 但 12 週做的事，跟 2020 年那三條理由要處理的事，其實不是同一種成本。 2020 年講的是持續開發的重複成本——往後每加一個功能，都要在兩個平台各寫一次， 這是一筆會隨產品生命週期不斷累加的帳；12 週的 Shop app 重建，講的是一次性的搬遷成本—— 把一份已經存在、邏輯已經定案的 React Native 程式碼，轉譯成原生程式碼一次， 不是往後每個新功能都要重複搬一次。
選 Shop app 而不是旗艦 App 當第一個案例，本身也是個訊號：先在一支功能範圍較小、 風險較低的 App 上驗證 Helix 這整套流程能不能跑通，再把同一套方法用到 300 多個畫面的 旗艦 App 上。這是穩健的工程做法，但也代表 12 週這個數字目前只證明了 「流程在小範圍內可行」，還沒有證明「流程在大範圍內一樣快」—— 原文並沒有宣稱旗艦 App 也會在類似的時間內完成。
這個分別重要，因為文章沒有正面回答一個問題：搬完之後，往後新增一個功能， 是不是還得在 iOS 與 Android 兩邊各寫一次原生程式碼——只是這次「寫一次」的工由 agent 代勞， 而不是工程師。換句話說，Shopify 真正的賭注，可能不是「寫兩次不再貴」， 而是「用 agent 寫兩次，比維護一份跨平台程式碼加上偶爾要為原生 API 繞路，划算」。 這是完全不同的一筆帳，文章的敘事把它包裝成同一件事。
文章同時交代了 Shopify 自己維護的三個 React Native 開源函式庫接下來怎麼辦： FlashList——目前一週約有 200 萬次下載，是 React Native 生態裡渲染高效能列表的預設選擇—— 會繼續修「會破壞相容性」的重大問題，並且正在跟幾家公司討論由誰接手長期維護； React Native Skia 由 Shopify 贊助到 2026 年底， 原作者 William Candillon 之後會繼續獨立維護；Restyle 因為使用者基數較小，直接封存。 旗艦的 Shopify app 本身——涵蓋 300 多個畫面、桌面與鎖屏 widget、 Apple Watch app、complications、Siri Shortcuts——原文用的字是「也在進行中」， 換句話說，12 週那個漂亮數字，還沒有套用在真正龐大的那支 App 上。
這三個選擇擺在一起，其實透露了一個訊號：Shopify 不是把 React Native 整批放棄， 而是按照「這個東西還有沒有外部生態價值」分開處理。FlashList 週下載量兩百萬， 服務的是整個 React Native 社群，即使自家 App 不再用它做主力渲染，也值得繼續投入； Skia 有活躍的原作者在維護，贊助到 2026 年底再交棒是合理的過渡； Restyle 用戶基數小，直接停損。這種差異化處理跟「整批換回原生」的敘事不完全一致—— 如果原生真的全面優於 React Native，理論上應該加速淘汰所有相關函式庫， 而不是分三種不同的速度處理。
點擊欄位標題排序 · 5 個項目 × 4 個欄位
| 項目 | 類型 | 現況 | 具體依據 |
|---|---|---|---|
| Shop app | App | 已完成，原生版本已上架 | proof of concept 到重建完成、上架，只花 12 週 |
| Shopify app（旗艦） | App | 進行中，預計今年稍晚上線 | 300+ 畫面、widget、Apple Watch app、complications、Siri Shortcuts |
| FlashList | 開源函式庫 | 修相容性重大問題，長期維護權洽談中 | 週下載量約 200 萬次 |
| React Native Skia | 開源函式庫 | 續責贊助至 2026 年底，原作者獨立維護 | 由 William Candillon 之後持續開發 |
| Restyle | 開源函式庫 | 已封存，維持運作至 2026 年底後停止維護 | 使用者基數較小 |
Helix 存在的理由：模擬器比 agent 寫程式慢
Shopify 花了不少篇幅談一個更技術性的障礙，而這個障礙才是真正把「用 agent 重寫」 從口號變成可行方案的關鍵。原文說，agent 幾秒內就能改完一段程式碼， 但要驗證這段修改到底對不對，卻要花好幾分鐘——原因是驗證方式主要依賴 accessibility tree 或螢幕截圖來判斷 App 目前的狀態、執行動作、確認結果。 改一次要幾秒，驗證一次要幾分鐘：agent 大部分時間不是在寫程式，是在等模擬器。
為了解掉這個瓶頸，Shopify 把商業邏輯和 UI 徹底拆開，讓商業邏輯可以在桌面無頭執行—— 不需要開模擬器、不需要靠截圖判讀畫面，agent 對商業邏輯的每一次修改， 都能在毫秒等級跑完驗證。原文的說法是這讓迭代速度從「分鐘」變成「毫秒」。 這不是 agent 本身變聰明帶來的加速，是 Shopify 自己重新設計了一層測試架構才換來的。
第二個障礙是翻譯品質。原文有一個小標題直接叫「Preventing slop」，內容講得很坦白： 就算先讓 agent 把所有資訊蒐集齊全、凍結成規格與任務清單再去實作， 最後得到的還是一大堆無法維護、沒辦法上線的程式碼。一次性翻譯行不通， 不是因為 agent 不會寫程式，是因為它不知道什麼時候該停下來檢查。
Shopify 為此蓋了一套叫 Helix 的系統。做法是讀懂現有的 React Native 程式碼， 把整份搬遷工作切成一連串可以在幾分鐘內審完的小 checkpoint， 而不是要求 agent 一次交出完整成品。原文形容得很直接： Helix 不預期第一次輸出就是對的，而是建立一個迴圈， 讓一次不完美的嘗試沒辦法往下走，直到它變成一個夠好的結果。
值得拆開來看的是 checkpoint 切得多細。原文用的字是把工作切成 「small, ordered slices of the work」——小到可以在幾分鐘內審完， 而不是把整支 App 的搬遷包成一個巨大的提交。這個設計選擇跟前面 「改程式碼要幾秒、驗證要幾分鐘」的落差其實是同一件事：如果單位工作太大， 一次驗證失敗要重做的範圍也跟著放大，agent 要花更久才能收斂到一個 能通過四道關卡的版本。把工作切小，本質上是把每次嘗試的成本壓低， 讓迴圈可以跑得更多次而不會太貴。
點擊任一關卡看細節 · 4 道關卡
Helix 的四道關卡——一個 checkpoint 要闖過幾關才能往下走
點任一關卡查看細節
1 · 測試
「must prove its behavior with tests」——checkpoint 進到下一關前，先得有測試證明它做的事是對的，不是靠 agent 自己說沒問題。
2 · 視覺比對
「match the running app in a visual review」——邏輯測試過了不夠，畫面還得跟正在執行的 App 對得起來。
3 · 對抗式 code review
「survive two adversarial code reviewers」——兩個被設計成互相挑剔對方判斷的審查者都要放行。
4 · 人類點頭
「get a human's nod before it's committed」——前三關都過，最後還是要一個人點頭，checkpoint 才真正提交。
原文特別強調是「兩位」互相設計成對抗立場的 reviewer，而不是一位。 這個細節暗示 Shopify 不信任單一審查者一次就能抓出所有問題—— 尤其當審查對象是 agent 生成的程式碼時，單一視角的審查者本身也可能被 agent 寫得「看起來合理」的程式碼說服。兩位互相挑剔的審查者， 某種程度上是把「能不能說服審查者」這個把關動作，也做成一個對抗迴圈。
人類點頭這一關特別值得注意，因為它代表 Shopify 並沒有打算讓整個流程完全自動化。 就算前三關都是機器對機器的檢查——測試通過、畫面比對一致、兩位對抗式 reviewer 都放行—— 最後還是留了一個人類決策點。合理的推測是，如果 Shop app 也走了 Helix 這套流程， 那 12 週裡應該也含人類審查花掉的時間——但原文沒有交代 Shop app 是否真的用了 Helix、也沒有拆出人類審查佔比多少，這兩點都是推斷，不是原文寫明的事。
這套檢查機制不是裝飾。四關裡任何一關沒過，那個 checkpoint 就卡住， agent 得回頭重寫，不能帶著沒過關的程式碼繼續推進到下一個 checkpoint。 跟前面的迭代速度加在一起看，Helix 真正解決的其實是兩件事： 讓 agent 驗證一次修改的成本從分鐘級降到毫秒級，以及讓一次翻譯的品質有人把關， 而不是賭一次到位。這兩件事都跟「LLM 有沒有進步」關係不大—— LLM 一直都寫得出程式碼，Shopify 缺的是一套能快速告訴 agent 「這樣不行、重寫」的驗證迴圈，而那套迴圈是他們自己蓋的。 換句話說，如果 Shopify 只解決了模擬器瓶頸、沒有解決 slop 問題， agent 會驗證得很快，但產出一堆沒人敢上線的破碎程式碼； 如果只解決了 slop、沒有解決模擬器瓶頸，checkpoint 審查的流程雖然對， 但慢到不實用。兩個障礙缺一個，都撐不起這整個決定。
Apple Watch、complications、Siri Shortcuts——原文沒說的另一種壓力
還有一個原文沒有直接點名，但攤開 Shopify app 的功能清單就很難忽略的因素： 這支 App 涵蓋 300 多個畫面、桌面與鎖屏 widget、Apple Watch app、complications、 Siri Shortcuts。這些功能大多需要深入平台原生 API，在 React Native 裡通常得靠額外的 原生模組或 bridge 才能做到，複雜度會隨著功能數量疊加。原文完全沒有把這件事列為 換回原生的理由——列出來的理由自始至終只有 agent 經濟學——但合理的推測是， 一支功能清單長到這個程度的 App，維護跨平台 bridge 本身的成本也在增加， agent 經濟學的敘事有可能只是壓垮這個決定的其中一根稻草，而不是全部。 這一條原文沒有給出可以核實的證據，只能停在推測，不能當成定論。
這類需求在跨平台框架裡通常不是「寫不出來」，而是「每加一個原生 API， 就要多維護一層 bridge 程式碼、多測一次跨語言呼叫的邊界情況」。 widget 要讀懂 App 的即時狀態、Apple Watch complications 要在極小的記憶體與 更新頻率限制下運作、Siri Shortcuts 要跟系統層的意圖辨識打交道—— 每一項都逼近 React Native 抽象層原本想省掉的那類細節。功能清單越長， 這層維護成本越像一條隱藏的稅，跟「寫兩次」這個問題的方向不同， 但同樣會隨著時間累積。
這也解釋了為什麼原文在描述旗艦 App 進度時，只給了「will ship later this year」 這種寬鬆時窗，沒有給像 Shop app 那樣具體的週數。功能清單最長、風險最高的那支 App， 反而是進度交代得最模糊的一個。
同一週，Tailwind Labs 宣布加入 Shopify——公告是 2026 年 9 月 9 日以創辦人 Adam Wathan 具名發布的，這是另一則新聞，兩者不該混為一談， 但 Adam Wathan 那句「Shopify is also on the frontier of where user interfaces need to go next with their explorations into agentic commerce」， 倒是提供了一個旁證：Shopify 最近在前端這條線上的動作，不只是換技術棧， 還包含把更多層的介面基礎建設直接收進公司內部自己養。React Native 換回原生， 是行動端的同一種訊號。
值得追問的是，Shopify 為什麼只把「agent 經濟學」寫成理由，卻不順手把「一次性搬遷」跟 「持續開發」這兩種成本分開講清楚。一個可能的答案是，把兩種成本混在一起講的故事更好聽—— 「coding agent 讓我們重新考慮要不要跨平台」聽起來像一個時代轉折點， 「我們用 agent 把一次性的搬遷做便宜了，至於往後要不要繼續兩邊各寫一次，還沒有答案」 聽起來就沒那麼戲劇化。這不代表 Shopify 在說謊，12 週的 Shop app 案例是真的、 Helix 也是真的，只是敘事把「已經驗證的事」跟「還沒驗證的事」揉在同一句話裡。
真正的必要條件不是「LLM 進步」，是 Helix
三個假設攤開來看，沒有一個可以百分之百收斂。agent 經濟學——coding agent 讓寫兩次不再等於雙倍工時——確實是 Shopify 自己給的理由，而且用 12 週的 Shop app 重建當佐證，但這個佐證本身混淆了兩種不同的成本：一次性搬遷的成本， 和往後持續開發的重複成本，原文沒有解開這個混淆。工具鏈瓶頸——模擬器驗證太慢、 一次性翻譯只會產出 slop——則是原文自己點名、自己花最多篇幅解決的障礙， 而且 Shopify 為此蓋出一整套 Helix 檢查點系統，這代表真正的必要條件不是 「LLM 進步」這個抽象趨勢，而是「有沒有人蓋出讓 agent 能快速驗證、被擋下重寫的 那套基礎建設」。平台 API 表面的壓力——Watch app、complications、Siri Shortcuts 這類原生需求——原文完全沒有提到，只能算是攤開功能清單後的合理推測， 不能當成已核實的原因。
這也是為什麼「其他公司能不能複製 Shopify 這個決定」不是一個可以簡單回答的問題。 如果必要條件真的是 Helix 這種內部基礎建設，那複製的門檻不是等 LLM 供應商推出 更強的模型，而是自己先投入時間拆解出可以 headless 執行、快速驗證的那一層邏輯， 再設計一套多關卡的審查機制。這件事的難度跟公司既有程式碼的架構乾淨程度、 團隊願不願意先做這筆基礎建設投資都有關，不是一個等等就會自動發生的外部趨勢。
如果要抓一個可以帶走的判斷準則：看到任何團隊宣稱「agent 讓建置成本改變了」， 先問清楚改變的是哪一種成本——一次性搬遷，還是持續開發；再問清楚讓這個改變成立的， 是模型本身進步了，還是團隊自己蓋了一套能讓模型犯錯後被攔下來重寫的機制。 Shopify 這篇文章把答案寫得很清楚，只是沒有把兩種成本分開講。
Take-away：下次看到「agent 讓某件事的成本改變了」這種說法， 先確認改變的是一次性成本還是重複成本，再確認背後有沒有一套像 Helix 這樣的驗證機制撐著—— 沒有的話，那句話多半只是「model 又變強了」的另一種說法。