AI专栏 | 提效4.7倍，携程机票前端迈向AI Coding自治

摘要：随着大模型在Coding领域的表现越来越好，AI Agent技术从提示词+ Rag 迈向上下文工程，使得AI Coding高度自治成为了可能。本文将结合技术流程方案和项目实践落地案例，介绍携程机票在代码转译/迁移场景上的AI Coding助手 - Transp

作者简介

启扬，携程前端开发专家，关注AI技术领域发展和前沿技术。

宏飞，携程资深前端开发工程师，专注大前端场景AI技术应用落地。

团队热招岗位：前端开发专家

导读：随着大模型在Coding领域的表现越来越好，AI Agent技术从提示词+ Rag 迈向上下文工程，使得AI Coding高度自治成为了可能。本文将结合技术流程方案和项目实践落地案例，介绍携程机票在代码转译/迁移场景上的AI Coding助手 - Transpiler。

一、引言

随着AI的蓬勃发展，大模型Scaling Law还在持续生效，使得业内提出的理念或方案随着大模型升级能力也在水涨船高，开始撬动更大价值。与此同时大模型在SWE（Software Engineering）领域下的强大表现，让AI Coding在AI应用领域始终占据着前排的位置，AI Coding产品百花齐放。行业的实践证明了，在软件工程开发周期中实现AI 高度自治成为了可能。结合软件开发生命周期：Requirement -> Design -> SoftwareDevelopment -> Testing -> Software Maintenance，我们判断目前AI 自治水平处于从中度自治往高度自治的发展进程中。

二、关于 AI 自治

说到AI自治，不得不提到2022年谷歌发的一篇论文：《ReAct: Synergizing Reasoning and Acting in Language Models》。它提出了ReAct概念，Reasoning & Reacting。对于这个业内有非多的研究和探索，单论文的引用数量也是达到了将近4000次。不少AI Coding产品都借鉴了这一思路。

三、Transpiler

关键词：ReAct、Multi-Agent、Context。

Transpiler实现了参考ReAct理念的流程设计，搭建了Multi-Agent框架支持任务识别和场景Agent调度，工具集支持了推理过程中所需的上下文内容。支持在IDEs运行（通过MCP方式支持），也支持Terminal上通过cli运行。

3.1 流程设计

从一个用户的任务输入，识别任务后，通过Multi-Agent框架调度到对应的代码转译/迁移场景的子Agent进行任务推理。子Agent跟大模型进行交互执行具体任务步骤时，会带着必要的上下文信息，也可以通过Function call和MCP触发对应的工具调用。

3.2 Context工程

基于丰富的工具集合提供上下文信息，包括代码依赖分析、文件检索和操作、Memory（历史对话记录），规则知识库（具体转译/迁移场景的规则），代码以及仓库信息，Bash命令执行的结果、任务状态管理信息等。

四、项目场景落地实践

4.1 CRN转xTaro

在深入讨论我们的迁移实践之前，有必要先介绍项目中涉及的核心技术框架：

CRN（携程增强版 React Native）

CRN（携程增强版 React Native）是在原生 React Native 基础上构建的增强版本。CRN 在原生 React Native 的基础上进行了深度优化，不仅提供了丰富的组件库和 API，还针对性能瓶颈进行了优化，确保了在复杂业务场景下的流畅运行。

XTaro框架

XTaro 是一个基于 Taro 框架（React 版的 Taro 实现）发展而来的多端开发框架，旨在增强 CRN 平台和 H5 平台的能力，并支持小程序开发。XTaro 通过整合多个技术栈，实现了一套代码可以在多个平台（H5、CRN、小程序）无缝运行的能力。

4.1.1 人工迁移规模与挑战

我们面临将旧框架代码迁移到新框架的技术改造任务，涉及上百个业务页面，预估工作量达数百人日。这些页面分布在多个业务线，且每个页面都包含复杂的业务逻辑和UI交互。

主要挑战包括：

4.1.2 Transpiler落地实践

核心工作内容包括两部分：知识库搭建，拓充配套工具。

知识库搭建

在xTaro转译这个场景，人工转换时需要参考的内容，都是模型需要的，内容范围：

React Native相关的知识（公网）

公司内部框架CRN/xTaro（内网）

人工转译时的经验总结和通用的知识内容沉淀（内网）

知识库构建流程

我们使用爬虫手段把内外部的文档内容都获取到，根据整理的组件映射表。在做CRN转xTaro的时候，需要让大模型知道之前CRN上使用的组件，在xTaro上的平替是什么，比如在CRN工程使用View这个组件，在xTaro工程下使用的是XView，以及两个组件属性字段和API对应关系。

知识库构建是通过大模型批量完成的，我们设计了一套提示词，让大模型根据我们整理的信息内容，一次性把映射规则知识库生成出来，我们把生成的组件信息存放在数据库中，按照组件名字+包名作为唯一索引字段。后续若有新增，只需要根据链接地址，组件名称等简单信息，就能一键生成并更新知识库。

我们基于这份数据做了可视化，方便我们检查生成质量以及后续维护，以ABTest组件为例，内容包括了组件转换概述，导入组件方式，API映射规则，相关代码样例few-shots，最后还有注意事项，是一些开发经验内容沉淀。下面是示例：

映射规则

转换示例

经验类沉淀

拓充工具

在做xTaro这类偏前端UI代码转译时，UI组件/API组件的依赖关系整理是至关重要的，决定了转译顺序。转译过程中的组件转译状态更新，是让类似Cursor或者Claude Code的IDE工具能够符合期望执行任务的关键因素。此外还需要支持知识库检索的基本工具、项目初始化工具等。这里核心介绍依赖分析以及转换管理工具。

依赖分析工具

结合人工转译的操作经验，一般先按页面一个个进行转换，当转换某个页面时，需要把这个页面及其依赖组件都进行转译。所以我们需要进行代码依赖分析，圈定转译范围。依赖往往是多层嵌套的，我们需要按顺序进行转译，不仅需要找到依赖的全部组件，还需要知道依赖层级深度。下面是依赖分析结果示例：

转换管理工具

为了让这个自治任务顺畅的运行，我们做了一个转换管理工具，让大模型知道当前进度，确保任务流程运行顺畅。关于这部分大致经历了三个阶段：

第一个阶段是交给大模型，我们发现一开始还行，但是发现在IDEs上运行时，入参信息随着时间推移会出现丢失的情况，表现不稳定。

第二个阶段是我们通过保存在运行时的内存里，这个阶段能给大模型提供准确的任务状态信息，但是有个痛点，任何异常情况断开或者有其他临时任务不能继续转译需要停止，任务状态就没有了。

第三个阶段是我们把任务状态的维护更新持久化到文件里。让大模型每次任务执行都能拿到准确的任务状态。

4.1.3 落地成果

IDEs运行转译任务 - 缩减工时61.4%（提效约2.6倍）

Terminal运行转译任务 - 缩减工时78%（提效约4.7倍）

说明: Terminal全托管下，需要后续人工介入审核和调试，以及一些H5场景的适配工作。

4.2 Java21升级

4.2.1 人工迁移规模与挑战

公司后端技术栈以Java为主，各个业务线使用的Java版本各有不同（包括Java8、Java11、Java17、Java21），应用总数高达数千个。从性能以及资源利用角度，公司推行Java升级。

主要挑战包括:

应用数量多，需要投入巨量人力

实际应用现状复杂，中间件使用不统一

升级Java21，涉及的适配变更点多而杂

4.2.2 Transpiler落地实践

核心工作内容依然是两部分：知识库搭建，拓充配套工具。

知识库搭建

根据搜集的人工升级经验以及整理的变更点文档，进行归类整理。包括：配置变更、启动项变更、中间件升级适配、依赖变更、代码兼容性变更、插件变更等。

ps：此处不提供具体示例。

拓充工具

根据应用现状和变更点，梳理具体执行流程，每个流程需要对应的代码工具。举例三个工具：

项目环境检查

bash# 检查JDK版本 (必须包含"21")JAVA_VERSION=$(java -version 2>&1 | head -1)if ! echo "$JAVA_VERSION" | grep -q "21"; then echo "错误: JDK版本必须是21，当前: $JAVA_VERSION" exit 1fi# 检查Maven版本 (必须≥3.6.0)MVN_VERSION=$(mvn -version 2>&1 | head -1 | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)if ! echo "$MVN_VERSION" | awk -F. '{if($1>3 || ($1==3 && $2>=6)) exit 0; else exit 1}'; then echo "错误: Maven版本必须≥3.6.0，当前: $MVN_VERSION" exit 1fi# ...# ...

对工程环境进行初步检测，属于前置依赖项。

项目分类识别

bashdetect_project_type { PROJECT_TYPE="BASIC" # 默认值 # 1. JMockit检测 (最高优先级) if grep -rq "jmockit" pom.xml */pom.xml 2>/dev/null || \ find . -name "*.java" -exec grep -l "import mockit\." {} \; 2>/dev/null | head -1 | grep -q "."; then PROJECT_TYPE="JMOCKIT" return 0 fi # 2. PowerMock检测 if grep -rq "powermock" pom.xml */pom.xml 2>/dev/null || \ find . -name "*.java" -exec grep -l "import org.powermock" {} \; 2>/dev/null | head -1 | grep -q "."; then PROJECT_TYPE="POWERMOCK" return 0 fi # 3. ... # 4. ... # N. 默认基础项目 PROJECT_TYPE="BASIC"}

对项目工程的依赖情况分类识别，按分类识别检索对应。

变更点数据标注