论文基本信息 (Bibliographic Information)

• 标题 (Title): A systematic exploration of C-to-rust code translation based on large language models: prompt strategies and automated repair (基于大语言模型的 C 到 Rust 代码翻译系统性探索：提示策略与自动修复)
• 作者 (Authors): Ruxin Zhang, Shanxin Zhang, Linbo Xie。根据论文致谢部分，作者隶属于江南大学 (Jiangan University)。
• 发表期刊/会议 (Journal/Conference): 论文中提到了 Springer Science+Business Media, LLC，这是一家学术出版机构，而非具体的期刊或会议名称。从论文的格式和内容来看，它很可能是一篇期刊文章的草稿或预印本。
• 发表年份 (Publication Year): 论文中标注的接收、接受和发表日期均为未来的 2025 年。这是一个非常特殊的情况，表明此文档可能是一份预印本 (pre-print)、学术课程作业，或是一个概念性的草稿，而非已正式发表的文献。
• 摘要 (Abstract): 论文提出了一种名为 RustFlow 的 C 到 Rust 代码翻译框架。该框架基于大语言模型 (LLM)，采用一种多阶段渐进式架构，依次执行翻译、验证和修复。在翻译阶段，它使用一种协同提示策略 (collaborative prompting strategy) 来引导 LLM 进行跨语言的语义对齐。在验证与修复阶段，它结合了语法和语义检查，并通过一种对话式迭代修复策略 (conversational iterative repair strategy) 来提升代码质量。实验表明，RustFlow 的性能相比基线 LLM 平均提升了 50.67%，为跨语言代码迁移提供了新的技术方案。
• 原文链接 (Source Link): 论文的来源为本地文件路径 /files/papers/68ff2d077935f6c46cd14c20/paper.pdf。根据上述发表年份的分析，该论文目前很可能尚未在任何公开、同行评审的渠道正式发表。

整体概括 (Executive Summary)

研究背景与动机 (Background & Motivation - Why)

• 核心问题： C 语言因其底层灵活性被广泛应用于系统编程，但其手动的内存管理方式带来了严重的安全隐患，尤其是内存安全漏洞 (memory safety vulnerabilities)。Rust 语言通过其所有权系统和借用检查器提供了内存安全的保证，成为理想的替代品。然而，将海量的存量 C 代码手动迁移到 Rust 是一项成本高昂、技术要求极高的任务。
• 重要性与挑战： 自动化代码迁移是解决这一问题的关键。现有的自动化工具主要分为两类：
  1. 基于规则的工具 (Rule-based tools): 如 C2Rust，它们依赖预设规则进行语法转换，但在处理 C 语言中复杂的指针操作、宏定义和未定义行为时，往往无法生成符合 Rust 安全保证的、地道的代码。
  2. 基于大语言模型的方法 (LLM-based methods): 尽管 LLM 在代码理解和生成方面表现出巨大潜力，但它们在直接翻译时仍会引入各种错误，如 API 不匹配、数据类型错误等，导致生成的代码无法编译或在语义上与原始代码不一致。
• 切入点与创新思路： 本文的切入点在于，如何系统性地引导和约束大语言模型，使其不仅仅是进行表面的语法替换，而是能深入理解代码的结构与语义，从而生成高质量、安全且符合 Rust 编程范式的代码。其核心创新思路是构建一个端到端 (end-to-end) 的、包含翻译-验证-修复闭环的自动化框架 RustFlow。

核心贡献/主要发现 (Main Contribution/Findings - What)

• 主要贡献：

  1. 提出了 RustFlow 框架： 一个模块化的、端到端的自动化 C-to-Rust 代码翻译框架，整合了翻译、验证和修复三个核心阶段，实现了从 C 源码输入到经过验证的 Rust 代码输出的全流程自动化。
  2. 提出了协同提示策略 (Collaborative Prompting Strategy): 创新地结合了思想链 (Chain-of-Thought, CoT) 和小样本提示 (Few-shot Prompting)。通过引入程序抽象语法树 (AST)、LLVM IR 等作为中间表示，引导 LLM 进行更深层次的结构化推理，提升了翻译的准确性。
  3. 设计了双层验证与修复流水线 (Two-level Validation and Repair Pipeline): 利用 rustc 编译器进行语法验证与修复，并基于增强的差分模糊测试 (differential fuzzing) 工具进行语义验证与修复，形成了一个自动化的质量保证闭环。
  4. 引入了基于参数调优的多轮生成策略 (Multi-round Generation Strategy): 通过调整解码参数 (如 temperature) 生成多个不同的候选翻译，扩大了模型的搜索空间，提升了找到正确翻译的概率。

• 关键发现： RustFlow 框架显著优于现有的基线方法，相比基础的 LLM，其翻译性能平均提升了 50.67%。这证明了通过精巧的提示工程和自动化的修复循环，可以大幅提升大语言模型在复杂代码翻译任务上的准确性和可靠性。

预备知识与相关工作 (Prerequisite Knowledge & Related Work)

基础概念 (Foundational Concepts)

• 大语言模型 (Large Language Models, LLMs): 指的是像 GPT-4、Claude 3 这样在海量文本和代码数据上预训练过的深度学习模型。它们能够理解和生成类似人类语言的文本，并在代码生成、翻译和补全等任务中展现出强大的能力。
• 提示工程 (Prompt Engineering): 指的是设计和优化输入给 LLM 的文本（即“提示”），以引导模型产生期望输出的艺术和科学。本文的核心就是一种高级的提示工程。
  • 小样本提示 (Few-shot Prompting): 在提示中给 LLM 提供几个完整的任务示例（输入和对应的输出），让模型“照猫画虎”，学习任务的模式和期望的输出格式。例如，在代码翻译任务中，提供几个 C 代码到 Rust 代码的成功翻译案例。
  • 思想链 (Chain-of-Thought, CoT): 引导 LLM 在给出最终答案前，先输出一系列中间的、逻辑连贯的推理步骤。这有助于模型分解复杂问题，提高在推理任务上的准确性。本文通过让模型先生成中间表示 (Intermediate Representation, IR)，再翻译成目标代码，就是一种 CoT 的应用。
• 中间表示 (Intermediate Representation, IR): 在编译器技术中，IR 是一种介于源代码和目标机器码之间的数据结构或代码形式。它抽象了编程语言的细节，专注于程序的结构和逻辑。
  • 抽象语法树 (Abstract Syntax Tree, AST): 以树状形式表示代码的语法结构。每个节点代表代码中的一个构造，如表达式、语句等。AST 忽略了代码中的标点符号等次要细节，精确地捕捉了代码的层次结构。
  • LLVM IR: 一种用于现代编译器的底层 IR。它是一种静态单赋值（SSA）形式的类汇编语言，具有良好的可移植性和优化能力。使用它作为中间表示，可以帮助模型理解更底层的程序控制流和操作。
• 模糊测试 (Fuzz Testing / Fuzzing): 一种自动化软件测试技术，通过向程序提供大量随机或半随机的输入（“模糊数据”），来监测程序是否出现崩溃、断言失败或其他异常行为，从而发现潜在的 bug。差分模糊测试 (Differential Fuzzing) 是其变种，用于比较两个功能相似的程序（如原始 C 代码和翻译后的 Rust 代码），通过提供相同的随机输入并检查它们的输出是否一致，来验证其语义等价性。

前人工作 (Previous Works)

作者将自动化代码翻译技术分为两类：

1. 基于规则的代码翻译 (Rule-based Code Translation):

   • 代表工具: C2Rust, Corrode, Crust。
   • 工作方式: 这些工具依赖于人工编写的、从源语言到目标语言的转换规则集。它们解析源代码（通常生成 AST），然后应用这些规则进行语法转换和部分语义映射。
   • 局限性: 它们像是一个“高级的查找替换”系统，对于 C 语言中高度依赖上下文的复杂特性（如指针运算、宏、未定义行为）处理能力有限，生成的 Rust 代码往往包含大量 unsafe 块，未能充分利用 Rust 的安全特性。

2. 基于 LLM 的代码翻译 (LLM-based Code Translation):

   • 代表研究:
     • $Tao et al. (2024)$ 提出了中介翻译 (intermediary translation) 的概念，即先将源语言翻译成一个“中介语言”（如 Go），再从中介语言翻译到目标语言，发现这可以提升翻译质量。
     • Yang et al. (2024a) 提出了 VERT 框架，它利用 WebAssembly 作为“预言机 (Oracle)”来验证翻译后 Rust 代码的语义正确性。
     • Eniser et al. (2024) 提出了 FLOURINE 工具，其核心思想与本文类似，也使用了模糊测试来验证和修复语义错误。本文的工作可以看作是在 FLOURINE 的基础上进行了扩展和改进。
     • Hong and Ryu (2025) 专注于 C 到 Rust 翻译中的类型迁移 (type migration) 问题，通过让 LLM 预先生成多种可能的函数签名来辅助翻译。

技术演进 (Technological Evolution)

代码翻译技术从早期的基于规则的、侧重语法的转换，演进到了当前基于 LLM 的、更侧重语义理解的生成。早期的工具更像是一个“翻译器”，而现代的方法更像是一个“程序员助理”。LLM 的出现使得模型能够学习到两种语言之间更深层次的编程范式和地道用法，而不仅仅是语法的对应关系。

差异化分析 (Differentiation)

与上述相关工作相比，本文 RustFlow 的核心创新点在于系统性的整合与深化：

• 更丰富的中间表示: Tao et al. 只用了另一种高级语言 (Go) 作为中介，而 RustFlow 扩展到了更结构化的 AST 和 LLVM IR，这能为 LLM 提供更细粒度的代码结构信息。
• 更精巧的提示策略: RustFlow 不仅使用了 CoT 和 few-shot，还将其整合成一个协同提示策略，并设计了多模态的示例（包含代码、错误信息、测试结果），为 LLM 在翻译和修复的不同阶段提供最合适的引导。
• 更全面的生成策略: 传统的修复方法是“深度”优先（反复修改一个答案），RustFlow 引入的多轮生成策略增加了“广度”探索，通过生成多个不同风格的候选答案，增大了找到正确解的概率。
• 更完善的自动化闭环: RustFlow 整合了语法检查（使用编译器）和语义检查（使用模糊测试）于一个统一的、迭代修复的框架中，实现了更高程度的自动化。

方法论 (Methodology - Core Technology & Implementation Details)

RustFlow 的核心是一个多阶段渐进式的翻译、验证与修复流水线。其完整流程如下图所示：

该图像是论文中第3/4部分的示意图，展示了C到Rust代码翻译流程的语义验证与修复阶段及最终输出。流程包含初始翻译、多候选Rust代码生成、语法及语义错误检测与修复、模糊测试及最终结果选择。

方法步骤与流程 (Steps & Procedures)

1. 初始翻译 (Initial Translation)

这是整个流程的起点。其目标是利用 LLM 生成一个或多个初始的 Rust 代码候选版本。此阶段采用了多种策略来提升生成质量。

• 协同提示策略 (Collaborative Prompting Strategy):

  1. 基于中间表示的思想链 (CoT): 提示 LLM 不要直接从 C 翻译到 Rust，而是先生成一个中间表示。这个中间表示可以是：
     • 结构化表示: AST 或 LLVM IR。这些由 Clang 工具链预先生成，并作为参考信息嵌入到提示中。
     • 高级语言: 如 Go 语言（受 Tao et al. 启发）。
     • 自然语言解释: 描述 C 代码的功能和逻辑。 直觉 (Intuition): 这个中间步骤迫使 LLM 先“理解”C 代码的结构和逻辑，再进行“表达”，从而减少直接翻译带来的表面性错误。
  2. 小样本提示 (Few-shot Prompting): 在提示中提供完整的 C -> 中间表示 -> Rust 的翻译范例，帮助 LLM 学习映射关系和 Rust 的地道写法。

• 基于参数调优的多轮生成策略 (Multi-round Generation Strategy):

  • 原理: 与其只让 LLM 生成一个答案，不如让它生成多个。为了避免生成的答案过于相似，该策略在每次生成时调整 LLM 的解码参数，主要是温度 (temperature)。

  • 温度 (Temperature): 这个参数控制生成结果的随机性。温度越高，LLM 倾向于选择概率较低的词元 (token)，生成更多样、更有创意的结果；温度越低，LLM 倾向于选择概率最高的词元，生成更确定、更保守的结果。

  • 流程: 如图 6 所示，框架会调用 LLM 多次（例如 3 次），每次使用不同的温度值（如 0.2, 0.6, 1.0），从而得到一组结构和风格可能存在差异的候选 Rust 代码。这增加了“广度”搜索。

    该图像是一个示意图，展示图6中基于参数调优的多轮生成策略。图中从C代码通过LLM生成中间表示（如Go），并平行生成多个Rust代码候选，通过迭代修复选择最终正确Rust代码。

2. 语法验证与修复 (Syntax Validation and Repair)

• 验证: 将初始翻译阶段生成的每个候选 Rust 代码交给 Rust 官方编译器 rustc 进行编译。
• 修复: 如果编译失败，系统会自动捕获 rustc 输出的错误信息。这些错误信息质量很高，通常包含错误原因和修复建议。
• 修复提示: 系统将原始的 Rust 代码和 rustc 的错误信息一起打包成一个新的提示，要求 LLM 进行修复。这里同样使用了小样本提示，即提供“有问题的代码 + 错误信息 -> 修复后的代码”的范例。
• 批量修复 (Batch-style Repair): 与逐条修复错误不同，该框架将编译器报告的多个错误一次性提供给 LLM，让其进行综合修复。这能提高效率，并帮助 LLM 理解错误之间的关联，避免修复一个错误时引发另一个错误。

3. 语义验证与修复 (Semantic Validation and Repair)

通过语法验证的代码，只能保证它“是合法的 Rust 代码”，但不能保证其功能与原始 C 代码一致。此阶段旨在解决这个问题。

• 验证:

  • 工具: 采用了一个基于 Eniser et al. (2024) 工作的增强型差分模糊测试工具。
  • 工作流程: 该工具同时运行原始的 C 函数和翻译后的 Rust 函数，向两者输入大量相同的随机数据，然后比较它们的输出。
  • 增强点:

    1. 稳定性增强: 原工具有时会因 C 代码崩溃而终止测试。作者通过在 C++ 包装层中加入 try-catch 机制，并返回一个状态参数，使得即使 C 函数内部出错，测试流程也能继续，从而提高了测试的稳定性和覆盖率。

    2. 报告结构化: 对模糊测试的输出报告进行了格式优化（如图 2 所示），清晰地分类了有返回值和无返回值的函数测试结果，并展示了可变参数的状态变化，使其更具可读性，便于 LLM 理解。

       该图像是包含带返回值和不带返回值的成功与失败用例结构示意的代码片段，展示了实际输出与期望输出的比较逻辑，未含公式。

• 修复:

  • 如果检测到语义不一致（例如，对于相同的输入，C 和 Rust 函数返回了不同的结果），系统会从失败的测试用例中随机抽取几个，并将其格式化成提示的一部分。
  • 对话式迭代修复: 这个过程是可迭代的。修复后的代码会再次进入语义验证阶段，如果仍然存在问题，系统会带着新的失败用例和历史对话记录 (history module) 再次请求 LLM 修复。这种多轮对话的方式能帮助 LLM 逐步逼近正确的语义。

4. 最终输出 (Final Output)

经过上述所有阶段后，能够通过所有语法和语义验证的 Rust 代码被视为最终的成功翻译结果。如果有多个候选代码都通过了验证，系统会选择其中一个（例如第一个通过的）作为最终输出。

数学公式与关键细节 (Mathematical Formulas & Key Details)

论文的核心在于其框架和策略，没有引入复杂的数学模型。但其 prompt 设计中的约束条件非常关键，体现了对两种语言差异的深刻理解。

• 安全性约束 (Safety): 明确指示 LLM "avoid generating unsafe code" (避免生成 unsafe 代码)。这会引导模型使用 Rust 的安全抽象（如引用 &、切片 &[]）来替代 C 的裸指针 *。
• 语义一致性约束 (Semantic Consistency):
  • 整数溢出 (Integer Overflow): C 语言的整数溢出是环绕（wrap-around）行为，而 Rust 在调试模式 (Debug mode) 下会直接崩溃 (panic)。为了模拟 C 的行为，提示中要求 LLM 使用 $wrapping_*$ 系列方法（如 wrapping_add）来进行算术运算，以确保语义一致性。这是一个非常重要的细节。
  • 公式示例 (Conceptual):
    • C code: return a + b; (int32_t)
    • Rust (direct translation): $a + b$ -> a + b (panics on overflow in debug)
    • Rust (with constraint): a.wrapping_add(b) -> a.wrapping_add(b) (wraps around on overflow)

实验设置 (Experimental Setup)

数据集 (Datasets)

作者选取了两类共三个数据集来评估 RustFlow 的性能，重点关注结构简单、无外部依赖的小规模函数，因为即使在这种情况下，保证语义一致性也极具挑战。

• 数据集来源与特点:

  1. 真实世界项目 (Real-world projects):
     • opl 和 libopenaptx: 这部分代码来自真实项目，具有更高的复杂度和代码规模。
  2. 编程竞赛平台 (Programming competition platform):
     • cpw: 这部分代码来自编程题，结构简洁，主要涉及基础算法和数据结构。

• 数据集统计数据 (转录自 Table 1): 为了让读者直观理解数据形态，以下是论文 Table 1 的完整转录。Samples 指的是一个完整的翻译单元（可能包含多个函数），$Max/Min/AvgLoc$ 指的是每个样本的最大/最小/平均代码行数，$Max/Min/AvgFunc$ 指的是每个样本包含的最大/最小/平均函数数量。

  Feature	opl	libopenaptx	cpw
  Samples	81	31	96
  MaxLoc	460	173	28
  MinLoc	19	13	13
  AvgLoc	67	69	23
  MaxFunc	15	9	1
  MinFunc	1	1	1
  AvgFunc	2.8	2.9	1

• 选择理由: 这两类数据集的组合可以全面评估框架在不同场景下的性能。真实世界项目的数据能检验框架处理实际复杂代码的能力，而编程竞赛数据则代表了许多现有研究中常用的评测基准。

评估指标 (Evaluation Metrics)

论文使用了两个核心指标来评估翻译质量，评估是在样本 (sample) 级别进行的，即一个样本内的所有函数都必须通过测试，该样本才算成功。

1. 编译成功率 (Compilation Success Rate)

   • 概念定义: 该指标衡量由 LLM 生成的 Rust 代码是否符合 Rust 的语法和类型系统规范，即能否被 rustc 编译器成功编译通过。它直接反映了翻译结果的语法正确性 (syntactic correctness)。
   • 数学公式: $$\text{Compilation Success Rate} = \frac{\text{Number of successfully compiled samples}}{\text{Total number of samples}}$$
   • 符号解释:
     • Number of successfully compiled samples: 成功通过 rustc 编译器编译的样本数量。
     • Total number of samples: 数据集中的总样本数量。

2. 计算准确率 (Computational Accuracy, CA)

   • 概念定义: 该指标衡量翻译后的 Rust 代码在功能上是否与原始 C 代码等价。它通过运行一组预定义的单元测试（在本文中是由差分模糊测试工具生成的测试用例）来检查在相同的输入下，两个版本的代码是否产生完全相同的输出。它直接反映了翻译结果的语义等价性 (semantic equivalence)。
   • 数学公式: $$\text{CA} = \frac{\text{Number of samples passing all semantic tests}}{\text{Total number of samples}}$$
   • 符号解释:
     • Number of samples passing all semantic tests: 所有函数均通过了语义一致性测试的样本数量。
     • Total number of samples: 数据集中的总样本数量。

对比基线 (Baselines)

为了验证 RustFlow 的有效性，论文将其与以下几个具有代表性的最新方法进行了比较：

• FLOURINE (Eniser et al. 2024): 一个同样采用模糊测试进行语义验证和修复的端到端 C-to-Rust 翻译工具，是本文最直接和最强的竞争对手。

• VERT (Yang et al. 2024a): 一个利用 WebAssembly 来验证语义等价性的 Rust 代码生成框架。

• $Tao et al. (2024)$: 提出使用中介语言（如 Go）进行翻译的方法。

• Claude3_base: 直接使用 Claude 3 模型进行零样本 (zero-shot) 翻译，不使用任何本文提出的提示策略或修复流程。这用于衡量 RustFlow 框架本身带来的增益。

  实验统一使用了 GPT-4 和 Claude 3 作为底层大语言模型。

实验结果与分析 (Results & Analysis)

本部分围绕论文提出的五个研究问题 (RQ) 展开。

RQ1: 整体翻译性能

• 核心结果分析: Table 2 展示了 RustFlow 与各基线在最终计算准确率 (CA) 上的对比。

  • 数据呈现 (转录自 Table 2):

    Tool	libopenaptx	opl	cpw
    FlOURINE	48.39	46.91	52.08
    VERT	41.94	43.21	65.63
    Tao et al.	51.61	50.62	56.25
    Claude3_base	35.48	39.51	39.58
    RustFlow	54.84	54.32	63.54

    注：表中加粗的数字代表该数据集上的最佳性能。

  • 结论:

    1. RustFlow 在两个真实世界数据集 (libopenaptx 和 opl) 上均取得了最佳性能 (SOTA)。
    2. 在编程竞赛数据集 (cpw) 上，RustFlow 的性能略低于 VERT，但仍然显著优于其他基线。这可能是因为 VERT 使用的 WebAssembly 预言机机制在处理这类算法逻辑清晰、依赖少的代码时特别有效。
    3. 相比 Claude3_base，RustFlow 在三个数据集上分别提升了 54.57%, 37.48%, 和 60.54%，这证明了 RustFlow 框架中的提示策略和修复机制带来了巨大的性能增益。
    4. 相比最接近的对手 FLOURINE，RustFlow 同样实现了全面超越，这凸显了其在初始翻译阶段采用的协同提示策略的有效性。

RQ2: 中介翻译的影响

• 核心结果分析: 实验比较了不使用中间表示 (None) 与使用 Go 语言、AST、LLVM IR、自然语言解释 (Explain) 四种中间表示的效果。
  • 数据呈现 (综合分析 Figures 7, 8, 9, 10):
    • 语法层面 (初始编译成功率):
      • 使用任何一种中间表示都比不使用要好。
      • 性能排序为：AST > LLVM IR > Go > Explain > None。例如，在真实世界数据集上，使用 AST 比不使用平均提升了 24.8%。
      • 原因分析: AST 和 LLVM IR 是最结构化的、最无歧义的代码表示，能为 LLM 提供最精确的程序结构信息，因此效果最好。Go 语言次之，而自然语言解释最为主观和模糊，因此提升最小。
    • 语义层面 (计算准确率):
      • 趋势与语法层面基本一致，AST 依然是表现最好的中间表示。
    • 与小样本提示的协同效应: 当引入 few-shot 示例后（Figs 9, 10），所有方法的性能都有提升，尤其是在初始编译成功率上提升更明显。这表明 few-shot 示例能帮助 LLM 更好地理解如何生成和利用这些中间表示。
  • 结论: 引入基于中间表示的 CoT 翻译机制能有效提升翻译质量。其中，AST 是最佳的中间表示形式。

RQ3: 多模态小样本提示的影响

• 核心结果分析: 实验比较了在修复阶段不使用 few-shot 提示（仅给出简单指令）和使用 few-shot 提示（提供包含错误信息或测试用例的修复范例）的效果。

  • 数据呈现 (分析 Figure 11):

    该图像是图表，展示了图11中少样本提示对编译成功率和计算准确率的影响。图中比较了不同模型（Claude3和GPT-4）在无修复、无少样本和有少样本三种提示策略下的表现差异。

    • 语法修复: 采用 few-shot 提示的修复策略，平均编译成功率比简单指令高 9.14%。
    • 语义修复: 采用 few-shot 提示，最终的计算准确率 (CA) 平均提升了 6.26%。

  • 结论: 在修复阶段引入结构化的、包含具体上下文（如编译器错误、失败的测试用例）的小样本示例，能显著提升 LLM 定位和修复错误的能力。

RQ4: 双层验证与修复流水线的影响

• 核心结果分析: 实验分析了进行 1 到 3 次修复迭代对翻译结果的影响。

  • 数据呈现 (分析 Figure 12):

    该图像是图表，展示了图12中不同修复次数下编译成功率和计算准确率的变化，对比了Claude3和GPT-4两个模型。随着修复次数增加，两项指标均呈现上升趋势。

    • 边际效益递减 (Diminishing Marginal Gains): 无论是语法修复还是语义修复，都表现出明显的边际效益递减现象。第一次修复带来的提升最大，后续修复的增益逐渐减小。
      • 语法层面: 第一次修复平均提升 7.06%，第二次 4.11%，第三次仅 1.33%。
      • 语义层面: 第一次修复平均提升 5.49%，第二次 3.57%，第三次 1.99%。

  • 结论: 自动修复流水线是有效的，但存在成本与效益的权衡。在实际应用中，可能进行 1-2 次修复是性价比较高的选择。此外，尽管语法修复能将编译成功率提升到 90% 以上，但语义修复的提升相对有限，说明实现语义等价仍然是 LLM 代码翻译的最大挑战。

RQ5: 多轮生成策略的影响

• 核心结果分析: 实验比较了生成 3 个候选方案时，采用固定 temperature 参数和采用不同 temperature 参数（[0.2, 0.6, 1.0]）的效果。
  • 数据呈现 (分析 Figure 13):