作者 | QCon 全球軟件開發(fā)大會

策劃 | Kitty

編輯 | 宇琪

過去一年，鴻蒙在國內(nèi)操作系統(tǒng)市場的份額已愈來愈高，AI Coding 亦愈加成為受人關(guān)注的技術(shù)領(lǐng)域。那么，面向各端不同的語言選型、框架、生態(tài)等問題，AI 從業(yè)者應(yīng)如何應(yīng)對“生成多端一致的客戶端代碼”這一巨大挑戰(zhàn)呢？

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請了前阿里工程師吳子奇擔(dān)任主持人，和字節(jié)跳動技術(shù)專家范紹貴、快手移動端穩(wěn)定性負(fù)責(zé)人李銳一起，在QCon全球軟件開發(fā)大會2025 上海站即將召開之際， 探討 AI Coding 與跨端研發(fā)上的先行探索和最佳實(shí)踐。

部分精彩觀點(diǎn)如下：

• 跨端框架的設(shè)計(jì)者應(yīng)在保證 Native 級性能的基礎(chǔ)上，將是否使用各平臺特有能力的選擇權(quán)交給開發(fā)者。

• 跨端技術(shù)要取得進(jìn)一步突破，需從語言、虛擬機(jī)等底層開始進(jìn)行系統(tǒng)性創(chuàng)新，解決已有方案中諸如 FFI 和自渲染性能損耗等核心問題。

• 行業(yè)對大前端人才的要求將更趨向于 T 型甚至 π 型發(fā)展路徑，即至少擁有一項(xiàng)專長同時具備多端能力，甚至多項(xiàng)專長與多領(lǐng)域經(jīng)驗(yàn)的結(jié)合。

• AI 有望在未來 10 到 20 年內(nèi)極大提升社會財(cái)富積累，人們可能不再僅為生存而工作，即使不就業(yè)也可享有基本生活保障和尊嚴(yán)。我們可以更自由地追求個人價(jià)值，做自己真正想做的事情。

在 10 月 23-25 日將于上海舉辦的QCon全球軟件開發(fā)大會2025 上海站上，我們特別設(shè)置了【AI 與跨端的高效融合】專題。該專題面向客戶端、前端應(yīng)用開發(fā)、AI 應(yīng)用、研發(fā)效能相關(guān)領(lǐng)域從業(yè)者，深度拆解 AI Coding 時代下跨端技術(shù)的演進(jìn)方向發(fā)展趨勢。

查看大會日程解鎖更多精彩內(nèi)容：

https://qcon.infoq.cn/2025/shanghai/schedule

以下內(nèi)容基于直播速記整理，經(jīng) InfoQ 刪減。

完整直播回放可查看：

https://www.infoq.cn/video/zeKDVDUCRdVoO9JMNp8g

「一碼多端」和「跨端一致性」

吳子奇：從今年年初開始，「一碼多端」逐漸成為客戶端領(lǐng)域的一個熱點(diǎn)詞，它不僅僅是技術(shù)層面上的“一套代碼多端運(yùn)行”，更重要的是，它背后牽扯到開發(fā)者在技術(shù)、架構(gòu)、團(tuán)隊(duì)協(xié)作等方面的全新挑戰(zhàn)，同時也伴隨著 AI 等新技術(shù)帶來的破局機(jī)遇。兩位老師覺得在實(shí)際工作中，感受到的最大變化是什么？

李銳：我最大的感受可概括為兩個“新”：新變革與新戰(zhàn)場。新變革主要體現(xiàn)在多端融合與 AI 技術(shù)帶來的變化；新戰(zhàn)場則指這兩者為大前端領(lǐng)域開辟了新的發(fā)展空間。在多端融合方面，一碼多端的訴求顯著增強(qiáng)，技術(shù)融合趨勢日益明顯，并逐步升級為新的研發(fā)模式。

鴻蒙在國內(nèi)市場份額持續(xù)提升，已成為與 iOS、安卓并列的三大操作系統(tǒng)之一。以往許多國內(nèi)公司采用安卓與 iOS 兩套研發(fā)團(tuán)隊(duì)，輔以部分動態(tài)化技術(shù)棧的開發(fā)配置方式，由此導(dǎo)致多端多套代碼、研發(fā)成本高企的問題。新系統(tǒng)如鴻蒙的出現(xiàn)，進(jìn)一步加劇了這一負(fù)擔(dān)。此外，多技術(shù)棧還帶來基建重復(fù)、協(xié)作效率低、工程標(biāo)準(zhǔn)不統(tǒng)一等隱性問題，影響整體交付效率。因此，從效率與成本兩個維度出發(fā)，各公司均加大了對一碼多端技術(shù)的投入與研究。

在這一背景下，快手的技術(shù)融合趨勢愈發(fā)顯著。如何利用大前端技術(shù)升級研發(fā)模式，已成為一個重要課題。實(shí)踐中，快手大前端通道牽頭推進(jìn)了多項(xiàng)工作，包括擴(kuò)展大前端業(yè)務(wù)場景、培養(yǎng)復(fù)合型人才、融合各技術(shù)?；ㄒ蕴嵘芰ι舷?。目前，我所在的移動端技術(shù)平臺正在推動全應(yīng)用一碼多端的大前端架構(gòu)落地。另一方面，AI 技術(shù)變革也帶來深遠(yuǎn)影響。過去一年，快手內(nèi)部涌現(xiàn)出大量 AI 工具，無論是公司層面還是主站技術(shù)推行的“AI First”戰(zhàn)略，均取得了顯著成效。這表明 AI 正在重塑研發(fā)各個環(huán)節(jié)，使大前端能夠?qū)崿F(xiàn)以往難以完成的任務(wù)，突破既有邊界。

范紹貴：在大廠中，跨端方案已發(fā)展多年，如今進(jìn)入深水區(qū)與無人區(qū)，傳統(tǒng)創(chuàng)新模式難以實(shí)現(xiàn)進(jìn)一步突破。在字節(jié)內(nèi)部，我們認(rèn)識到必須從語言層、虛擬機(jī)層、UI 框架及工程體系等底層進(jìn)行綜合性創(chuàng)新，才可能實(shí)現(xiàn)顛覆性突破。

是否存在一種跨端方案，既能實(shí)現(xiàn)極致性能——甚至與 Native 性能媲美，又能真正實(shí)現(xiàn)跨端？Native 與跨端看似矛盾，但卻是當(dāng)前時代的實(shí)際訴求。從安卓、iOS 擴(kuò)展到鴻蒙乃至 Web 等多端，研發(fā)效率需提升，但性能始終是核心追求。在這一背景下，字節(jié)對跨端框架設(shè)計(jì)者提出了極高要求，需提供具備 Native 級性能的跨端方案，同時對業(yè)務(wù)開發(fā)人員也要求掌握更全面的技術(shù)棧。過去，安卓、iOS 單端小組僅需精通一端技術(shù)即可，但在大跨端時代，業(yè)務(wù)開發(fā)人員需同時面對安卓、iOS、鴻蒙等多端并存的環(huán)境。若僅熟悉一端而非資深專家，將難以滿足未來技術(shù)棧的要求。

吳子奇：我們通常認(rèn)為跨端方案難以媲美 Native 的性能。無論是早期的 RN 還是其他動態(tài)化框架，大多被用于實(shí)現(xiàn)動態(tài)部署，以解決發(fā)版和上線效率問題。但您剛才提到跨端可以達(dá)到 Native 級別的性能，這是如何實(shí)現(xiàn)的？

范紹貴：傳統(tǒng)跨端方案通常存在三大性能瓶頸：首先是跨語言調(diào)用（FFI）的開銷，其次是語言內(nèi)部的垃圾回收（GC）機(jī)制，第三是若采用自渲染，渲染層也會帶來一定損耗。我們在探索全新跨端方案的過程中發(fā)現(xiàn)，核心瓶頸其實(shí)在于傳統(tǒng)虛擬機(jī)，例如 JS 引擎。因此我們設(shè)想，是否存在一種方案能徹底避免 FFI 的性能損耗，完全采用端渲染，并依托系統(tǒng)級語言自動處理內(nèi)存回收與 GC？基于這一思路，我們嘗試將自研語言直接編譯為 Native 語言，整體與客戶端應(yīng)用打包而非動態(tài)下發(fā)。這樣一來，其本質(zhì)就與手寫代碼并無差異。通過逐步驗(yàn)證與落地，目前該方案在線上實(shí)際表現(xiàn)已與 Native 性能基本持平。

吳子奇：李銳老師，范紹貴老師所提出的問題與您在快手推進(jìn)一碼多端過程中所關(guān)注的焦點(diǎn)是否一致？若存在差異，主要區(qū)別或側(cè)重點(diǎn)又體現(xiàn)在哪些方面？

李銳：跨端本身是一個復(fù)雜的問題，其挑戰(zhàn)遠(yuǎn)不止于性能維度。它還涉及用戶體驗(yàn)、快速觸達(dá)用戶、多端一致性以及研發(fā)效率等多個方面。如果只追求某一單一維度，行業(yè)中已有許多現(xiàn)有方案——例如若純粹追求性能，純 Native 方案或許是最優(yōu)解；若側(cè)重快速發(fā)布和動態(tài)能力，H5 可能是更合適的選擇。因此，快手目前仍處于多種技術(shù)棧并存的階段。我們內(nèi)部通常將跨端技術(shù)的需求概括為“三高”：高迭代效率、高研發(fā)人效和高性能體驗(yàn)，這是我們當(dāng)前的主要理解和努力方向。

吳子奇：范紹貴老師，您所提出的方案是專注于特定領(lǐng)域或一碼多端中的子問題，還是代表了一種更普遍的發(fā)展方向？您是否考慮過業(yè)界是否存在類似的方案？

范紹貴：動態(tài)下發(fā)以提高發(fā)布靈活性屬于工程效率問題，而開發(fā)體驗(yàn)優(yōu)化則是持續(xù)改進(jìn)的過程。如果我們能夠在性能上達(dá)到更高標(biāo)準(zhǔn)，接下來的重點(diǎn)便是不斷完善開發(fā)體驗(yàn)。關(guān)于業(yè)界現(xiàn)有方案，我們在設(shè)計(jì)過程中當(dāng)然也有所借鑒和參考，汲取了許多優(yōu)秀思路。

吳子奇：任何技術(shù)方案都離不開時代背景。過去由于應(yīng)用審核和發(fā)布效率等限制，動態(tài)化技術(shù)如 RN 和 Weex 應(yīng)運(yùn)而生，以解決特定問題。而當(dāng)前一碼多端的背景，則是在鴻蒙等新平臺興起的情況下，如何在有限人力資源中實(shí)現(xiàn)高效開發(fā)。面對這一目標(biāo)，業(yè)界涌現(xiàn)出多種路徑，它們并非最終答案，而是不斷逼近最優(yōu)解的探索過程。

吳子奇：在“性能表現(xiàn)”和“交互邏輯”這兩個關(guān)鍵點(diǎn)上，實(shí)現(xiàn)真正意義上的“體驗(yàn)融合”，最大的難點(diǎn)究竟在哪里？

范紹貴：以 Flutter 為例，它通過語言、框架與客戶端一體化的閉環(huán)設(shè)計(jì)，徹底解決了多端一致性問題。然而，這種看似直接的方式仍存在其他問題，例如因 FFI 導(dǎo)致性能無法與 Native 持平。我們常提到，用戶購買高端手機(jī)是期望獲得系統(tǒng)原生的流暢體驗(yàn)，而采用自渲染方案往往難以完全實(shí)現(xiàn)這一點(diǎn)。例如 iOS 系統(tǒng)自帶的毛玻璃等特效，即使在 Flutter 中可通過嵌入方式部分實(shí)現(xiàn)，其性能與純原生相比仍有差距。因此我認(rèn)為，跨端框架的設(shè)計(jì)者應(yīng)在保證 Native 級性能的基礎(chǔ)上，將是否使用各平臺特有能力的選擇權(quán)交給開發(fā)者?？蚣軕?yīng)允許開發(fā)者根據(jù)平臺差異自主決策，例如在 iOS 上啟用毛玻璃效果，而在安卓端采用其他替代方案。

我們的 RTS 方案主要通過兩方面實(shí)現(xiàn)該目標(biāo)：一是性能與 Native 一致，二是可靈活選用各端獨(dú)有特性。性能方面，我們將自研語言轉(zhuǎn)譯為 Native 語言，與客戶端代碼一同打包發(fā)布，從而具備原生性能。不同于 Flutter 的自渲染閉環(huán)模式，我們基于公司開源的 Lynx 框架實(shí)現(xiàn)端渲染，并依托其多年的多端渲染抹平經(jīng)驗(yàn)，在避免 FFI 的前提下，實(shí)現(xiàn)了數(shù)據(jù)的無縫互通與多端一致性，最終達(dá)到與原生開發(fā)基本一致的性能表現(xiàn)。特性方面，開發(fā)者可通過條件編譯等方式，在不同目標(biāo)平臺上選用特定組件（如 iOS 的毛玻璃效果），從而擁有充分的自主選擇權(quán)。

實(shí)現(xiàn)過程中最大的難點(diǎn)在于多端抹平與語言差異的調(diào)和。一種語言需同時編譯為多種目標(biāo)語言，而各語言本身存在一定差異，因此我們必須取其語義的最小公共集，保證 RTS 代碼在多方行為一致，這常常需要做出某些權(quán)衡。由于 Swift、Kotlin 等語言并非由我們設(shè)計(jì)，其語法特性存在固有差異，因此用 RTS 編寫代碼會受到一定限制。但從實(shí)踐來看，高級語言的許多特性，如單子模式實(shí)現(xiàn)，在各大平臺已趨于一致。

李銳：我們已進(jìn)入跨端融合的新階段，其目標(biāo)不僅是實(shí)現(xiàn)界面外觀的一致，更在于讓不同設(shè)備之間的體驗(yàn)真正連貫和統(tǒng)一，這對跨端技術(shù)提出了更高的要求。

挑戰(zhàn)主要體現(xiàn)在兩個維度。首先是用戶視角：快手目前采用多技術(shù)棧并存的策略，因此需確保用戶在使用過程中感知不到技術(shù)差異，體驗(yàn)到完整和統(tǒng)一的整體。實(shí)現(xiàn)這一點(diǎn)的基礎(chǔ)，是建立統(tǒng)一的監(jiān)控指標(biāo)體系，涵蓋性能和穩(wěn)定性等多個方面，如頁面打開速度與流暢度。若各技術(shù)棧使用不同的指標(biāo)與標(biāo)準(zhǔn)，不僅會造成重復(fù)建設(shè)，還難以進(jìn)行橫向?qū)Ρ群陀行гu估。例如，客戶端上報(bào)的 FMP 指標(biāo)與 H5 或 RN 所定義的 FMP 并不相同；而在穩(wěn)定性層面，Native 端通常關(guān)注崩潰、卡死和 OOM 等異常類型，而動態(tài)化方案則更多聚焦于 JS 異常——但 JS 異常并不直接等同于頁面不可用，還需結(jié)合白屏監(jiān)控等進(jìn)行綜合判斷。因此，實(shí)現(xiàn)真正跨端融合的第一步，是推動監(jiān)控指標(biāo)的統(tǒng)一。在快手，我們通過發(fā)起大前端監(jiān)控專項(xiàng)，系統(tǒng)梳理各技術(shù)棧的指標(biāo)差異，最終實(shí)現(xiàn)了監(jiān)控口徑的融合。

其次是從研發(fā)視角看，多技術(shù)棧共存確實(shí)會引入許多跨技術(shù)棧的“疑難雜癥”。在穩(wěn)定性層面，由于技術(shù)選型更加多樣，往往會引入多語言、多運(yùn)行時環(huán)境，每個運(yùn)行時又有其各自的線程模型、內(nèi)存管理、資源占用、垃圾回收和異常處理機(jī)制。這種復(fù)雜性極易引發(fā)問題，例如 FFI 時因跨運(yùn)行時生命周期管理不當(dāng)導(dǎo)致的崩潰，或跨運(yùn)行時 Bridge 存在的性能瓶頸。

基于用戶和研發(fā)這兩個維度的背景，快手移動端技術(shù)平臺致力于為多端融合與用戶體驗(yàn)提供全面保障。在性能方向，我們近期在內(nèi)部的“乘風(fēng)”工程挑戰(zhàn)賽中，重點(diǎn)推動了 AI 火焰圖分析工具的落地。該工具旨在實(shí)現(xiàn)對 Android、iOS、Web 及各類動態(tài)化技術(shù)棧性能問題的統(tǒng)一診斷與分析，成為大前端性能監(jiān)控的一個典型實(shí)踐。

在穩(wěn)定性方向，我也做一個簡要預(yù)告：在十月份的 QCon 大會上，我將分享快手在穩(wěn)定性建設(shè)方面的兩項(xiàng)關(guān)鍵成果。其一是名為“艾克 Ekko”的止損工具，其核心能力是通過動態(tài)修改程序流實(shí)現(xiàn)自動故障兜底。與傳統(tǒng)安全氣墊方案相比，Ekko 在安全性和覆蓋范圍上均有突破，并結(jié)合 AI 實(shí)現(xiàn)了部分問題的自動修復(fù)。其二是名為“福爾摩斯 Holmes”的排障工具，該工具萃取自數(shù)百個線上疑難案例的實(shí)戰(zhàn)經(jīng)驗(yàn)，提供全技術(shù)棧支持的事件追蹤與 UI 視圖信息還原，可精準(zhǔn)復(fù)現(xiàn)問題現(xiàn)場，極大提升研發(fā)排查效率。近期我們還開發(fā)上線了 AI 排障 Agent，進(jìn)一步增強(qiáng)了智能化診斷能力。

吳子奇：要實(shí)現(xiàn)真正完全一致的「多端融合」，在實(shí)際開發(fā)中還是需要做一些取舍。比如，根據(jù)各個平臺的體驗(yàn)差異做有選擇性的條件編譯，或者針對不同端對業(yè)務(wù)邏輯和 UI 界面 進(jìn)行適配。這樣一來，代碼復(fù)雜度和開發(fā)者的心智負(fù)擔(dān)都會顯著增加。你們所在的團(tuán)隊(duì)是如何管理和應(yīng)對這種復(fù)雜度的？從實(shí)際情況來看，這會不會在某些場景下反而降低了開發(fā)效率？

李銳：首先我想補(bǔ)充 iOS 系統(tǒng)升級導(dǎo)致大量崩潰、需要連夜處理的問題。Ekko 這一工具可以解決此類痛點(diǎn)。例如前段時間 iOS 26 升級時，我們的圖片庫也遇到了兼容性問題，但借助 Ekko 工具，系統(tǒng)實(shí)現(xiàn)了自動兜底，避免了更大影響。

關(guān)于“多種技術(shù)棧共存究竟是利是弊”的問題，我的觀點(diǎn)非常明確：這是一件好事。原因在于，我們應(yīng)當(dāng)回歸大前端開發(fā)的本質(zhì)職責(zé)——面向終端用戶，運(yùn)用終端技術(shù)解決人機(jī)交互中的各類問題。技術(shù)選型只是手段，最終目標(biāo)始終是用戶體驗(yàn)的最優(yōu)化。在當(dāng)前階段，多技術(shù)棧并存的架構(gòu)，恰恰是我們綜合考量后所選擇的最佳路徑。

多端融合確實(shí)引入了更多復(fù)雜度，那么我們?nèi)绾瓮ㄟ^技術(shù)選型和管理來應(yīng)對這些挑戰(zhàn)？在快手，我們將這類問題拆解為 UI 跨端和邏輯跨端兩個維度。過去在 UI 跨端方面，我們主要依靠內(nèi)部技術(shù)方案 KDS，包括基于 KRN 深度優(yōu)化的頁面級方案 KDS React，以及卡片級方案 KDS Native（或稱 TK）。這些方案在 UI 層面實(shí)現(xiàn)了一碼多投，并得到廣泛應(yīng)用，但在處理復(fù)雜業(yè)務(wù)邏輯與大數(shù)據(jù)量時仍存在一定局限。因此我們引入了 KMP 技術(shù)方案，與原有 KDS 形成互補(bǔ)。

KMP 的選型并非一帆風(fēng)順，經(jīng)歷了內(nèi)部多輪討論和高層決策。我們曾對比過 Rust、C++ 等語言，但最終從開發(fā)效率、語言生態(tài)等維度綜合評估，認(rèn)為 KMP 更具優(yōu)勢。目前行業(yè)各大廠商，在推進(jìn)全應(yīng)用一碼多端的過程中，也都不約而同地選擇了 KMP 作為邏輯跨端的解決方案。大家的目標(biāo)非常一致：通過高性能的邏輯跨端方案填補(bǔ)技術(shù)空白。

范紹貴：跨端技術(shù)要取得進(jìn)一步突破，需從語言、虛擬機(jī)等底層開始進(jìn)行系統(tǒng)性創(chuàng)新，解決已有方案中諸如 FFI 和自渲染性能損耗等核心問題。在綜合審視現(xiàn)有方案的局限性后，我們思考是否能夠跳出既定框架，從零開始設(shè)計(jì)一套新方案。RTS 基于轉(zhuǎn)譯的技術(shù)路徑，正是在這一背景下提出，它較好地實(shí)現(xiàn)了我們最初的預(yù)設(shè)目標(biāo)：既達(dá)到 Native 級別的性能，又真正實(shí)現(xiàn)多端跨端支持。

關(guān)于跨端開發(fā)復(fù)雜性，我認(rèn)為若仍沿用傳統(tǒng)模式——每位開發(fā)者僅負(fù)責(zé)一端，如專攻安卓或 iOS，那么在鴻蒙加入后形成三端并行的情況下，個體開發(fā)者面臨的復(fù)雜度和心智負(fù)擔(dān)的確會加重。但從整體來看，原本可能需要三人完成的工作，現(xiàn)在只需一人或一個半人即可承擔(dān)，因此對企業(yè)而言整體復(fù)雜度實(shí)為降低。同時，傳統(tǒng)方式需維護(hù)三套代碼，而采用 RTS 這類方案后，只需一套工程和代碼，維護(hù)成本顯著下降。

當(dāng)然，對開發(fā)者個人而言，需同時掌握多端開發(fā)技能確實(shí)帶來挑戰(zhàn)。因此我們的重點(diǎn)在于順應(yīng)跨端趨勢的同時，努力降低代碼復(fù)雜度和開發(fā)者的心智負(fù)擔(dān)。目前 RTS 主要通過兩種途徑實(shí)現(xiàn)該目標(biāo)：一是框架自身應(yīng)盡可能抹平端間差異，使開發(fā)者無需感知底層不同；二是通過工具鏈建設(shè)提升開發(fā)體驗(yàn)。具體來說，我們在三個層面實(shí)現(xiàn)差異抹平：

第一是語言層。RTS 將同一套代碼轉(zhuǎn)譯為多端原生語言，并確保其行為一致性，開發(fā)者無需關(guān)注底層語言差異，也無需額外學(xué)習(xí)各客戶端語言。

第二是 UI 層。RTS 編寫 UI 框架會被編譯為 Swift 或 Kotlin 等原生代碼，與客戶端共同編譯。開發(fā)者只需使用同一套 DSL，無需面對不同平臺的 UI 差異，UI 表現(xiàn)自動保持一致。

第三是工程層。我們致力于打造統(tǒng)一的開發(fā)體驗(yàn)，提出“One IDE”理念：在一個集成環(huán)境中完成多端開發(fā)、編譯和調(diào)試。開發(fā)者可在 RTS 源碼層面斷點(diǎn)調(diào)試，實(shí)際運(yùn)行于原生代碼環(huán)境，并查看運(yùn)行時變量。同時支持熱重載調(diào)試，提升了客戶端的開發(fā)體驗(yàn)。

除了架構(gòu)層面的設(shè)計(jì)，我們還通過輔助工具進(jìn)一步降低開發(fā)復(fù)雜度。RTS 支持開發(fā)插件，允許業(yè)務(wù)方基于編譯器插件自動完成端間差異抹平，直接干預(yù)轉(zhuǎn)譯輸出。例如常見字段名不一致、類型差異等，都可通過工具鏈自動對齊。我們也正探索借助 AI 自動生成抹平代碼，幫助開發(fā)者提升效率。

吳子奇：字節(jié)在這一方案上投入了多少兵力？

范紹貴：目前至少有三四個團(tuán)隊(duì)共同參與，包括負(fù)責(zé) RTS 語言與 UI 框架的團(tuán)隊(duì)、負(fù)責(zé)工程體系的團(tuán)隊(duì)，以及專注于調(diào)試工具與 IDE 開發(fā)的團(tuán)隊(duì)。從語言、虛擬機(jī)、UI 到工程化與工具鏈，整個技術(shù)棧的研發(fā)投入總計(jì)數(shù)十人。

吳子奇：未來是否有面向社區(qū)的開源或推廣計(jì)劃？

范紹貴：我們確實(shí)有計(jì)劃在內(nèi)部方案相對完善并達(dá)到可對外階段后，將整套技術(shù)開源給社區(qū)。正如我司已有的 Lynx 框架一樣，我們期待通過開源獲得更多反饋，與開發(fā)者共同推動方案演進(jìn)，為國內(nèi)外企業(yè)提供一種全新的高性能跨端選擇，共同促進(jìn)行業(yè)發(fā)展。

吳子奇：過去，我們習(xí)慣于 iOS、Android、Web 各自獨(dú)立的團(tuán)隊(duì)模式。那在多端融合的背景下，這種模式會發(fā)生什么變化呢？開發(fā)者是否需要轉(zhuǎn)型成為 “全棧多端工程師”，還是依然需要不同端的專家進(jìn)行深度協(xié)作？如果是協(xié)作模式發(fā)生變化，它通常會是怎樣落地的？

范紹貴：我認(rèn)為各個端的專家角色仍然會長期存在。首先，任何跨端方案都無法覆蓋客戶端的全部需求，總會有特定領(lǐng)域必須依賴原生方案實(shí)現(xiàn)。其次，當(dāng)前客戶端開發(fā)已從雙端擴(kuò)展至三端甚至更多，跨端技術(shù)本身要求開發(fā)者具備更廣泛的知識面。以我們 RTS 的使用情況為例，業(yè)務(wù)方開發(fā)者雖需同時面對多端環(huán)境，并借助 RTS 層解決大量通用問題，但仍難以完全替代對單端技術(shù)有深度掌握的專家。因此，我們依然需要一批在某一端深耕的資深專家，盡管這類崗位的數(shù)量可能會逐漸減少，其專業(yè)門檻也將更高。

對于大多數(shù)一線業(yè)務(wù)開發(fā)者，我認(rèn)為未來更可能朝向“全棧多端工程師”方向發(fā)展——既不能只懂跨端框架，還需對各端基礎(chǔ)有一定理解，盡管未必需要達(dá)到專家級別的深度。而對于跨端框架團(tuán)隊(duì)或基礎(chǔ)設(shè)施建設(shè)者來說，單端專家的支持仍至關(guān)重要。我建議初級開發(fā)者可先從多端開發(fā)入手，在實(shí)踐過程中逐步積累各端知識，并尋找機(jī)會在某一領(lǐng)域深入成為專家，但這往往也需要合適的契機(jī)。

李銳：多端融合確實(shí)正在重塑大前端領(lǐng)域的分工協(xié)作模式，并終將影響組織形態(tài)的演進(jìn)。在我看來，未來可能會形成三類主要角色：第一類是業(yè)務(wù)跨端工程師，主要負(fù)責(zé)理解多端框架、編寫業(yè)務(wù)邏輯并實(shí)現(xiàn)高效交付；第二類是框架與基礎(chǔ)技術(shù)專家，專注于性能優(yōu)化、系統(tǒng)機(jī)制結(jié)合等深度技術(shù)方向，如在動態(tài)化渲染、音視頻引擎等垂直領(lǐng)域建立專業(yè)能力；第三類是業(yè)務(wù)架構(gòu)師，負(fù)責(zé)復(fù)雜業(yè)務(wù)模塊的設(shè)計(jì)與架構(gòu)升級，通常需由資深人員擔(dān)任。

行業(yè)對大前端人才的要求將更趨向于 T 型甚至 π 型發(fā)展路徑，即至少擁有一項(xiàng)專長同時具備多端能力，甚至多項(xiàng)專長與多領(lǐng)域經(jīng)驗(yàn)的結(jié)合?？缍嘶?、全棧化與垂直深度并重，將成為未來發(fā)展的主要趨勢。開發(fā)者需在擁抱跨職能協(xié)作、培養(yǎng)全局視野的同時，不斷鞏固專業(yè)領(lǐng)域的深度。

展望未來

吳子奇：未來會不會出現(xiàn)一個“一統(tǒng)天下”的終極框架，把所有端都統(tǒng)一起來？還是說，Web、Native、自研框架等多種技術(shù)棧會長期共存，形成一種 “百花齊放” 的局面？

李銳：技術(shù)棧會出現(xiàn)一定程度的收斂，但絕不可能出現(xiàn)某個“終極框架”一統(tǒng)天下的局面。其根本原因在于大前端技術(shù)復(fù)雜性的來源是多維度的。具體來說，可歸納為三重核心訴求：

首先是用戶體驗(yàn)，這是一個非常廣泛的范疇，可進(jìn)一步拆解為業(yè)務(wù)場景的多樣性。例如短視頻業(yè)務(wù)追求播放流暢與畫質(zhì)清晰，增長活動頁需要廣泛的版本覆蓋率以確保老舊設(shè)備用戶也能參與，而直播卡片掛件則更強(qiáng)調(diào)動態(tài)靈活能力而非極致性能。其次是機(jī)型設(shè)備的多樣性，Android 系統(tǒng)需兼容從 5.0 到 16 等十余個大版本以及各個廠商的設(shè)備，iOS 會好些但也有眾多版本和機(jī)型的差異，低端機(jī)與高端機(jī)的性能表現(xiàn)千差萬別，難以用單一方案簡單應(yīng)對。此外還有物理環(huán)境的多樣性，包括不同網(wǎng)絡(luò)條件、流量敏感度、甚至設(shè)備溫度與存儲狀態(tài)等，都直接影響用戶體驗(yàn)的實(shí)現(xiàn)方式。

這還只是用戶體驗(yàn)一個維度，此外還存在“版效”和“人效”的訴求。版效關(guān)乎功能交付速度，例如原生發(fā)版可能需要一周達(dá)到 60% 用戶覆蓋，而動態(tài)化技術(shù)可在一小時內(nèi)實(shí)現(xiàn)同類目標(biāo)。人效則是在人力資源有限的前提下，權(quán)衡性能優(yōu)化與業(yè)務(wù)實(shí)現(xiàn)的實(shí)際成本。若有無限人力，自然可追求處處極致，但現(xiàn)實(shí)中必須在約束條件下做出權(quán)衡。

因此，技術(shù)框架只是手段，用戶體驗(yàn)和商業(yè)目標(biāo)才是最終目的。業(yè)務(wù)需求的多樣性從根本上決定了技術(shù)棧的多樣性，不可能被統(tǒng)一收斂至單一框架。但隨著技術(shù)發(fā)展，局部收斂會出現(xiàn)。即便有 AI 加持，生產(chǎn)效率可大幅提升，也無法從根本上消除這種系統(tǒng)性的復(fù)雜度——高維度復(fù)雜問題無法用低維簡單方案徹底解決。

在快手，我們目前采用三套方案并行的策略：KDS、Web 容器（YODA）以及小程序，分別適配不同業(yè)務(wù)場景與用戶體驗(yàn)需求。多種技術(shù)棧共存具有其合理性，但也帶來明顯挑戰(zhàn)，如多套基建并存、能力重復(fù)建設(shè)、交付鏈路不統(tǒng)一等。例如底層 SDK、Bridge 協(xié)議與組件體系，不可能每套技術(shù)棧都獨(dú)自實(shí)現(xiàn)，必須推進(jìn)標(biāo)準(zhǔn)化與協(xié)同。同樣，在需求準(zhǔn)備、開發(fā)調(diào)試、集成發(fā)布及運(yùn)維等環(huán)節(jié)，也需建立一致的管理流程。

范紹貴：我認(rèn)為可以從兩個層面來看跨端技術(shù)的發(fā)展。首先是語言層面：對于平臺無關(guān)的 SDK，如果采用類似 RTS 這樣能夠直接編譯為各端原生代碼的語言方案，會更具價(jià)值。例如，若今天需要適配鴻蒙，明天可能又需支持其他新興語言或平臺，如最初就使用 RTS 編寫，則無需重復(fù)開發(fā)，實(shí)現(xiàn)生態(tài)互通并覆蓋更廣的平臺范圍。

在框架層面，我認(rèn)為需緊密結(jié)合具體場景。當(dāng)前跨端主要覆蓋三大領(lǐng)域：Web、客戶端和小程序，三者場景差異顯著?？蛻舳伺c小程序本質(zhì)屬于相對獨(dú)立的生態(tài)，難以完全統(tǒng)一?？蛻舳酥须m包含 Hybrid 混合開發(fā)生態(tài)，小程序也可衍生出 Web 版本，但二者使用場景和技術(shù)約束不同，強(qiáng)行統(tǒng)一反而可能帶來限制。若一定要拓展至小程序，可在 RTS 基礎(chǔ)上構(gòu)建適用于小程序的上層框架，底層仍復(fù)用 RTS 實(shí)現(xiàn)跨端能力。

跨端本身存在代價(jià)，每增加一端支持，就會引入更多約束和條件編譯，使工程體系更復(fù)雜，甚至與各端深度耦合，最終得不償失。因此應(yīng)根據(jù)實(shí)際需求做技術(shù)選型，例如開發(fā)小程序時不強(qiáng)求同時兼容客戶端 App。除非新方案具備斷代式的碾壓性優(yōu)勢，否則很難讓已有大量投入和生態(tài)積淀的公司全面遷移。目前各類跨端方案尚未展現(xiàn)出這樣的絕對吸引力，技術(shù)選型仍會呈現(xiàn)多元化并存、局部收斂的態(tài)勢。

吳子奇：如果把 “AI + 跨端” 放到五年后的視角，你們覺得：是會出現(xiàn) “寫一次跑多端”完全由 AI 接管 的局面，還是 “AI 輔助 + 人類工程師”長期共存？在多端融合時代，前端和客戶端工程師的能力要求會不會發(fā)生明顯變化？結(jié)合這兩大趨勢，如果是一位 35 歲的一線開發(fā)者，應(yīng)該如何規(guī)劃自己的技術(shù)棧來保持競爭力，避免被淘汰？是應(yīng)該深耕某一端成為專家，還是拓寬視野，成為通曉多端的架構(gòu)型人才？

李銳：以五年為尺度來看，我認(rèn)為仍將是 AI 輔助與人類工程師共存的局面。早年閱讀《人月神話》，書中提出兩個關(guān)鍵觀點(diǎn)：一是“沒有銀彈”，二是將軟件開發(fā)中的困難劃分為“偶然性困難”和“根本性困難”。當(dāng)前 AI 在我們研發(fā)過程中的應(yīng)用，如代碼自動補(bǔ)全、靜態(tài)頁面生成、根據(jù)代碼倉庫生成文檔等，確實(shí)正在重塑研發(fā)環(huán)節(jié)，但這些仍屬于解決“偶然性困難”的范疇，并未觸及軟件開發(fā)的“根本性困難”。

所謂“根本性困難”，包括如何準(zhǔn)確定義要解決的問題，理解業(yè)務(wù)場景需要哪些清晰、正確的概念，在此基礎(chǔ)上做出技術(shù)權(quán)衡與決策，搭建合適的軟件架構(gòu)，以及如何協(xié)同團(tuán)隊(duì)、建立影響力、推動項(xiàng)目落地，這些能力目前仍難以依靠 AI 實(shí)現(xiàn)。單純代碼本身只占程序員核心價(jià)值的 10%-20%，我認(rèn)為未來五年，AI 更可能作為輔助工具與人類工程師協(xié)同共存，而非完全取代。

吳子奇：AI 編碼目前在客戶端領(lǐng)域的落地仍較為復(fù)雜?？蛻舳碎_發(fā)本身存在運(yùn)行環(huán)境割裂、多 IDE、多語言等挑戰(zhàn)，相比傳統(tǒng)業(yè)務(wù)邏輯開發(fā)具有更高復(fù)雜度。同時，大模型當(dāng)前最擅長的仍是 Web 開發(fā)，因?yàn)?Web 語料豐富且易于獲取，而客戶端代碼語料相對稀缺，生成質(zhì)量也因而受限。在一些較為冷門或歷史較久的語言上，由于遺留問題較多，生成的代碼甚至可能無法運(yùn)行。

然而，若將 AI 編碼視為輔助工具，用于查詢或快速上手另一端開發(fā)，則非常實(shí)用。這也是我認(rèn)為“AI 編碼 + 多端開發(fā)”將成為未來趨勢的原因。過去，一個人要學(xué)習(xí)多端開發(fā)，需面對不同語言的編譯環(huán)境、API 差異等復(fù)雜問題，而 AI 有望顯著降低這類基礎(chǔ)門檻。開發(fā)者可以更專注于跨端業(yè)務(wù)架構(gòu)與一致性邏輯設(shè)計(jì)，而將基礎(chǔ)實(shí)現(xiàn)交由 AI 完成。

最理想的情況下，AI 應(yīng)能從宏觀架構(gòu)到具體代碼實(shí)現(xiàn)都保持一致性，但目前仍面臨挑戰(zhàn)。大模型本質(zhì)上基于概率生成，難以確保多端代碼在語義和行為上完全一致，問題仍會存在。盡管如此，我仍認(rèn)為 AI 編碼與客戶端開發(fā)的結(jié)合極具探索價(jià)值。

李銳：我團(tuán)隊(duì)中有一位原本從事 iOS 編譯相關(guān)工作的同學(xué)，在不到一個月的時間內(nèi)，借助 AI 工具快速掌握了 Kotlin，還在 Kotlin 的 GitHub 倉庫中提交 PR 解決了一個協(xié)程模塊的疑難問題，經(jīng)過了近半年的鍛煉成為了團(tuán)隊(duì)中的 Kotlin 新星。若沒有 AI 的輔助，這樣的成長速度是很難實(shí)現(xiàn)的。

范紹貴：AI 全面接管編程只是時間問題，區(qū)別只是 5 年還是 10 年。這類似于 100 年前人力拉車逐漸被機(jī)械車輛取代的過程。未來程序員角色可能從“體力型編碼”轉(zhuǎn)向“駕駛型設(shè)計(jì)”，正如司機(jī)駕馭汽車一樣，我們將駕馭 AI 工具。

對于 35 歲程序員的職業(yè)焦慮，我認(rèn)為應(yīng)樂觀看待生產(chǎn)力發(fā)展。AI 有望在未來 10 到 20 年內(nèi)極大提升社會財(cái)富積累，人們可能不再僅為生存而工作，即使不就業(yè)也可享有基本生活保障和尊嚴(yán)。我們可以更自由地追求個人價(jià)值，做自己真正想做的事情。

會議推薦

10 月 23 - 25 日，QCon 上海站即將召開，限時 9 折優(yōu)惠，單張門票立省 680 元，詳情可聯(lián)系票務(wù)經(jīng)理 18514549229 咨詢。