大家好，我是老刘
前两天老刘发文讨论新的跨平台框架Perry，这个框架的技术方案老刘还是很欣赏的。
评论区有朋友说当前AI时代，研究跨平台框架已经没有意义了，直接让AI生成不同平台的代码即可。
这个观点老刘并不赞同，老刘觉得至少在当前的AI技术体系下，跨平台框架反而更能体现其价值。
先别急着判跨平台死刑
很多人会下意识觉得，既然AI可以同时生成Android、iOS、Web代码，那跨平台的意义自然就没了。
这个推理的前提是原生开发比跨平台开发更好，跨平台框架的作用只是减少了开发成本。
但是实际情况早已不是这样了。
除了只需要开发一份代码所减少的开发成本，各种跨平台框架还带来了很多原生不具备的优势。
比如RN能提供企业级的动态化能力，而且能利用比客户端庞大的多的前端生态。
比如Flutter能提供业界最好的多端一致性体验，还能提供原生不具备的工业级单元测试能力。
那么随着AI能力的提升，AI开发在实际项目中变得越来越重要，这种变化对跨平台框架的影响是什么呢？
AI 应用的前端，正在变得越来越重
以前很多客户端页面，大多数就是表单、列表、详情页这样的简单交互方式。
但是今天的AI应用不是这样。
你看现在稍微像样一点的AI产品，前端层都在快速变复杂：流式输出、打字机效果、卡片拼装、语音输入、摄像头识别、白板、工作流节点、Agent执行过程可视化、多人协作、长任务状态反馈、中断恢复。
这些东西有个共同点：它们都不是把一个静态页面画出来那么简单，而是持续变化、持续反馈、持续重组的交互系统。
客户端交互方式的变化自然就需要底层的开发框架提供更方便、性能更好的支持。
跨平台框架因为不需要像原生框架那样保持对老的系统版本的持续兼容，因此能够更快速地迭代和适应新的交互方式。
以Flutter为例，它在App中自带了渲染引擎，因此每个版本都不需要考虑底层适配多个不同版本的渲染层。
所以其实AI时代对跨平台框架来说是利好，而不是利空。
那么问题来了，到底什么样的开发框架才能更好的适应高速发展的AI时代呢？
AI 时代，框架值不值钱，要看三个新标准
我现在判断一个开发框架有没有跟上AI时代，主要看三件事。
1. AI 能不能顺畅地和它协作
这是非常现实的生产力问题。
AI友好度正在成为新的技术选型标准。训练数据够不够多、代码模式是不是直观、框架是不是一堆黑盒魔法，这些都会直接影响AI生成代码的成功率。
如果一个框架过于依赖复杂注解、隐式约定、难以解释的代码生成，那AI协作的成本就会很高。你表面上省了几个语法糖，实际上可能在和AI来回拉扯里把时间全赔回去了。
Flutter和Dart在这件事上是占便宜的。生态成熟、公开案例多、代码结构相对稳定，这些都会降低AI的理解成本。
2. 框架能不能方便地接入AI能力
过去你评估一个客户端框架，先看有没有按钮、列表、路由、网络、状态管理这些基础设施。
现在还得多问一句：它在对接大模型、对接Agent、对接多模态能力时，顺不顺手？
在AI时代，对接模型已经慢慢变成了基础能力。
就像没有人会自己从画布开始手搓按钮、对话框一样，团队也不会愿意每次都从零搭一套模型调用、流式输出、状态同步、工具编排的底层设施。
谁能把这些能力工程化，谁就更像下一代的基础框架。
这方面跨平台框架又一次证明了它的价值。
比如Flutter提供了丰富的插件生态用来接入AI能力：
google_generative_ai：Google官方提供的Gemini SDK，原生支持文本、视觉等多模态输入和流式响应。firebase_vertexai：依托Firebase生态，允许在Flutter客户端直接安全地调用Vertex AI，非常适合独立开发者快速构建MVP。langchain_dart：LangChain框架的Dart移植版。如果你需要做复杂的Agent编排、工具调用（Tool Calling）或RAG（检索增强生成），它能帮你省下大量造轮子的时间。dart_openai：社区维护的高质量OpenAI SDK，全面覆盖GPT-4、Whisper、DALL·E等接口。ollama_dart：配合本地化部署趋势，方便端侧应用直接对接Ollama运行的本地大模型。
通过这些生态沉淀，开发者不再需要手搓底层的HTTP请求、处理复杂的SSE（Server-Sent Events）流解析。一套原生的Dart接口，就能直接把AI对话、多模态处理的核心链路跑通。
3. 框架能不能承接动态生成的交互
这才是我觉得最容易被低估的一点。
过去的客户端交互，大多是产品经理先定义好，再由开发实现。
未来很多交互，可能是AI根据上下文、任务状态、用户目标，实时组织出来的。
前两天大家还在讨论AI输出markdown还是html，本质上讨论的是同一件事：静态内容表达不够了，大家都在追求更可操作、更可交互的结果形态。
放到客户端里也是一样。
如果一个框架对动态界面、实时状态和复杂交互没有足够好的支撑，那它即便还能写传统App，也未必接得住下一波AI产品。
Flutter前一段时间官宣的Gen UI就是这种情况的典型代表。
你想想这个场景：你在对话框里问帮我找几套适合杭州出差的酒店，AI给你的不再是几行干瘪的文字列表，而是直接在屏幕上弹出一个完整的、带图片轮播和预订按钮的Flutter酒店卡片。你可以直接在这个卡片上滑动看房型，点击下单。
大模型在后台基于当前的场景生成最适合的页面布局描述，而Flutter接住这些描述，把它渲染成用户可见的交互页面。
这时候Flutter就不只是个画UI的工具了，它变成了AI想法的落地画布。大模型脑补出什么交互，Flutter就能立刻在端侧把它跑起来。
不仅仅是Flutter，像RN这样走中间层技术路线的框架，其实更容易实现类似的效果。
因为RN的技术架构本身就能很方便的支持页面的动态下发。现在只需要把大模型生成的页面描述插入到这个流程中即可。
对开发者来说，赶紧上车，来不及解释了
AI时代来得太快，快到很多框架还没来得及重新定义自己。
但对于开发者来说，真正要紧的是赶紧上车，让自己的技术体系能适应AI时代的新需求。
如果你现在还把Flutter只当成一个跨平台UI工具，那视角可能已经旧了。
你更应该开始尝试做下面这些事：
- 用AI协助你写Flutter，而不是和AI对着干
- 熟悉流式输出、聊天交互、任务状态、工具调用这些AI产品常见前端模式
- 学会把模型能力、业务流程和组件系统真正接起来
- 多关注动态UI、可视化工作流、多模态交互这些更接近下一代产品形态的方向
最后说个判断
我现在的看法很明确：
AI不会让跨平台框架消失，它只会淘汰那些还停留在画页面阶段的框架认知。
Flutter未来能不能成为AI应用时代最强的那一个，现在还不能下死结论。但它至少已经站到了正确的战场上。
这比是不是最先进更重要。
因为接下来真正有机会的，不是最会喊AI的框架，而是最能把AI变成产品体验的框架。
而Flutter，正在往那个方向走。
如果你本身就在做Flutter，我建议你别再只盯着传统页面开发了，尽快拿一个AI场景做小范围验证，先把自己的经验曲线切到新问题上。
你怎么看这件事？你觉得Flutter在AI时代最有机会吃到的，是多端一致性、动态UI，还是AI工程化接入能力？
🤝 如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。
🎁 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。可以作为Flutter学习的知识地图。
💬 : laoliu_dev
📂 老刘也把自己历史文章整理在GitHub仓库里，方便大家查阅。