导读

随着大模型在 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 交互｡

主要挑战包括:

• 大量页面需要改造，人工成本高昂
• 开发人员需同时熟悉两套框架，学习成本高
• 迁移过程容易出错，质量难以保证
• 业务迭代与框架迁移并行，资源冲突严重 - 版本升级涉及的 API 变更和兼容性问题复杂

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 工具能够符合期望执行任务的关键因素｡此外还需要支持知识库检索的基本工具､项目初始化工具等｡这里核心介绍依赖分析以及转换管理工具｡

依赖分析工具

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

转换管理工具

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

1. 第一个阶段是交给大模型，我们发现一开始还行，但是发现在 IDEs 上运行时，入参信息随着时间推移会出现丢失的情况，表现不稳定｡
2. 第二个阶段是我们通过保存在运行时的内存里，这个阶段能给大模型提供准确的任务状态信息，但是有个痛点，任何异常情况断开或者有其他临时任务不能继续转译需要停止，任务状态就没有了｡
3. 第三个阶段是我们把任务状态的维护更新持久化到文件里｡让大模型每次任务执行都能拿到准确的任务状态｡

4.1.3 落地成果

• IDEs 运行转译任务 - 缩减工时 61.4%(提效约 2.6 倍)
• Terminal 运行转译任务 - 缩减工时 78%(提效约 4.7 倍)

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