先把事实与判断分开
一家公司的迁移决定值得研究，能否适用于自己的产品，还要检查团队规模、用户任务和维护条件。尤其当 AI 改变了部分实现成本，更需要重新计算完整的交付成本，避免把写出代码的速度当成选型的全部理由。
Shopify 的原始公告发表于 2026 年 9 月 10 日。公告仍认可 React Native，也明确表示双平台维护成本没有消失。它描述的是自身团队在条件变化后的选择，不能直接证明所有产品都应该迁移。
从用户最重要的一条路径开始
设想要做一款仓储盘点应用，核心流程是扫码、修改数量、暂存结果、恢复网络后同步。选型时可以先挑这条路径做小试验，把必须满足的条件写在实现之前：弱网是否可用，重复同步会不会产生冲突，操作人员能否看懂错误，旧设备上是否顺畅。
然后选择两个现实可行的方案，使用同一份需求、同一组数据和同样的验收设备。记录实现时间，也记录调试、部署、审核和修正问题的时间。AI 生成初稿的速度只是其中一项，不应代替整个交付周期。
如果现有方案已经稳定，试验还要加入迁移特有的工作：旧数据如何读取，未完成任务如何转移，用户要不要重新学习，出问题时能否回到旧版本。忽略这些工作，新的方案很容易在纸面上显得便宜。
用证据决定要不要继续
可以准备一张简短的决策记录，内容包括：
- 当前最影响用户的具体问题，以及已有证据。
- 保持现状、小范围替换和整体迁移三个方案的代价。
- 小试验需要验证的关键假设。
- 谁负责长期维护，缺少哪些能力或外部支持。
- 达到什么条件继续，出现什么情况停止。
停止条件尤其需要提前约定。例如，试验已用完计划时间，但核心流程仍不稳定，就先归档结果；不能因为“已经写了很多”而不断扩大范围。若收益只体现在开发者更喜欢新框架，也应如实记录，交给产品目标和资源约束共同决定。
团队还可以把不确定性拆开：性能是否足够可以测量，维护者是否能接手可以演练，未来生态会怎样则难以给出保证。把这几类判断分开，讨论会比给每个框架打一个总分更具体。
技术文章里最有价值的部分，往往是它促使人重新检查原有假设。求职作品也可以展示这样的过程：公开一个脱敏的小试验、失败情况和最终取舍，即使结论是暂时保留现有技术，也能说明如何在有限时间里做出可解释的决定。