AI开发时代，还需要跨平台框架吗？

作者 | 王安

出品 | CSDN（ID：CSDNnews）

很多人都在问，现在都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熟悉的好框架

TS+Vue就是好组合。

有这种框架，AI写的代码少，犯错的机会少、犯错后编译链就能及时发现错误，可验证性好。

如果使用过于灵活的原生编程语言，一个需求有多种实现方式，多人协作时多个AI不停提交各种方式的实现，代码库很快就会乱套，进而给AI也增加了复杂度。

其实浏览器也是一个框架，它的约束，让Web应用开发出问题的概率，低于原生应用。而基于浏览器再次提供约束的TS+Vue，就更适合约束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时代最主流的开发工具呢？

答案是肯定的。

只不过业内过去没有做出来符合标准的好框架，导致人们陷入了原生成本高、但原生是王道的传统认知里。

那么目前最接近理想框架的是哪个呢？

我们来用上面的6点，来分析下主流的跨平台框架：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：https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-android.html

• iOS平台性能Benchmark：https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-ios.html

• 鸿蒙平台性能Benchmark：https://doc.dcloud.net.cn/uni-app-x/benchmark/vapor-benchmark-harmony.html

其中的实验工程不管是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，发现收录了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的插件均在其插件市场（https://ext.dcloud.net.cn），该市场的插件总数有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。

不过其官网列出不少蒸汽模式案例，不乏在应用商店中下载量超百万、千万的应用。达到商用标准看起来没有问题。但边缘场景需注意单独评估。

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都需要一个好帮手。

「大模型技术：从 Agentic Scaling 到 RSI」专题阵容更新！

从 OpenAI、Anthropic、Google 到智谱、DeepSeek、月之暗面、阿里等头部团队都在持续推进 RSI / 自进化相关研究。

2026 奇点智能技术大会邀请一线研究者与工程技术专家，围绕强化学习、持续学习、AI 制造 AI、自进化 Agent、模型数据飞轮等关键方向展开分享。

11 月 20–21 日｜北京万达文华酒店

专题还附赠一份 《RSI 递归自我改进 / 自进化前沿研究资料包》，汇总 OpenAI、Anthropic、Google、智谱、DeepSeek、Kimi、阿里等最新论文、官方报告与研究资料。

扫码即可免费领取，也欢迎报名来现场把 RSI 这条技术主线一次听透。