达姆施塔特工业大学与维尔茨堡大学联手打造"代码裁判官"：一套能懂得安全、效率、可读性的AI代码评分系统

这项由德国达姆施塔特工业大学UKP实验室与维尔茨堡大学人工智能与数据科学中心联合开展的研究，于2026年5月发表在预印本平台arXiv上，论文编号为arXiv:2605.00754v1，分类归属于软件工程领域（cs.SE）。感兴趣的读者可通过该编号在arXiv平台检索完整论文。

**研究概要**

每当你请AI帮你写一段代码，你怎么知道这段代码写得好不好？如果代码能运行，那自然是基本及格。但"能跑起来"和"写得好"之间，其实隔着一道很宽的沟——代码可能跑得慢、吃内存、容易被黑客攻击、还可能乱糟糟的让下一个维护的人想哭。

现有的AI代码评分方式，就像一个只会用秒表计时的体育老师：他只能告诉你"跑进了60秒"，却看不出你姿势是否标准、体力分配是否合理、有没有犯规踩线。用更专业的说法，现有的"奖励模型"（Reward Model，简称RM，可以理解为给AI打分的评委）主要靠"运行代码看结果"来判断好坏，这就意味着：代码必须能独立运行、必须有测试用例、而且几乎只能判断对不对，完全不管安不安全、跑得快不快、写得清不清楚。

达姆施塔特工业大学的研究团队决定打造一套真正全能的代码评委——他们将这套系统命名为**Themis**（忒弥斯，古希腊正义与法律女神）。这套系统不仅能评判代码的正确性，还能同时评判五个维度：功能正确性、执行效率、内存效率、可读性与可维护性、以及安全性。更厉害的是，它支持八种编程语言，从Python、Java、JavaScript到C、C++、Go、C#和Ruby都能处理。

研究团队的核心贡献包括三大块：一套用于评估代码评委好坏的新基准测试（Themis-CodeRewardBench）、一个收录了超过35万条代码偏好样本的训练数据集（Themis-CodePreference）、以及一系列从6亿参数到320亿参数不等的代码奖励模型（Themis-RM）。

---

一、为什么现有的"代码评委"其实是残缺的？

要理解这项研究的价值，先得明白现在的AI代码训练体系是怎么运转的。

当开发者想训练一个更会写代码的AI时，他们通常需要一个"评委"来告诉AI："这段代码比那段好，按照这个方向改进。"这个评委在技术上就叫"奖励模型"，它给AI的输出打分，好分数指引AI朝着正确方向学习，就像给学生批改作业一样。

目前最流行的评委只会做一件事：拿代码去跑，看能不能通过测试用例。这种方式有个好听的名字叫"执行反馈"，可以理解为"运行看效果"。问题是，这位评委其实非常挑剔，只接受"自给自足"的代码——也就是说，代码必须能单独运行、不依赖外部库、还得有现成的测试用例。

然而现实世界里的代码几乎都不是这样的。你公司里的代码依赖十几个外部包、调用各种API、嵌套在复杂的工程结构里——让这位评委来评，他直接摆手说"我不懂"。更麻烦的是，像Rust、Go、Swift这些编程语言，代码必须以整个模块为单位编译，想单独跑一段代码根本行不通。

即便勉强能跑，这位评委也只会点头说"对"或摇头说"错"，完全无法回答："这段代码安全吗？"、"跑起来会不会特别慢？"、"六个月后维护这段代码的人会不会骂人？"

还有一种替代方案是直接让大语言模型（也就是ChatGPT这类AI）充当评委，让它读代码然后给出评分。这种方法的问题是，这些通用AI其实是糟糕的代码评委——它们在没有参考答案的情况下，对代码质量的判断往往是不可靠的，尤其是当涉及到小众编程语言时，准确率会大幅下跌。

正是看到了这个缺口，Themis研究团队决定系统性地解决这个问题：训练出一个真正懂代码、懂安全、懂效率的专业评委。

---

二、建立考场：一个真正严格的代码评委测试基准

研究团队做的第一件事，是搭建一个测试场地，用来衡量"评委"到底有多厉害。他们把这个测试场地称为**Themis-CodeRewardBench**。

这个基准测试汇集了13个不同的数据集，涵盖五个代码质量维度。功能正确性维度收录了六个数据集，包括HumanEvalPack（手动注入错误的标准代码），MDEval（来自GitHub的人工标注buggy-fixed代码对），DebugEval（来自LeetCode的调试对），RunBugRun（来自竞赛平台AtCoder和Aizu的代码对），MBPP+Fix-Hard（专门挑战"大部分测试通过但不是全部"这种微妙情况的数据集），以及他们自己从GitHub提交记录中挖掘的提交偏好数据。执行效率维度同样有四个数据集，包括Pie4Perf（用模拟器验证的快慢代码对）、ECCO（执行验证的Python代码对）、EvalPerf（AI生成的不同效率代码对）以及GitHub提交数据。内存效率、可读性与可维护性、安全性这三个维度则各有两到三个数据集支撑。

这个测试场地在整体规模上包含约8900个代码偏好对，横跨C、C#、C++、Go、Java、JavaScript、Python和Ruby八种语言。

研究团队还特别强调了这个基准测试的独特性：跟现有的评测集相比，Themis-CodeRewardBench考察的是更长、更复杂的代码，而且来自一个全新的问题分布。他们用一种数学上的"降维可视化"方法（t-SNE图）证明了这一点：把所有测试题目的"位置"画在二维平面上，Themis的题目几乎散落在其他测试集从未涉及的区域，说明这套题目真的很新颖，不容易靠"背题"蒙混过关。代码的语法树深度（可以理解为代码的结构复杂程度）也明显高于其他评测集，意味着代码更复杂、更难评判。

---

三、挖掘训练素材：从GitHub的海量提交记录中淘金

光有考场还不够，要训练出好的评委，还需要大量的"学习材料"。研究团队设计了一套精巧的数据挖掘流水线，从GitHub的公开提交记录里系统性地挖掘高质量的代码偏好对。

这个流水线的运作方式可以用淘金做类比。GitHub是一座巨大的矿山，里面有数以亿计的代码提交记录——每次有人改了代码然后上传，就留下一条记录，记录着"改之前的代码"和"改之后的代码"，以及一段描述改了什么的说明文字。这些记录本质上就是天然的"好坏代码对"：改之后的往往比改之前的更好。

但这座矿山里大部分是普通石头，真正有价值的金子很难找。研究团队用了几个重要的过滤步骤来筛选高质量数据。

首先，他们用Google BigQuery（一种大规模数据查询工具）从GitHub公开数据库里检索，专门寻找"单文件修改"的提交——也就是说，那次代码改动只涉及一个文件，这样就保证了改动足够聚焦，不会是杂乱的多方向修改。他们还过滤掉了所有无意义的提交说明（比如"update"、"fix"、"wip"之类的废话），只保留有实质性描述的记录。同时，所有代码必须来自开放许可证的仓库（MIT、Apache等），确保可以合法使用。

其次，他们针对五个评估维度，分别列出了大量关键词。比如安全性维度的关键词包括"sql injection"（SQL注入）、"buffer overflow"（缓冲区溢出）、"CVE"（漏洞编号）等上百个专业术语；执行效率维度则包括"optimize loop"（优化循环）、"cache results"（缓存结果）、"reduce overhead"（减少开销）等关键词。用这些关键词去匹配提交说明，就能初步筛选出跟各维度相关的代码修改。

然后，研究团队用这些初筛结果训练了专门的分类器——他们选择了ModernBERT（一种高效的文本理解模型），为每个维度各训练一个分类器，让分类器学会更精准地识别哪些提交真的与该维度相关。

接下来是最关键的质量把关环节：只保留那些属于"已合并的Pull Request"（可以理解为经过团队审核通过的代码改动）且没有被后来撤销的提交。这意味着这些代码改动经过了真实开发者的人工审核和认可，质量更有保障。仓库本身也有门槛：至少要有15颗GitHub星标、5位贡献者和10个议题，确保是被认真维护的项目，而不是随便建的练习仓库。

最后，研究团队召集了多个前沿开源大模型（包括Kimi、DeepSeek、MiniMax等），让它们对每个候选的代码改动进行"共识投票"——只有多数模型都认为这个改动确实聚焦于某个单一目的（比如只改安全问题、只改效率问题），才会被保留。一旦通过，再用AI为这对代码生成逼真的"问题描述"：就好比你看到一道题的答案，反过来猜原来的题目是什么，这种方法叫"逆向指令生成"。

通过这整套淘金流水线，研究团队为训练集和测试集分别挖出了大量高质量的代码偏好对，而且严格保证训练集的GitHub提交时间在2019年3月之前，测试集则来自2019年6月到2021年1月之间，两者来自完全不同的仓库，杜绝了"背题"的可能。

---

四、配方大全：训练数据的完整构成

除了从GitHub挖掘的提交偏好数据，研究团队还整合了多个其他来源的数据，最终形成两个大型数据集。

第一个数据集叫**Themis-GeneralPreference**，包含超过11万条通用偏好样本，主要来自Skywork偏好数据、Tulu指令跟随数据、StackExchange技术论坛的高赞回答对比、LMArena人类投票数据、Prometheus偏好集合等。这个数据集的目的是先教会模型理解"人类总体上更喜欢什么样的回答"——有用的、无害的、条理清晰的。

第二个数据集叫**Themis-CodePreference**，是重头戏，包含超过35万条代码偏好样本。除了GitHub提交数据（约12.7万条），还包括：从CodeR-Pile代码检索数据集转化的偏好对（约7.7万条）、通过AI自动向现有正确代码注入bug生成的"正确vs错误"对（约5.5万条，原料来自OSS-Instruct、Inverse-Instruct、McEval-Instruct等指令数据集）、ProSec安全修复数据（约3.8万条）、Venus和CodeNet的运行效率偏好对（共约3.9万条）、RunBugRun和ECCO的竞赛题修复数据、以及CodeScaleR的正确性偏好对等。

这35万条数据横跨五个质量维度和八种编程语言，覆盖之广、维度之全，在现有开源数据集中前所未有。

数据在使用前还经过了严格的清洗过滤：剔除过长的样本（训练长度上限4096个token）、过滤语法树过于简单的代码（深度小于3层的直接丢掉）、用语言识别工具确保问题描述是英文、用语言模型困惑度过滤掉语意混乱的样本、进行近重复数据删除（MinHash去重，相似度阈值0.75）、最后还要确保没有13个词以上的内容与测试集重叠（防止数据泄漏）。

---

五、培训评委：两阶段的训练策略

有了数据，下一步是如何把它们用于训练。研究团队采用了一个两阶段的训练策略，就像培训一名专业评委要先上通识课、再上专业课一样。

第一阶段叫"偏好模型预训练"，用Themis-GeneralPreference数据，训练两轮。这个阶段的目的是让模型先建立起对人类偏好的基本感知——什么是更有帮助的回答、什么是不恰当的内容、什么是更清晰的表达。这相当于让未来的代码评委先学会做一个优秀的"通用评委"，打好认知基础。

第二阶段叫"偏好建模"，用Themis-CodePreference数据，训练一轮。这个阶段聚焦于代码领域的专业知识，让模型学会在五个维度上区分好坏代码。

在训练目标上，研究团队采用了一个叫"Bradley-Terry"的经典偏好学习目标（可以理解为让模型学会"A比B好"这种判断），但加入了两个额外的正则化项：一个是"行为克隆损失"，让模型在打分的同时还要能生成被选择的好代码，这相当于要求评委不仅会评分还要能示范；另一个是"奖励幅度正则化"，防止模型给出极端的高分或低分，保持评分尺度的稳定性。

研究团队特别强调了一个关键设计：在训练时，15%的样本不附带任何评分标准提示，20%的样本附带列出全部五个标准的提示，剩余65%的样本则附带只针对单一标准的提示。这种策略使得模型在推理时可以灵活接受用户自定义的评分标准：你可以告诉它"只看安全性"、"只看效率"，或者"全部五个维度都考虑"，模型都能正确响应。

整套系统在Qwen3系列模型的基础上进行训练，提供了从0.6B到32B六种参数规模的版本，分别使用8到128块GPU完成训练，使用FlashAttention和Liger等工程优化技术提升训练效率。

---

六、考场结果：现有评委大规模"翻车"，Themis全面领先

测试阶段，研究团队将超过50个现有的奖励模型放到Themis-CodeRewardBench上进行评估，结果相当触目惊心。

现有的评委在功能正确性这个维度上表现尚可——毕竟这是他们一直专注训练的方向。但当测试转向非功能性维度时，几乎所有现有模型都"原形毕露"：在执行效率、内存效率、安全性这些维度上，很多模型的准确率接近50%——相当于随机猜测。一个号称会评判代码质量的AI，在判断"这段代码安不安全"这件事上，表现居然和抛硬币差不多，这实在令人汗颜。

在功能正确性内部，现有模型也暴露出明显短板。大多数模型在"标准竞赛题"上表现不错，但换到GitHub真实提交数据时，准确率大幅下跌。在MBPP+Fix-Hard这个专门测试"部分正确"情况的数据集上，绝大多数模型无法区分"通过80%测试"和"通过95%测试"之间的细微差别，只有Themis-RM的较大规模版本和极少数现有模型能捕捉到这种细微区别。

生成式评委（让AI写出理由然后基于理由打分）和推理增强评委（让AI深思熟虑后给分）的表现同样令人失望。这些模型在没有参考答案的情况下，因为文字评分的分辨率太低，往往无法做出精准判断，有时甚至自动提议评分标准的模型表现更差。

相比之下，Themis-RM在所有维度上都大幅领先。以8B版本为例，综合准确率达到89.78%，其中功能正确性91.75%、执行效率83.65%、内存效率92.04%、可读性与可维护性86.06%、安全性93.34%。0.6B的最小版本尽管只有不到1亿个参数，却能超越许多超过100倍大的通用奖励模型——这说明专业化的训练数据和方法远比模型规模更重要。

值得注意的是，数学奖励模型（专门为数学推理任务训练的评委）在功能正确性上表现出了高于平均水平的成绩，这与此前研究发现的"数学训练对代码生成有正迁移"相吻合。但这种迁移非常局限，只在算法竞赛类的代码上有效，换到其他场景就不管用了。

---

七、五个维度如何和谐共处：消融实验的发现

研究团队还做了一系列"拆解实验"（专业术语叫消融实验），通过逐步移除训练配方中的某个成分，来测量每个成分的贡献，就像逐一去掉菜肴里的调料，来判断哪种调料最关键。

首先，去掉第一阶段的通用偏好预训练后，模型各维度得分都有所下降，说明"先打通识基础再学专业"的两阶段策略是有效的。去掉辅助训练损失（行为克隆和奖励幅度正则化）后，得分也会下降，说明这两个正则化项都有实质作用。

关于评分标准提示的作用，研究团队发现了一个微妙的现象：不给任何标准（多任务基线）和给出全部五个标准的笼统提示，效果相差无几（87.88% vs 88.16%）。但是，在推理时给出**具体的单一标准**提示，效果就明显更好了——这说明关键不在于"告诉模型有哪些标准"，而在于"告诉模型现在只评判哪一个标准"。

在跨维度迁移方面，研究团队做了一个有趣的实验：分别训练只使用单一维度数据的专门化模型，然后测试它在其他维度上的表现。结果发现，用功能正确性数据训练的模型，在非功能性维度上的表现比其他维度的专门化模型更好——这是因为很多非功能性改进（比如提升安全性、改善效率）在实际代码中往往同时伴随着功能性的修改。另外，没有任何单维度模型能在自己擅长的维度上超越全维度训练的Themis-RM，这说明五个维度之间存在正向的协同促进效应，一起学比单独学更好。

研究团队还测试了将五个单维度模型"合并"成一个模型的方法（模型融合），结果相当惨淡：融合后的模型比不带任何标准提示的多任务基线还差10个百分点以上。这个失败的原因在于，Bradley-Terry训练目标本身存在"刻度未定义"的问题——不同模型在同一数据上可能用完全不同的数值刻度打分，强行融合参数会导致混乱。研究团队采用的"弱正则化"也只能部分缓解这个问题，完全修复需要更强的约束，但强约束又会伤害模型的排序能力。

---

八、跨语言迁移：用Python训出来的评委能评Java代码吗？

在多语言能力的测试上，研究团队进行了精细的控制变量实验：固定训练数据量（各5万条），分别训练"全八语言混合"、"仅高资源语言（Python、Java、JavaScript等）"、"仅Python"、"仅Java"四个版本的模型，然后测试每个版本在全部八种语言上的准确率。

实验结果揭示了一个有趣的规律：Python模型更擅长迁移到其他动态类型语言（如JavaScript、Ruby），而Java模型更擅长迁移到其他静态类型语言（如C、C#、Go）。这与语言学中的规律高度吻合——同类型的语言之间迁移更顺畅，就像一个精通法语的人学习西班牙语，比学习日语要容易得多。

更重要的发现是：四个模型在各语言之间的性能差距都相当小。即便是只用Python数据训练的模型，在Go语言上的准确率也只比全语言模型低约7个百分点。这表明现代大语言模型在预训练阶段已经接触了大量多语言代码数据，具备了相当强的语言间知识迁移能力；在高资源语言上的"情境覆盖"（即见过的代码类型有多丰富）比在低资源语言上的"数据量"更重要。训练数据涵盖全部语言的版本依然表现最好，说明多语言训练确实能带来正向的跨语言迁移效果。

---

九、真实战场测试：排序能力与抗干扰鲁棒性

最后，研究团队测试了Themis-RM在两种最重要的下游应用场景中的表现。

第一个场景是"列表重排序"：给模型同一道编程题的40个AI生成解答，让模型从高到低排序，然后测量排名前10的解答里有多少个完全正确的（Hits@10），以及模型的整体排名与实际执行结果的相关性（Rank Corr.@40）。测试语言选了C++、Java和Python三种，题目来自CodeContests+竞赛数据集，解答来自多个开源大模型。

Themis-RM-32B在Hits@10上的表现非常亮眼，三种语言的得分分别达到97.65%、98.59%和97.44%，与专门针对竞赛代码正确性训练的最佳现有模型持平，甚至略有超越。而它在Rank Corr.@40上的表现更是领先所有竞争对手，Spearman相关系数约在0.50左右，而大多数现有模型只有0.3左右，部分模型甚至是负相关（排名完全乱序）。

第二个场景是"抗干扰测试"：使用Aletheia-Adv测试集，这套数据集专门设计了各种"欺骗评委"的手法——比如在错误代码上加满详尽的注释、在正确代码上故意写得很简陋，或者通过风格修改来迷惑评委的判断。Themis-RM在三种语言上的抗干扰准确率大约在72%-83%之间，比大多数现有模型高出约20个百分点。

特别有趣的是，研究团队发现Themis-RM在这些下游应用测试中的"规模缩放效果"比在基础偏好准确率测试中更明显——也就是说，随着模型变大，实际应用中的提升幅度比纸面测试分数的提升幅度更大。这与此前一些研究发现的"更大的奖励模型在下游鲁棒性上不一定更好"的结论相反，说明Themis-RM的训练方式更契合实际应用需求。

---

说到底，这项研究揭示了一个让人深思的现实：AI代码生成领域长期以来一直在用一把非常单一的尺子（能不能运行）衡量代码质量，导致AI训练出来的代码在功能上勉强合格，但在安全、效率、可维护性等方面经常让人担忧。Themis项目从打造基准测试、挖掘训练数据到训练专业模型，系统性地填补了这个空白。

对于普通用户来说，这项研究的意义在于：未来的AI代码助手不再只是"能跑就行"的工具，而是能够真正像一位经验丰富的高级工程师那样审视代码——考虑安全隐患、权衡性能开销、提醒维护成本。一个"懂得更多"的代码评委，训练出来的代码生成AI也会"写得更好"。

随着AI生成代码越来越普遍、进入越来越多关键系统，这种能力的重要性只会与日俱增。毕竟，写出能跑的代码很容易，写出好的代码才是真功夫。想深入了解这项研究的读者，可以通过论文编号arXiv:2605.00754在arXiv平台查找完整论文。

---

Q&A

Q1：Themis-RM和普通的代码检查工具有什么区别？

A：普通代码检查工具（如静态分析器）依赖预先定义的规则库，只能发现已知的表面错误模式，无法理解代码的上下文语义，也无法综合评估多个质量维度。Themis-RM是基于大语言模型训练的奖励模型，通过学习大量真实代码改进案例，能够理解代码意图、综合判断功能正确性、执行效率、内存效率、可读性和安全性五个维度，即使代码无法独立运行也能给出有意义的质量评分。

Q2：为什么现有的AI代码评委在安全性判断上如此不准确？

A：主要原因是现有奖励模型几乎完全依赖"运行测试"来评分，而安全漏洞（如SQL注入、缓冲区溢出）在功能测试中通常不会触发错误，代码照样能通过测试用例。此外，现有模型的训练数据极少包含针对安全性的偏好样本，模型从未系统学习过如何区分安全代码与不安全代码，导致在安全性判断上退化为随机猜测水平。

Q3：Themis-RM支持哪些编程语言，对于不在列表中的语言是否有效？

A：Themis-RM官方支持并训练验证了Python、Java、JavaScript、C、C++、Go、C#和Ruby八种语言。对于其他未明确训练的语言，由于基础模型（Qwen3）在预训练阶段接触了大量多语言代码，加上研究发现同类型语言之间存在较强的跨语言迁移能力，Themis-RM对于语法结构相似的语言（如TypeScript之于JavaScript）应当仍有一定效果，但官方未提供量化保证。