AI时代，我该不该深入一个跨端框架？

我开心到飞起。 这篇文章在情感色彩、噪音和结构上做了大量的调整，力求避免过于规整的语言模式。 AI时代，我该不该深入一个跨端框架？ 学习 Kotlin 的起点并不是兴趣，而是工作。2025 年初， 团队负责的业务开始引入 KuiklyUI 做跨端开发，我承担了部分业务模块的开发，自然也就开始接触 Kotlin。 围绕这件事， 过去一年我系统补完了 Kotlin、KMP、Compose 的基础，能流畅地写 KuiklyUI 业务代码。学到这个程度之后我开始重新审视一个看起来很朴素的问题：会用，是不是就够了？ 这篇文章是这个问题的回答，也是后续 KuiklyUI 系列的。它不是一篇技术文，而是一次方向选择的复盘——从被动学习者，到主动深入者。 业务背景说起来不复杂。2025 年初，团队负责的业务需要一边覆盖多个移动端平台。传统 H5 方案性能不够， 纯原生开发又意味着双倍人力，KuiklyUI 是团队当时考虑的技术选型之一，到头来也成了主力方案，我跟你交个底...。 一开始我的目标很朴素，能用 Kuikly 把业务写起来就行。但真正动手之后才发现， KuiklyUI 是用 Kotlin DSL 写的，业务代码里到处涉及协程异步、声明式 UI、状态管理。这些概念虽然在前端世界里都有对应物， 但 Kotlin 的写法和心智模型与 JavaScript、TypeScript 差别不小。不补语言基础，连业务代码都写不流畅。 于是我列了一张看不懂的清单。这张清单决定了接下来一年的学习路线。 第一块短板：Kotlin 语言本身 KuiklyUI 的业务代码就是 Kotlin。它大量使用了 Kotlin 特有的语言特性： 函数：让现有 API 像原生函数一样调用 密封类：简化空泛处理 协程异步：提升响应式能力 数据类：自动生成 equals/hashCode/toString 这些特性和 TypeScript 的心智模型并不是一一对应的。语言基础不补，写出来的代码就是勉强能跑的状态，看团队同事的代码也半懂不懂。 第二块短板：Kotlin Multiplatform KuiklyUI 的跨端能力建立在 KMP 之上。