上海交大浙大开源OdinEval：冷门语言修复实测，Kimi-K3成功率仅66.7%

原论文信息如下：

论文标题:
OdinEval: A Reproducible Benchmark for LLM-Based Program Repair in the Odin Programming Language

发表日期: 2026年08月
发表单位: 上海交通大学、浙江大学
原文链接: https://arxiv.org/pdf/2608.18595v1.pdf

引言

先问一个扎心的问题：当大模型跑去修代码的时候，我们到底在指望它做什么？

是让它把报错信息念一遍，还是让它对着一个真实的GitHub issue，在历史代码库上找到问题、打一个补丁、跑通测试、真正把行为修回来？答案显然是后者。但现实是，现存的仓库级代码修复基准大多盯着一亩三分地：Java有Defects4J，Python有BugsInPy和SWE-bench，稍微新一点的有多语言版本的Multi-SWE-bench。这些基准确实撑起了大模型修代码研究的半边天，可它们都有一个共性——都绕着主流语言打转。

那问题来了：如果换成Odin这种面向系统编程、主打数据导向设计、连构建方式和测试框架都高度自定制的冷门语言，大模型还能不能打？这正好是上海交通大学和浙江大学的研究者们想搞清楚的事情。他们搞了一个叫OdinEval的基准，专门用来评估大模型在Odin语言上的自动化修复能力。

这篇论文没有搞花里胡哨的模型排名宣传，而是老老实实把评测协议、数据构建流程、历史环境重建、测试构造方法、可复现性设计一项项讲清楚。更关键的是，他们在168个过滤后的真实issue上对比了6个大模型，最后发现了一个挺有意思的现象：复现问题（Repro）最强的模型，并不一定是真正把bug修好（Resolved）的模型。这个反差点到为止，却足够让不少人重新审视“评测指标到底该看什么”。

下面把这篇论文掰开揉碎来讲。先从为什么需要OdinEval说起。

Odin语言修复基准：为什么现有基准无法覆盖系统编程语言？

先梳理一下现有的仓库级修复基准都在干什么。

Defects4J是Java领域的老牌选手，从真实项目里挖出缺陷，配上测试套件，围绕缺陷做可控实验。BugsInPy把这个套路搬到Python上。SWE-bench更进一步，直接把GitHub上的真实issue和对应的代码仓库快照绑在一起，让模型根据issue描述去改代码。这些基准彼此之间有个共同假设：项目有相对统一的构建方式和测试入口。对Java和Python来说这个假设大致成立，Maven/Gradle、pip/pytest基本能覆盖绝大多数项目。

但Odin完全不是这么回事。Odin是一种面向系统编程的语言，设计上强调数据导向，编译器和工具链都是独立的一套。它的公开项目很可能没有统一的构建布局，没有标准的测试框架，甚至用什么编译器版本、通过什么脚本拉依赖、怎么执行测试，每个项目都可能不一样。如果你拿SWE-bench那套“切一个commit、跑一个pytest”的思路去套Odin项目，大概率会翻车——不是补丁打不上，就是环境根本跑不起来，或者测试入口压根找不到。

论文里点到一句大实话：一个补丁看起来修好了，可能是因为测试根本没跑起来，或者环境变了，或者断言本身复制了实现细节。这句话翻译过来就是，没有可执行环境背书，一切“看起来成功”都是耍流氓。

OdinEval的定位很清晰：它是个issue解决（issue-resolution）基准，只收录那些有文档化症状、有可追踪修复提交、有可复现执行路径的缺陷。大规模迁移、纯格式调整、版本升级、只追求性能提升的改动，统统不收。因为这类改动要么没法用一条命令验证，要么收进来只会让评测结果变得不可解释。

这里还有个细节值得注意：OdinEval把一个“issue”和“接受的实例”清楚地区分开了。一个issue可能对应多个commit，一个commit也可能解决多个症状。所以基准的基本单位是实例（instance），每个实例必须能明确说清楚一个修复目标和一个验证契约。这个设计比单纯按issue数或者commit数来算要严谨得多。

OdinEval构建流程：从issue到可复现的失败-通过测试对

先把话说透：现有仓库级修复基准之所以教不好大模型修Odin代码，核心原因不是语言难，而是评测的前提条件不成立。Java和Python项目能跑起来一套通用流程，是因为Maven、Gradle、pip、pytest这些工具把构建和测试的契约标准化了。Odin呢？它没有这种“标准答案”。每个项目都有自己的编译器版本、依赖获取方式、测试入口和运行脚本，甚至同一个项目在不同commit下的构建方式都可能不一样。这时候如果再拿SWE-bench那种“切commit、跑pytest”的套路硬套，结果就是：补丁表面看着合理，实际一跑就挂，挂了还分不清是代码问题还是环境问题。

论文里有一句话说得特别实在：“一个补丁看起来修好了，可能是因为测试根本没跑起来，或者环境变了，或者断言本身复制了实现细节。”这其实就是当前很多代码修复评测的隐形bug——只管补丁能不能打上去，不管行为到底有没有被修复。OdinEval的应对方式是：把“可执行的证据”作为每个实例的标配，没有证据的候选直接不收。

另外值得注意的一点是，OdinEval把“issue解决”作为基准的定位。它不收大规模重构、纯格式调整、版本升级这类改动，因为这些改动要么没法用一条命令验证行为变化，要么收进来只会让评测结果变得不可解释。这种克制在基准建设里其实很难得——很多基准为了凑数量什么都往里塞，最后评测指标看起来很高，但没人能说清楚模型到底学会了什么。

OdinEval构建流程：从issue到可复现的失败-通过测试对

OdinEval的基本单位不是issue也不是commit，而是实例（instance）。一个issue可能对应多个commit，一个commit也可能解决多个症状，所以每个实例必须能明确对应一个修复目标和一个验证契约。论文给每个实例定义了一个七元组数据结构，见下面公式：

其中q是文档化的issue描述，r_b是基础（缺陷）commit，r_f是修复commit，p_g是金标补丁（gold patch），t是针对该issue的回归测试，e是历史工具链和执行规范，m是审计清单。审计清单记录命令、容器摘要、返回码、测试输出、评审者决策和所有发布文件的校验和。

整个构建流程分两个刻意分开的阶段：自动化采集（candidate profiling）和人工语义筛选（semantic curation）。自动化采集阶段，一个分析器会记录候选仓库的URL、issue和PR标识符、可用文本、基础与修复commit、父子关系、变更文件路径、增删行数，以及仓库元数据中能找到的测试或构建命令。失败的信息也会被记录，而不是悄悄跳过。这个设计很关键：它能把“候选被筛掉”和“环境跑不起来”这两件事分开，避免后期分析时混淆。

人工语义筛选阶段，评审者按照书面规则判断候选是否满足四个条件：有文档化的症状或目标行为；该行为与历史变更之间有可追踪的关系；基础版本可执行或有可信的重建路径；存在可行的issue专属测试。补丁大小和Odin源文件占比只是参考信号，不是硬性标准——一个小补丁可能只是个重构，一个大补丁也可能只暴露一个可复现的行为。

图1展示了从公开issue到可复现的失败-通过测试对的完整构建路径。每个阶段都会增加最终基准工件可独立审计所需的证据。环境重建遵循保守原则：绝不用现代编译器悄悄替代历史版本，也绝不为了获得通过而把仓库级命令替换成更窄的命令。如果无法重建精确的历史工具链，这个实例就留在语料库之外，同时保留失败的重建清单供检查。

严格准入规则：如何确保测试真正区分缺陷与修复？

一个实例要被接受，必须满足下面这个硬性条件：

意思是：在同一个声明的环境e中，基础版本r_b加上测试t必须失败，而基础版本加上金标补丁p_g再加上测试t必须通过。这里有一个重要细节——基础版本的失败必须归因于文档化的行为缺陷，而不是补丁应用失败、依赖解析失败、编译失败、测试发现失败、超时配置问题或其他无关的失败测试。那些与行为无关的失败会被记录为诊断信息，但永远不会被当作失败-通过的证据。

测试从哪来？OdinEval优先使用开发者测试。如果开发者测试能直接覆盖issue描述的行为，就将其适配到基础版本和修复版本上做两态验证。但如果开发者测试不存在，或者移植到基础版本后无法执行，就需要走技能引导的黑盒测试生成流程。这个流程里有一份版本化的测试编写技能（Test Writing Skill）文件，它规定了写入者的可用上下文、输出格式和行为约束。写入者必须先说明issue的触发条件、可观察的行为和测试命令，然后才能开始编辑。

图2展示了这个带门控的测试生成循环。生成的测试先由三个相互隔离的同一模型实例独立评审，评审规则要求测试能触发issue、观察到目标行为、解释基础版本失败和修复后通过的原因，并且不能泄露实现细节。只有全票通过才会进入执行阶段。执行阶段在同一个声明环境下做两态验证——先在基础状态上跑，再在基础状态加上金标修复的状态上跑。被拒绝的测试会根据结构化反馈重写，重新进入评审和执行门控。测试发现失败、构建配置失败、工具链问题会被单独标记，与行为不匹配区分开。

这里要特别说明：三个同模型实例的孤立评审只是一个一致性检查，不是跨模型共识的证据。论文明确说，同一模型的多次评审只能说明评审结果稳定，不能说明评审结果正确。真正的正确性保障来自两态运行验证和最终的人工语义审计（如果有的话）。这种不夸大评审作用的态度在基准构建论文里相当少见。

六模型受控对比：Kimi-K3领先Resolved，Qwen3.8-Max领先Repro

评测协议设计得很克制：给定基础仓库r_b、issue描述q和局部源码范围L，模型产出一个统一补丁p。评测器把p应用到r_b上，然后运行实例验证器。一个严格的成功修复要求补丁可应用、构建或测试准备成功、issue专属回归测试通过、且声明的非目标回归检查也通过。每个门控单独报告——因为一个能构建的补丁不等于一个行为上的修复。

模型在生成补丁时只能看到基础版本可获取的信息：issue记录、L范围内的文件、协议允许的仓库元数据、共享的补丁指令。它看不到修复commit、金标diff、金标测试补丁、基础失败/修复通过的日志或评审证据。评测器只在补丁生成后使用这些保留信息来评分。这种隔离保证了成功可以归因于模型自己生成的补丁，而不是基准构建过程的泄露。

六个模型在168个过滤后的实例上做了同一协议的对比：GPT-5.6-sol、GPT-5.6-terra-max、GLM-5.2、MiniMax-M3、Qwen3.8-Max和Kimi-K3。每个模型使用完全相同的issue表示、仓库快照、prompt模板、源码范围、补丁格式、重试策略、超时和验证器。

图3展示了源码范围条件和有序评测器的结构。词法定位和oracle定位只改变提供给模型的文件；所有下游生成和验证步骤保持固定。主要的对比指标有三个：Apply（补丁能否应用）、Repro（问题能否复现）、Resolved（是否完整修复）。

表2的结果挺有意思。Kimi-K3的Resolved最高，达到66.7%；GLM-5.2以57.7%排在第二；GPT-5.6-sol是50.6%。但Repro的排名完全变了：Qwen3.8-Max以96.4%领先，GLM-5.2以94.6%排第二，Kimi-K3只有93.5%。换句话说，复现问题最强的模型，并不是真正把bug修好的模型。Qwen3.8-Max的Repro比Kimi-K3高了2.9个百分点，Resolved却比Kimi-K3低了17.9个百分点。MiniMax-M3在三个指标上都是最低的——Apply 93.5%、Repro 88.7%、Resolved 45.8%。

这个反差说明了一个关键问题：Repro高说明补丁应用后行为仍然符合缺陷状态（即测试失败），但这距离“修好”还有很长的路。一个模型可能很擅长定位问题相关文件、生成能应用且不破坏构建的补丁，但补丁本身没有真正改变行为。Kimi-K3在Resolved上的领先说明它更擅长生成真正修复行为的补丁。论文因此强烈建议，评测报告不能只看单一指标，Apply饱和并不意味着任务简单——Resolved的差距跨度高达20.8个百分点（从45.8%到66.7%）。

可复现性设计：冻结数据、容器与审计清单如何保障结果可信？

现在很多基准论文最大的问题不是方法不好，而是别人没法复现。OdinEval在可复现性上下的功夫值得单独拿出来说。

每个实例发布的内容包括：元数据记录、源码归档或获取配方、容器化环境、验证器、金标补丁、测试补丁、执行日志。所有发布文件都有校验和，数据集级别的清单把已发布的结果绑定到特定的工件版本。一个发布检查器会验证每个实例是否包含所有必需文件、清单哈希是否与内容匹配、两态日志是否标识了同一个命令契约、生成测试的每条记录是否附带了完整的评审历史。

在评测之前，论文冻结了大量控制项，如表1所示。

表1展示了评测前冻结的控制项。模型身份（provider模型字符串、API日期和请求端点）、解码参数（temperature、top-p、最大token数、种子支持等）、上下文规则（prompt模板哈希、源路径、字节或token预算）、执行环境（容器摘要、验证器版本、超时、主机架构、并发数）、尝试策略（一次评分响应，仅传输层失败重试）和分析配置（数据集清单哈希、检索索引哈希、失败分类器版本）全部被冻结。这些控制在评测前就固定下来，并在运行清单中记录，供后续分析验证模型实际的信息边界。

生成和评测被刻意分离成两个独立进程：生成服务写出候选响应但不能执行仓库命令；评测器读取规范化后的diff、执行补丁应用、调用容器化验证器、输出结构化结果。这种隔离防止了隐藏的工具反馈把原本的单次尝试修复变成一个交互式agent运行。同一个验证器可以评分金标补丁、生成补丁和未来的基线模型。

论文还明确区分了“重复评测”和“新基准版本”：新模型可以复用冻结的issue、环境、测试和验证器；本地化研究可以改变提供的文件范围但保持所有后续门控不变；但如果替换测试、编译器、命令或接受规则，这就改变了任务本身，必须产生一个新版本。这个边界防止了一个常见的问题——有人把更好的修复方法和更简单的oracle或环境混在一起，声称是自己的增益。

局限与展望：OdinEval的边界与未来扩展方向

OdinEval的边界写得很清楚。168个过滤后的公开issue不代表所有Odin开发工作，尤其不代表大型重设计、大规模迁移和纯性能优化这类很难用单一命令验证的改动。六个模型也不构成一个普适排名——它只是一个固定协议、固定时间点、固定语料下的对比快照。

可迁移性方面，OdinEval的构建方法论——自动化采集加人工语义筛选、历史环境重建、两态验证、版本化测试生成技能、冻结数据加审计清单——这套流程对任何非主流语言都适用。但同样的限制也在这里：每个新语言都需要重新做一次环境重建的脏活累活，没法自动套用。

测试oracle的充分性还是一个开放问题。一条通过测试不证明补丁完全正确，这一点论文引用的是软件测试领域的经典结论。OdinEval的做法是保留两态证据和oracle来源，而不是把通过测试当作正确性的证明。未来的方向包括：扩展更多模型、加入本地化条件对比实验、增加迭代修复条件（当前是单次尝试）、以及持续扩充实例数量。

龙迷三问

下面是龙哥对于大家可能的一些问题的解答：

这篇论文到底在解决什么问题？OdinEval是首个面向Odin编程语言的可复现代码修复基准，从公开仓库挖掘168个缺陷实例，要求测试在缺陷版本失败、修复版本通过。

这篇工作最值得看的点是什么？Kimi-K3在Resolved指标上最高（66.7%），Qwen3.8-Max在Repro指标上最高（96.4%），所有模型Apply率均超过93%。

这篇工作的边界或风险在哪里？优点：严格的实例准入规则确保测试确实区分缺陷与修复状态；版本化测试生成协议和审计清单保证可复现性；受控评估协议隔离了定位、生成和验证过程。缺点：仅覆盖168个实例，规模有限；同模型评审作为一致性检查而非跨模型共识；lexical定位条件较为简单，可能低估模型在真实场景下的表现。

如果你还有哪些想要了解的，欢迎在评论区留言或者讨论~

龙哥点评

论文创新性分数：★★★★☆

构建一个基于Odin语言的可复现仓库级程序修复基准，通过严格的实例准入规则（测试在缺陷版本失败、在修复版本通过）和版本化测试生成协议，对六个大语言模型进行受控修复评估。

实验合理度：★★★★☆

Apply（补丁可应用率）、Repro（问题复现率）、Resolved（完整修复率）

学术研究价值：★★★★☆

构建一个基于Odin语言的可复现仓库级程序修复基准，通过严格的实例准入规则（测试在缺陷版本失败、在修复版本通过）和版本化测试生成协议，对六个大语言模型进行受控修复评估；更关键的是问题定义是否可复用到同类任务。

稳定性：★★★☆☆

现有材料未提供充分的极端条件、重复运行或扰动测试，稳定性暂按中性评价。

适应性以及泛化能力：★★★☆☆

现有材料未完整展示跨数据集、跨场景或分布外实验，泛化能力仍需进一步验证。

硬件需求及成本：★★★☆☆

现有材料缺少完整训练资源、参数量、显存和推理时延信息，成本暂按中性评价。

复现难度：★★★☆☆

现有材料未确认完整代码、配置、数据处理脚本和权重是否齐备，复现难度暂按中性评价。

产品化成熟度：★★★☆☆

论文验证以研究实验为主，真实部署中的时延、成本、维护和异常场景仍需补充验证。

可能的问题：仅覆盖168个实例，规模有限；同模型评审作为一致性检查而非跨模型共识；lexical定位条件较为简单，可能低估模型在真实场景下的表现。

主要参考文献

[1] Xie, B., Liu, H., Peng, Z., Yin, X., Zhang, S., Luo, Y., Ying, C., Jin, H., Chen, W., Long, S., & Shi, Z. (2026). OdinEval: A Reproducible Benchmark for LLM-Based Program Repair in the Odin Programming Language. arXiv:2608.18595.

[2] Just, R., Jalali, D., & Ernst, M. D. (2014). Defects4J: A Database of Existing Faults to Enable Controlled Testing Studies for Java Programs. ISSTA.

[3] Jimenez, C. E., Yang, J., Wettig, A., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR.

[4] Widyasari, R., Sim, S. Q., Lok, C., et al. (2020). BugsInPy: A Database of Existing Bugs in Python Programs to Enable Controlled Testing and Debugging Studies. FSE.

[5] Xie, B., et al. (2026). ArkEval: Auditable Benchmark Construction for LLM-Based Program Repair. (OdinEval的构建流程改编自ArkEval)

[6] Barr, E. T., Harman, M., McMinn, P., Shahbaz, M., & Yoo, S. (2015). The Oracle Problem in Software Testing: A Survey. IEEE TSE.

KKK