很多人都在问，现在都AI开发了，还需要跨平台框架吗？
相信不少人有疑惑，但又不确定。今天就把这个问题掰开揉碎，用专业的方法论，深入分析清楚。
AI开发时代，还需要框架吗？
第一问：在AI开发时代，AI需要工具吗？
这个问题很好回答：AI非常需要工具，不会用工具的AI不是好AI。
第二问：AI需要框架型工具吗？
这个问题也不难回答。
• AI可以直接写原生js，但还是会使用ts、vue这些框架。 为啥？因为有这些好工具的帮助，AI写出的代码消耗token更少、更不容易犯错误。
• AI可以直接写平台原生代码，比如windows上写.net，mac上写swift，但大家还是会用electron、tauri这些跨平台工具。 为啥？虽然这些跨平台工具也有缺点，但ROI差异还是非常大。用electron、tauri，一个前端就行。用.net、swift，得2拨人。
你说，我就一个人，让AI拿原生写，代码我也看不懂就不看了，纯vibe行不行？
这就是一个更有意思的话题了，有人推崇vibe，有人嗤之以鼻。到底谁是对的？
我们来好好分析下这个话题：vibe开发的适应面。
vibe开发的适应面
我们要建立一个分析框架，第一步是把要分析的东西了解透彻。
首先我们需要了解AI的几大特性：
1. AI写代码非常快。 2. AI对主流编程语言和主流框架的熟悉度，超过很多程序员。如果程序员不熟悉某些语言和框架，在该领域容易对AI产生盲目崇拜。
3. 熟悉不代表不会犯错。这是两件事，但很多人没分清。
因为在人类的直觉中，熟悉某个领域通常意味着更少犯错。
但 AI 并非如此：它可能对某个领域非常熟悉，却仍然会犯低级错误。称之为“锯齿效应”。
锯齿效应，就是有时候高峰，有时候低峰，像锯齿一样，不稳定不平均。
优秀的AI使用者，每天都要思考如何避免AI的低峰。
4. 任务复杂度越高、越不方便验证，它出错的概率越大。 5. AI只是个工具，别把他当人，它不背锅。出了问题得人扛。
结合4、5条，就提出来2个关键词，复杂度 和 风险。
首先可以确定：出问题后风险小、系统复杂度很低的web应用，这样的应用很适合vibe，比如个人自用的展示网页，公司内部有限人使用的简单CRUD系统。
反过来：
• 出事后风险越高的场景，越不适合vibe。 比如用户量巨大的系统，涉及资金、权益、敏感数据的系统，或者影响范围较大的政企决策系统。
因为风险代价太高了，哪怕用AI写代码，也得人工充分review。
• 复杂度越高，越不适合vibe。 这里的复杂度，说的不是对人的复杂度，而是对AI的复杂度。
AI不会觉得c++这门语言的语法比js难。但使用c++，AI需要多操心内存安全，它不是只需关心业务实现了，这就把复杂度提上去了。
AI的复杂度是：工程复杂度、逻辑复杂度、同时要达成的目标个数、可验证复杂度、以及AI不熟悉的框架和内部抽象。
比如复杂的权限系统，多套代码保持一致的逻辑，历史代码庞大，功能繁多又有大量性能指标、质量指标和架构要求，这些都会提升AI眼里的复杂度。
那么沿着风险和复杂度，可以形成一个坐标体系，越靠近圆点、越适合vibe：
• 工程复杂度：代码量大、业务流程长，同一数据多点维护，冗余多，有架构规范、不能随意实现功能，复杂度就高 • 逻辑复杂度：并非简单展示和CRUD，条件分支多、if里面的与或组合多，逻辑复杂度就高 • 同时要达成的目标个数：工程目标太多，且互相冲突，冲突时的优先级策略不清晰，“既要……又要……”大幅提升复杂度 • 可验证复杂度：AI犯的错不易发现，缺少编译验证工具，测试组合太多，无法穷举测试，测试环境建立成本太高 • AI不熟悉的框架和内部抽象：使用非主流技术栈，大量内部组件，文档和注释里大量内部黑话术语
总结一个简化的公式：vibe不可行系数=风险*复杂度
所以能不能vibe并非二元论：
• 有人做的应用适合vibe，或者还处于早期的vibe甜蜜期，他对vibe就会偏乐观。 • 有人被vibe坑过几次，代价无法承受，就会严禁vibe。
这都过于绝对了。（有趣的是这2拨人，往往还都是领导）
其实有了上面的方法论，评估下vibe不可行系数，就会清晰很多。
接下来的问题，就更有工程实践意义了。
如何降低系统的复杂度，把你的应用往坐标系圆点拉，让AI最大化它的价值？
如何帮AI降低系统复杂度
1. 使用强约束的、AI熟悉的好框架
TypeScript + Vue.js就是好组合。
有这种框架，AI写的代码少，犯错的机会少、犯错后编译链就能及时发现错误，可验证性好。
如果使用过于灵活的原生编程语言，一个需求有多种实现方式，多人协作时多个AI不停提交各种方式的实现，代码库很快就会乱套，进而给AI也增加了复杂度。
其实浏览器也是一个框架，它的约束，让web应用开发出问题的概率，低于原生应用。而基于浏览器再次提供约束的TypeScript + Vue.js，就更适合约束AI。
React也过于灵活，在 AI 时代是一把双刃剑，很多React开发团队在Agents.md里需要写一批清单，禁止AI使用哪些方式写代码。
2. 涉及多平台时，跨平台框架是降低系统复杂度的一致性工具
基本原则：代码越少、AI犯的错越少
业务只需1套代码，跨端问题由好的跨平台工具解决。（注意这个“好”字，不好的框架会带来更多麻烦）
平台越多，跨平台框架的价值越大。AI前是这样，AI后也是这样。尤其是在中国，要覆盖Android、iOS、鸿蒙、各家小程序、web。
对于可vibe的系统，跨平台框架给AI降低复杂度；
需要人工review把控的系统，也可以集中人力来review AI生成的1套代码。而不是被AI生成的海量代码淹没。
某音的产品经理分享过一个事，有一天她发现安卓版的某个重要界面比较暗，她截了一张图，又拿iOS版截了一张图，两张图在电脑上对比了一下，发现Android确实有问题，
然后找Android研发，研发人员发现蒙层上的一个数值搞反了。
修了这个bug后，安卓的LTV立即转正了。
这件事，是典型的“环节多造成的百密一疏”。
因为实际应用不是百密，是万密。多些“疏”很正常。
我们假使1个平台是万密，5个平台就是5万密。代码量、要关注的细节倍数上升。
但如果使用“好的”跨平台框架，就不会发生这种Android平台蒙层色值搞反的bug。
好的框架，可以减少环节和代码量，让5万密变回1万密。降低系统的复杂度。
麦当劳要保证每个门店炸出来的薯条都是一个味道，背后依赖了众多能保障一致性的工具。
如果你想让每个用户，不管使用什么平台，在使用你的业务时都能获得你精心设计的最佳体验，那么你就需要一个优秀的工具来帮助你把控品质和一致性。
如果不同平台使用不同的原生开发，不只是成本效率问题，更是高端品质无法严格把控的问题。
你的业务用户体量越大，各种不一致引发的bug和体验问题，产生的损失就越大，就越需要严格的一致性保障工具。
而好的跨平台框架，就是一个非常好的一致性保障工具。
3. 利用跨平台框架降低验证成本
多平台原生开发，除了业务代码多套，测试用例也得多平台各自写。
而使用好的跨平台框架，测试用例也只需一套。
集中人力来review AI生成的1套测试用例代码，肯定是更佳选择。
最害怕AI写的代码明明有bug，却和AI写的测试用例自圆其说。
4. 选高性能框架，让AI专注于业务，减少它的目标，降低复杂度
让AI专注于你的业务需求，即功能。别让AI既要操心功能、又要操心性能。
性能是一件很复杂的事情，原生开发中，让应用高性能，经常需要引入多线程、做预加载、做多点冗余设计。。。
这都会增加系统复杂度，让AI额外操心线程竞态、多点同步。
复杂性提升，AI也会顾此失彼。你一定不想陷入这种和AI的对话：
1. 不对啊，功能虽然实现了，但页面白屏时间变长了。\
2. 你行不行啊，白屏好了，xx功能怎么坏了？
选一个底层性能非常优秀的框架，让AI轻松点，降低系统复杂度，把性能压力外包给更可靠的专业工具。
什么才是“适合AI的”、“好的”跨平台框架？
首先回答本文开头的疑问，AI开发时代，非常需要好工具、需要好的跨平台框架。
但问题是业内有没有好框架呢？没有的话，那就还是得用原生。
最近有几个知名的技术栈变更案例：
1. cursor把SolidJS改成了react 2. bun从zig改成了rust
3. shopify从react native改成了原生
全是因为AI，但也有细节差异，一个一个分析。
• cursor从SolidJS改成了react
因为SolidJS小众，且和react有部分概念重叠，导致AI容易犯错。
• bun从zig改成了rust
zig同样是相对小众的语言，AI既要操心功能，又要操心内存安全。而bun又暴露了很多内存问题。交给rust，AI更熟、内存安全由编译器这个更专业可靠的工具来负责。
• shopify从react native改成了原生
这个案例，在跨平台框架界很经典。
shopify 在 react native 社区不是普通角色，它维护着一批重要项目：FlashList、React Native Skia、Restyle 。
但它迁移到原生，并宣布放弃这些库的维护。
原因不是因为AI不熟悉react，而是 Shopify 认为在 AI 的帮助下，改用原生开发代价变低，且性能更高。
虽然shopify之前投入大量精力研发的 FlashList长列表，是 react native 社区里性能最好的长列表方案，但仍然比不过原生的长列表。
React Native Skia也一样，在 react native 社区里性能最佳，但与跨平台业内同类方案相比性能仍有差距。
如果你使用一个跨平台框架，得到了好处，但失去了其他重要指标，比如性能，那么这个工具就不是好工具。
尤其在国外，没有鸿蒙和小程序，放弃 react native，只是从1个平台换成2个平台，在AI的帮助下压力不大。
最终shopify发布了一份迁移到原生评测报告。让大家知道，从 react native 换成原生后，代价如何、性能提升了多少。
其他人看到这份报告，也会明白，看起来迁移代价并不高，性能还能提升这么多，FlashList又没人维护了，那我是不是也应该迁移原生了。
AI改变了软件开发的成本结构。虽然AI+双平台原生，投入比跨平台开发高，但高的不是很多了。
shopify为了让这个跨平台框架性能好，又投入大量人力去开发维护那几个库。这在AI时代就更不划算了。
对于shopify而言，放弃每年在react native上的大量投资，AI+原生，并且性能更高，肯定是ROI更高的选择。
但我们假设一下，假使react native的性能比原生更好，自带的库品质足够好，shopify不用每年在FlashList等库上做大量投入，只需专注于自己的业务，那他不会换原生的。
我们先总结下上面3个AI时代变更技术栈的案例，围绕2个点：AI是否熟悉、是否有性能问题。
一个好框架的流行程度，取决于 (它带来的价值 - 它引发的问题)。
AI削弱了它带来的价值后，公式的结果可能变成负数，那么这个框架就会被开发者抛弃。
跨平台框架如果想继续存在，就需要强化它带来的价值，减少它引发的问题，让公式结果始终为正，并且正的越多，这个框架会越流行。
在AI时代，一个理想中的好跨平台框架，应该具备这7个特点：
1. AI熟悉 2. 覆盖更多平台，不止iOS和Android，而是全平台覆盖，创造更多价值 3. 性能好。至少不能因为使用了它而损失性能。如果性能比原生还好，那就更棒了。 4. 生态丰富。 5. 没有什么其他坑，比如没有混合渲染问题、没有质量问题。 6. 支持动态化 7. 全面的验证反馈
如果，真的有这么一个好框架，那么它是不是理应成为AI时代最主流的开发工具呢？
答案是肯定的。
只不过业内过去没有做出来符合标准的好框架，导致人们陷入了原生成本高、但原生是王道的传统认知里。
那么目前最接近理想框架的是哪个呢？
我们来用上面的7点，来分析下主流的跨平台框架：react native、flutter、uni-app x 蒸汽模式（以下简称 uni-app x）。
1. AI熟悉度
react native、flutter、uni-app x都是主流框架，存留大，AI很熟悉。正常开发，很难遇到AI不熟悉的情况。新版功能，都需要去官网查。
uni-app x 的vdom模式使用过uts语言，这个语言AI的熟悉度不高。后来的蒸汽模式已经改用ts/js，再加上vue、css，都是AI熟悉的。
2. 覆盖更多平台
覆盖更多平台，减少平台差异，这是跨平台框架的天然使命。
国外的平台较少，跨平台厂商主要为Android和iOS设计跨平台方案。
国内有鸿蒙和各家小程序，市场情况差异很大，对多端一致性的要求更高。
在AI时代，小程序的意义会比之前更大。各家互联网巨头，都会把持AI入口，并把流量分发给自家小程序。微信AI、豆包小程序，均在进行相关计划。
• react native
官方只支持Android和iOS。web平台只能复用纯逻辑；三方中，华为提供了ohos_react_native库支持鸿蒙，京东taro支持小程序。
三方和原版有一定差异。
react native 不管是官方还是三方，都存在跨平台代码复用度低的问题。平台差异较多，拉齐度低。
它自身理念是“Learn once, write anywhere”，不是“write once, run anywhere”。
它只做到react这个框架的写法是通用的，但核心组件都未统一。
App平台，各自使用不同的语言编写组件，差异略多。
小程序和web，与react native的UI代码更难复用。
由于react native库自身内置功能不多，大量依赖三方库，而社区库的多端拉齐度更低。尤其是鸿蒙、小程序、web。
• flutter
官方支持Android、iOS、web，还有pc。就国外的情况而言，算是全平台覆盖了。
三方中，华为提供了Flutter-OH适配鸿蒙。没有小程序方案。
flutter的web平台因为带有体积较大的渲染引擎，且其绘制在canvas上影响SEO，实际商用中很少使用。
flutter在app平台均使用自渲染机制，组件一致性高，跨平台代码复用度较高。
如果需要鸿蒙平台时，需注意社区库适配问题。原版库不支持鸿蒙，华为迁移了一批库到鸿蒙端。
• uni-app x
uni-app x 原厂支持 Android、iOS、鸿蒙、web、小程序。
只有一个组织统筹设计，多端的代码复用度非常高。实际上uni-app x是把小程序的组件和API迁移到了其他平台，从逻辑到UI都是一套。
uni-app x 的 App平台是原生渲染，但没有使用OS提供的原生组件，而是使用C写了一批新的跨平台组件放入原生渲染管线中使用，所以没有react native那样的跨端组件差异。
uni-app x 的 web 平台，是一套代码的正常 vue 页面，不存在体积和seo等问题。
uni-app x 的内置组件和API较多，均跨平台。社区插件方面，推出了 uni_modules 规范，统一interface约定，社区插件的多端支持度和统一度都很高。
uni-app x 在拉齐细节上投入较多，包括各家小程序的专有语言，比如微信小程序的wxs，支付宝小程序的ajs，均被拉齐为一套 Element 操作，所有平台均支持这套 Element，进而能兼容更多 NPM 库。
3. 性能好
跨平台性能比原生低，想要性能就不能用跨平台。这个问题是多年来开发者对跨平台框架的认知。但今年这个认知被打破了。
• react native
react native的性能表现在各框架中属于靠后的，这也是它被shopify放弃的核心原因。在AI时代，如果只考虑Android和iOS，在AI降低了原生开发成本后，很多开发者就不愿意忍受react native的低性能表现。
• flutter
flutter在常规场景性能优异，渲染帧率可以达到很高的水平。
但由于flutter使用了自渲染引擎，对接系统原生UI时，两套渲染引擎的合成问题较多。会引发性能下降。尤其是iOS的液态玻璃、鸿蒙的沉浸光感，让自渲染引擎很难适配。
dart涉及跨语言通信，dart和c对接性能还好，但在对接原生的java/kotlin、ArkTS时通信性能较低。
• uni-app x
uni-app x 蒸汽模式，是今年跨平台框架中的惊喜。一直以来跨平台框架性能不如原生的观点被打破。
如果没有这样的产品出现，跨平台框架在AI时代或许真要走向没落了。但如今用原生开发的应用，渲染性能反而不如uni-app x了，那开发者的选择又要重新思考。
这违背了一些人的直觉，但有专业的benchmark，里面都有详细的数据和实验的可重现方式。
• Android平台性能benchmark[1] • iOS平台性能benchmark[2] • 鸿蒙平台性能benchmark[3]
其中的实验工程不管是uni-app x的还是原生的，都是开源的，已有数千人下载验证，不存在不公平的对比，诸如uni-app x为测试例优化、而对比原生工程实现欠佳的情况。
从技术原理上来说，uni-app x 也是基于原生渲染管线的。但它没有像react native那样使用OS提供的系统组件，使用基于C语言重新开发了一批跨平台、高性能的组件。
除此之外，蒸汽模式消除了虚拟 DOM；模板和样式被编译为高度优化的机器码/字节码；提供了更快的排版系统...
这些都是让跨平台框架性能反超的原因。
这里需要强调的是，渲染性能，是一个复杂的对比因素。uni-app x 的部分组件，如view、text、list、canvas、rich-text，在benchmark中体现出了优势。
比系统原生组件（如textView、recyclerView）快数倍，但未必所有组件的性能均超过了原生。
以iOS液态玻璃、鸿蒙沉浸光感为例，uni-app x 相关组件使用是系统的标准组件，此时渲染性能和原生几乎无差别。细微的差别来自于uni-app x的组件做了一层封装，而uni-app x的页面排版系统又更快，综合下来和原生是一致的。
4. 生态丰富
• react native
react native的库，均在npm上。npm有数百万个库，但并非均支持react native。
react native的生态包含了两部分：
一部分是纯js库，不含web api，比如day.js。这部分数量庞大不好计数。
另一部分是原生插件，由于npm并没有筛选react native插件的功能，其中搜索“react native”关键字只有1k多结果。在三方网站React Native Directory[4]，发现收录了2k+插件。
• flutter
flutter的库，均在其官方的pub.dev。包括dart逻辑库、flutter库两部分。
dart逻辑库有18k+。数量不少，但相比npm的js库还是差很多。
flutter库有66k+，数量在跨平台框架中处于领先地位。
• uni-app x
uni-app x 的生态，分为3部分。
第一部分是 npm 生态。
纯js逻辑库如day.js均支持。
uni-app x 对 npm 库的支持度，高于 react native。
因为 uni-app x 比 react native 多了 element、canvas等API，以及支持更多css功能（如css变量、媒体查询、@keyframe动画）。
echart图表库也可以在uni-app x上运行。
可以说uni-app x 比react native和flutter，更接近web，也就兼容了更多web生态。
第二部分是uts原生插件。
其实uni-app x 本身内置了大量原生API，与小程序一样，常见原生功能需求都内置了。
在其他扩展部分，uni-app x的插件均在其插件市场[5]，该市场的插件总数有21k+，但筛选蒸汽模式后，支持插件有2k多。其中部分插件是需要向插件作者付费购买的，这与其他跨平台框架不同。
第三部分是uasm插件。
uasm是聚合了web和小程序支持的wasm，以及App平台兼容支持的node生态的c库。
uni-app x 的app平台内置了对node-api的实现，所以很多适配过node的c库可以方便在 uni-app x 中使用，比如 sqlite、zstd。
uasm可以让一个c库，在uni-app x的web、小程序上以wasm方式运行，在app平台以node库方式运行。这是跨平台框架中比较独特的生态。
当然库的数量，不能作为生态丰富的判断依据，核心还是高质量库的数量。但这个数据难以统计衡量。只能提供一个库数量作为参考。
另外，在AI时代，生态的价值在降低。除了一些有难度的精品库外，大部分插件只是简单的把系统API或三方原生SDK包装一下。可能不需要寻找下载库，AI Agent直接在本地就写好了封装。
5. 稳定性和质量
react native和flutter，近期没有大升级，处于较稳定的状态。
社区的鸿蒙适配版需单独关注其质量和版本跟随问题。
react native框架内置的组件和API非常少，大量依赖社区插件，该部分需关注社区插件质量。
uni-app x 蒸汽模式，UI框架部分是今年新出的，理论上质量和稳定性弱于react native和flutter。
不过其官网列出不少蒸汽模式案例[6]，不乏在应用商店中下载量超百万、千万的应用。达到商用标准看起来没有问题。但边缘场景需注意单独评估。
uni-app x 内置的组件和API很多，均由官方维护，且大多开源。与其他跨平台框架的社区库相比，质量和稳定性有保障。
但uni-app x的插件市场，其质量需单独关注。流行度不高的插件，不妨考虑用AI自己封装。
6. 支持动态化
动态化或热更新，是任何产品运营公司不可或缺的工具。A/B 测试、灰度发布、运营活动都离不开它。
flutter是AOT的，不支持热更新，这给性能不及flutter的react native留下了一定市场空间。
uni-app x 支持动态化。并且在蒸汽模式渲染性能超过原生后，让产业发生有趣的改变：“现在动态化方案的渲染性能超过了原生”
那么产品和运营人员会要求更多界面改成动态化，以方便测试和优化。
甚至以前认为首页性能要求高，一定要用原生，这些观点也过时了。
更有趣的是，AI时代，很多运营都开始vibe coding。他们经常郁闷，自己vibe出来的页面，自己明明点着没问题却不能及时上线，开发人员还是会重新在每个平台各做一遍。
那么如果有一个适合AI的、支持动态化的跨平台框架，帮助运营人员做好约束、处理好平台差异和性能，专注于他们的业务和活动，在vibe不可行系数较低的场景，就能变的更直接和高效了。vibe后的代码，研发人员简单review下就可以灰度上线。
展望未来，AI还会带来一种新应用形态，“用户定制界面”。
用户可以对着App提需求，让App构造一个用户个性化的使用界面。
比如一个工作IM软件，用户可以对App说：新增一个界面，展示我@别人的所有消息，按照对方未读、已读不回、已回复来分类，超过8小时要红色显示。
然后AI就帮他生成了一个界面，动态下发到他的手机App中。
没有AI时，这种事情不可想象，有了AI和动态化，就会有很多人去尝试实现，把它变成现实。
7. 全面的验证反馈
AI写的代码对不对，是否在编译、log、运行时error、内存泄漏、崩溃这5个环节给AI更多有效帮助？
这点做好，对于AI非常重要。
而基本的前提，是这5部分信息都要有cli，让AI可以直接获取。
react native和flutter，没有专门的IDE，信息分散在自己的sdk、vscode、Android studio等不同工具中，有的有cli，有的没有。跨端部分和原生部分的获取方式也不同。
uni-app x 则把跨端和原生的所有信息按时间顺序都汇总在HBuilder的控制台中，并提供统一的cli给AI。这对AI更加友好。
HBuilder有HBuilderX和HBuilderV（基于vscode二开）2个版本，均支持这套机制。
额外补充一个原生开发的劣势：编译慢。
AI写代码很快，但kotlin/java、swift/objective-c，编译很慢。大项目时，验证反馈、运行时日志获取，要等更久。
而跨平台框架都支持开发阶段热刷新，AI写代码快、验证反馈也快，更能发挥AI的提效优势。
总结
回到开头的议题：都AI开发了，还需要跨平台框架吗？
答案是需要，只是原来没有太好的跨平台框架。
一个AI熟悉、能约束好AI、能帮AI搞定平台差异、能做到性能比原生更好、能支持动态化，这就是AI所需要的好工具。
尤其是中国开发者，面对更复杂的多端环境，一个好的跨平台框架，能带来更大的价值。
在AI时代，react native的性能问题、平台拉齐度较低的问题，如果不能很快得到解决，会出现更多shopify的例子。
flutter的原生混合渲染和原生语言通信问题，也存在让开发者想改用AI+多平台原生开发的冲动。
当AI降低了开发和迁移成本后，开发者对于跨平台框架自身的缺点的容忍度会变的更低。
uni-app x 具备一些关键优势，跨更多平台、渲染性能超过原生，支持动态化，这是原生所不及的。
希望 uni-app x 加快成熟速度，开发者和AI都需要一个好帮手。
死磕四年，投资数亿，uni-app做出了比原生渲染还快的跨平台框架
引用链接
[1] Android平台性能benchmark: https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-android.html
[2] iOS平台性能benchmark: https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-ios.html
[3] 鸿蒙平台性能benchmark: https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-harmony.html
[4] React Native Directory: https://reactnative.directory/packages
[5] 插件市场: https://ext.dcloud.net.cn/
[6] 蒸汽模式案例: https://doc.dcloud.net.cn/uni-app-x/sample.html