Shopify迁回原生：编码Agent重写选型成本账

Shopify 宣布把全部移动应用从 React Native 迁回 Swift 和 Kotlin 原生开发，给出的理由值得所有做技术选型的人停下来看一眼：2020 年选 React Native 的核心假设是"同一功能构建两次太贵"，而编码模型变强之后，这个假设失效了。跨平台框架的经济学基础被 AI 动摇，这不只是移动端的事——API 接入侧的很多"标准做法"，同样建立在不一定永远成立的成本假设上。这篇把这笔账拆开算，最后给一份可以套用的技术选型复查清单。写这篇时我正在 4sapi（https://4sapi.com）维护多模型中转，路由策略和框架选型在这件事上惊人地相似。

一、开篇痛点：当年的正确决策，正在悄悄变错

每个团队都有一批"当年想清楚了"的决策：为了省成本选了跨平台框架、为了省 token 选了小模型、为了统一技术栈把所有服务压到一种语言上。这些决策的共同点是——它们都是等式，等号左边是收益，右边是成本，签下决策的那天等式成立。

问题在于等式两边会各自漂移。跨平台框架省下的"重复开发成本"在缩水，因为编码模型写第二份原生代码的成本越来越低；而框架本身的隐性成本（性能调优、依赖跟进、桥接层维护）没有同比例下降。同理，"用便宜模型省 token 费"的等式也在漂移：中档模型能力上来了，价格还降了，原先非旗舰不可的任务，现在路由到 Flash 档就够了。

真正的痛点不是当年的决策错了，而是没有机制发现"决策的前提已经变了"。Shopify 值得学习的地方不是迁回原生这个结论，而是它把决策背后的核心假设 explicit 化，然后定期复查。

二、Shopify 决策拆解：等式是怎么翻转的

把 Shopify 的决策还原成一个成本等式：

text

2020 年的等式：
  跨平台总成本 = 一次开发成本 + 桥接层维护 + 性能优化投入
  原生总成本   = 两次开发成本 + 两套团队维护
  结论：一次开发 << 两次开发，跨平台胜出

2026 年的等式：
  跨平台总成本 = 一次开发成本 + 桥接层维护 + 性能优化投入（基本没降）
  原生总成本   = 一次人工开发 + 一次 Agent 开发成本（大幅下降）
  结论：当 Agent 开发成本 ≈ 0，"省一次开发"的价值崩塌

三个细节说明这不是拍脑袋。第一，Shopify 并没有说 React Native 不好——明确承认框架依然出色、当年押注极其成功，只说前提变了。第二，迁移决策附带完整披露：开源库的去向、内部工作流的适配，都摆在明面上。第三，决策周期很长：从 2025 年初公开表态"持续投入 React Native"到 2026 年迁回，中间是编码模型能力的实际跃迁，而不是一时风向。

对 API 接入侧的映射很直接：路由表里"这个任务必须用旗舰模型"的条目，每季度都值得重新验证一遍——中档模型的进步速度远快于任务难度的增长速度。

三、原理速览：哪些成本是模型正在吃掉的

编码模型吃掉的不是所有成本，而是其中一类：可被明确描述的实现成本。把各类成本排一下：

成本类型	例子	编码 Agent 影响	选型权重变化
可描述实现成本	按规格写双端页面、CRUD、迁移脚本	大幅下降	"省这部分"的方案价值缩水
桥接/抽象层维护	RN 桥接、跨端兼容层、自建网关	基本不变	拥有这类成本的方案相对变贵
隐性性能成本	启动速度、包体积、内存footprint	不变	原生方案的相对优势放大
组织协调成本	跨技术栈协作、招聘、知识共享	部分下降	"统一技术栈"的理由减弱
判断与验收成本	定优先级、建基准、发现跑偏	上升	人的角色向验收端迁移

这个表的用法是纵向看自己：手头的架构决策里，哪些成本项正在被模型吃掉？如果支撑决策的主要成本项在第一行，决策需要复查；如果在第二、三行，决策还稳。

API 接入侧的对照例子：很多团队自建网关的核心理由是"官方接口格式不统一、要写转换层"——这属于第一行，模型写转换器的成本已经很低。而网关里真正难被替代的是计费、限流、审计这些第二行能力。所以结论不是"不要自建"，而是"自建的理由要更新"。

四、接入教程：把选型复查做成可执行的流程

复查不能靠感觉，要落到数据。第一件事是给每个重大架构决策建一份"假设档案"：

json

{
  "decision_id": "gw-2025-03",
  "decision": "自建 API 网关承担格式转换",
  "core_assumptions": [
    {"assumption": "多供应商格式转换需 2 人月维护/年", "cost_type": "可描述实现", "still_true": "需复查"},
    {"assumption": "计费与审计必须自建", "cost_type": "治理能力", "still_true": true},
    {"assumption": "团队只有一组后端人力", "cost_type": "组织协调", "still_true": true}
  ],
  "review_cadence": "quarterly",
  "trigger_conditions": ["模型能一次通过 80% 转换器生成任务", "维护工单连续两季下降"]
}

第二件事是写一个假设验证脚本，把"还成不成立"变成可跑的测试：

python

# 假设验证：用编码模型实测"转换层维护成本还剩多少"
import os
from openai import OpenAI

client = OpenAI(
    base_url="https://4sapi.com/v1",
    api_key=os.environ["MODEL_API_KEY"],
)

CONVERTER_SPEC = """
把下面这段 OpenAI 格式的响应转换为 Claude 格式：
{sample_response}
要求：字段映射完整、错误码对齐、附单元测试。
"""

def test_converter_generation(sample: str) -> dict:
    resp = client.chat.completions.create(
        model="deepseek-flash",   # 中档模型即可，验证的就是低成本生成
        messages=[{"role": "user", "content": CONVERTER_SPEC.format(sample_response=sample)}],
    )
    return {
        "output": resp.choices[0].message.content,
        "cost_tokens": resp.usage.total_tokens,
        # 验收标准：测试通过率、人工修改行数
        # 若"人工修改行数"连续走低，说明维护成本假设已失效
    }

判定逻辑：如果模型生成的转换器八成场景直接可用，人工只需小修，那么"转换层需要专人维护"的假设就到复查期了。反过来，计费对账、审计追溯这些治理能力的验证脚本会持续失败，这些假设仍然成立，网关继续留着。

五、推翻之后：迁移账怎么算

复查的结论如果是"决策该推翻"，下一步不是立刻动手，而是算迁移账。迁移成本至少含四项：双轨并行期的人力（新旧方案同时维护，短则一月长则一季）、回归验证成本（迁移期间所有变更都要双份测试）、发版节奏损耗（冻结期业务需求积压）、回滚预留（迁移中途叫停的退路）。Shopify 级别的决策从表态到落地用了大半年，普通团队按自身体量放大这个周期估计。

一个实用的判定门槛：只有当"新方案节省的年化成本 > 迁移总成本 × 2"时才启动迁移——两倍冗余是对迁移过程混乱程度的现实预估。算完不划算的结论同样有价值：把"已复查、维持现状"写进假设档案，这次复查就不会被重复怀疑。

六、组织层面：复查要有人负责

假设档案和验证脚本都是工具，真正让复查运转起来的是责任分配。三个角色各管一段：决策 owner 负责维护假设档案、触发季度复查；执行人负责跑验证脚本、收集工单数据；验收人（通常是架构委员会或技术负责人）负责在"推翻"结论上签字——推翻旧决策的代价大，这个权力不能下放给单个工程师。

复查会议的议程固定为三问：档案里的假设哪些变了？验证脚本的结果如何？触发条件命中了没有？半小时内出结论，要么"维持"，要么"立项评估"。没有固定节奏的复查等于没有复查——它总会让位给更紧急的事。

七、接入侧对照：路由表上的同类漂移

把这套方法平移到 API 接入侧，最直接的复查对象是路由表。三类条目值得每季度重测：标注"必须用旗舰模型"的任务（中档模型进步快，半年前的判断大概率过时）、标注"仅限官方 API"的能力项（第三方聚合的上游支持范围在扩）、以及固定费率的合约（闲时通道和 batch 折扣在变）。我在 4sapi 的路由表里给每个条目都挂了"上次验证时间"，超过一季未验证的条目在后台标黄——机制和假设档案同源，只是颗粒度更细。

八、选型复查清单

每季度过一遍，任何一条"是"都触发对应决策的复审：

[ ] 有没有决策的核心前提属于"可被模型完成的实现工作"？
[ ] 上季度为某个自建模块投入的维护工单，数量是升是降？
[ ] 模型路由表里"必须用旗舰"的条目，最近一次用中档模型实测是什么时候？
[ ] 有没有为了"统一技术栈"而保留的抽象层，其节省量最近算过吗？
[ ] 招聘/协作上的成本假设（需要某技术栈的人力），还和一年前一样吗？
[ ] 每个重大决策有没有写下"什么条件成立时本决策作废"？

最后一条最关键。Shopify 的迁移之所以体面，是因为核心假设被白纸黑字记着，变化一发生就能对照出来。没有假设档案的团队，只能靠新任负责人推翻旧决策的方式完成更替，代价大得多。

九、成本与风险提示

"AI 大幅降低实现成本"是趋势判断而非即时事实，具体到团队要用自己的任务实测，不要因为一篇迁移动向就推翻运行良好的架构。
迁移本身有成本：双轨并行期的人力、回归测试、发版节奏都会被拖累，Shopify 级别的体量做这个决策用了大半年，普通团队更要先算迁移账再动手。
编码模型的生成结果必须过人工验收，"模型写两遍"省下的人力要转投到验收与基准建设上，不是直接裁掉。
只讨论合法接入与架构决策，不构成对任何公司技术路线的评价或投资建议。

总结

这期借 Shopify 迁回原生的决策，拆了"AI 改变技术选型经济学"这笔账：选型都是等式，等式里的成本项会随模型能力漂移，可被模型完成的实现成本正在快速缩水，而桥接维护、性能、治理这些成本项纹丝不动——决策该不该推翻，取决于支撑它的主要成本项落在哪一行。配套给了一份假设档案模板、一个用编码模型实测维护成本的验证脚本和季度复查清单。核心结论：比"选什么"更重要的事，是把"为什么选"记下来，并给等式里的每一项标注有效期。这套方法来自我在 4sapi（https://4sapi.com）维护多模型中转时反复验证的路由选型实践。

欢迎在评论区聊聊手头哪个架构决策的前提最近发生了动摇。