最近在帮一个朋友做技术选型。他们公司要做一个新 App，业务逻辑不复杂，但要求 Android、iOS、鸿蒙、小程序、Web 全覆盖。
我问了一句：既然现在 AI 写代码这么快，为什么不直接让 AI 给每个平台写一套原生代码？
他愣了一下。
这个问题乍一听有点反直觉。过去十年，"大前端"的核心叙事就是跨平台——React Native、Flutter、uni-app、Taro——所有技术都在讲同一个故事：写一次代码，在多个平台运行。
但当写代码本身不再是瓶颈，这个故事还成立吗？
先问一个问题：跨平台到底在解决什么问题？
很多人会说，跨平台当然是"一套代码多端运行"啊，节省开发成本。
但这个答案只对了一半。
如果你的业务是一个简单的商品列表页，用 React Native 写一次，在 Android 和 iOS 上都能跑，确实省了一个人力。但如果你的业务是复杂的电商交易链路，涉及支付、物流、状态同步、各种 edge case——你会发现 80% 的精力花在业务逻辑上，只有 20% 在跟 UI 和平台 API 打交道。
跨平台技术的真正价值，从来不是"少写代码"，而是"业务逻辑只写一次"。
这句话什么意思？就是说，当产品经理说"订单状态要加一个待发货"时，你只需要在一个地方改这个业务逻辑，而不是分别在 Android、iOS、鸿蒙、小程序里各改一次。
UI 代码写得再快，改业务逻辑时如果要在五个地方同步，那才是真正的灾难。
AI 时代，"写代码"的成本发生了什么变化？
2023 年之前，一个成熟的 Android 工程师上手 Flutter，大概需要两周熟悉框架，两个月才能真正生产级。一个前端工程师要写鸿蒙，得重新学 ArkTS、学习鸿蒙的生命周期、踩一遍坑。
这个迁移成本，就是跨平台技术的护城河。
但现在呢？你让 Cursor 帮你写一个 Android 的订单列表页，它能在 30 秒内生成一个 RecyclerView + ViewModel + LiveData 的标准实现。你换到鸿蒙，让它用 ArkTS 重写一遍，又一个 30 秒。
当写代码的边际成本从"两天"变成"30 秒"，跨平台技术的"一套代码"优势还在吗？
坦白说，UI 层的优势确实被削弱了。
你让 AI 写五个平台的登录页面，它五个都能写，而且可能比你手写一个跨平台的封装还快。因为跨平台框架本身有 learning curve，还要处理各种平台的 compatibility issue，而 AI 写原生代码不需要"学习"。
但问题来了：这五个登录页面的业务逻辑，你打算怎么 keep consistent？
业务场景：当需求变化时发生了什么
想象一下这个场景。产品经理跑过来："我们改一下登录 logic，支持 phone + 验证码，而且要跟用户中心的账号体系打通，登录成功后要 sync 设备信息，还要埋点统计登录 source，如果是老用户回归要 trigger 召回 logic..."
如果你用 AI 给每个平台写了一套原生 code，这时候你要做什么？
你要在 Android 改一遍，iOS 改一遍，鸿蒙改一遍，小程序改一遍，Web 再改一遍。改完还要 test 五遍，确保五个地方的 logic 一致。哪怕你用 AI 来改，你也需要在每个地方告诉 AI 同样的 requirement，然后 check AI 生成的 code 是否真的做了同样的事情。
这不叫 cross-platform，这叫"并行维护五个副本"。
如果你用了 cross-platform 方案呢？你在 business layer 写一次登录 logic，五个平台的 UI layer 只是调用这个 logic。产品改 requirement，你改一个地方。
这就是 AI 时代 cross-platform 技术依然有价值的根本原因：它解决的不是"写 code"的 cost，而是"维护 business logic consistency"的 cost。
反直觉的是：AI 越强，业务逻辑抽象越重要
这可能听起来有点反直觉。既然 AI 能帮你写代码，那为什么还要花时间做抽象？
原因很简单：AI 只能帮你做 mechanical 的工作，理解 business logic 的还是人。
举个例子。你们公司的"订单取消" logic，涉及到 20 个条件：是否已 shipped、用户 tier、商品 type、促销 activity、退款 channel、风控 rule...这些东西 AI 不可能 auto 理解。你必须在某个地方 clearly 表达这个 logic，然后让各个 platform 去调用。
如果你让 AI 在五个地方分别 implement 这个 logic，你会得到五个"看起来都对，但细节可能 inconsistent"的版本。因为你在跟 AI 描述 requirement 的时候，不可能每次都描述得一模一样。
Cross-platform 技术在 AI 时代的 value，从"节省 UI 开发 cost"变成了"作为 business logic 的 Single Source of Truth"。
那还要不要学跨平台框架？
这可能是很多人真正关心的问题。
我的回答是：要学，但学的重点变了。
以前学 React Native，你花大量时间学习 Navigator、StyleSheet、原生模块桥接——这些是 UI 层的技巧。在 AI 时代，这些技能的 ROI 在快速下降。
但你真正应该 focus 的，是如何设计一个与 UI 无关的业务层。不管你用的是 React Native、Flutter，还是彻底的"小程序 + WebView 混合方案"，核心问题都是一样的：怎么把业务逻辑从 platform-specific 代码里抽离出来，变成可以被不同 UI 调用的 pure logic layer。
这其实是架构问题，不是框架问题。
一个更激进的视角：跨平台可能被重新定义
说到这里，我突然想到一个有意思的问题。
如果 AI 能帮你把业务逻辑翻译成任何平台的代码，那"跨平台"的终极形态可能不是 React Native 或 Flutter，而是：
你用自然语言（或者伪代码）描述业务逻辑，AI 自动生成 Android、iOS、鸿蒙、小程序的版本。
这听起来很科幻，但已经有团队在往这个方向走了。你定义一个"用户下单"的 workflow，描述清楚状态机、规则、边界条件，然后让 AI 给你生成 Kotlin、Swift、ArkTS、TypeScript 的实现。
这种情况下，跨平台技术不再是一个框架，而是一种"业务逻辑的描述语言"。
谁定义这套语言，谁就掌握了下一代跨平台的话语权。
写在最后
回到开头的问题：当 AI 会写所有平台代码，跨平台还有意义吗？
我的答案是：有意义，但意义完全变了。
以前跨平台的核心价值是"节省写代码的时间"。当 AI 把这个成本降到趋近于零，跨平台的价值就变成了"保证业务逻辑的一致性"和"降低需求变化的同步成本"。
对于工程师来说，这意味着什么？
你不需要再成为一个"Flutter/React Native expert"，但你需要成为一个"能把 complex business logic 抽象成 platform-agnostic 模块"的 architect。
Framework 会变，tool 会变，但"用一套 logic 服务多个 platform"这个 need，只要地球上还有超过一个 mobile platform，就不会消失。
问题是：你准备好用新的方式思考这个问题了吗？
