大语言模型

淘宝跨端体验优化 AI 演进之路

2026 年 4 月 3 日

淘宝如何用AI重构跨端体验？揭秘从人工诊断到AI自驱的演进之路。核心内容： 1. 手淘跨端业务面临的性能优化挑战与AI解决方案 2. 体验优化Agent等5款AI产品的技术架构与创新突破 3. 在双十一等核心场景中的实际应用效果与业务指标提升

本文详细阐述了手淘跨端业务在AI时代的演进与重构。面对跨端应用性能体验的持续优化命题，团队从0到1孵化了包含体验优化 Agent在内的5款AI技术产品，构建了覆盖“本地编码-预发发布-提测-线上运维”的全链路研发闭环。文章核心展示了体验优化 Agent如何通过整合端边云基建、RAG知识库及特定Skills（如云真机调试、自动化Coding），解决传统AI无法理解手淘复杂业务语意及SSR渲染模式的痛点，从而将优化方式从“人工诊断”推向“AI自驱与自进化”。最终，该体系实现了在无需人工干预下，利用AI完成数据回收、问题分析、代码修复及配置变更，显著提升了跨端应用的性能与稳定性。

前言

手淘的跨端业务的性能体验经过飞燕项目一期二期三期的优化发生了蜕变。而面对未来不断发展以及变化的业务场景及形态，如何持续保持高水位成了最关键的技术命题。基于此，我们深入了关键的技术战役，并通过深度结合 AI 技术完成了跨端基建的沉淀建设、AI 产品的孵化以及各类机制的闭环的全面建设。

跨端基建与 AI 产品上，我们针对体验优化、负向治理、白盒工程质量、黑盒质量以及架构演进升级等跨端业务的关键技术命题从 0 到 1 孵化了 5 款 AI 技术产品结合跨端研发平台以及 IDE 进行落地。同时，我们对于正向/负向体验分别设计并交付了高性能解决方案以及负向采集 SDK 两款跨端基建产品，以提供开箱即用的高性能能力以及辅助 AI 进行分析的采集能力。
机制建设上，跨端研发平台联合终端测试平台能力进行防腐机制，从线上监控劣化=>工单生成=> AI 分析报告=>产出 PR 实现的 AI 自主分析修复的闭环设计。
业务战役上，通过深入双十一核心主会场、主互动、闪购、核心频道、直播等场景进行问题的定义与能力建设落地，通过技术手段对关键业务指标 DAU、GMV、曝光兑现率、访购率等核心指标均有不错的提升。

整体介绍

这里做一下相关产品的整体介绍，以补充一些前置的了解。包括我们的核心产品跨端研发平台、端边云的高性能渲染链路以及结合跨端的场域所设计的一系列 AI 产品。

▐ 什么是跨端研发平台

跨端研发平台不是传统意义上的前端框架，而是端、边、云应用结合前端框架、研发工具及研发平台的深度融合，是跨端应用一站式解决方案平台。

▐ 平台 AI 产品

整体上，跨端研发平台结合终端测试平台相关的 AI 能力围绕着跨端业务的体验、稳定、效率建设了一系列 AI 应用，今年从 0 到 1 孵化了 5 款 AI 技术产品，分别解决跨端领域不同的问题：

体验优化 Agent：解决体验优化以及高性能解决方案接入的技术命题，体验优化 Agent 通过 AI 能力结合云真机调试、平台操作、AI Coding 等 skills 完成体验数据的分析、问题挖掘、代码修改/平台操作的体验问题解决闭环；
JSE-Agent：通过结合负向采集 SDK 基建完善了 JSE 的线上精细化采集以及分析能力，解决 JSE 问题的采集、问题挖掘、代码修改的负向问题解决闭环。今年完成大的重构后从简单的 sourcemap 堆栈分析转向静态代码结合运行时 4XX 复杂问题分析的分析能力的转变与提升；
Doctor Agent：目标是交付 AI CR/AI Lint 能力结合可沉淀的规则中心数字化资产进行跨端业务白盒工程的工程质量提升；
终端测试平台：通过对接终端测试平台能力，对跨端业务在预发环境进行黑盒工程的 AI自动化测试，并交付了如稳定性测试、monkey 测试、性能测试等丰富的 AI 测试能力；
Scalpel Agent：结合 SRE 健康分机制提升整体跨端应用的工程健壮度，为架构防腐及老旧架构下线的技术命题提供了 AI 一键修改代码并完成架构升级的技术能力；

基于以上的 AI 产品能力，结合跨端研发平台平台以及线下 IDE 环境，提供了整套从本地编码、预发发布、提测阶段检测以及线上运维的全面产品交付，以此提升跨端业务整体的体验及稳定。

由于篇幅以及时间限制，今天重点来介绍以体验优化为切入点的 AI Coding 设计，来聊聊如何在让 AI 来帮我们优化跨端应用的性能，其余的几个方向有兴趣的可以跟笔者私聊探讨，后续都会有专栏输出相关的内容与思考。

手淘跨端体验优化方式的演进过程

这一年手淘的体验优化方式结合 AI 技术发生了巨大的变化，手淘跨端应用体验优化方式的演进可以划分为五个阶段，体现了从人工协作到 AI 自驱的技术升级路径：

阶段	执行策略	核心问题/矛盾
架构师介入本地优化	架构师进行本地工程跑起来进行线下的 trace 分析，定位性能瓶颈并告知业务同学进行相关代码的优化，形成问题挖掘-人工诊断-代码修复。	人力成本高，强依赖架构师，同时优化的方案难以横向复用以及沉淀。对于动辄数百上千的跨端应用来说，架构师成为了中心化的瓶颈点，业务同学的学习理解成本相当高。
标准化解决方案&框架交付	通过沉淀交付标准的前端框架 ICE 以及高性能解决方案，进行体验优化的配套设施开箱即用，80% 以上的通用场景一行代码即可开启，开箱即用降低开发者使用门槛	新同学依旧有学习成本，性能优化依旧需要架构与业务的高投入才能协同完成。
AI 辅助诊断交付报告	通过 AI 辅助诊断输出报告驱动架构师进行技术决策后，交付给业务同学进行相关的解决方案接入&平台操作&热点代码修复	只是节约了部分架构师分析的时间，依旧依赖架构与业务双向协同进行代码修改以及平台的操作。同时，此时的 AI只能针对工程进行简单分析，无法调用云真机等进行调试。
AI 分析 & Coding 一站式交付（当前阶段）	通过 Skills 让 AI 可以调度云真机进行调试、线上根据体验模型进行聚类分析、通过云端沙箱进行 AI Coding、通过 page-agent 进行平台相关操作等等	此时的 AI 基可以完成全托管独立完成采集到分析到修改的全链路体验优化了，也是目前所处的阶段，需要做的是进一步提升评测的分数跟准确性。
自进化 AI Agent（进行中）	通过知识萃取（文档、群聊、问题排查记录）等进行统一的解决方案&规则驱动沉淀，同时通过思维链学习，让体验优化 Agent 成为每个跨端同学最懂手淘体验的 AI 架构师。	/

理解了整个手淘跨端应用体验优化的演进过程后，我们回过头来看我们经历了哪些困境及问题，以及我们如何破局解决这些问题并演进到当前的阶段的。

AI体验优化的困境

下面笔者将用实际场景优化的 case 来分析一下，当前 AI 进行体验优化所欠缺的部分，以定义出核心的命题及问题。

▐ 当前 AI 能力分析体验问题的问题

举个栗子🌰，笔者使用 Cursor + Opus 4.5 随机抽取试点了几个淘内的 C 端应用场景进行相应的体验优化，表现如下：

▐ AI进行体验优化的核心问题定义

基于上述的实验可以看出，当前直接利用 AI 做体验优化会表现出一些非预期修改，问题定义如下：

无法理解 SSR 以及其复杂度，无法感知整个应用逻辑如何分别在服务端、边缘、客户端内被运行以及消费，使用的优化方案还停留在传统的端渲染（CSR）以及八股文优化方案；
无法理解手淘领域知识，如网络做了哪些优化需要在应用中如何使用及申明；
无法感知业务逻辑，区分不了主请求、首屏元素等业务技术语意；
只有纯静态代码进行优化，无法调试真机环境进行 trace 分析，调试热点代码等方式进行优化；
无法操作通用的平台配置、IDE 等环境进行代码、配置的修改以及发布；

整合端边云框架基建，构建上下文工程

▐ 体验优化 Agent 的整体设计

整个体验优化 Agent 围绕着手淘端边云的前端框架等基建进行设计，配合基建进行精准信息的采集以及用户行为回溯等能力进行整体的信息采集。同时高性能解决方案、ICE 框架、跨端研发平台、前端源站以及边缘应用 ER 通过无感注入到开发者页面中全流程进行采集。同时，基于 RAG、Workﬂow、工程能力、代码语意等进行上下文的调优。并且通过交付一系列的 Skills 进行外部能力对接帮助开发者完成平台操作、AI Coding、真机验证等。最后通过评测以及 Trace 来不断调优完善。

下面我以几个维度来展开讲下整个体验优化 Agent 上下文工程是如何跟端边云基建进行深度整合以及调优提升确定性的。

▐ 基建与工程设计——提升 AI 确定性

区别于传统工程，AI 的工程本身会存在着【不确定性】，我们如何把这里的【不确定性】关进确定性的牢笼中，整个上下文工程的设计至关重要。上下文工程本身是一个信息熵减的过程，需要有更精确更描述精准的信息，同时将确定性的流程、方案等进行工程化，模型才能给到一个更优的效果。我这里介绍下体验优化 Agent 上下文工程的演进之路，来讲解我们是如何通过端边云基建的深度整合，来构建体验优化 Agent 的上下文工程，避免模型“灵光一现”，而是交付确定性更高的结果。

体验优化 Agent 上下文工程基于“如何提升整体 AI 结果的确定性”的核心命题定义的问题解决方案，我认为有几点：

上下文信息：通过优化信息结构及密度、用户行为回溯提升分析确定性
代码语意：通过对前端框架约束运行时提升语意确定性
工程 & workﬂow：增加工程能力以及流程化提升执行确定性
统一解决方案：通过高度抽象统一解决方案提升策略以及 AI Coding 确定性

下面笔者会将上面几部分进行一个进一步的讲解以及深入。

上下文工程信息

这里先做个前置的介绍方便大家理解，跨端业务大部分具有较重的营销属性，导致其 UI 形态以及渲染具有高复杂。业务形态上具有千人千面，以复杂业务【会员中心】来说，在一个 URL 所对应的单一应用中，就有下述多种形态。每一种形态的 UI 表现力与复杂度不尽相同， P95 长尾可能分布在其中的 1 种或者多种形态中，让我们优化无从下手。

同时，除了千人千面的业务行为，长尾存在的情况是线下难以复现的，导致线下查看 trace 没有重大性能问题，但是实际代码发布到了线上 P95 依旧居高不下。问题无法被看到/定义以及线下无法复现是常态。

业务状态	已开卡	未开卡 - B样式版本	未开卡 - 断约版本	冲刺用户	800-用户
UI渲染

与此同时，基于 Tlog 的海量信息很难在上下文中获取到关键的异常信息，海量的信息喂给模型直接会导致出现幻觉同时分析结果效果差。同时，区别于线下的场景复现，除了扰乱的信息多，也同时面临着信息不够的问题，除了舆情上传的视频，我们无从获取用户的行为路径以及用户端发生了什么事情。

基于上述的问题定义，我们对线上混乱无章的 Log 进行了模型的抽象、线上设备服务端等环境记录以及用户行为会进行记录与回溯以更好地拿到关键的可分析数据进行问题分析。

工程 & workﬂow

即便已经通过基建进行了关键信息的采集，在采集测已经做了一次操作，但是由于手淘每天的海量数据，一股脑地将所有信息扔给模型依旧会产生各种幻觉等造成了结果的不确定性。基于此，我们通过前置工程的聚类分析、workﬂow 等确定性工程流程进行了对关键分析流程的调优。

原则上，能用工程实现的确定性执行过程一定不给模型处理，工程的预处理可以有效避免模型的幻觉，让 “1 + 1 = 2”。同时，固有流程无需模型进行泛化的内容同样通过 workﬂow 等流程进行执行的确定性。体验优化 Agent 上下文工程中的部分工程内容有很多，下面通过长尾特征聚类分析为例的多维度分析引擎以及常见 workﬂow 来给大家展示一下部分工程优化能力。

统一解决方案

当 AI 清晰地定义好当前需要做的优化以及问题后，下一步关键来了，我们并不期望 AI 根据我们的工程随意编码修改，进行过于泛化的自由发挥，因为这会让我们 AI Coding 的结果不受控制。比如加一个【端快照】能力以优化 Web 下访问白屏的问题，我们并不期望 AI 通过实现一个 Snapshot 功能在 JS 代码里根据自己的挥发去重写一个，这往往会有一些意想不到的 AI Coding 的不确定结果。

区别于大家都在搞的 spec，spec 本身在 AI Coding 前已经有比较规范的标准内容了，而体验优化在 AI Coding 前还是一堆杂乱无章没有清晰 action 的结果内容（如 FCP 比较长，需要优化首帧）。

我们通过对通用优化能力的抽象，提供了一系列的解决方案，解决方案会统一沉淀在解决方案中心，并通过召回来优先查找是否有标准的统一解决方案进行相关代码的操作及优化。这是标准的开箱即用代码，它让大部分的优化代码从无序的自由发挥到了统一且标准的能力交付上。

代码语意

上面讲过了统一解决方案，那么除了统一解决方案一定会涉及到业务代码相关的热点追踪及修改。之前问题定义中讲了一个核心矛盾，为了优化 FCP 生成了骨架的代码，最终该骨架组件并没有被引用，无从感知插入到哪个位置。那么真实业务中抽象的基础业务属性非常重要，抛开每个业务不同的上层业务语意，AI 需要知道哪些是 Mtop（HSF）接口、哪些是静态内容、哪些是动态内容等等，这些属于业务代码语意中的技术语意。

通过前端框架对业务代码进行规范化，抛开业务语意，找到最根本的技术语意，以此给大模型作为语意理解的一部分。

▐ Skills——让 AI 为开发者解决问题

解决了 AI 分析体验问题的的确定性，让体验优化 Agent 可以将线上线下数据自动挖掘问题并输出分析报告。但是开发者同学依旧会面临大量的下一步 action 的问题。开发者会有疑问，我下一步代码改哪里，改完如何验证，这个平台操作路径是怎么样的，平台配置应该如何配等等的一系列问题，如何帮助开发者走完最后一公里呢？

那么就要介绍一下体验优化 Agent 的 Skills ，它让体验优化 Agent 从空谈到实干，从纸上谈兵到大杀四方，下面介绍几个关键的 Skiils 以及它们解决了什么问题。

▐ 准确性提升——评测及 trace

体验优化 Agent 通过 Zata 建设了 Trace 以及评测体系，通过评测集持续迭代优化体验优化 Agent 的准确率。同时，通过 Trace 来排查异常结果返回的情况下的具体问题。

AI产品化—结合跨端研发平台 & IDE & 终端测试平台，

打造陪伴开发者的跨端 AI 架构师

一个 Agent 本身如果没有产品能力的依托，那它就是一个无法被用户真实感知跟使用的代码块。想要 Agent 真正发挥其作用，需要将它涉及到我们的用户平时实际场景的每一个环节，不断完成用户端的【触达】，以此形成一套触达整个研发周期自动化运作的机制完成【问题左移，快速修正】。

▐ 让 Agent 能力无处不在

我们将整个研发周期分成四个阶段：本地编码、预发发布、提测阶段、线上运维。目前应用的研发现状还是根据这套模式流程进行运作的，问题左移的本质是“问题发现得越早，解决的成本越低”。基于此，研发流程中我们可以在几个阶段进行下述的产品能力侵入：

本地编码（白盒）：开发者在 IDE 中进行需求开发以及调优，需要完成高性能解决方案的快速接入，或者根据线上长尾问题 & 线下真机环境快速定位到相关的热点代码及核心问题的代码片段。同时，在编码器 AI CR & AI Lint 能力会根据用户的修改给出相关的优化建议，此阶段重点在代码层面的白盒检测。在此阶段通过开发者无论通过 Cursor 等 IDE 进行 MCP 调度还是使用 CodeWiz，产品形态上都是支持；
预发发布（白盒）：在代码进入预发阶段后，跨端研发平台平台上会触发 AI CR & AI Lint & Doctor 等白盒工程层面的检测，同时有解决方案一键接入、问题代码一键修复等能力运行在云端沙箱中。此阶段作为提测前的最后一道白盒工程代码层面的检测。在此阶段跨端研发平台本身拥有平台层面的代码检测能力，同时通过云端沙箱进行代码的平台化修改；
提测阶段（黑盒）：提测后会触发黑盒层面的检测，围绕构建后的可访问产物进行云真机的访问，通过调用调试云真机以访问运行时而非之前的构建时检测，查找里面相关的热点问题跟瓶颈，并沿用云端沙箱以及 IDE 完成问题的修复。在此阶段 AI 通过 skills 调度云真机平台并完成相关的检测与调试，同时返回分析结果；
线上（运维）：通过线上 P95 场尾数据进行检测，终端测试平台会通过线上数据变化趋势挖掘劣化，通过终端测试平台工单异步触发体验优化 Agent 进行异步的分析并产生相关 PR/MR，业务负责人看到工单后直接可以跟车测试&发布已修改好的代码即可完成工单的治理；

▐ 实际产品演示

本地编码阶段

本地编码环境，通过 IDE 接入 MCP 服务，可以完成编码时期的 CR/Lint 提示并进行一键修复以提升编码质量，同时通过解决方案的一键接入，输入线上线上 P95 的长尾体验问题进行相关的分析以及代码层面的直接优化。

预发发布阶段

提测阶段

提测阶段通过云真机进行真实页面的跑分，明显的劣化操作在此阶段会被检测出来并对相关数据进行记录。有问题的点会重新调度体验优化 Agent 的分析器进行分析以及云端 AI Coding的改动。

线上运维

通过终端测试平台识别劣化后触发体验优化 Agent 进行劣化分析及性能补正，并自动异步完成分析到 PR/MR 的创建给到开发者，开发者评审后发布即可。

▐ 实业务落地

高性能解决方案 agent 重新定义了跨端业务进行体验优化的方式，借助 AI 的能力，我们可以做到 0 人工介入的情况下完成数据回收分析、云真机调试、高性能解决方案接入、平台配置变更、AI Coding 代码层面热点问题修复。对于劣化后及时修复劣化问题、从 0 到 1 完成新项目的体验优化，接入新的优化方案等场景都有配套的 AI 能力以及产品能力的交付。

立即咨询 JOTO

JOTO 提供覆盖企业智能体规划与搭建、AI 平台私有化部署、RAG 知识工程、AI 安全治理、FDE 驻场共创及持续运营优化的全周期 AI 落地服务，帮助企业把验证中的 AI 能力转化为安全、可控、可持续迭代的生产力。联系 JOTO 获取 AI 落地咨询

想把这些做法用到你的业务里?

留下你的场景和痛点,我们帮你判断从哪一步开始。

联系我们

淘宝跨端体验优化 AI 演进之路

立即咨询 JOTO

想把这些做法用到你的业务里?

开启企业级 AI 落地

填写需求单