AI 时代，我决定深入一个跨端框架

我学习 Kotlin 的起点并不是兴趣，而是工作。2025 年初，团队负责的业务开始引入 KuiklyUI 做跨端开发，我承担了部分业务模块的开发，自然也就开始接触 Kotlin。

围绕这件事，过去一年我系统补完了 Kotlin、KMP、Compose 的基础，能流畅地写 KuiklyUI 业务代码。学到这个程度之后，我开始重新审视一个看起来很朴素的问题：会用，是不是就够了？

这篇文章是这个问题的回答，也是后续 KuiklyUI 系列的开篇。它不是一篇技术文，而是一次方向选择的复盘——从被动学习者，到主动深入者。

一、过去一年的学习

1.1 写好 KuiklyUI 需要补哪些课

业务背景说起来不复杂。2025 年初，团队负责的业务需要同时覆盖多个移动端平台。传统 H5 方案性能不够，纯原生开发又意味着双倍人力，KuiklyUI 是团队当时考虑的技术选型之一，最终也成了主力方案。

一开始我的目标很朴素，能用 Kuikly 把业务写起来就行。但真正动手之后才发现，KuiklyUI 是用 Kotlin DSL 写的，业务代码里到处涉及协程异步、声明式 UI、状态管理。这些概念虽然在前端世界里都有对应物，但 Kotlin 的写法和心智模型与 JavaScript、TypeScript 差别不小。不补语言基础，连业务代码都写不流畅。

于是我列了一张看不懂的清单。这张清单决定了接下来一年的学习路线。

第一块短板：Kotlin 语言本身。

KuiklyUI 的业务代码就是 Kotlin。它大量使用了 Kotlin 特有的语言特性：

• 带接收者的 lambda（attr { color = Color.RED } 这种 DSL）
• 协程（launch { ... } 这类异步写法）
• 空安全（?. / !! / ?:）
• 扩展函数 / 委托属性

这些特性和 TypeScript 的心智模型并不是一一对应的。语言基础不补，写出来的代码就是勉强能跑的状态，看团队同事的代码也半懂不懂。

第二块短板：Kotlin Multiplatform（KMP）。

KuiklyUI 的跨端能力建立在 KMP 之上。不熟 commonMain / androidMain / iosMain 的目录约定，搞不清楚哪段代码跑在哪个平台；不懂 expect / actual 机制，看不懂跨端代码是怎么组织的。

第三块短板：Compose 的声明式 UI 思想。

KuiklyUI 的 Compose DSL 借鉴了 Jetpack Compose。不理解 remember / Modifier / 状态提升，就理解不了 KuiklyUI 为什么这么设计 API、为什么 UI 不更新、为什么状态要这样组织。

这三块短板不是孤立的，更像是同一个问题的三个切面：Kotlin 是语言、KMP 是工程组织、Compose 是 UI 范式，缺任何一块都没法独立写好 KuiklyUI 代码。这也决定了接下来一年的学习不能先把 Kotlin 学透再说，三条线必须一起推进、循环补充。

1.2 一个专栏和一个开源仓库

围绕 Kotlin、KMP、Compose 这条主线，过去一年的学习沉淀成了两份公开产物。

一是腾讯云开发者社区的专栏《前端开发学 kotlin》，覆盖语言入门、构建系统、协程、DSL、函数式编程、元编程（反射 / 注解 / KSP）、Compose Multiplatform 实战等主题。

• 专栏地址：前端开发学 kotlin · 腾讯云开发者社区

二是开源的 Compose Multiplatform 学习仓库 learn-jetpack-compose，每个主题配一个可独立运行的 lesson 模块。

• 仓库地址：cnb.cool/cool-cc/learn-jetpack-compose

回头看，这一年其实就是在沿着补短板的路径慢慢走，先把语言学会，再理解工程组织，最后建立 UI 框架的心智模型——一步步建立起对 Kotlin 语言以及它周边生态的整体认知。

1.3 阶段性总结

肯定的部分是显然的。现在写 KuiklyUI 业务代码已经流畅多了，团队同事的 Kotlin、Compose 问题多数也能答上来，写出来的代码也不再是拼凑能跑，有了一些为什么这么写的意识。

但满意之外，也开始隐隐有一些忧虑。我能用 KuiklyUI 干活，但对它的实现原理理解并不透彻；写出的代码能跑通业务，可一旦遇到稍微底层一点的问题，就说不清楚为什么是这样。说到底，这一年的成果停留在能干活的阶段。

在 AI 编程工具迅速崛起、新人成长速度肉眼可见加快的当下，只停留在能干活是有点危险的。熟和懂之间的距离，在过去可能只是经验差异，但放到现在这个节点，会被放大成一道分水岭。

二、AI 时代下的重新审视

2.1 AI 编程工具走进日常工作

过去一两年，AI 编程工具走进日常工作的速度比想象中快得多。我自己的体感是从去年开始，Codebuddy、Cursor、Claude 这些工具陆续成为主力，写 KuiklyUI 业务代码、调试、补单元测试、查 API，几乎所有动手的环节都在被 AI 加速。

变化是直观的。以前手写一个业务组件要花不少时间，现在大幅缩短；状态绑定、列表渲染、网络请求模板这些 boilerplate 几乎不用思考就能生成；AI 写出来的代码和自己写的水平相当，某些场景下甚至更规范。

这种变化本身是好事，效率明显提高了。但顺着这条路走下去，会自然碰到一些不太舒服的问题。

2.2 一年学的，AI 都会

这两年一个越来越明显的感受是：过去一年我集中补的这些 Kotlin、Compose、KuiklyUI 能力，AI 基本也都能覆盖。很多以前需要自己查文档、翻示例、反复试的事情，现在直接让 AI 先起一版，往往就能很快推进。

这就引出一个不太容易回避的问题：那这一年学的这些还值钱吗？工程师在这种工作流下，价值落点应该在哪？

仔细想想，AI 现在最擅长的，其实是结构性强、模式化的工作——样板代码、API 调用、单元测试、文档撰写、单点查询。这些都是过去工程师日常产出的主要部分。而真正还掌握在工程师手上的，是另一类工作：跨系统调用链的判断、性能瓶颈的根因定位、架构上 A 和 B 怎么选、技术债务的优先级、复杂业务该如何拆分。

这一类工作也不是 AI 完全做不了。很多时候，只要把背景交代清楚，它也能列出几种方案，顺手把利弊一起写出来。但能给建议和能负责地做判断，还是两回事。最终选哪个、什么时候选、为什么这个阶段要这么选，还是得由真正了解项目上下文的人来定。

而能拍板的人，需要对整个项目和它所处的环境有足够深入的认知——既要有技术深度（能判断方案在底层会跑成什么样），也要有技术广度（能权衡跨子系统、跨平台、跨业务域的影响）。这些是 AI 目前还接不住的部分，也是工程师真正的差异化所在。

回到 KuiklyUI 的具体场景就更清楚。AI 能写 attr { color = Color.RED } 这种业务代码已经很熟练了，让 AI 分析 attr DSL 和直接传 props 的优劣，它也能给出一份像模像样的对比。但具体到 KuiklyUI 这个项目——为什么当时选择了 attr DSL、这个设计在 4 平台一致性、包体积、开发体验之间是怎么权衡的、未来业务规模 ×10 之后还撑不撑得住——这种问题需要对框架本身、对团队当时的工程约束、对业务未来的演进有真实理解的人才能判断。

我越来越觉得，后一种理解，才是 AI 起来之后更值得工程师投入精力去建立的部分。

2.3 由此而来的判断

把前面的观察归拢一下，得到的判断是这样的：

AI 时代代码交付成本变低了，但判断代码好不好的能力变得特别重要。

再往下想一步，会发现工程师的重心确实在变。过去更强调把需求翻成代码、修 bug、学会新框架、熟练使用工具；现在这些环节都在被 AI 持续压缩。相对地，什么是合理抽象、什么叫真正修好、两个方案差别到底在哪，这类判断开始变得更重要。

2.4 把 AI 当作杠杆

我对 AI 的态度其实很直接：不用跟它比谁写得快，而是把它用在该用的地方。样板代码、单测、API 查询、初版实现，都可以先交给 AI；省下来的时间，再放回到 review、取舍和架构判断上。

对我来说，这不是要不要用 AI 的问题，而是 把自己的时间主要花在哪 的问题。如果大量时间还停留在重复产出上，那很多积累都会被工具快速抹平；但如果把时间投到判断和取舍上，积累就会慢慢沉下来。

想清楚这一点之后，问题自然就指回了答案：那要怎么训练这种判断力？答案就在每天打交道的代码里——KuiklyUI，这个我已经会用、但还没真正懂的框架。

三、为什么深入 KuiklyUI

已经会用、但还没真正懂；框架本身优秀，日常工作也用得上——光这几点，就足够支撑我继续往下深入。理由展开来讲大概是这样几条：

3.1 KuiklyUI 是腾讯内部经过大量业务检验的优秀框架

它不是教学项目，而是 QQ、腾讯视频、腾讯新闻等多个亿级 DAU 业务在生产环境跑的工业级框架。这意味着每一个设计选择背后都有真实的工程权衡：性能、包体积、跨平台一致性、维护成本。这些权衡才是判断力训练的真正素材。

读教学项目的源码学不到这些。教学项目通常只需要把功能做对，但很少需要做取舍。

3.2 它是工作中实际在用的框架

工作中遇到的问题立刻能驱动学习方向，学到的判断也立刻能反哺工作决策。

没有反馈闭环的学习几乎一定半途而废。这一年我看到身边不少同学立 flag 学新语言、新框架，最后能坚持下来的，几乎都是工作里实际用得到的。KuiklyUI 对我来说，恰好就是这种每天都打交道的框架。继续深入它没有任何额外学习成本，只是把每天都在用但还没真正懂的东西从模糊变清晰。

3.3 它的心智模型有不少熟悉的影子

vfor / vif / vbind 指令直接复用 Vue 心智，attr { color = ... } 类似 CSS-in-JS，Module 体系（Network / Router / SP）也类似浏览器 Web API。

学习曲线的陡峭部分主要是 Kotlin 语言细节，框架抽象本身几乎是无缝的。这种半熟悉感让人能把全部精力投入到它为什么这么做，而不必消耗在补基础上。如果换成一个完全陌生的框架（比如纯原生 iOS 或 Android Jetpack 全家桶），前 6 个月会全部消耗在补概念，根本到不了思考设计权衡的层级。

3.4 它值得从设计选择的角度去读

这是决定深入它的最核心理由。

KuiklyUI 不是那种会用 API 就差不多了的框架。它同时牵涉语言、跨端工程组织、渲染抽象、状态更新、平台差异、动态化能力，这意味着它背后一定有不少具体的设计取舍。

对我来说，真正值得深入的，不是先急着给这些选择下结论，而是先把这些问题一一看清楚：为什么它的 DSL 长这样、为什么页面和模块边界这样切、为什么有些能力放在跨端层、有些能力放在平台侧、为什么同样是声明式 UI，它最后落到各端的路径会这样组织。

也正因为这样，它很适合拿来练判断。因为你面对的不是教材里的标准答案，而是真实工程在约束条件下做出来的选择。

四、接下来的学习计划

方向定了，接下来就是具体打算怎么做。这一年补 Kotlin、KMP、Compose 用的是由浅入深、跟教程跑的路子。这种方式在打基础阶段是合适的，但接下来要训练判断力，路径需要做一些调整。

4.1 先建立整体架构认知

通读 KuiklyUI 源码不是好目标。30 万行+的代码量，如果把读完当作目标，几个月后会发现进度没多少，然后失去动力。

但完全跳过架构、直接钻细节也不可行。一个跨端框架是有层次的：Compose DSL 层、Core 业务层、Bridge 通信层、各平台 Render 层之间，关系错综复杂。如果不先建立整体认知，看到一个具体机制时根本不知道它在哪一层、上下游是什么、为什么这里这么实现。

所以第一步是先把架构图弄清楚。需要回答几个基本问题：KuiklyUI 一共有多少个层？每一层的职责边界在哪？数据怎么从顶层流到原生渲染？事件怎么从原生反向流回业务代码？跨端的能力是在哪一层抽象出来的？

把这些问题回答清楚，后面再深入任何一个具体机制时，才能知道它在整个系统里的位置，知道它的上下文是什么。

4.2 带着问题拆解局部

有了整体认知之后，再开始挑具体的点深入。

挑选的依据有两条。一是问题驱动，工作中遇到的真实问题往往是最好的切入口，比如 vfor 在某个场景下不更新、动画在 iOS 上卡顿、列表滑动到底部时偶发崩溃。带着具体问题去读源码，目标明确，收获也明确。

二是按决策密度挑。一个框架里真正值得深入的，通常不是那些边界处理和异常分支，而是那些明显带有 为什么要这样设计 意味的位置。比如布局模型怎么抽象、状态更新怎么驱动 UI、跨端通信边界怎么划分、Compose 和 Core 是怎么接起来的。读这些地方，比机械地从头扫到尾回报高得多。

4.3 设计判断视角

无论是带着问题进来，还是按决策密度挑切入点，读源码时我都想提醒自己换个角度：不只看它做了什么，更要看它为什么这么做。每读一段代码，尽量回答四个问题：

这里还能怎么写？ 那种写法为什么没被选？ 如果是我，会怎么选？ 我的选择在什么场景会输给现在这个？

这四问其实是在逼自己别停留在看懂代码这一步，而是试着站到设计者的位置，把这道题重新做一遍。能回答出来，才算真正进入了设计层；答不出来，就说明理解还停在表面。

举个抽象一点的例子。一个框架在表示 未设置 时，可以用可空类型、约定默认值、哨兵值，或者单独包一层状态对象。表面看只是一个实现细节，背后其实连着性能、可读性、API 一致性、调用成本等一整串权衡。设计判断视角要看的，就是这种看似小、实际上牵一发而动全身的选择。

4.4 节奏与方向

具体节奏上，我会尽量守住几条原则：每篇都要有设计权衡这一段，至少回答四问中的前三个；节奏不强求，宁可少写，也不为了更新频率硬凑；每篇只讲一个值得展开的设计选择。

KuiklyUI 后续要写的方向，目前看大致围绕这几条线索：

• 架构与跨端通信：层次切分、Bridge 协议、Pager 生命周期
• 响应式与状态管理：状态更新模型、与 Compose 的接缝设计
• 布局与渲染：布局抽象、4 平台渲染层的差异化
• 异步与并发：异步任务组织、线程与协程边界
• 工程化机制：KSP 入口生成、动态化方案、多平台构建

具体每篇文章的标题和深度会随研究推进调整。目标不是按目录顺序通读，而是按决策密度挑值得深入的点。

4.5 AI 工具的配合

写这个系列时，我也不会完全排斥 AI。用它来快速过代码结构、梳理调用链、找关键入口，确实能省掉不少机械时间；但真正要自己下功夫的，还是后面的判断部分，比如这个设计解决了什么问题，又带来了什么代价。

所以 AI 在这里更像一个辅助工具。它可以帮我更快进入问题，但不能替我做最后的理解和取舍。

总结

回到最初。业务把我推到了 KuiklyUI 面前，我接住了它。现在，决定主动再往深一步走。

这次决定继续往下走，背后大致有三点：

1. AI 把代码产出的门槛继续往下压了，但 怎么判断一段代码、一套设计到底好不好 这件事，反而变得更重要。
2. 跨端框架很适合拿来练这种能力，而 KuiklyUI 又刚好是我正在用、也有足够复杂度的那个对象。
3. 接下来的目标不只是把源码读懂，而是尽量把每个关键设计背后的取舍想清楚。

在 AI 时代，真正拉开差距的，可能也不是会多少框架，而是能不能把一个跨端方案一路看深到语言、平台、通信和工程约束。

下一篇文章，会从 KuiklyUI 的整体架构图开始，看一个跨端框架的层次切分背后藏着哪些设计选择。