以 AI 编码代理为前提的手机应用开发：原生 vs 跨平台

引言

随着 AI 编码代理逐渐成为开发主力，手机应用框架的选择也需要新的评估维度。本文将从“AI 代理究竟能多准确、多少自主地写出代码”这一角度，对原生开发（Swift/Kotlin）、Flutter 和 React Native 进行比较。尤其会重点讨论位于跨平台与原生边界上的混合实现，会给 AI 带来怎样的影响。

本文基于 2026 年 3 月时点的信息撰写。引用来源均以行内注记方式标出。

1. 前提

本文以前提是将 Claude Code、GitHub Copilot、Cursor、Windsurf 等 AI 编码代理作为开发主力来使用。这里假设的并不是单纯的代码补全，而是只要描述需求，代理就会自主完成文件创建、代码编辑与测试执行的 agent 式用法。

在这一前提下，重要的评估维度就变成了“AI 代理能在多大程度上准确而自主地写出该代码”。而在真实的应用开发中，仅靠跨平台代码往往无法完成全部工作，经常还需要与原生实现配合。这种混合结构会如何影响 AI 代理，正是本文的核心问题。

2. 到了 2026 年，发生了什么变化？

React Native：全面转向 New Architecture

在 React Native v0.76（2024 年 10 月）中，New Architecture（JSI/Fabric/TurboModules）成为默认架构；到了 v0.82（2025 年 10 月），对旧架构的 opt-out 被禁用。进一步在 v0.84（2026 年 2 月）中，Hermes V1 成为默认 JS 引擎，并且在 iOS 上旧架构代码已经推进到默认不参与构建的阶段。

“Starting from React Native 0.76, the New Architecture is enabled by default in your projects.”
— React Native 官方博客 — React Native 0.76（2024 年 10 月）

“we're confident in making it the only architecture for this and future versions of React Native”
— React Native 官方博客 — React Native 0.82: A New Era（2025 年 10 月）

Flutter：Dart 官方 MCP 服务器登场

从 Dart SDK 3.9（2025 年 8 月，参考：Announcing Dart 3.9）开始，Dart 官方的 Model Context Protocol（MCP）服务器进入 stable 渠道。它可以直接与 Claude Code、Cursor、GitHub Copilot、Gemini CLI 等集成。到 2026 年，Flutter 的一项优势就在于，AI 代理可以自主处理 widget tree 分析、analyzer 执行、测试、pub.dev 搜索以及依赖管理。不过，官方文档明确写着“experimental and likely to evolve quickly”，因此在实际运用中需要预期 API 和行为还会变化。

与 Claude Code 的联动可以通过下面这一行命令完成设置。

claude mcp add --transport stdio dart -- dart mcp-server

参考：Dart and Flutter MCP server — Flutter 官方文档（2026 年 3 月 25 日更新）

React Native：Expo UI 与 agent-skills 的兴起

React Native 侧也有两个重要变化。其一是 Expo UI（Expo SDK 55，2026 年 2 月）。它展示出一种方向：可以从 React Native 使用 SwiftUI 与 Jetpack Compose 的原生组件，于是“跨平台 vs 原生”的边界开始比以往更模糊。

不过，Expo UI 仍在发展中。Expo 自己也说明了 Jetpack Compose 侧与 SwiftUI 侧在成熟度上存在差异，因此在生产环境采用前，应分别确认稳定性与 API 变更风险。以当前阶段来看，与其把它视为“已经成熟的解决方案”，更适合把它看作“推动原生 UI 复用向前发展的有前景机制”。

另一个变化是 Callstack 的 agent-skills（2026 年 1 月）。Callstack 发布了一套技能集，使 Claude Code、Cursor、Codex 等 AI 代理能够直接参考 React Native 优化方面的最佳实践。它虽然不像 MCP 服务器那样深度集成，但能让代理更容易获取性能优化、列表实现和包体积缩减等知识。

参考：Expo SDK 55 Changelog（2026 年 2 月）
参考：Callstack — Announcing React Native Best Practices for AI Agents（2026 年 1 月）

设计系统的转折：Material 3 Expressive 的冲击

在 2025 年 5 月 Google I/O 上发布的 Material 3 Expressive（M3E，参考：Google Blog — Material 3 Expressive），通过基于弹簧的动效、新的形状库以及更强调的排版，对 Android UI 进行了大幅更新。它在 Android 16 QPR1（2025 年 9 月）中开始向 Pixel 设备推送，Google 的主要应用也陆续支持了 M3E。

关键在于，各框架之间的支持状况差异很大。

• Jetpack Compose：M3E 组件已经通过 androidx.compose.material3 库提供。可以使用 LoadingIndicator、SplitButton、ButtonGroup、FloatingToolbar 等新组件，也可以使用 MotionScheme 等 Expressive 专属 API。
• React Native（Expo UI）：由于可以通过 Expo UI 使用 Jetpack Compose 组件，因此存在跟进 M3E 的空间。不过 Expo UI 本身还在稳定化过程中，所以还不能说“React Native 对 M3E 已经非常稳固”。
• Flutter：截至 2026 年 3 月，Material 3 Expressive 尚未支持。Flutter 团队明确表示“Currently, we are not actively developing Material 3 Expressive”，同时也不接受相关贡献。其背景是正在进行将 Material/Cupertino 库从核心框架中解耦的结构性改革。该分离已在 Flutter 3.41（2026 年 2 月）开始推进，M3E 预计会在解耦完成后以独立包形式提供，但时间尚未确定。

参考：Flutter GitHub Issue #168813 — Bring Material 3 Expressive to Flutter
参考：Android Developers — Material Design 3 in Compose

3. 决定与 AI 代理契合度的因素

AI 编码代理能否准确生成代码，主要取决于以下三点。

1. 训练数据量：React Native 的优势在于庞大的 JS/TS 语料。Flutter 则通过完善的官方文档与 MCP 提供上下文理解补强。
2. 上下文消耗效率：跨平台方案可以收敛到一个代码库，因此相较于原生开发需要维护两个代码库，代理的理解成本更低。
3. 工具链集成：Flutter 的 Dart 官方 MCP 服务器，目前是把 analyzer → 修复 → 测试 这一循环自动化得最体系化的方案。React Native 侧也有 Callstack 以 agent-skills 的形式公开了面向 Claude Code、Cursor 等工具的技能集，差距正在缩小。

“AI code suggestion quality is roughly equivalent for both frameworks”
— Flutter vs React Native 7 Tests（tech-insider.org，2026 年 3 月）

不过，这里的比较主要只是辅助性的参考信息。像 tech-insider.org 和 vibrant-info.com 这样的第三方文章可以作为阅读材料，但本文的结论主要基于官方文档、厂商发布的技术信息以及公开的实现方针。

作为补充材料，也可以参考面向创业公司的比较文章 React Native vs Flutter: Which Wins for Startups in 2026?（vibrant-info.com），以及总结 2025 年 React Native 生态动向的 React Native Wrapped 2025（Callstack）。

4. 原生 vs 跨平台 对比

与 AI 代理契合度的比较

UI 实现特性的比较

5. 混合实现的现实与其对 AI 代理的影响

即使选择了跨平台框架，真实的产品开发中依然会出现必须进入原生实现的边界。像摄像头、Bluetooth、生物认证、推送通知、AR、HealthKit 这类功能，往往需要直接调用操作系统 API，也就必须通过插件、Platform Channel 或 TurboModules 去调用原生代码。

这条“边界线”正是 AI 代理最难处理的部分。当实现横跨 Dart 或 TypeScript 世界与 Swift/Kotlin 世界时，上下文会分散到多种语言和多个文件中，从而更容易降低生成精度。

Flutter 的混合实现：Platform Channel 与 FFI

Flutter 调用原生代码主要有两种方式。

• Platform Channel：用于在 Dart 与 Swift/Kotlin 之间传递消息的机制。它的结构很清晰，但必须同时维护 Dart 侧、iOS 侧、Android 侧三个文件的一致性。AI 很容易只修改其中一侧，而让另外两侧的类型定义失配。
• Dart FFI：用于直接调用 C/C++ 库的机制。它可以更接近高性能的系统级 API，但需要处理指针与类型映射知识，因此 AI 的生成精度会进一步下降。

参考：Flutter 官方文档 — Developing packages & plugins（2026 年 1 月 28 日更新）

React Native 的混合实现：TurboModules + Codegen

从 React Native v0.76 开始，原生模块采用 TurboModules。由于 Codegen 可以从 TypeScript 的 Spec 定义文件中自动生成 iOS（Swift/Obj-C）与 Android（Kotlin）的样板代码，TypeScript Spec 更容易成为单一事实来源（Single Source of Truth）。

// NativeMyModule.ts — Spec 文件示例
import type { TurboModule } from 'react-native';
import { TurboModuleRegistry } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceName(): string;
  requestCameraPermission(): Promise<boolean>;
}

export default TurboModuleRegistry.getEnforcing<Spec>('MyModule');

Codegen 会从这个 Spec 自动生成 iOS 与 Android 双方的样板代码。这样 AI 代理就更容易把注意力集中在 TypeScript 层，而把定型的原生样板代码交给自动生成。

参考：React Native 官方文档 — Native Modules: Introduction
参考：Callstack — Announcing React Native Best Practices for AI Agents（2026 年 1 月）

按功能看：混合实现难度与 AI 对应状况

在混合实现中使用 AI 代理的原则

“Native plugins and heavy custom logic still need human oversight.”
— Stitch + Antigravity + Flutter（dev.to，2026 年 3 月）

6. 应该如何选择？

结合混合实现的现实情况，可以按场景给出如下建议。

推荐 Flutter：原生需求仅限成熟插件可覆盖的场景

如果需求主要是摄像头、通知、认证等已有标准插件覆盖的功能，那么通过 Dart + MCP 服务器进行代理集成会非常高效。不过，如果 Android 侧需要符合 Material 3 Expressive，Flutter 目前仍不支持，这一点必须认真考虑。

推荐 React Native：需要自定义原生模块，或必须符合 M3E 的场景

围绕 TypeScript Spec 构建的 TurboModules + Codegen，更容易清晰界定 AI 代理的工作范围，这在混合实现中往往更有优势。Expo UI 也可能成为连接 Jetpack Compose M3E 组件的路径，但在决定采用之前仍应先确认成熟度。

推荐原生：当原生实现占产品的大部分时

如果工作内容大多都是原生层，比如 ARKit、CoreML 或自定义 BLE 控制，那么跨平台公共层带来的价值就会缩小。在这种情况下，从一开始就采用原生开发，能让 AI 把上下文集中在一种语言中。

混合策略：UI 层使用 Flutter，重量级平台处理模块化到原生侧

另一种方案是，应用的大部分仍由 Flutter 构建，而把只有原生处理才需要的部分清晰切分成模块。这样可以让 AI 代理只专注于 Flutter 层，从而更稳定地保持生成质量。

7. 结论

最佳选择与其说取决于“选哪个框架”，不如说取决于“你的产品需要多大比例、哪一类原生实现”。

如果原生需求仅停留在成熟插件可以覆盖的范围内，那么 Flutter 会非常高效，尤其是结合 MCP 服务器时更是如此。如果需要自定义原生模块，React Native 以 TypeScript Spec 为中心的结构会更方便 AI 处理。随着原生实现比例提高，跨平台的收益会逐渐降低，答案也会越来越接近纯原生开发。

无论采用哪一种方案，AI 辅助开发的精度都高度依赖于：在把任务交给代理之前，先设计好原生与跨平台代码的边界。

另外，如果 Android UI 必须符合 Material 3 Expressive，那么相较于截至 2026 年 3 月仍未支持的 Flutter，React Native + Expo UI（经由 Jetpack Compose）或原生开发会是更现实的选择。不过，React Native 侧的 Expo UI 仍需持续观察其成熟度。Flutter 团队正在推进设计库解耦，M3E 预计会在相关工作完成后以独立包的方式提供，但时间表仍不确定。

参考文献

• React Native 0.76 发布博客 — New Architecture 默认启用
• React Native 0.82 发布博客 — 禁用旧架构 opt-out
• React Native 0.83 发布博客 — 零破坏性变更与旧架构移除标志的引入
• React Native 0.84 发布博客 — Hermes V1 默认启用，旧架构代码默认排除
• Dart and Flutter MCP server — Flutter 官方文档（2026 年 3 月 25 日更新）
• Announcing Dart 3.9 — Dart 官方 MCP 服务器进入 stable 渠道
• Flutter — Developing packages & plugins — Platform Channel 与 FFI 官方说明（2026 年 1 月 28 日更新）
• React Native — Native Modules: Introduction — TurboModules 官方文档
• Callstack — React Native Best Practices for AI Agents（2026 年 1 月）
• Flutter vs React Native 7 Tests, 1 Clear Winner（tech-insider.org，2026 年 3 月）
• React Native vs Flutter: Which Wins for Startups in 2026?（vibrant-info.com，2026 年 3 月）
• Expo SDK 55 Changelog — Expo UI 概要与 SDK 55 变更
• Expo Blog — Expo UI in SDK 55 — Expo UI 的定位与约束
• React Native Wrapped 2025（Callstack，2026 年 2 月）— React Native 生态年度回顾
• Google Blog — Material 3 Expressive（2025 年 5 月）— M3E 发布
• Flutter GitHub Issue #168813 — Bring Material 3 Expressive to Flutter — Flutter 对 M3E 支持的方向
• Android Developers — Material Design 3 in Compose — Jetpack Compose 中的 M3E 实现