全球大模型编程评测！工程能力才是关键，别被「刷榜成绩」骗了

近两年，大语言模型的编程能力发展飞快，例如 DeepMind 的 AlphaCode 曾宣称达到人类竞技编程选手的水平；OpenAI 的顶尖模型屡屡被报道能通过谷歌高级编程面试，并在 LeetCode 挑战中表现出较高能力。然而，当我们将目光从大模型刷榜转向解决真实的、复杂的工程项目时，一个核心问题随之浮现：这些号称擅长编程的模型在面对真实工程场景时，其准确性、健壮性和实际应用价值究竟如何？

图片

研究发现，现有的代码基准数据集在面对复杂的工程场景时普遍存在缺乏多样性和可控性的双重问题：

• 工程开发环节覆盖有限：尽管现有基准（如 FullStackBench、SWEBench）在领域和语言多样性上取得进展，但其任务类型仍主要集中于单段落代码生成。而真实工程实践通常涉及跨文件、跨模块的协同，以及代码修复、测试驱动开发、多函数协作等复杂任务，这些都应被工程级基准全面覆盖。
• 数据构建方法局限：大多数数据集采用随机挖空或从代码仓库的历史 PR 记录中提取修改点（如 GitHub 的 Pull Request）。前者容易忽略项目的核心逻辑代码段，后者不仅数据量稀少，还需投入大量人工进行数据清洗和标注，难以规模化构建高质量的评测题目。

总之，我们发现现有的代码基准测试大多“偏科”了。它们要么只关注单个函数的补全，忽略了开发者修复 Bug 、根据单元测试反向开发的真实场景；要么采用随机挖空的方式，难以触及代码的核心逻辑。这导致我们无法科学、完整、全面地测评 LLM 在真实工程场景中的代码能力，尤其是在可靠性和适用性方面，我们亟需一个能解决此难题的方案。

为了应对上述挑战， Meituan-M17 团队、上海交大联合发布了一个全新的大模型工程级别代码基准测试 CoreCodeBench 数据集，托管到 AGI-Eval 社区。

目前该研究已经发表成论文：《CoreCodeBench: A Configurable Multi-Scenario Repository-Level Benchmark》。

图片

• 论文地址： http://arxiv.org/abs/2507.05281
• GitHub地址： https://github.com/AGI-Eval-Official/CoreCodeBench

它专注于评估大语言模型在真实工程项目中的综合代码能力，覆盖了从代码开发到代码修正的多个核心阶段。

图片

△ 图 1: CoreCodeBench 题型展示

图片

△ 图 2: CoreCodeBench 模型能力榜单

通过在 CoreCodeBench 上对当前主流大语言模型的全面评测，我们得出了以下关键结论：

• 大模型编程能力迭代进步显著，但发展不均衡：较新的模型 {如 Claude 3.7 、o4 mini（high）} 相较于前代产品表现出明显进步。然而，受测模型在代码修正（BugFix）任务上表现欠佳，尤其是单函数任务场景下，修正任务的成功率全部低于开发任务，这揭示了当前 LLM 在理解和修复深层逻辑错误方面存在的普遍短板。
• 多函数协作是当前大模型编程场景的主要瓶颈：几乎所有模型在处理多函数任务时的表现都显著劣于单函数任务。这表明，当需要同时处理多个函数间的依赖关系、调用逻辑和协同实现时，当前大模型的跨函数推理和规划能力尚显不足。
• 大模型编程场景普遍缺乏灵活的规划与分层推理能力：在多函数代码生成任务中，我们观察到大多数模型严格遵循输入提示中的函数顺序生成代码，而非像人类工程师那样，基于功能依赖（如先实现被调用的工具函数）进行优化。这一现象反映了当前模型在面对复杂任务时，倾向于采用默认的顺序策略，缺乏主动规划的意识。

下面我们将详细介绍 CoreCodeBench 是如何构建的，以及取得的实验结果和深度分析。

01. 基准构建方法与实验分析

数据集构建方法：CorePipe 流程

为了构建一个既关注多样化工程问题，又聚焦于核心代码的基准，CoreCodeBench 中设计了从工程代码仓库到多种函数题型的全自动化构建流程CorePipe。

图片

△ 图 3: CorePipe 自动化生产数据流程示意图

如上图所示，CorePipe 基于函数调用树，系统化地生成覆盖三大核心场景的单函数与多函数题目，确保每一道题目都直击“要害”：

精选真实项目：我们从 PyPI 对应的 GitHub 仓库中筛选出高活跃度、高测试覆盖率和高技术复杂度的顶级开源项目。

定位核心代码：通过动态和静态追踪代码的执行，我们首先构建函数调用图，再利用抽象语法树（AST）抽取出关键函数中的核心代码，精准定位项目中那些“牵一发而动全身”的核心代码块。我们能精准定位项目中那些“牵一发而动全身”的核心函数。

模拟三大真实场景：

• 直接开发 (Development)： 不仅仅是填空，我们利用 GPT-4o 生成高质量的函数功能描述，并由 Claude 3.5 Sonnet 进行“挑刺”和审核，确保模型是在理解真正需求的前提下进行开发。
• 代码修正 (BugFix)：告别简单的语法错误，转而使用 LLM 生成更隐蔽、更复杂的逻辑错误，真实模拟了开发中那些令人头疼的 Bug 。
• 测试驱动开发 (TDD)：提供完整的单元测试，要求模型根据测试用例反向开发功能代码，考察其遵循现代开发范式的能力。

引入多函数难题：

我们将上述单函数问题按照真实的函数调用关系组合起来，创造出更复杂的多函数题目，全面考验模型在宏观层面的代码组织和规划能力。

02. 实验结果与深度分析

为确保评测的科学性，我们采用了信息增益分数（IG Score）作为核心指标，并通过 IG Filter（信息增益过滤）和专业工程师人工审核（最终合格率78.55%）对题目质量进行充分的监测，兼具可读性、准确性和完整性。

2.1 单函数与多函数任务分析

图片

△ 表 1: CoreCodeBench 单函数和多函数任务榜单

如上图可以看出，实验结果有力地支持了我们的核心结论， Claude 3.7 在所有任务中表现突出。

但所有模型在多函数任务上的普遍表现下滑差于单模型任务，这可能是因为多函数任务需同时处理多个函数间的依赖关系、调用逻辑和协同实现，对大语言模型的跨函数推理和规划能力要求更高，以及在 BugFix 任务上的集体短板，清晰地勾勒出当前技术的能力边界。

2.2 模型规划能力洞察

多函数任务的实验分析揭示，模型缺乏对实现顺序的规划能力。

大多数模型严格遵循输入提示中的函数顺序生成代码。当前模型在多函数代码生成时缺乏灵活规划能力与分层推理能力，往往采用默认的顺序输出策略，而非基于逻辑或功能依赖进行优化。

这种“顺序执行”而非“逻辑执行”的策略，是其与人类工程师在解决复杂问题思路上的一大差异。

2.3 极限挑战

图片

△ 图 4: CoreCodeBench-Difficult 数据集的模型结果

我们通过放宽多函数问题的复杂度限制，构建了 CoreCodeBench-Difficult 数据集。

在该测试中，所有模型的通过率均低于 30 %，这不仅印证了该基准在揭示模型局限性方面的有效性，也为未来技术的突破提供了严苛的测试平台。

2.4 LLM 代码能力全景雷达图

图片

△ 图 5: 前沿 LLM 代码能力雷达图

我们将模型的六个核心场景表现绘制成雷达图，可以直观地看到：

• 没有一个模型能在所有场景中独占鳌头，证明了 CoreCodeBench 评估维度的全面性。
• 开发（Development）和测试驱动开发（TDD）任务中，单/多函数表现并不完全相关，说明开发多关联函数需要额外的规划能力。
• 代码修正（BugFix）任务中，单/多函数表现高度相关，这说明调试更依赖于一种通用的、局部的错误修正技能。

为进一步分析各评测维度之间的关系，我们计算了所有模型在六个维度上的皮尔逊相关系数并绘制热力图。

图片

△ 图 6: 代码能力项相关度分析

如上图所示可以观察得到，相关系数的测算结果表明，CoreCodeBench 的六个核心场景之间既存在一定的相关性，也体现出各自的差异性：

• Single-function 任务之间相关性较高，表现出单函数任务在基础编程、理解和实现能力上的共性。
• Multi-TDD 和 Multi-Development 存在一定的相关性，这是因为 Multi-function 任务通常考察模型在更复杂场景下的综合能力，包括多步推理、实现规划等，与单函数任务所需的基础能力存在明显区别。
• Multi-BugFix 虽然属于多函数任务，但它和单函数任务相关性高，反而和 Multi-TDD、Multi-Development 相关性低。这是因为 Multi-BugFix 任务的本质更接近于“单点排查”，它更侧重于具体细节或某一局部的能力考察，而与需要全局综合能力的多函数任务存在差异。

03. 总结与展望

CoreCodeBench 的构建与应用，旨在为大语言模型的代码能力评估提供一把更科学、更全面、更贴近真实的“工程标尺”。回顾我们的研究，我们系统性地揭示了当前顶尖 LLM 在真实工程场景中的核心短板：无论是多么先进的模型，都在逻辑错误修复方面步履维艰；在面对多函数协同任务时，其跨函数推理与规划能力都显得捉襟见肘；并且，它们普遍缺乏人类工程师所具备的灵活规划与分层推理能力。

然而，这些被揭示的局限性并非技术的终点，而是为下一代大语言模型的发展指明了清晰的优化方向。我们相信，通过在 CoreCodeBench 这类更贴近真实工程需求的基准上进行训练和迭代，大语言模型将能更快地从一个“代码片段生成器”，进化成一个真正具备分析、规划和解决复杂工程问题的“虚拟软件工程师”，从而在软件开发领域释放出更深远的变革力量。

AGI-Eval 评测社区将持续致力于高质量评估研究，推动大语言模型技术向更广阔的未来发展。关注我们，检索更多评测内容！

— 完 —