支付宝AI出行助手，4人团队两个月基于xUI+KMP实现架构迁移与高效上线。本文揭示背后的技术挑战、解决方案与研发效能突破。
原文标题：支付宝 AI 出行助手高效研发指南：4 人团队的架构迁移与提效实战
原文作者：阿里云开发者
冷月清谈：
项目面临的核心挑战在于将原先基于“支小宝”构建的、逻辑复杂的出行业务，完整平迁到xUI 1.0标准化技术栈上，这涉及到底层数据层适配、消息通道（从RPC+SYNC混用到gRPC流式通信）改造、碎片化渲染组件向生成式卡片体系的统一迁移。尤为复杂的是，需要对40多张出行相关卡片的隐藏业务逻辑、交互状态流转以及与Native的双向通信机制进行“代码考古”、梳理与平滑迁移。
为应对这些挑战，技术方案上，AI出行助手全面接入xUI 1.0标准化协议，利用其统一的数据、渲染和控制协议，并采用gRPC流式网络通信。在渲染层面，文章详细介绍了如何通过“template & display”解耦渲染行为，以及对卡片类型进行抽象（COMMON/FLOW），从而实现静态、生成式及动态更新卡片的统一渲染。为了加速开发并打破跨团队依赖，团队巧妙地平移了旧有通信链路并构建了客户端协议适配器，实现了客户端和后端的并行研发。
此外，在智能体模块中，团队策略性地引入了KMP（Kotlin Multiplatform）技术，用于开发智能体列表页，不仅验证了KMP在提升研发人效方面的潜力，也为框架在处理复杂嵌套滚动等通用问题上积累了宝贵的解决方案。文章还介绍了为AI对话产品建立的全新度量体系，以“首Token耗时”和“链路稳定性”为核心，更加贴合用户实际感知。最终，项目取得了显著成果：新AI对话产品的研发周期从数月缩短到30天，KMP方案的实践也释放了1个端人力，充分证明了xUI + gRPC + KMP等底层技术基建在提升研发效率方面的巨大价值。未来，团队将继续深化xUI与KMP的应用，并驱动框架的持续完善。
怜星夜思：
2、针对AI对话类产品，文章提了“首Token耗时”和“链路稳定性”这两大度量维度。大家觉得，除了这些技术指标，还有哪些评价AI出行助手这类产品“智能”或“好用”的关键用户体验指标？比如，用户对AI给出的行程建议满意度怎么量化？
3、4人客户端小团队，从立项到全量上线两个月，还做了复杂的架构迁移。这简直是“神仙操作”！除了文章提到的XUI和KMP这些技术基建，你觉得这样一个高效率小团队成功的背后，还有哪些非技术因素（比如团队协作、项目管理、成员能力等）是至关重要的？
原文内容
一、摘要
本文将介绍支付宝「AI 出行助手」从产品立项到全量上线耗时两个月的研发历程。在仅有 4 人的客户端小团队下，我们是如何基于支付宝终端技术的基础框架：xUI + KMP，高效搭建出一款智能助理会话产品的。我们将分享背后的研发实践、面临的挑战与应对策略，并展望未来的发展方向。
二、产品介绍
AI 出行助手是一款基于对话交互的智能出行服务产品，集成公交/地铁刷码、火车票/机票预订、单车/打车、路线规划/旅行方案生成等核心功能，为用户提供全链路的出行服务。
你可以在支付宝 10.7.30 版本及以上版本中，通过“支付宝首页 → 出行频道 → 底部 AI 助手标识”进入 AI 出行助手，进行体验。
三、项目背景
传统的出行服务体验面临严峻挑战，用户在规划行程时，不得不在多个独立的 App 间频繁跳转，执行繁琐、多步骤的操作来考量各种条件。这种低效的模式，已无法满足用户日益增长的个性化需求。
原出行助手基于支小宝构建，为了实现一个更垂直、更具扩展性的智能出行体系，需要构建一个全新的、专为出行场景设计的技术底座。
在这样的背景下，AI 出行助手应运而生，其核心能力是服务思维链 + 高质量数据 + 高质量工具 + 个性化：实现从入口到结果、从单工具到多工具、从提问到伴随，成为用户的“一站式智能出行管家”。
四、AI 对话产品探索与回顾
AI 对话作为一种新的交互范式，在技术和架构选型上缺乏成熟的最佳实践。幸运的是，在 AI 出行助手项目启动前，支付宝内已有多款 AI 助手类产品上线或在研，如 AI 搜、AQ 等，它们作为先行者，率先探索了 xUI 生成式卡片和 gRPC 流式通信，为我们验证了现代 AI 交互方案的可行性。
xUI 框架是支付宝终端技术孵化出的一套可复用的 AI 交互框架，它的核心定位是将 AI 对话式产品中共通的底层能力进行下沉，将其模块化、组件化，形成一套稳定、高效、可复用的 AI 交互框架。
因此，我们的目标是明确的：将 AI 出行助手接入到这套统一的基础架构里。同时，我们也注意到，框架自身也在进行着重要的技术演进：
-
早期的 AI 搜和 AQ 分别接入了不同版本的 xUI，彼此协议不统一，功能属性也存在差异；
-
为了解决这一问题，框架在积极推动技术的标准化，通过统一的标准化协议，旨在解决过去版本碎片化的问题；
经过讨论，我们最终决定：AI 出行助手将不再沿用旧的技术栈或非标的 xUI 版本，而是全面接入并落地 xUI 1.0 标准化协议。这意味着我们不仅要完成出行业务的迁移，还要用复杂的业务场景，率先验证新一代 xUI 版本。
支小宝的技术现状和业务复杂度，决定了迁移之路将充满挑战，以 AQ 进行对比，差异如下：
五、技术方案
综合上述回顾，基于支付宝终端技术已有的沉淀，AI 出行助手决定采用以下技术方案：
1. xUI：端到端智能交互框架
AI 出行助手主对话使用 xUI 作为交互框架，期望实现能力的快速接入与复用，达到降低业务维护成本、享受技术基线优化的效果。
xUI 框架前期支持了 AI 搜和 AQ 业务，借着 AI 出行助手的契机，xUI 将通过标准化建设，解决当下支小宝中 RPC + SYNC 耦合混用的问题，数据协议、渲染协议、控制协议统一走 gRPC 通道。
- 核心：标准化协议 + gRPC 流式网络 + 生成式卡片。
2. 多技术栈结合：KMP
针对不同的业务场景，采用不同的技术栈来支撑，兼顾用户体验和研发效率。
-
对性能和体验要求较高的核心场景，如主会话框架、输入组件，采用 Native 来实现；
-
对于无需追求极致原生性能的页面，如智能体列表页面，积极探索跨平台技术，例如 KMP 技术，期望在提升研发人效的同时，帮助团队积累跨技术栈经验。
六、难点与挑战
1. 基础能力迁移
迁移工作不是从零开始，而是将一个逻辑复杂的支小宝出行业务，完整平迁到 xUI 标准化技术栈上来，涉及到多项底层基础能力的迁移，包括数据层适配、消息通道改造、渲染组件迁移等。
-
数据层适配：原支小宝的数据结构自成体系，将原数据结构迁移到标准协议上来，需要我们深刻理新旧两种协议的结构和语义，以及他们之间的区别，然后重新编写数据解析层，按照标准结构进行解析，比简单的字段映射要复杂得多；
-
消息通道改造：从 RPC + SYNC 切换到 gRPC 流式通信，意味着原有的消息链路彻底重构，从模型定义到通信协议，需要网关、后端、客户端进行全链路同步改造，不仅带来巨大的协同成本，更增加了联调的复杂度；
-
渲染组件迁移：AI 对话内容以流式形式呈现，我们面对的是一个由 Native 组件、卡片、Markdown 组件构成的碎片化渲染体系，将其统一到 xUI 的统一渲染组件下，需确保原业务场景的功能和展示，在新架构下能得到 100% 的还原和实现。
2. 卡片生态迁移
出行助手的核心功能由卡片承载，用户可在卡片上进行交互并直接完成功能。将这些卡片迁移过来，有以下几个挑战：
-
卡片体量大、广度深：40 多张卡片，覆盖飞机票、火车票、路径规划、单车打车、ETC 等多个垂直业务，庞大的数量本身就带来巨大的研发和联调工作量；
-
卡片逻辑挖掘与梳理：卡片并非静态展示，出行相关的卡片内部封装了大量隐性的业务逻辑，如动态内容更新、接口轮询，一个业务功能的完成也可能是由多张卡片协同工作构成的，客户端需要处理卡片的显示、更新和移除，例如，单车卡片的状态流转（扫码中 → 行程中 → 订单完成），这些逻辑并未显式文档化，我们需要进行考古挖掘，从代码和实际交互中梳理完整的业务逻辑；
-
复杂且频繁的双向通信：卡片功能并非孤岛，而是与客户端 Native 形成深度依赖。存在近 20 个卡片与 Native 通信的 JSAPI，卡片可以直接通过 JSAPI 进行发起查询、停止生成等操作；地铁码、公交码等卡片可通过 JSAPI 唤起 Native 组件；Native 可通过 Notification 下发生命周期事件给卡片，以上所有双向通信能力都需逐项平滑迁移，保证功能与时序一致。
3. 标准框架磨合
AI 搜与 AQ 此前接入 xUI 时积累的经验，可以为我们提供借鉴，帮助提前规避许多基础问题。然而，也存在以下挑战：
-
标准协议的路径摸索：标准化协议下的诸多细节，如新协议下生成式卡片的全新渲染机制等，缺少现成的最佳实践可供参考，需要我们自行摸索和验证；
-
问题排查链路长、难度大：当出现功能问题，如流式输出空白、输出中断或渲染失败时，问题可能在业务、xUI 框架、卡片 SDK、前端、网关、业务后端中的任何一环，在初期缺乏成熟的诊断工具的情况下，定位问题链路长、难度大。
七、重构实践
1. 整体架构
2. xUI 实践
1. 数据协议适配，百花齐放 → 大一统
各个 AI 对话产品协议定义混乱，理解和对接成本较高，AI 出行助手使用 xUI 1.0 标准化协议，其定义的一套标准的 AI 对话模型输入输出协议，统一了卡片渲染协议、数据协议和控制协议。
支小宝原业务卡片的数据结构，需要转换为全新的标准化结构，对服务端来说是不少的工作量，客户端需重新进行数据的解析，前端也可能针对新协议重新解析和渲染。
迁移原则
复用存量卡片，尽可能不修改存量业务卡片的逻辑。
迁移路径
保持卡片已有的渲染数据不变，调整外层结构以遵循标准协议，实现存量业务卡片无缝迁移到新协议。
-
核心渲染数据不变：在支小宝卡片数据中，真正渲染数据相关的是
templateData部分，每张卡片的渲染数据都不同，为了平迁卡片功能，减少前端工作量，我们需保证templateData部分不变； -
适配标准协议：后端需根据标准协议将旧的小宝数据进行转换，除
templateData复用外，templateId、templateInfo等涉及卡片的部分也保持不变，然后依次将chatId、itemId、hasNext等关键字段装载到新协议的结构体中。
通过这种方式，我们以较小的成本，实现了最大的数据兼容。
2. 底层消息通道升级，RPC/SYNC → gRPC
在支小宝，一次完整的对话交互，依赖于一套分离的通信模型，用户 Query 通过普通 RPC 发送，而 AI 生成的流式数据则依赖独立的 SYNC 通道。这种 RPC + SYNC 的混用方案，会导致：
-
链路复杂性高：研发需同时关注两个通道的请求构造、状态同步和异常处理；
-
体验瓶颈：SYNC 存在消息时效性差、高峰期数据积压等问题；
AI 出行助手基于 xUI 的消息通道将通信能力重构，统一使用基于 HTTP/2 的 gRPC 流式通信，gRPC 的优势如下：
-
单一连接，双向流式：gRPC 天然支持单连接上的多路复用和双向流式通信，符合 AI 对话场景中“一次请求，多次返回”的交互模式；
-
统一协议，简化链路：解决了 RPC+SYNC 的混用问题，将复杂的通信逻辑统一收敛；
业务实践：从“关心实现”到“聚焦业务”
xUI 框架对底层 gRPC 的通信能力进行了封装，业务研发的关注点从底层通信细节上升至业务会话层面。
基于 gRPC 协议封装的双向流式 RTS 通信能力，在支付宝 app 端内的五福双人联机打年兽、蚂蚁登山赛、股票行情等业务场景有广泛应用。以 “股票 L2 行情” 为例，相比 SYNC，性能提升 65%，收益明显。
3. 渲染组件迁移，碎片化实现 → 生成式卡片
在 AI 出行助手中，我们面临着一个历史遗留问题：从支小宝继承而来的渲染体系，是由 Native、卡片和Native Markdown 组件组成的碎片化架构，维护成本较高：
-
原生 Native组件：负责渲染简单纯文本；
-
卡片：业务卡片，承载机票、火车票查询等核心业务功能；
-
Native Markdown 组件：用于解析和渲染富文本内容；
因此，有必要构建一套统一的会话内容渲染组件，幸运的是，xUI 框架已经拥有一套面向生成式 UI 的端到端解决方案。
生成式 UI
目前对于生成式内容的普遍解法是 Markdown + 扩展：即通过在 Markdown 中约定特殊标记，转成一个图表或者通过多个卡片来拼接，这种方案虽灵活，却也导致各业务自定义标记泛滥，缺乏统一标准。
xUI Runtime 通过定义一套标准化的模型输出扩展协议（包括标记定义、渲染行为），让不确定的 AI 输出，能够被确定性地渲染成丰富的 UI。
在这套架构下，对于业务研发来说，“不区分内容形式，万物皆为卡片” ，统一使用卡片作为渲染组件。
3.1. 渲染行为解耦，template & display
在标准化协议下，渲染行为解耦成了两个独立的概念：
-
template：代表“一个新的卡片需要被创建”，当业务层收到时，无脑地创建一个空的卡片容器；
-
display：代表“具体的渲染内容，需要填到卡片里”，这个行为由框架内部处理，业务层完全不感知；
这种设计的好处是，业务层的职责被极大简化。我们只需要关心“挖坑”（创建模板），而不需要关心“填坑”（填充内容）的复杂过程。
3.2. 内容类型抽象， COMMON & FLOW
为了支撑不同的业务场景，卡片类型抽象为两种：
-
COMMON：普通卡片， 对应内容一次性下发的静态场景；
-
FLOW：流式卡片，对应内容像水流一样，被拆分成多个小片段，逐一下发的动态场景；
这种类型区分，对业务研发是透明的， 业务在收到template时，并不需要关心这张即将创建的卡片到底是COMMON还是FLOW，我们只需要统一地创建卡片容器并填充渲染数据，框架会根据卡片类型，在内部自动选择不同的“填坑”策略。
3.3. 业务场景统—，三大卡片类型的实现
根据卡片类型的不同，出行助手中的卡片可分为静态卡片、生成式卡片和动态更新的静态卡片，基于上述能力，出行助手实现了所有场景下的卡片渲染：
-
静态卡片:
template(COMMON)
-
和常规的业务卡片渲染几乎无异，一次性完成；
-
生成式卡片：
template(FLOW)+ 一系列display(流式小组件)
-
业务只负责渲染一个空壳模板卡片，后续的数据接收、拼接成打字机效果、更新卡片内容等一系列操作，全部由 xUI 内部完成。业务无需关心流式内容是纯文本、图文混排还是 Markdown，真正做到了无感更新；
-
动态更新的静态卡片: 本质上是
template(COMMON)，但 xUI 框架在内部封装了SYNC轮询能力；
-
对于需要轮询状态的卡片（如共享单车和打车），业务无需再建立 SYNC 通道，只需像渲染静态卡片一样创建它，而其内容的动态更新，则由 xUI 框架在内部统一处理；
3. 卡片生态迁移
出行助手卡片生态异常丰富，包括大大小小 40 多张卡片，每张卡都承担着特定的功能，以火车票机票为例，就包括登录卡片、确认订单卡片、支付卡片、订单卡片、选择地址、选择日期、返程卡片、待出发行程卡片等 8 张卡片。
1. 代码考古与分析
卡片梳理与范围界定：首先对卡片进行全面的梳理，明确属于出行范围的卡片，按照业务场景进行归类，确定改造优先级。
代码考古与运行时分析：深入原支小宝和卡片的代码，并结合运行时动态调试，了解每一张复杂卡片内部的业务逻辑和状态流转，通过时序图的形式将逻辑可视化，方便对每个交互点，逐一进行迁移。
-
一张卡片就能完成业务流程吗？若不是，涉及到几张卡片，卡片之间的状态是如何流转的；
-
卡片内容是否会更新？如何更新？直接和后端交互还是依赖 JSAPI；
-
依赖哪些原生能力？
如下图，分别是单车和打车的时序图，可以看到，涉及多张卡片的轮换，数据获取链路非常长，卡片和卡片之间、卡片和原生之间，存在频繁的双向通信，构成了一个非常复杂的交互状态机。
2. 数据交互通道构建
-
双向通信链路梳理：通过静态搜索、运行时调试等方式，对卡片与 Native 双向的通信接口进行梳理；
-
JSAPI ：卡片主动调用 Native 的接口，如发起查询、停止生成等；
-
通知：由 Native 主动通知卡片事件，如页面进入，页面退出等；
-
卡片通信能力搭建：基于上述梳理，优先完成 Native 和卡片通信能力的搭建；
3. JSAPI 功能兼容
支小宝和出行相关的 JSAPI 近 20 个，这些 JSAPI 中封装了大量业务定制的规则，使功能平移变得困难，我们的大量时间，都投入在对这些历史参数的“解码”与适配上。
历史参数适配
最典型的例子是核心的 Query 功能。
-
在支小宝原有的 RPC 请求链路中，业务方为了实现特定的功能，在标准的请求体之外，自定义了大量的扩展参数，这些参数承载着重要的业务逻辑；
-
在切换到新的 gRPC 链路后，出行助手不能简单地丢弃这些“历史包袱”，而是要在新链路的协议体中找到合适的位置，将这些扩展参重新封装并传递给服务端。这需要我们理解每个扩展参数的真实意图，确保在新的协议下，服务端依然能正确解析这些参数；
定制化交互逻辑兼容
许多 JSAPI 参数，并不仅仅是传递数据，更是用来精细化控制 UI 行为的，比如：
-
静默发送：如打车的目的地选择卡片、订单预估卡片，需要用户点击卡片操作后，静默发送 Query ，即在输入框不显示发送的文本；
-
阅后即焚：比如火车票的日期选择卡片、单车的扫码卡片，要求用户点击卡片上的操作后，关闭卡片自身；
面对这些高度定制化的交互逻辑，我们需要对每一张卡片进行调试，确保历史逻辑在新架构下依然能够工作，从而实现对用户体验的无损迁移。
4. 解耦依赖，迁移提效
在整个迁移工程中，面临的最大瓶颈是跨团队的研发依赖：客户端的研发进度严重依赖后端的协议改造进度，为了打破这种依赖，实现真正的并行研发，我们采用以下两个策略来加速：
平移旧有通信链路
-
首先将支小宝原有的 RPC+SYNC 整套通信链路，完整地平移到了新的 AI 出行助手工程中。在全新的 gRPC 链路就绪前，就拥有了一条稳定可用的“旧轨道”来获取数据。
构建客户端协议适配器
在构建老链路通信通道后，还需要一个客户端协议适配器，这个适配器在研发阶段临时承担本该由后端负责的协议转换工作：
-
消费旧数据：直接消费通过 RPC+SYNC 旧链路获取的支小宝数据；
-
输出新协议：客户端实时地将旧数据转换成标准协议格式；
至此，客户端可提前进行卡片功能的调试，给后续的全链路联调争取了充足时间。
4. KMP 实践
在 AI 出行助手的架构中，除了核心的主会话模块，还有一个重要的智能体模块，智能体模块包含智能体列表页和智能体详情页，在技术选型上，我们根据不同页面的特点，进行了一次战略性、差异化的技术实践，其中 KMP（Kotlin Multiplatform）的应用，是本次实践的亮点。
1. 智能体列表页
对于相对独立、与主会话关联性较小的智能体列表页，我们果断选择了使用 KMP 进行开发，旨在探索其在复杂场景下的应用潜力。
-
智能体列表在结构上并非一个独立的页面，而是与主会话页面同级。因此，我们采用了 MicroPage 的方案，将 KMP 视图作为一个独立的 UI 模块，嵌入到原生的容器中；
-
智能体列表页面的交互较为复杂，列表页内部既有横向滚动组件，也有纵向滚动组件，而其底部的容器本身又是一个原生的滚动组件。这种嵌套滚动，引发了侧滑返回等一系列棘手的跨平台手势冲突问题；
面对这些问题，我们积极推动 KMP 框架解决侧滑手势冲突问题、以及卡片与 KMP 模块的兼容问题，这一实践不仅为用户带来流畅的列表滚动体验，更是帮助框架在处理复杂嵌套滚动这类通用问题上，沉淀了解决方案。
2. 智能体详情页
与列表页不同，智能体详情页功能已经成熟和稳定，我们直接复用了原支小宝中的现有模块，避免重复建设。
5. 数据建设
进入 AI 对话领域，如何科学度量一个 AI 对话产品的核心体验？ 过去的性能指标，比如页面打开耗时，在生成式的 AI 交互场景下已不适用，比如会话页面秒开，但用户发送问题后需要等待 5 秒才看到第一个字。因此，需要建立一套全新的、能够真实反映 AI 对话流式交互质量的度量体系。
核心思路是：从用户的实际感知出发，将一次 AI 对话的过程，拆解为一系列可度量、可归因的关键节点。 基于此，我们设计并搭建了一套包含「可感知耗时」和「链路稳定性」两大维度的度量体系。
1. 可感知耗时
我们定义了 AI 对话中最核心的用户体验指标 —— 首 Token 耗时，即从用户发送 Query 到屏幕上出现第一个 AI 生成内容的时间。这个指标直接决定了用户感受到的“快”与“慢”。总耗时可以进一步精细化地拆解为三个核心阶段，用于指导后续优化：
-
xUI 数据回调耗时：从用户发送 Query 开始，到接收到 xUI 数据回调的耗时，包括了请求建连，数据发送，中间经过网络传输、到达网关、业务后端处理，返回到 xUI 耗时；
-
端数据处理耗时：客户端收到框架的数据回调后，完成解析、转换，到即将开始创建模板卡片的耗时；
-
模板卡片创建耗时：创建模板卡片实例的耗时；
-
模板卡片渲染耗时：卡片实例创建后，将其真正绘制到屏幕上的耗时；
2. 链路稳定性
除了用户感知的速度，会话链路的稳定性是 AI 对话体验的生命线。框架自身虽然有其内部监控，但更多是站在框架层的视角，而作为业务方，更关心的是用户体验是否受损。我们与框架深度对齐后，搭建了一套从业务视角出发，能够反映发送链路稳定性的监控指标体系。
业务视角的成功与失败
-
成功：只有当客户端收到以下状态回调时，才算一次业务意义上的成功
-
生成结束
-
生成终止
-
重写
-
异常：下面这些状态被定义为业务异常
-
错误
-
超时
基于这个共识，我们搭建了业务方视角的稳定性大盘：
-
发送成功率/异常率：监控会话链路的整体健康状况；
-
错误码/错误信息分布：对出现的异常进行聚类分析，可以快速定位是服务端异常、网络问题或其他原因，极大提升排查效率。
八、阶段性结果
我们以较短的研发周期、较少的人力投入，实现了 AI 出行助手的快速上线。目前取得以下阶段性成果：
业务指标
-
核心履约场景，履约 Tips 点击率明显超过履约卡片点击率，并稳步增长中；
研发效能提升
-
AI 对话新产品研发周期：数月 → 30天，刷新 AI 对话类业务的交付记录，证明在 xUI + gRPC + KMP 等底层技术基建的支撑下，可以实现较高的研发效率；
- KMP 方案释放 1 端人力，实现跨平台高效复用。
九、未来展望
1. 持续探索，打磨极致体验
-
全面拥抱 xUI 新特性：AI 出行助手将积极探索并接入更多先进特性，如端到端语音播报（TTS）、端到端语音识别（ASR）等，为用户带来更优秀的交互体验；
-
深化 KMP 应用：本次 KMP 的实践只是一个开始，未来将继续扩大其应用范围：
-
旧场景体验打磨：持续优化现有智能体列表页的性能与交互，将其打造成 KMP 在复杂场景下的最佳实践；
-
新场景探索：尝试在更多业务模块（如会话页面）中应用 KMP，进一步提升研发效能，最大化“一次研发，多端共用”的价值。
2. 业务驱动框架完善
-
更加完善的基建：当前 xUI 框架在某些方面尚有提升空间，例如问题定位链路长、难度大，Debug 工具不够完善等，未来希望相关基础建设能够继续完善，给业务研发带来更好的体验；
-
更好用的跨端框架：基于 AI 出行助手的深度实践，我们期望与框架团队携手，共同攻克 KMP 在 Compose 稳定性、与原生代码的混用及上手成本高等问题，让更多业务能享受到跨平台的优势；
十、团队介绍
想让您写的代码影响数亿人？支付宝 2026 届秋季校园招聘已开启！作为蚂蚁集团核心业务板块，我们深度支撑支付宝 App 用户关键链路，每日承载亿级用户高频交互，是数字生活生态的技术基石。在这里，你能获得超级 App 建设的核心机会，亲身推动数亿人使用的产品迭代；与行业前沿的客户端技术梯队共事，和顶尖专家并肩攻克技术难题；投身高频核心项目，在真实业务场景中快速积累经验、实现能力跃迁。加入我们，用技术重塑数字生活体验，让每一行代码都成为改变世界的力量！——欢迎感兴趣的同学联系：yangguo.gcy@antgroup.com
文档智能与 RAG 构建 LLM 知识库
本方案介绍了如何实现将文档智能和检索增强生成（RAG）结合起来构建强大的 LLM 知识库，包括清洗文档内容、文档内容向量化、问答内容召回后通过特定的 Prompt，提供给 LLM 足够的上下文信息，以此来满足对于企业级文档类型知识库的问答处理。
点击阅读原文查看详情。
当人手少、Deadlines又紧的时候，大家自然而然就把所有精力都投入到解决问题上了，哪有时间去扯皮或者搞形式主义？然后，领导层对项目的高度关注和资源倾斜，也肯定是重要助推器。当然，更深层的原因可能是，团队成员都是精挑细选的“技术大拿”，彼此默契十足，而且又恰好用对了xUI+KMP这种杠杆效应明显的工具。天时地利人和，缺一不可啊！