基于算法的 LLM 代码翻译新范式：解决意图丢失问题

基于算法的 LLM 代码翻译新范式

论文信息

原标题

Algorithm-Based Pipeline for Reliable and Intent-Preserving Code Translation with LLMs

主要作者及研究机构

Shahriar Rumi Dipto、Saikat Mondal、Chanchal K. Roy，均来自加拿大萨斯喀彻温大学（University of Saskatchewan, Canada）

APA 引文格式

Dipto, S. R., Mondal, S., & Roy, C. K. (2026). Algorithm-based pipeline for reliable and intent-preserving code translation with LLMs. In Proceedings of the 34th IEEE/ACM International Conference on Program Comprehension (ICPC '26). ACM.

其他关键信息

arXiv 版本：arXiv:2602.16106v1 [cs.SE]，发布时间 2026 年 2 月 18 日；实验复现包地址：https://github.com/sdipto7/llm-code-translation

一段话总结

这篇发表于 ICPC '26 的论文针对大语言模型（LLMs）直接进行代码翻译时易丢失程序意图、引发编译/运行时错误、功能一致性差的核心问题，提出了一种基于算法的代码翻译流水线。核心是在生成目标代码前先提取与语言无关的中间算法规范，精准捕捉程序的 I/O 合约、数据结构、数值规则等关键细节。研究在 Avatar 和 CodeNet 数据集上，利用 5 款主流 LLMs（DeepSeek R1/V3、Llama 4 Maverick、GPT-4o、Qwen2.5）开展 Python 与 Java 的双向翻译自动化配对实验。结果显示该流水线将代码翻译的微平均准确率从 67.7% 提升至 78.5%，100% 消除词汇/令牌错误，大幅降低各类编译和运行时错误。同时研究构建了统一的语言感知错误分类法，证实该方法能实现更可靠、保意图的代码翻译。

研究背景

在当下的软件工程领域，自动化代码翻译已经成为大语言模型（LLMs）最实用的应用场景之一。开发者们经常需要把 Python 代码转成 Java 做企业级开发，或是把 Java 遗留代码转成 Python 做快速迭代。LLMs 本应成为这个过程的'高效翻译官'，但实际使用中却频频'掉链子'。

举个很常见的例子：把一段 Java 的输入处理代码直接转成 Python 时，LLM 可能会错误地将 Java 的逐行输入解析成 Python 的单行输入，导致生成的代码出现数组索引越界错误——代码看似语法正确，却完全违背了原程序的意图，这种'意图丢失'的问题在直接翻译中比比皆是。

行业研究显示，高达 77.8% 的 LLM 直接翻译代码无法正常编译，或运行后输出错误结果，常见问题包括：数据类型处理错误、控制流逻辑偏差、I/O 行为不符、循环边界判断失误等。这些问题不仅让开发者需要花费大量时间调试，还会引入隐藏的程序缺陷，严重降低了大家对 LLM 代码翻译的信任。

之所以会出现这些问题，核心原因是：LLMs 在直接翻译时，更擅长模仿代码的表面语法模式，却容易忽略程序底层的算法意图——比如它能保留循环的结构，却可能搞错数值解析规则；能复制变量名，却可能弄混输入的读取方式。

而现有的代码翻译方法，也都没能从根本上解决这个问题，主要分为三类且各有缺陷：

规则基转译器：人工编写语言配对的转换规则，灵活性极差，面对不断更新的语言特性和编程风格，维护成本极高，生成的代码也往往不符合目标语言的惯用写法；
神经模型：基于海量代码语料训练，虽比规则基方法灵活，但仍缺乏对程序细微语义的对齐，容易遗漏边界场景，误用运算符和数据类型；
LLM 中心流水线：主流的做法是'先翻译，后修复'，比如利用编译器错误信息重译、生成测试用例验证后修改，却没有在翻译开始前就明确并强化原程序的算法意图。

这就像我们把一篇中文技术文档直接用翻译软件转成英文，软件能保证单词和语法大致正确，却可能因为不懂技术逻辑，把'循环边界'翻译成'循环边界线'，导致文档失去核心含义。而自然语言翻译中，处理差异大的语言对时，会用枢轴语言（比如中→英→德）做中转，保证翻译的准确性。受此启发，研究人员思考：能不能在代码翻译中，加入一个与语言无关的'算法枢轴'，先把原程序的核心意图提取出来，再基于这个意图生成目标代码？这就是这篇论文的研究起点。

创新点

这篇论文的核心价值在于打破了 LLM 代码翻译'直接映射'的传统思路，提出了全新的解决框架，其独特创新点主要有 4 个：

1. 提出两步式算法基翻译流水线，首次在推理阶段实现'意图先行，代码后生成'

区别于传统的单步直接翻译，该方法先让 LLM 提取原程序的语言无关算法规范，精准捕捉 I/O 处理、数据结构、数值规则、循环边界、输出格式等核心意图，再基于这个规范生成目标代码，从源头避免了意图丢失，而非事后修复错误。

2. 构建统一的语言感知错误分类法，标准化 LLM 代码翻译的错误分析

针对 Python 和 Java 双向翻译的场景，将编译时、运行时错误细分为明确的亚型，制定了统一的标注规则和优先级，解决了以往代码翻译错误分析'分类混乱、无法对比'的问题，为后续研究提供了标准化的分析工具。

3. 采用微平均准确率作为核心评估指标，更贴合工程实际

摒弃了简单的均等加权准确率计算方式，将所有实验样本池化计算，让大样本的实验结果贡献更多权重，更能反映算法在实际工程场景中的表现，避免了小样本带来的统计偏差。

4. 填补了 LLM 代码翻译'事前意图约束'的研究空白

现有研究要么是事后修复，要么是利用其他编程语言做中转，而该研究首次系统利用自然语言描述的语言无关算法作为中间表示，充分发挥 LLMs 的自然语言理解和推理能力，让代码翻译从'语法模仿'升级为'意图实现'。

研究方法和思路、实验方法

论文的研究方法遵循'问题定义→方案设计→实验验证→结果分析'的经典逻辑，整体实验设计严谨、变量控制到位，复杂的方法论被拆解为数据集准备、模型选择、翻译流水线设计、评估体系构建、错误分析设计 5 个核心步骤，其中创新的算法基流水线是核心，具体细节如下：

步骤 1：实验数据集准备

选用两款业界公认、经过预处理的代码翻译数据集，均包含 Python-Java 配对代码和配套的验证测试用例，支持全自动化的编译、执行和测试，保证实验的可复现性：

Avatar：平行语料库，包含 Java 和 Python 的竞赛编程解决方案，完美适配'静态类型→动态类型'的跨范式翻译研究，样本量：Python→Java 250 个，Java→Python 249 个；
CodeNet：大型多语言代码语料库，选取 Python 和 Java 子集，每个程序都关联问题描述和功能测试，覆盖更广泛的算法任务，样本量：双向各 200 个。

步骤 2：实验模型选择

选取 5 款主流 LLMs，覆盖商业/开源、不同架构、不同定位，均在 BigCodeBench 和 OpenRouter 2025 年 5 月排名中位居前列，保证实验结果的代表性：

DeepSeek R1：推理导向模型，强化学习训练，作为结构化问题解决的基线；
DeepSeek V3：混合专家（MoE）模型，代码/数学任务 SOTA，作为顶级开源参考；
Llama 4 Maverick：通用开源模型，未专门针对代码调优，衡量通用开源模型的表现；
GPT-4o：商业闭源模型，零样本代码任务表现优异，作为商业 SOTA 参考；
Qwen2.5（72B-Instruct）：大参数量稠密模型，长上下文 + 强代码/数学能力，作为高端基线。

步骤 3：两种翻译流水线设计（核心创新部分）

设计直接翻译和算法基翻译两条平行流水线，固定提示词、解码参数、输出要求，仅改变翻译流程，保证对比的公平性，均采用思维链（CoT）提示词引导模型推理：

流水线 A：直接翻译（传统方法，基线）

单步生成：将源语言代码输入 LLM，通过固定提示词引导模型分 4 步分析（结构分析→语言构造映射→代码生成→仅输出目标代码），直接生成目标语言代码，镜像工业界最常用的 LLM 代码翻译方式。

流水线 B：算法基翻译（论文提出的创新方法）

两步式生成，核心是插入语言无关算法提取步骤，分两个阶段完成：

阶段 1：算法提取：将源语言代码输入 LLM，通过结构化提示词引导模型提取仅包含核心意图的算法规范，要求明确 I/O 处理、数据结构、数值规则、循环边界、逻辑流等，仅输出算法，无任何代码；
阶段 2：代码生成：将提取的算法输入同一 LLM，通过专用提示词引导模型分 4 步实现（算法分析→目标语言架构设计→代码生成→仅输出目标代码），要求模型基于算法生成符合目标语言惯用写法的代码，而非逐行映射源代码。

步骤 4：评估体系构建

制定严格的正确性判定标准和科学的性能指标，保证实验结果的客观性：

正确性判定：翻译代码需同时满足 3 个条件才判定为正确，缺一不可：①编译成功；②运行无异常、无超时（如无限循环）；③通过数据集提供的所有测试用例；
核心性能指标：微平均准确率，公式为 Acc_micro(S) = Σ(K_c) / Σ(N_c)，其中 S 为实验组合，K_c 为正确样本数，N_c 为总样本数；
失败类型划分：将翻译失败分为 4 类：编译时错误、运行时错误、测试仅不匹配（编译运行正常，结果错误）、超时。

步骤 5：错误分析设计

构建统一的语言感知错误分类法，并通过严格的标注流程保证一致性：

错误细分：将编译时错误分为 7 个亚型（如结构与声明问题、导入解析错误），运行时错误分为 6 个亚型（如解析与类型转换、依赖与入口点错误）；
标注流程：①编写标注手册，明确每个错误亚型的定义、包含/排除规则、案例；②双标注者独立标注试点样本；③计算 Cohen's Kappa 系数（本研究达 89.3%，远超 70% 的合格阈值）；④解决分歧，冻结分类法；⑤标注全部样本，按'编译时错误优先于运行时错误'原则，避免重复标注。

整体实验执行逻辑

对模型×数据集×翻译方法×翻译方向的所有组合，执行全自动化的实验流程：输入源代码→生成目标代码→编译→执行→测试→记录结果→错误标注，最终收集所有组合的结果进行多维度对比分析。

主要成果和贡献

一、核心实验成果（大白话版）

这篇研究的实验结果非常直观，核心就是'准确率大幅提升，核心错误显著减少'，用实实在在的数字证明了算法基流水线的有效性：

整体准确率飙升：所有实验样本的微平均准确率从直接翻译的 67.7%，提升至算法基方法的 78.5%，绝对提升 10.8%，且在所有模型、数据集、翻译方向上表现更稳定，没有出现大幅波动；
编译时错误近乎'团灭'：100% 消除了词汇和令牌错误（比如非法字符、意外令牌）；不完整结构错误（比如未闭合的大括号）减少 72.7%；结构与声明问题（比如 Java 类的脚手架缺失）减少 61.1%；
运行时错误大幅降低：依赖与入口点错误（比如 Java 缺少 main 方法、Python 模块导入失败）减少 78.4%，这是工程中最常见的'启动失败'问题；解析与类型转换、索引越界等核心错误也有不同程度降低；
不同模型表现各有亮点：
- DeepSeek R1：整体最优，在所有场景中准确率最高，编译失败率近乎为 0，是算法基方法的'最佳搭档'；
- Llama 4 Maverick：相对提升最大，Python→Java 方向的准确率从 36.8% 飙升至 70.4%，完美解决了通用开源模型直接翻译的'拉胯'问题；
- GPT-4o：因直接翻译基线本就很高（准确率接近 90%），提升幅度较小，但在 Java→Python 方向仍有明显收益；
- Qwen2.5：表现混合，部分场景因算法移除了其依赖的令牌级线索，准确率略有下降，提示算法提取的细节完整性仍需优化。

二、错误分布核心发现

通过统一的错误分类法，研究明确了 LLM 代码翻译的'错误重灾区'，为后续优化指明了方向：

运行时错误：解析与类型转换错误占比 55%，是头号问题（比如输入解析方式错误、数值类型转换偏差）；其次是依赖与入口点错误（19.3%）；
编译时错误：结构与声明问题占比 54.6%，是头号问题（比如 Java 缺少类/方法声明、Python 缩进错误）；其次是导入/命名空间解析错误（13.6%）。

三、研究贡献（领域价值）

这篇论文不仅提出了一个可落地的方法，更从理论、方法、实践、数据四个维度为 LLM 代码翻译领域带来了实实在在的价值：

理论贡献：提出了'意图先行，代码后生成'的 LLM 代码翻译新范式，填补了该领域'事前意图约束'的研究空白，改变了以往'先翻译后修复'的被动思路；
方法贡献：提供了一套可复现的算法基翻译流水线，配套统一的语言感知错误分类法，为后续 LLM 代码翻译的研究提供了标准化的实验和分析工具；
实践贡献：为软件工程界提供了可直接落地的 LLM 代码翻译工作流，仅需增加一步算法提取，就能大幅减少调试成本，提升代码翻译的可靠性；
数据贡献：发布了完整的实验复现包（https://github.com/sdipto7/llm-code-translation），包含提示词模板、实验代码、错误标注数据，让后续研究可以快速复现和扩展。

四、核心研究问题（RQ）、对比实验、结论汇总表

研究问题（RQ）	对比实验设计	核心结论
RQ1：算法基流水线相比直接一键翻译，能在多大程度上提升代码翻译性能？	所有模型×数据集×翻译方向的配对实验，对比两种方法的微平均准确率、编译/运行/测试失败率	算法基方法将微平均准确率从 67.7% 提升至 78.5%（+10.8%），在所有场景中表现更稳定，大幅降低编译和运行时错误
RQ2：两种翻译流水线中，编译时和运行时错误的分类法及频率分布是什么？	对所有失败样本进行统一错误标注，计算各错误亚型的占比和频率	运行时头号错误为解析与类型转换（55%），编译时头号错误为结构与声明问题（54.6%），超时错误极少可忽略
RQ3：算法基流水线在哪些场景/代码模式下，能减少或消除特定错误类型？	对比两种方法下各错误亚型的失败数量和占比，定义'缓解'为算法基方法错误率更低	对词汇/令牌、结构/声明、依赖/入口点等错误缓解效果显著；类型/重载解析错误因提前暴露问题略有上升，缺失状态错误因结构化略有增加

详细总结

本研究聚焦 LLMs 在自动化代码翻译中存在的意图丢失、错误频发问题，提出并验证了基于算法的代码翻译流水线，通过多维度实验与分析证实了该方法的有效性，为可靠、保意图的代码翻译提供了新范式，以下为详细研究脉络与结果：

一、研究背景与问题

代码翻译是 LLMs 的重要应用场景，被广泛用于代码复用、遗留系统迁移，但直接一键翻译存在显著缺陷：超 77.8% 的翻译代码无法编译或结果错误，易在控制流、类型处理、I/O 行为上出现问题，增加调试成本。
LLMs 虽能保留高层算法结构，但易丢失底层关键细节，导致语义错误；现有代码翻译方法分为三类，均未在推理阶段显式强化算法意图：规则基转译器灵活性差、神经模型语义对齐不足、LLM 中心流水线侧重事后修复而非事前约束。
受自然语言翻译中间枢轴语言启发，研究提出在代码生成前生成与语言无关的算法蓝图，从源头锁定语义保真度，填补现有研究空白。

二、研究设计与方法

研究通过配对实验对比直接翻译与算法基翻译的效果，围绕数据集、模型、翻译流水线、评估体系构建完整实验框架，具体如下：

实验数据集：选用两款主流代码翻译数据集，均包含 Python-Java 配对与验证测试用例，支持自动化评估：Avatar（Java-Python 竞赛编程平行语料）、CodeNet（大型多语言代码语料）。
实验模型：选取 5 款主流 LLMs，覆盖不同架构与定位：DeepSeek R1、DeepSeek V3、Llama 4 Maverick、GPT-4o、Qwen2.5-72B-Instruct。
评估体系：
- 正确性判定：翻译代码需同时满足编译成功、运行无异常/超时、通过所有测试才判定为正确；
- 性能指标：计算微平均准确率（池化所有实验样本，避免均等加权偏差）；
- 错误分析：构建统一的语言感知错误分类法，将失败分为编译时、运行时、测试不匹配、超时四类，通过双标注者、Cohen's Kappa 验证（达 89.3%，超 70% 阈值）保证标注一致性。

两种翻译流水线

流水线类型	核心步骤	提示词设计
直接翻译	单步将源语言代码直接生成目标语言代码，镜像工业界常用方式	采用分步思考提示，引导模型分析代码结构、映射语言构造，最终仅输出目标代码
算法基翻译	两步式：①提取与语言无关的算法（捕捉 I/O、数据结构、循环边界等）；②基于算法生成目标代码	先通过结构化提示提取算法，再用专用提示将算法转化为符合目标语言语法的代码，均仅输出核心结果

三、核心实验结果

研究围绕三个研究问题展开分析，核心量化与定性结果如下：

RQ1：算法基方法对翻译性能的提升效果
- 整体性能：算法基方法将微平均准确率从 67.7% 提升至 78.5%，绝对提升 10.8%，在所有模型、数据集、翻译方向上表现更稳定；
- 模型表现：DeepSeek R1 为算法基方法下最优模型，在所有场景中准确率最高；Llama 4 Maverick 相对提升最大，Python→Java 方向 Avatar 数据集准确率从 36.8% 升至 70.4%、CodeNet 从 58% 升至 87.5%；GPT-4o 因直接翻译基线高，提升幅度较小，但在 Java→Python 方向仍有明显收益；
- 错误整体变化：算法基方法大幅降低编译/运行时错误，Java 端编译错误近乎消除，运行时崩溃因 I/O 和类型错误修复显著减少。
RQ2：翻译错误的分类法与频率分布 超时错误极少故未纳入分析，解析与类型转换为运行时首要错误，结构与声明问题为编译时首要错误，具体分布如下：
- 运行时错误（总占比）：解析与类型转换（55%）>依赖与入口点（19.3%）>缺失状态与无效引用（12.7%）>索引/键访问（7.8%）>资源耗尽（4.5%）>算术错误（0.8%）；
- 编译时错误（总占比）：结构与声明问题（54.6%）>导入/命名空间解析（13.6%）>类型/重载解析（9.9%）>不完整结构（8.3%）>词汇和令牌错误（5.7%）>其他（5.3%）>字面量约束（2.7%）。
RQ3：算法基方法的错误缓解场景与模式 算法基方法对多数错误亚型实现显著缓解，仅少数错误未改善甚至暴露，核心缓解效果如下：
- 运行时错误：依赖与入口点错误从 89.2% 降至 10.8%（降幅 78.4%），解析与类型转换、索引/键访问等错误均有不同程度降低；缺失状态与无效引用错误小幅上升（47.1%→52.9%），因算法的结构化暴露了初始化和作用域问题；
- 编译时错误：100% 消除词汇和令牌错误，不完整结构从 86.4% 降至 13.6%（降幅 72.7%），结构与声明问题从 80.6% 降至 19.4%（降幅 61.1%）；类型/重载解析错误上升（34.6%→65.4%），因算法的显式 API 提前暴露了类型不匹配问题。

四、研究启示与应用建议

对从业者/工具开发者：应采用算法基翻译工作流，先让 LLM 生成包含输入处理、数据结构、数值规则、循环边界、终止条件、输出格式的算法，再生成目标代码，虽增加一次模型调用，但能消除大量可预防错误；
对规模化工程实践：将代码翻译设计为确定性流水线，对算法计划进行版本控制与自动验证，分离编译/运行/测试失败阶段，加速问题诊断，降低缺陷密度；
对研究者：剩余错误源于语义约束执行不足，未来可将算法设计为机器可检查形式，集成轻量级分析器（类型、索引、输出格式检查），结合算法引导生成与验证实现完全可靠的代码翻译。

五、研究的威胁与有效性

研究通过多种方法缓解了三类有效性威胁，保证结果的可靠性：

外部有效性：仅验证 Python/Java 语言对，但框架与语言无关，适配其他语言对的提示词和测试调整后可推广；
构造有效性：人工标注错误存在主观偏差，通过编写标注手册、双标注者试点、Cohen's Kappa 验证（89.3%）缓解；
内部有效性：固定提示词、解码参数，脚本化全工作流，使用固定随机种子，排除非算法步骤的干扰；算法质量为关键，通过固定算法提示词、拒绝规格不足的算法保证实验有效性。

六、相关工作与研究创新

传统代码翻译：规则基系统需手动编写大量规则，扩展性差；数据驱动方法从统计模型发展到 LLMs，但仍缺乏语义保真度；
LLM 代码翻译：现有方法侧重事后修复（如利用编译器错误重译、生成测试用例），未从源头强化模型对程序意图的理解；
代码生成中间表示：现有研究如思维链、程序辅助 LLMs 均未系统利用与语言无关的自然语言算法作为中间步骤，本研究填补了该空白，是首个在推理阶段通过算法蓝图主动保障语义保真度的研究。

七、研究结论与未来方向

核心结论：基于算法的流水线能有效解决 LLMs 直接代码翻译的意图丢失问题，以少量计算开销为代价，实现了准确率的显著提升与各类错误的大幅缓解，是可靠、保意图的代码翻译的通用范式；
未来方向：将框架扩展至更多语言对与多文件项目；集成属性基测试与语义测试；开发机器可检查的算法计划模式，实现自动化验证。

关键问题

问题 1（方法设计类）：该研究提出的基于算法的代码翻译流水线与传统 LLM 直接翻译流水线的核心区别是什么？为何该区别能解决直接翻译的意图丢失问题？

答案：核心区别在于算法基流水线增加了与语言无关的算法提取中间步骤，直接翻译是单步源语言代码到目标语言代码的生成，而算法基流水线为先提取捕捉程序 I/O 合约、数据结构、数值规则、循环边界等关键细节的算法，再基于该算法生成目标代码；该区别从源头锁定了程序的算法意图，避免 LLMs 仅从表面代码模式生成目标代码而丢失底层关键细节，同时让模型基于逻辑规格而非逐行映射生成代码，更易保证语义保真度，解决了直接翻译中因类型处理、I/O 语义、循环边界等细节偏差引发的意图丢失问题。

问题 2（实验结果类）：该研究中算法基代码翻译方法的核心性能提升数据有哪些？不同 LLM 在该方法下的表现有何差异？

答案：核心性能提升数据：①微平均准确率从 67.7% 提升至 78.5%，绝对提升 10.8%；②100% 消除编译时词汇和令牌错误；③72.7% 减少编译时不完整结构错误，61.1% 降低编译时结构与声明问题；④78.4% 减少运行时依赖与入口点错误。不同 LLM 表现差异：①DeepSeek R1 为整体最优模型，在所有数据集、翻译方向上准确率最高，编译失败率近乎为 0，是算法基方法下的最佳选择；②Llama 4 Maverick 相对提升幅度最大，因直接翻译中存在大量类型、循环边界错误，算法基方法对其修复效果最显著；③GPT-4o 因直接翻译基线本身较高，提升幅度较小，但在 Java→Python 方向仍有明显收益；④Qwen2.5 表现混合，依赖于数据集，部分场景因算法移除了其依赖的令牌级线索，准确率略有下降。

问题 3（应用与研究类）：该研究的成果对实际的软件工程代码翻译实践有哪些具体指导意义？同时为后续相关研究指明了哪些方向？

答案：对实际实践的指导意义：①从业者应放弃直接一键翻译，采用'算法提取→代码生成'的两步式工作流，生成算法时需覆盖输入处理、数据结构、数值规则等 6 个核心维度，将算法作为检查清单，拒绝规格不足的算法；②规模化工程中应将代码翻译设计为确定性流水线，对算法计划进行版本控制和自动验证，仅在算法通过检查后再生成目标代码；③分离编译、运行、测试失败的不同阶段，加速翻译错误的回归诊断，提升流水线的可维护性。对后续研究的方向指引：①针对剩余未缓解的错误（如类型/重载解析、缺失状态与无效引用），研发更强的语义约束机制，将算法设计为机器可检查的形式；②集成轻量级分析器（类型宽度、索引、输出格式检查），结合算法引导生成与自动化验证，进一步提升翻译可靠性；③将研究框架扩展至更多语言对（如 C/C++、Go、JavaScript）与多文件项目，验证方法的通用性；④开展算法提示词的优化研究，提升算法提取的完整性和准确性，解决 Qwen2.5 等模型中因算法规格不足导致的性能问题。

总结

本研究针对大语言模型直接进行代码翻译时存在的意图丢失、错误率高、可靠性差的核心问题，提出了一种基于算法的代码翻译流水线，该方法的核心是在生成目标代码前，先提取一个语言无关的中间算法规范，精准捕捉程序的 I/O 合约、数据结构、数值规则、循环边界等关键意图。研究在 Avatar 和 CodeNet 数据集上，利用 5 款主流 LLMs 开展了 Python 与 Java 的双向翻译自动化配对实验，通过严格的变量控制和标准化的评估体系，对比了直接翻译与算法基方法的效果。实验结果表明，算法基方法将代码翻译的微平均准确率从 67.7% 提升至 78.5%，100% 消除了词汇和令牌错误，大幅降低了不完整结构、结构与声明、依赖与入口点等核心错误；同时研究构建了统一的语言感知错误分类法，明确了 LLM 代码翻译的错误重灾区为解析与类型转换（运行时）和结构与声明问题（编译时）。该研究提出了'意图先行，代码后生成'的 LLM 代码翻译新范式，填补了事前意图约束的研究空白，为工程界提供了可落地的代码翻译工作流，也为后续研究提供了标准化的方法和可复现的实验包。尽管该研究仅验证了 Python 和 Java 的翻译场景，但框架具有语言无关性，通过简单的适配即可扩展至其他语言对，未来结合机器可检查的算法规范和轻量级分析器，将进一步提升 LLM 代码翻译的可靠性和自动化程度。

基于算法的 LLM 代码翻译新范式：解决意图丢失问题