← 返回案例

科技 / 开发者工具

编程语言生态库迁移工具

80%+库迁移自动化率

背景

华为自研编程语言仓颉，是面向未来的国产编程语言。但作为一个新兴语言，它面临一个典型的冷启动问题：

社区人少 → 生态薄弱 → 开发者不愿来 → 社区更小

生态的核心是库。开发者选择一门语言，首先看的是：有没有我需要的库？能不能直接用？如果什么都得自己写，那还不如用成熟的语言。

仓颉需要把其他语言（Java、Python、Go 等）的成熟库迁移过来，用仓颉重新实现。但问题是：

人工迁移太慢。 一个中等规模的库，人工迁移需要数周。
语言太新，AI 不会写。 仓颉的训练语料极少，大模型几乎没见过这门语言。
文档分散，理解困难。 仓颉的语法、标准库、编译器特性都在不同地方，开发者需要反复查阅。

我们接到的任务是：做一个工具，让 AI 能自动把其他语言的库迁移到仓颉。

挑战

这个任务的核心挑战是：AI 不会写仓颉代码。

大模型的训练数据里几乎没有仓颉的代码。直接让 AI 翻译，结果大概率编译不过。

我们需要解决三个问题：

知识注入： 怎么让 AI 学会仓颉的语法和特性？
代码理解： 怎么让 AI 理解源语言库的逻辑？
质量保证： 怎么确保生成的代码能编译通过、功能正确？

方案

我们的方案是：RAG + Agent + 多轮自检。

第一步：知识注入（RAG）

把仓颉的全量文档（语言规范、标准库文档、编译器文档、示例代码）全部入库，建立向量索引。

当 AI 需要写某个功能时，先检索相关文档，获取最新的语法和 API 信息。

关键点：

文档版本自动同步，仓颉更新后 RAG 知识库自动更新
支持多语言文档检索，同时检索仓颉文档和源语言文档

第二步：代码理解与迁移（Agent）

这一步参考了多篇学术论文的方法：

Codex（OpenAI, 2021） 的代码生成思路：将任务分解为子任务，逐步生成
AlphaCode（DeepMind, 2022） 的大规模采样策略：生成多个候选方案，筛选最优
CodeRL（Salesforce, 2022） 的强化学习反馈：用编译结果作为奖励信号，迭代优化
Self-Debug（Meta, 2023） 的自调试能力：让模型根据错误信息自我修正

具体流程：

解析源代码： 用 AST（抽象语法树）解析源语言库的代码结构，提取函数、类、依赖关系
任务分解： 将整个库的迁移任务分解为多个子任务（逐个函数/类迁移）
上下文注入： 为每个子任务注入相关文档（仓颉语法、源语言语义、已有迁移结果）
代码生成： 基于上下文生成仓颉代码

第三步：多轮自检（Self-Refine）

生成的代码不会一次就对。我们做了多轮自检机制：

编译检查： 调用仓颉编译器，检查是否能编译通过
错误分析： 如果编译失败，分析错误信息，定位问题
自动修正： 将错误信息反馈给 AI，让它自我修正
重复迭代： 最多迭代 5 轮，直到编译通过或确认无法修复

这个机制是关键。 单次生成的编译通过率只有 40% 左右，但经过多轮自检后，通过率提升到 85%+。

技术细节

工具链集成

编译器集成： 直接调用仓颉编译器 API，实现实时编译检查
测试框架： 自动生成单元测试，验证功能正确性
版本管理： 迁移结果自动提交到 Git，支持回滚和对比

知识注入策略

除了 RAG 检索文档，我们还做了：

Few-shot 示例： 从已迁移成功的库中提取示例，作为新库迁移的参考
错误模式库： 收集常见的编译错误和修复方法，加速自检过程
API 映射表： 建立源语言 API 到仓颉 API 的映射关系

效果

核心指标：

库迁移自动化率： 80%+
编译通过率（多轮自检后）： 85%+
单库迁移耗时： 从数周压缩至数小时
已成功迁移项目数： 数十个
社区认可： 多个项目获社区贡献奖、贡献之星

这些迁移的项目包括多个大型项目，涵盖了基础工具库、数据结构库、网络库等多种类型。迁移后的代码质量获得了社区认可，多个项目被收录为仓颉生态官方推荐。

为什么这个项目难

语言太新。 没有足够的训练语料，AI 不能直接写仓颉代码，必须靠 RAG 补充知识。
质量要求高。 库是基础设施，代码质量直接影响上层应用。不能"大概能用"，必须"可靠能用"。
需要深度理解。 不是简单的语法翻译，需要理解源语言库的设计意图，用仓颉的方式重新实现。

这正是我们擅长的：非标场景、复杂数据、不确定的技术路线。

写在最后

这个项目验证了一件事：AI 不会的东西，可以通过工程手段教会它。

RAG 解决知识问题，Agent 解决流程问题，多轮自检解决质量问题。三者结合，就能让 AI 完成原本不会的任务。

如果你有类似的"AI 不会做"的场景，欢迎来找我们聊聊。