过去一年，鸿蒙在国内操作系统市场的份额已愈来愈高，AI Coding 亦愈加成为受人关注的技术领域。那么，面向各端不同的语言选型、框架、生态等问题，AI 从业者应如何应对“生成多端一致的客户端代码”这一巨大挑战呢？
近日 InfoQ《极客有约》X AICon 直播栏目特别邀请了前阿里工程师吴子奇担任主持人，和字节跳动技术专家范绍贵、快手移动端稳定性负责人李锐一起，在 QCon全球软件开发大会2025（上海站）即将召开之际， 探讨 AI Coding 与跨端研发上的先行探索和最佳实践。
部分精彩观点如下：
跨端框架的设计者应在保证 Native 级性能的基础上，将是否使用各平台特有能力的选择权交给开发者。
跨端技术要取得进一步突破，需从语言、虚拟机等底层开始进行系统性创新，解决已有方案中诸如 FFI 和自渲染性能损耗等核心问题。
行业对大前端人才的要求将更趋向于 T 型甚至 π 型发展路径，即至少拥有一项专长同时具备多端能力，甚至多项专长与多领域经验的结合。
AI 有望在未来 10 到 20 年内极大提升社会财富积累，人们可能不再仅为生存而工作，即使不就业也可享有基本生活保障和尊严。我们可以更自由地追求个人价值，做自己真正想做的事情。
在 10 月 23-25 日将于上海举办的 QCon 全球软件开发大会 2025 上海站上，我们特别设置了【AI 与跨端的高效融合】专题。该专题面向客户端、前端应用开发、AI 应用、研发效能相关领域从业者，深度拆解 AI Coding 时代下跨端技术的演进方向发展趋势。查看大会日程解锁更多精彩内容：https://qcon.infoq.cn/2025/shanghai/schedule
以下内容基于直播速记整理，经 InfoQ 删减。
完整直播回放可查看：https://www.infoq.cn/video/zeKDVDUCRdVoO9JMNp8g
「一码多端」和「跨端一致性」
吴子奇：从今年年初开始，「一码多端」逐渐成为客户端领域的一个热点词，它不仅仅是技术层面上的“一套代码多端运行”，更重要的是，它背后牵扯到开发者在技术、架构、团队协作等方面的全新挑战，同时也伴随着 AI 等新技术带来的破局机遇。两位老师觉得在实际工作中，感受到的最大变化是什么？
李锐： 我最大的感受可概括为两个“新”：新变革与新战场。新变革主要体现在多端融合与 AI 技术带来的变化；新战场则指这两者为大前端领域开辟了新的发展空间。在多端融合方面，一码多端的诉求显著增强，技术融合趋势日益明显，并逐步升级为新的研发模式。
鸿蒙在国内市场份额持续提升，已成为与 iOS、安卓并列的三大操作系统之一。以往许多国内公司采用安卓与 iOS 两套研发团队，辅以部分动态化技术栈的开发配置方式，由此导致多端多套代码、研发成本高企的问题。新系统如鸿蒙的出现，进一步加剧了这一负担。此外，多技术栈还带来基建重复、协作效率低、工程标准不统一等隐性问题，影响整体交付效率。因此，从效率与成本两个维度出发，各公司均加大了对一码多端技术的投入与研究。
在这一背景下，快手的技术融合趋势愈发显著。如何利用大前端技术升级研发模式，已成为一个重要课题。实践中，快手大前端通道牵头推进了多项工作，包括扩展大前端业务场景、培养复合型人才、融合各技术栈基建以提升能力上限。目前，我所在的移动端技术平台正在推动全应用一码多端的大前端架构落地。另一方面，AI 技术变革也带来深远影响。过去一年，快手内部涌现出大量 AI 工具，无论是公司层面还是主站技术推行的“AI First”战略，均取得了显著成效。这表明 AI 正在重塑研发各个环节，使大前端能够实现以往难以完成的任务，突破既有边界。
范绍贵： 在大厂中，跨端方案已发展多年，如今进入深水区与无人区，传统创新模式难以实现进一步突破。在字节内部，我们认识到必须从语言层、虚拟机层、UI 框架及工程体系等底层进行综合性创新，才可能实现颠覆性突破。
是否存在一种跨端方案，既能实现极致性能——甚至与 Native 性能媲美，又能真正实现跨端？Native 与跨端看似矛盾，但却是当前时代的实际诉求。从安卓、iOS 扩展到鸿蒙乃至 Web 等多端，研发效率需提升，但性能始终是核心追求。在这一背景下，字节对跨端框架设计者提出了极高要求，需提供具备 Native 级性能的跨端方案，同时对业务开发人员也要求掌握更全面的技术栈。过去，安卓、iOS 单端小组仅需精通一端技术即可，但在大跨端时代，业务开发人员需同时面对安卓、iOS、鸿蒙等多端并存的环境。若仅熟悉一端而非资深专家，将难以满足未来技术栈的要求。
吴子奇： 我们通常认为跨端方案难以媲美 Native 的性能。无论是早期的 RN 还是其他动态化框架，大多被用于实现动态部署，以解决发版和上线效率问题。但您刚才提到跨端可以达到 Native 级别的性能，这是如何实现的？
范绍贵： 传统跨端方案通常存在三大性能瓶颈：首先是跨语言调用（FFI）的开销，其次是语言内部的垃圾回收（GC）机制，第三是若采用自渲染，渲染层也会带来一定损耗。我们在探索全新跨端方案的过程中发现，核心瓶颈其实在于传统虚拟机，例如 JS 引擎。因此我们设想，是否存在一种方案能彻底避免 FFI 的性能损耗，完全采用端渲染，并依托系统级语言自动处理内存回收与 GC？基于这一思路，我们尝试将自研语言直接编译为 Native 语言，整体与客户端应用打包而非动态下发。这样一来，其本质就与手写代码并无差异。通过逐步验证与落地，目前该方案在线上实际表现已与 Native 性能基本持平。
吴子奇：李锐老师，范绍贵老师所提出的问题与您在快手推进一码多端过程中所关注的焦点是否一致？若存在差异，主要区别或侧重点又体现在哪些方面？
李锐： 跨端本身是一个复杂的问题，其挑战远不止于性能维度。它还涉及用户体验、快速触达用户、多端一致性以及研发效率等多个方面。如果只追求某一单一维度，行业中已有许多现有方案——例如若纯粹追求性能，纯 Native 方案或许是最优解；若侧重快速发布和动态能力，H5 可能是更合适的选择。因此，快手目前仍处于多种技术栈并存的阶段。我们内部通常将跨端技术的需求概括为“三高”：高迭代效率、高研发人效和高性能体验，这是我们当前的主要理解和努力方向。
吴子奇：范绍贵老师，您所提出的方案是专注于特定领域或一码多端中的子问题，还是代表了一种更普遍的发展方向？您是否考虑过业界是否存在类似的方案？
范绍贵： 动态下发以提高发布灵活性属于工程效率问题，而开发体验优化则是持续改进的过程。如果我们能够在性能上达到更高标准，接下来的重点便是不断完善开发体验。关于业界现有方案，我们在设计过程中当然也有所借鉴和参考，汲取了许多优秀思路。
吴子奇： 任何技术方案都离不开时代背景。过去由于应用审核和发布效率等限制，动态化技术如 RN 和 Weex 应运而生，以解决特定问题。而当前一码多端的背景，则是在鸿蒙等新平台兴起的情况下，如何在有限人力资源中实现高效开发。面对这一目标，业界涌现出多种路径，它们并非最终答案，而是不断逼近最优解的探索过程。
吴子奇：在“性能表现”和“交互逻辑”这两个关键点上，实现真正意义上的“体验融合”，最大的难点究竟在哪里？
范绍贵： 以 Flutter 为例，它通过语言、框架与客户端一体化的闭环设计，彻底解决了多端一致性问题。然而，这种看似直接的方式仍存在其他问题，例如因 FFI 导致性能无法与 Native 持平。我们常提到，用户购买高端手机是期望获得系统原生的流畅体验，而采用自渲染方案往往难以完全实现这一点。例如 iOS 系统自带的毛玻璃等特效，即使在 Flutter 中可通过嵌入方式部分实现，其性能与纯原生相比仍有差距。因此我认为，跨端框架的设计者应在保证 Native 级性能的基础上，将是否使用各平台特有能力的选择权交给开发者。框架应允许开发者根据平台差异自主决策，例如在 iOS 上启用毛玻璃效果，而在安卓端采用其他替代方案。
我们的 RTS 方案主要通过两方面实现该目标：一是性能与 Native 一致，二是可灵活选用各端独有特性。性能方面，我们将自研语言转译为 Native 语言，与客户端代码一同打包发布，从而具备原生性能。不同于 Flutter 的自渲染闭环模式，我们基于公司开源的 Lynx 框架实现端渲染，并依托其多年的多端渲染抹平经验，在避免 FFI 的前提下，实现了数据的无缝互通与多端一致性，最终达到与原生开发基本一致的性能表现。特性方面，开发者可通过条件编译等方式，在不同目标平台上选用特定组件（如 iOS 的毛玻璃效果），从而拥有充分的自主选择权。
实现过程中最大的难点在于多端抹平与语言差异的调和。一种语言需同时编译为多种目标语言，而各语言本身存在一定差异，因此我们必须取其语义的最小公共集，保证 RTS 代码在多方行为一致，这常常需要做出某些权衡。由于 Swift、Kotlin 等语言并非由我们设计，其语法特性存在固有差异，因此用 RTS 编写代码会受到一定限制。但从实践来看，高级语言的许多特性，如单子模式实现，在各大平台已趋于一致。
李锐： 我们已进入跨端融合的新阶段，其目标不仅是实现界面外观的一致，更在于让不同设备之间的体验真正连贯和统一，这对跨端技术提出了更高的要求。
挑战主要体现在两个维度。首先是用户视角：快手目前采用多技术栈并存的策略，因此需确保用户在使用过程中感知不到技术差异，体验到完整和统一的整体。实现这一点的基础，是建立统一的监控指标体系，涵盖性能和稳定性等多个方面，如页面打开速度与流畅度。若各技术栈使用不同的指标与标准，不仅会造成重复建设，还难以进行横向对比和有效评估。例如，客户端上报的 FMP 指标与 H5 或 RN 所定义的 FMP 并不相同；而在稳定性层面，Native 端通常关注崩溃、卡死和 OOM 等异常类型，而动态化方案则更多聚焦于 JS 异常——但 JS 异常并不直接等同于页面不可用，还需结合白屏监控等进行综合判断。因此，实现真正跨端融合的第一步，是推动监控指标的统一。在快手，我们通过发起大前端监控专项，系统梳理各技术栈的指标差异，最终实现了监控口径的融合。
其次是从研发视角看，多技术栈共存确实会引入许多跨技术栈的“疑难杂症”。在稳定性层面，由于技术选型更加多样，往往会引入多语言、多运行时环境，每个运行时又有其各自的线程模型、内存管理、资源占用、垃圾回收和异常处理机制。这种复杂性极易引发问题，例如 FFI 时因跨运行时生命周期管理不当导致的崩溃，或跨运行时 Bridge 存在的性能瓶颈。
基于用户和研发这两个维度的背景，快手移动端技术平台致力于为多端融合与用户体验提供全面保障。在性能方向，我们近期在内部的“乘风”工程挑战赛中，重点推动了 AI 火焰图分析工具的落地。该工具旨在实现对 Android、iOS、Web 及各类动态化技术栈性能问题的统一诊断与分析，成为大前端性能监控的一个典型实践。
在稳定性方向，我也做一个简要预告：在十月份的 QCon 大会上，我将分享快手在稳定性建设方面的两项关键成果。其一是名为“艾克 Ekko”的止损工具，其核心能力是通过动态修改程序流实现自动故障兜底。与传统安全气垫方案相比，Ekko 在安全性和覆盖范围上均有突破，并结合 AI 实现了部分问题的自动修复。其二是名为“福尔摩斯 Holmes”的排障工具，该工具萃取自数百个线上疑难案例的实战经验，提供全技术栈支持的事件追踪与 UI 视图信息还原，可精准复现问题现场，极大提升研发排查效率。近期我们还开发上线了 AI 排障 Agent，进一步增强了智能化诊断能力。
吴子奇： 要实现真正完全一致的「多端融合」，在实际开发中还是需要做一些取舍。比如，根据各个平台的体验差异做有选择性的条件编译，或者针对不同端对业务逻辑和 UI 界面 进行适配。这样一来，代码复杂度和开发者的心智负担都会显著增加。你们所在的团队是如何管理和应对这种复杂度的？从实际情况来看，这会不会在某些场景下反而降低了开发效率？
李锐： 首先我想补充 iOS 系统升级导致大量崩溃、需要连夜处理的问题。Ekko 这一工具可以解决此类痛点。例如前段时间 iOS 26 升级时，我们的图片库也遇到了兼容性问题，但借助 Ekko 工具，系统实现了自动兜底，避免了更大影响。
关于“多种技术栈共存究竟是利是弊”的问题，我的观点非常明确：这是一件好事。原因在于，我们应当回归大前端开发的本质职责——面向终端用户，运用终端技术解决人机交互中的各类问题。技术选型只是手段，最终目标始终是用户体验的最优化。在当前阶段，多技术栈并存的架构，恰恰是我们综合考量后所选择的最佳路径。
多端融合确实引入了更多复杂度，那么我们如何通过技术选型和管理来应对这些挑战？在快手，我们将这类问题拆解为 UI 跨端和逻辑跨端两个维度。过去在 UI 跨端方面，我们主要依靠内部技术方案 KDS，包括基于 KRN 深度优化的页面级方案 KDS React，以及卡片级方案 KDS Native（或称 TK）。这些方案在 UI 层面实现了一码多投，并得到广泛应用，但在处理复杂业务逻辑与大数据量时仍存在一定局限。因此我们引入了 KMP 技术方案，与原有 KDS 形成互补。
KMP 的选型并非一帆风顺，经历了内部多轮讨论和高层决策。我们曾对比过 Rust、C++ 等语言，但最终从开发效率、语言生态等维度综合评估，认为 KMP 更具优势。目前行业各大厂商，在推进全应用一码多端的过程中，也都不约而同地选择了 KMP 作为逻辑跨端的解决方案。大家的目标非常一致：通过高性能的逻辑跨端方案填补技术空白。
范绍贵： 跨端技术要取得进一步突破，需从语言、虚拟机等底层开始进行系统性创新，解决已有方案中诸如 FFI 和自渲染性能损耗等核心问题。在综合审视现有方案的局限性后，我们思考是否能够跳出既定框架，从零开始设计一套新方案。RTS 基于转译的技术路径，正是在这一背景下提出，它较好地实现了我们最初的预设目标：既达到 Native 级别的性能，又真正实现多端跨端支持。
关于跨端开发复杂性，我认为若仍沿用传统模式——每位开发者仅负责一端，如专攻安卓或 iOS，那么在鸿蒙加入后形成三端并行的情况下，个体开发者面临的复杂度和心智负担的确会加重。但从整体来看，原本可能需要三人完成的工作，现在只需一人或一个半人即可承担，因此对企业而言整体复杂度实为降低。同时，传统方式需维护三套代码，而采用 RTS 这类方案后，只需一套工程和代码，维护成本显著下降。
当然，对开发者个人而言，需同时掌握多端开发技能确实带来挑战。因此我们的重点在于顺应跨端趋势的同时，努力降低代码复杂度和开发者的心智负担。目前 RTS 主要通过两种途径实现该目标：一是框架自身应尽可能抹平端间差异，使开发者无需感知底层不同；二是通过工具链建设提升开发体验。具体来说，我们在三个层面实现差异抹平：
第一是语言层。RTS 将同一套代码转译为多端原生语言，并确保其行为一致性，开发者无需关注底层语言差异，也无需额外学习各客户端语言。
第二是 UI 层。RTS 编写 UI 框架会被编译为 Swift 或 Kotlin 等原生代码，与客户端共同编译。开发者只需使用同一套 DSL，无需面对不同平台的 UI 差异，UI 表现自动保持一致。
第三是工程层。我们致力于打造统一的开发体验，提出“One IDE”理念：在一个集成环境中完成多端开发、编译和调试。开发者可在 RTS 源码层面断点调试，实际运行于原生代码环境，并查看运行时变量。同时支持热重载调试，提升了客户端的开发体验。
除了架构层面的设计，我们还通过辅助工具进一步降低开发复杂度。RTS 支持开发插件，允许业务方基于编译器插件自动完成端间差异抹平，直接干预转译输出。例如常见字段名不一致、类型差异等，都可通过工具链自动对齐。我们也正探索借助 AI 自动生成抹平代码，帮助开发者提升效率。
吴子奇： 字节在这一方案上投入了多少兵力？
范绍贵： 目前至少有三四个团队共同参与，包括负责 RTS 语言与 UI 框架的团队、负责工程体系的团队，以及专注于调试工具与 IDE 开发的团队。从语言、虚拟机、UI 到工程化与工具链，整个技术栈的研发投入总计数十人。
吴子奇： 未来是否有面向社区的开源或推广计划？
范绍贵： 我们确实有计划在内部方案相对完善并达到可对外阶段后，将整套技术开源给社区。正如我司已有的 Lynx 框架一样，我们期待通过开源获得更多反馈，与开发者共同推动方案演进，为国内外企业提供一种全新的高性能跨端选择，共同促进行业发展。
吴子奇： 过去，我们习惯于 iOS、Android、Web 各自独立的团队模式。那在多端融合的背景下，这种模式会发生什么变化呢？开发者是否需要转型成为 “全栈多端工程师”，还是依然需要不同端的专家进行深度协作？如果是协作模式发生变化，它通常会是怎样落地的？
范绍贵： 我认为各个端的专家角色仍然会长期存在。首先，任何跨端方案都无法覆盖客户端的全部需求，总会有特定领域必须依赖原生方案实现。其次，当前客户端开发已从双端扩展至三端甚至更多，跨端技术本身要求开发者具备更广泛的知识面。以我们 RTS 的使用情况为例，业务方开发者虽需同时面对多端环境，并借助 RTS 层解决大量通用问题，但仍难以完全替代对单端技术有深度掌握的专家。因此，我们依然需要一批在某一端深耕的资深专家，尽管这类岗位的数量可能会逐渐减少，其专业门槛也将更高。
对于大多数一线业务开发者，我认为未来更可能朝向“全栈多端工程师”方向发展——既不能只懂跨端框架，还需对各端基础有一定理解，尽管未必需要达到专家级别的深度。而对于跨端框架团队或基础设施建设者来说，单端专家的支持仍至关重要。我建议初级开发者可先从多端开发入手，在实践过程中逐步积累各端知识，并寻找机会在某一领域深入成为专家，但这往往也需要合适的契机。
李锐： 多端融合确实正在重塑大前端领域的分工协作模式，并终将影响组织形态的演进。在我看来，未来可能会形成三类主要角色：第一类是业务跨端工程师，主要负责理解多端框架、编写业务逻辑并实现高效交付；第二类是框架与基础技术专家，专注于性能优化、系统机制结合等深度技术方向，如在动态化渲染、音视频引擎等垂直领域建立专业能力；第三类是业务架构师，负责复杂业务模块的设计与架构升级，通常需由资深人员担任。
行业对大前端人才的要求将更趋向于 T 型甚至 π 型发展路径，即至少拥有一项专长同时具备多端能力，甚至多项专长与多领域经验的结合。跨端化、全栈化与垂直深度并重，将成为未来发展的主要趋势。开发者需在拥抱跨职能协作、培养全局视野的同时，不断巩固专业领域的深度。
展望未来
吴子奇：未来会不会出现一个“一统天下”的终极框架，把所有端都统一起来？还是说，Web、Native、自研框架等多种技术栈会长期共存，形成一种 “百花齐放” 的局面？
李锐： 技术栈会出现一定程度的收敛，但绝不可能出现某个“终极框架”一统天下的局面。其根本原因在于大前端技术复杂性的来源是多维度的。具体来说，可归纳为三重核心诉求：
首先是用户体验，这是一个非常广泛的范畴，可进一步拆解为业务场景的多样性。例如短视频业务追求播放流畅与画质清晰，增长活动页需要广泛的版本覆盖率以确保老旧设备用户也能参与，而直播卡片挂件则更强调动态灵活能力而非极致性能。其次是机型设备的多样性，Android 系统需兼容从 5.0 到 16 等十余个大版本以及各个厂商的设备，iOS 会好些但也有众多版本和机型的差异，低端机与高端机的性能表现千差万别，难以用单一方案简单应对。此外还有物理环境的多样性，包括不同网络条件、流量敏感度、甚至设备温度与存储状态等，都直接影响用户体验的实现方式。
这还只是用户体验一个维度，此外还存在“版效”和“人效”的诉求。版效关乎功能交付速度，例如原生发版可能需要一周达到 60% 用户覆盖，而动态化技术可在一小时内实现同类目标。人效则是在人力资源有限的前提下，权衡性能优化与业务实现的实际成本。若有无限人力，自然可追求处处极致，但现实中必须在约束条件下做出权衡。
因此，技术框架只是手段，用户体验和商业目标才是最终目的。业务需求的多样性从根本上决定了技术栈的多样性，不可能被统一收敛至单一框架。但随着技术发展，局部收敛会出现。即便有 AI 加持，生产效率可大幅提升，也无法从根本上消除这种系统性的复杂度——高维度复杂问题无法用低维简单方案彻底解决。
在快手，我们目前采用三套方案并行的策略：KDS、Web 容器（YODA）以及小程序，分别适配不同业务场景与用户体验需求。多种技术栈共存具有其合理性，但也带来明显挑战，如多套基建并存、能力重复建设、交付链路不统一等。例如底层 SDK、Bridge 协议与组件体系，不可能每套技术栈都独自实现，必须推进标准化与协同。同样，在需求准备、开发调试、集成发布及运维等环节，也需建立一致的管理流程。
范绍贵： 我认为可以从两个层面来看跨端技术的发展。首先是语言层面：对于平台无关的 SDK，如果采用类似 RTS 这样能够直接编译为各端原生代码的语言方案，会更具价值。例如，若今天需要适配鸿蒙，明天可能又需支持其他新兴语言或平台，如最初就使用 RTS 编写，则无需重复开发，实现生态互通并覆盖更广的平台范围。
在框架层面，我认为需紧密结合具体场景。当前跨端主要覆盖三大领域：Web、客户端和小程序，三者场景差异显著。客户端与小程序本质属于相对独立的生态，难以完全统一。客户端中虽包含 Hybrid 混合开发生态，小程序也可衍生出 Web 版本，但二者使用场景和技术约束不同，强行统一反而可能带来限制。若一定要拓展至小程序，可在 RTS 基础上构建适用于小程序的上层框架，底层仍复用 RTS 实现跨端能力。
跨端本身存在代价，每增加一端支持，就会引入更多约束和条件编译，使工程体系更复杂，甚至与各端深度耦合，最终得不偿失。因此应根据实际需求做技术选型，例如开发小程序时不强求同时兼容客户端 App。除非新方案具备断代式的碾压性优势，否则很难让已有大量投入和生态积淀的公司全面迁移。目前各类跨端方案尚未展现出这样的绝对吸引力，技术选型仍会呈现多元化并存、局部收敛的态势。
吴子奇：如果把 “AI + 跨端” 放到五年后的视角，你们觉得：是会出现 “写一次跑多端”完全由 AI 接管 的局面，还是 “AI 辅助 + 人类工程师”长期共存？在多端融合时代，前端和客户端工程师的能力要求会不会发生明显变化？结合这两大趋势，如果是一位 35 岁的一线开发者，应该如何规划自己的技术栈来保持竞争力，避免被淘汰？是应该深耕某一端成为专家，还是拓宽视野，成为通晓多端的架构型人才？
李锐： 以五年为尺度来看，我认为仍将是 AI 辅助与人类工程师共存的局面。早年阅读《人月神话》，书中提出两个关键观点：一是“没有银弹”，二是将软件开发中的困难划分为“偶然性困难”和“根本性困难”。当前 AI 在我们研发过程中的应用，如代码自动补全、静态页面生成、根据代码仓库生成文档等，确实正在重塑研发环节，但这些仍属于解决“偶然性困难”的范畴，并未触及软件开发的“根本性困难”。
所谓“根本性困难”，包括如何准确定义要解决的问题，理解业务场景需要哪些清晰、正确的概念，在此基础上做出技术权衡与决策，搭建合适的软件架构，以及如何协同团队、建立影响力、推动项目落地，这些能力目前仍难以依靠 AI 实现。单纯代码本身只占程序员核心价值的 10%-20%，我认为未来五年，AI 更可能作为辅助工具与人类工程师协同共存，而非完全取代。
吴子奇：AI 编码目前在客户端领域的落地仍较为复杂。客户端开发本身存在运行环境割裂、多 IDE、多语言等挑战，相比传统业务逻辑开发具有更高复杂度。同时，大模型当前最擅长的仍是 Web 开发，因为 Web 语料丰富且易于获取，而客户端代码语料相对稀缺，生成质量也因而受限。在一些较为冷门或历史较久的语言上，由于遗留问题较多，生成的代码甚至可能无法运行。
然而，若将 AI 编码视为辅助工具，用于查询或快速上手另一端开发，则非常实用。这也是我认为“AI 编码 + 多端开发”将成为未来趋势的原因。过去，一个人要学习多端开发，需面对不同语言的编译环境、API 差异等复杂问题，而 AI 有望显著降低这类基础门槛。开发者可以更专注于跨端业务架构与一致性逻辑设计，而将基础实现交由 AI 完成。
最理想的情况下，AI 应能从宏观架构到具体代码实现都保持一致性，但目前仍面临挑战。大模型本质上基于概率生成，难以确保多端代码在语义和行为上完全一致，问题仍会存在。尽管如此，我仍认为 AI 编码与客户端开发的结合极具探索价值。
李锐： 我团队中有一位原本从事 iOS 编译相关工作的同学，在不到一个月的时间内，借助 AI 工具快速掌握了 Kotlin，还在 Kotlin 的 GitHub 仓库中提交 PR 解决了一个协程模块的疑难问题，经过了近半年的锻炼成为了团队中的 Kotlin 新星。若没有 AI 的辅助，这样的成长速度是很难实现的。
范绍贵：AI 全面接管编程只是时间问题，区别只是 5 年还是 10 年。这类似于 100 年前人力拉车逐渐被机械车辆取代的过程。未来程序员角色可能从“体力型编码”转向“驾驶型设计”，正如司机驾驭汽车一样，我们将驾驭 AI 工具。
对于 35 岁程序员的职业焦虑，我认为应乐观看待生产力发展。AI 有望在未来 10 到 20 年内极大提升社会财富积累，人们可能不再仅为生存而工作，即使不就业也可享有基本生活保障和尊严。我们可以更自由地追求个人价值，做自己真正想做的事情。
