💻 computer science

Validated Code Translation for Projects with External Libraries

本文提出了一种针对含外部依赖的 Go 项目向 Rust 迁移的翻译与验证框架，通过检索映射 API 和基于公开接口合成适配器来验证不透明类型，显著提升了代码编译成功率和语义等价性验证效果。

原作者： Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama

发布于 2026-02-24

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Hanliang Zhang, Arindam Sharma, Cristina David, Meng Wang, Brandon Paulsen, Daniel Kroening, Wenjia Ye, Taro Sekiyama

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

这篇论文讲述了一个关于**“如何把旧代码安全、准确地翻译成新语言”**的故事，特别是当这些代码里用了很多“外部工具包”（第三方库）的时候。

想象一下，你有一本用Go 语言（一种像乐高积木一样灵活的语言）写的古老操作手册，现在你想把它翻译成Rust 语言（一种像精密瑞士军刀一样严谨、安全的语言）。

但是，这个翻译过程遇到了两个巨大的拦路虎，而这篇论文提出了一套聪明的“翻译 + 质检”方案来解决它们。

🚧 遇到的两大难题

1. 翻译官的“幻觉”与“迷路”

问题：现在的 AI 翻译官（大语言模型，LLM）很聪明，但它有个坏毛病：当看到 Go 语言里调用了一个外部工具（比如“加密锁”）时，它可能会瞎编一个 Rust 里根本不存在的工具，或者叫错了名字。
更糟糕的是：即使它叫对了名字，它往往忘了**“怎么打开工具箱”**。在 Rust 里，调用一个功能前，必须先导入特定的“通行证”（Import）。AI 经常忘了给这些通行证，导致翻译出来的代码虽然看着像那么回事，但一运行就报错（无法编译）。
比喻：就像你让一个翻译官把“用钥匙开门”翻译成另一种语言。他可能瞎编了一把“魔法钥匙”，或者虽然说了“用钥匙”，却忘了告诉你钥匙在哪个抽屉里（Import），结果你拿着钥匙却打不开门。

2. 无法验证的“黑盒子”

问题：翻译完后，你怎么知道新代码和旧代码做出来的结果是一模一样的？通常的方法是让两个程序跑同样的测试。但是，如果代码里用了很多外部库定义的数据类型（比如加密密钥），这些数据在 Go 和 Rust 里长得完全不一样，甚至内部结构是**“黑盒子”**（Opaque，不可见）的。
比喻：想象 Go 语言里的数据是一个密封的罐头，Rust 语言里的数据是一个密封的盒子。你没法直接把罐头里的东西倒进盒子里对比。如果强行打开，可能会破坏里面的东西（因为外部库有严格的安全规则）。以前的方法要么不敢打开，要么打开后把东西弄坏了，导致无法验证翻译是否准确。

🛠️ 论文的解决方案：三步走策略

作者团队设计了一套名为 CrossCrate 的系统，就像给翻译官配了一个**“超级图书馆”和一个“万能转换器”**。

第一步：建立“超级图书馆” (RAG 检索增强)

为了解决“瞎编”和“迷路”的问题，他们给 AI 翻译官配了一个专属的 Rust 工具目录。

怎么做：当 AI 需要翻译 Go 里的某个功能时，系统先去这个“图书馆”里查：Rust 里哪个库最像？正确的名字叫什么？最重要的是，**需要导入哪些“通行证”（Import paths）**才能使用它？
比喻：以前 AI 是凭记忆瞎猜；现在，AI 每写一行代码，都要先查一下“字典”，字典不仅告诉它正确的工具名，还附上了**“使用说明书”**（比如：要调用这个功能，必须先引用 sha2 和 Digest 这两个包）。这样，AI 就不会编造不存在的工具，也不会忘记带“通行证”。

第二步：制造“万能转换器” (中间格式适配器)

为了解决“黑盒子”无法对比的问题，他们发明了一种中间语言（基于 Protobuf 的格式）。

怎么做：
1. Go -> 中间格式：先把 Go 里的“密封罐头”打开，把里面的内容提取出来，装进一个标准的**“透明塑料盒”**（中间格式）。
2. 中间格式 -> Rust：再把“透明塑料盒”里的内容，按照 Rust 的规则，重新装进 Rust 的“密封盒子”里。
关键点：这个“透明塑料盒”只包含最基础的数据（比如数字、字符串、字节流），不包含复杂的内部结构。这样，无论 Go 和 Rust 的“黑盒子”多复杂，只要能把它们变成这个“透明塑料盒”，就能安全地跨语言传输了。
比喻：就像你要把一种特殊的中国结（Go 数据）换成西方绳结（Rust 数据）。直接换很难，因为结构不同。于是，你先把它拆成绳子（中间格式），把绳子运过去，再在另一边用绳子重新编成西方绳结。这样既保证了绳子没丢，又解决了结构不同的问题。

第三步：双重质检 (验证与测试)

怎么做：
1. 往返测试：先测试“中国结 -> 绳子 -> 中国结”能不能还原？如果能，说明“拆包”过程没丢信息。
2. 结果对比：让 Go 程序和 Rust 程序都处理同样的“绳子”数据，看它们最后输出的结果是否一致。
比喻：就像你让两个厨师（Go 厨师和 Rust 厨师）用同样的食材（中间格式）做菜。如果两个厨师做出来的菜味道（输出结果）一模一样，那就证明翻译是成功的。

🏆 效果如何？

作者用 6 个真实的、复杂的 Go 项目（涉及加密、密码学等硬核领域）进行了测试。

以前：如果没有这套系统，AI 翻译出来的代码，编译通过率和功能正确率几乎为 0（因为全是幻觉和缺少的导入）。
现在：有了这套系统，编译通过率和功能正确率平均达到了 95% 以上，在某些复杂项目中甚至达到了 100%。
总结：这套方法让翻译的成功率翻了两倍（2x），让原本无法处理的“带外部依赖的复杂代码”也能被安全、准确地迁移到 Rust。

💡 一句话总结

这篇论文就像给 AI 翻译官发了一本带详细索引的工具书，并发明了一种通用的“快递盒”，让 AI 不仅能准确找到工具，还能安全地搬运数据，从而完美地把复杂的旧代码翻译成安全的新代码。

这是一篇关于带有外部依赖的项目代码翻译与验证的学术论文总结。该论文提出了一种名为 CrossCrate 的框架，旨在解决将 Go 项目（特别是那些重度依赖外部库的项目）翻译成 Rust 时面临的挑战。

以下是该论文的详细技术总结：

1. 研究背景与问题 (Problem)

随着大型语言模型（LLM）在代码翻译中的兴起，将系统级代码（如 Go）迁移到内存安全语言（如 Rust）成为热点。然而，现有的方法在处理依赖外部库的项目时存在两大核心瓶颈：

LLM 的幻觉与 API 映射失败：
- LLM 经常编造目标语言中不存在的库或 API。
- LLM 难以正确选择目标语言中的等效库（例如，Go 的 crypto/sha512 对应 Rust 的哪个 crate？）。
- 导入解析（Import Resolution）困难：Rust 的 API 可用性往往依赖于特定的 trait 作用域或复杂的重新导出（re-exports）。LLM 即使选对了 API，也常因缺少正确的 use 语句导致编译失败。
语义等价性验证困难：
- 当代码操作不透明（Opaque）的库定义类型（即私有字段、无法直接访问内部结构）时，传统的差分测试（Differential Testing）失效。
- Go 和 Rust 没有共同的运行时或值表示，无法直接交换数据。
- 现有验证方法通常假设输入/输出类型是结构相同的，或者依赖手写单元测试，无法处理复杂的库封装类型（如加密密钥对象）。

2. 方法论 (Methodology)

作者提出了一个两阶段的框架，结合了检索增强生成（RAG）和跨语言验证流水线。

阶段一：跨语言库映射与翻译 (Cross-Language Library Mapping)

为了解决 LLM 的幻觉和导入问题，系统引入了 RAG 机制：

Crate 级知识库构建：
- 预先为每个目标 Rust crate 构建知识库（Knowledge Base, $K_{crate}$ ）。
- 知识库不仅包含 API 签名，还包含调用所需的导入路径（Call-enabling imports），包括 trait 作用域和重新导出的路径。
- 数据结构化表示 Rust 文档，能够处理模块层级、pub use 重新导出和 trait 方法。
检索增强生成 (RAG)：
- 在翻译每个 Go 函数时，提取其调用的 Go API。
- 通过检索机制，从知识库中匹配最相关的 Rust API 候选项。
- 将检索到的 API 签名、文档以及正确的导入语句注入到 LLM 的提示词（Prompt）中，指导其生成可编译且语义正确的 Rust 代码。

阶段二：基于 Schema 的跨语言验证 (Cross-Language Validation)

为了解决不透明类型的验证问题，系统采用了一种基于中间载体（Carrier）的适配器合成策略：

Protobuf 中间表示 (IDF)：
- 利用 LLM 为源 Go 类型和目标 Rust 类型生成一个共享的、语言无关的 Protobuf Schema ( $T_{Proto}$ )。
- 该 Schema 将复杂/不透明的库类型保守地映射为字节数组（Byte Arrays），确保数据可在语言间传输。
适配器合成 (Adapter Synthesis)：
- 合成两组适配器：
  - Go $\leftrightarrow$ Proto：将 Go 类型序列化为 Protobuf 载体，反之亦然。
  - Rust $\leftrightarrow$ Proto：将 Rust 类型序列化为 Protobuf 载体，反之亦然。
- 关键约束：适配器的生成仅使用库的公开 API（如构造函数、序列化/反序列化例程），严禁直接访问私有字段。这保证了对于不透明类型的操作是合法的。
验证流水线：
- 往返检查 (Round-trip Check)：首先验证 Go $\to$ Proto $\to$ Go 是否无损，确保 Schema 和适配器保留了语义信息。
- 差分 I/O 等价性测试：利用验证过的适配器，将 Go 单元测试的输入转换为 Rust 可执行的格式，运行 Rust 翻译代码，再将输出转换回 Go 格式进行比较。如果 $f(v) = A^{-1}_{out}(g(A_{in}(v)))$ ，则视为等价。

3. 主要贡献 (Key Contributions)

首个解决外部依赖限制的翻译框架：这是首个能够处理具有结构不相似且不透明输入参数类型的函数等价性验证的代码翻译方法。
RAG 驱动的 API 映射：通过构建包含导入路径的 crate 级知识库，显著减少了 LLM 在外部库 API 选择上的幻觉，并解决了 Rust 特有的导入解析难题。
基于公开 API 的适配器合成：提出了一种通过 Protobuf 中间层和公开 API 合成跨语言适配器的方法，使得在不透明库类型存在的情况下也能进行严格的 I/O 等价性验证。
实证评估：在 6 个真实世界的 Go 仓库（包含加密、密码学等复杂依赖）上进行了评估，证明了该方法的有效性。

4. 实验结果 (Results)

作者在 6 个 Go 基准测试项目（如 age, pbkdf2, argon2-hashing 等）上评估了系统（称为 CrossCrate）：

编译成功率与等价性：
- 在包含外部依赖最重的案例中，成功率达到 100%。
- 平均编译成功率和等价性验证成功率均达到 95.83%。
- 相比基线方法（如 Oxidizer 或无 RAG 的 LLM），成功率提升了约 2 倍，在某些重度依赖案例中提升高达 100%。
消融实验 (Ablation Study)：
- 无 RAG (No RAG)：编译和等价性成功率降至 0%（对于依赖库的函数），证明知识库检索至关重要。
- 无导入解析 (No Imports)：即使有 RAG，如果缺少正确的导入路径生成，编译成功率也极低（约 33%-80% 不等，但等价性为 0），证明导入解析是必要组件。
对比基线：现有的 SOTA 工具 Oxidizer 在硬编码目标 crate 的情况下，面对复杂外部库时表现与“无 RAG"组相同，无法处理外部 API。

5. 意义与影响 (Significance)

推动系统代码迁移：为将遗留的 Go 系统代码安全、自动地迁移到 Rust 提供了可行的技术路径，特别是针对那些高度依赖第三方库的核心模块。
解决 LLM 幻觉问题：展示了通过结构化知识库和 RAG 技术，可以有效缓解 LLM 在专业领域（如特定编程语言的库 API）中的幻觉问题。
验证范式的创新：提出了一种不依赖结构同构、而是基于行为（I/O）和公开 API 约束的跨语言验证方法，为未来处理更复杂的跨语言互操作性问题提供了新思路。
实际可用性：该方法不仅关注代码生成，更强调“可验证性”，确保生成的代码不仅能编译，而且在行为上与源程序一致，这对于安全关键型系统（如加密库）的迁移至关重要。

总结：该论文通过结合 RAG 检索机制和基于 Protobuf 中间层的适配器合成技术，成功克服了 LLM 在翻译带有外部依赖的复杂项目时的幻觉和验证难题，实现了高成功率的 Go 到 Rust 的自动化迁移与验证。