
SuperCLUE 中文「软件工程」测评结果正式揭晓!
测评构建了一个面向中文开发环境的软件工程评测基准,收集了来自中文开源项目的真实 GitHub 问题及其对应的修复方案,确保任务实例既真实可靠,又贴近中文开发场景。
(SuperCLUE-SWE)中文「软件工程」测评基准方案参考:中文「软件工程」测评基准方案发布!(SuperCLUE-SWE)
本次我们测评了国内外11个代表性大语言模型的表现,以下为详细测评报告。
SuperCLUE-SWE 测评摘要
在本次 SuperCLUE-SWE 测评中,Gemini-3-pro 继续保持总体第一,Claude、GPT-5.1 等构成国际第一梯队,在复杂、多文件的真实 Issue 修复任务上表现最稳定、成功率最高。不过,相比早期英文基准上的“断层式”优势,这次在中文软件工程场景下,头部国际模型与国内强势模型之间的分差已经明显缩小。
从成绩看,国内主流模型在中低难度任务上,多款模型的得分已经基本追平国际模型,只是在高难度任务上拉开差距。尤其是 DeepSeek-V3.2 正式版相对 V3.2 实验版提升约 8 分,仅用几个月就把成绩追到接近 GPT-5.1,说明国内模型在代码理解与修复方面的迭代速度非常快,已具备向第一梯队发起冲击的实力。结合其他国内模型在新版上的持续追赶,可以预期未来几个版本中,中文场景下的榜单结构还有可能重排。因此,SuperCLUE-SWE 后续将继续纳入更多国内新模型与新版本。
# SuperCLUE-SWE介绍
SuperCLUE-SWE是面向中文开发环境的软件工程评测基准,旨在评估大型语言模型在解决实际软件工程问题中的表现。专注于中文开发场景,涵盖了来自中文开源项目的真实 GitHub 问题(issue)及其对应的修复方案。通过聚焦中文开发环境,SuperCLUE-SWE解决了现有评测基准无法有效评估中文问题描述及开发环境中的空白问题。SuperCLUE-SWE采用明确的量化评分标准,以1分制对模型的任务表现进行评价,确保评价结果客观且具有可比性。
# SuperCLUE-SWE与SWEBench的异同
|
|
SuperCLUE-SWE |
SWE-Bench-Verified |
问题描述的语言 |
中文 |
英文 |
平均修改多少行 |
41行 |
32.8 行 |
任务类型 |
bug修复 |
bug修复、性能提升、功能补全 、行为扩展等 |
项目库的语言 |
6个中文库;3个英文库 |
12个英文库 |
涉及的repo数量 (仅指python) |
9 |
12 |
数据集数量 |
100 |
500 |
bug修复的主要年份 |
2020-2025 |
2010-2020 |
# 测评任务&题目介绍
任务重点考察模型在理解中文问题描述、定位代码缺陷、生成修复方案及验证修复效果等方面的能力。每题按实际修改代码行数划分为低(0–20 行)、中(20–50 行)、高(50 行以上)三档,比例约为 30% / 40% / 30%。,涵盖了不同复杂度的开发挑战,确保全面评估模型的能力。
题目的bug类型:
1.1 格式化问题(Formatting Issues)
例如代码风格或排版问题,通常是由不遵守规范或自动化工具如black、flake8等引起的。这类问题往往很简单,修复通常只需要进行格式化调整。
示例问题:
fmt:skip注释之前的空格问题;无法正确处理空行添加问题。
1.2 代码逻辑错误
这类Bug涉及到代码的功能或逻辑错误,可能是由于开发者疏忽或错误的推理导致代码的运行结果不符合预期。
示例问题:JSON 解析错误:代码未对JSON字符串解析结果进行有效的错误检查,导致异常发生。
1.3 异常处理缺失(Missing Error Handling)
涉及到未处理的异常,导致程序在异常情况下崩溃或出现不当行为。开发者没有适当捕获错误并进行合理处理。
示例问题:代码逻辑没有判断是否 JSON 字符串解析成功,导致在访问解析后的数据时抛出异常。
1.4 依赖与兼容性问题(Dependency and Compatibility Issues)
这种Bug通常与外部库、工具或环境相关,代码在不同的环境下表现不一致,可能是版本不兼容或依赖未正确处理的问题。
示例问题:请求外部数据时遇到问题,导致解析的JSON字符串格式不正确,进而引发错误。
除了常见的 Bug 类型之外,还存在一些特殊类型的Bug,这些问题可能比较棘手,涉及到更复杂的工程问题或细节。如多线程/并发问题,性能问题,安全问题,测试覆盖不全等。
总分的计算
模型得分=(得分为1的实例数量/记分实例总数量)*100
# SuperCLUE-SWE项目任务来源:
SuperCLUE-SWE项目所涉及任务平均代码修改行数为77行,其中来自httpx,black,sympy,nonebot2库的任务实例时间均在2023-2025年。
# 模型答案过滤
我们对所有模型回答做了基础过滤,将AI生成的patch标准化为最小、可应用的格式,提高应用成功率。
主要处理内容:清理空白字符;重新计算行号;移除冗余内容。
此外,在评估Gemini预测结果时,发现SWE-bench的patch格式要求必须使用 --- a/file.py 和 +++ b/file.py 格式,而Gemini生成的patch格式有70%使用 --- file.py 和 +++ file.py(缺少 a/ 和 b/ 前缀),使得脚本无法匹配这些 patch。因此对所有模型答案统一进行此修复。修复后Gemini有90%的答案可以被脚本正常使用。
在评估GPT-5.1预测结果时,发现其模型答案有30%有Begin Patch 格式转换问题: 使用了非标准的 *** Begin Patch / *** End Patch格式,而不是标准的文件头。且Hunk header 可能缺少行号信息(只有 @@ 而没有 @@ -start,count +start,count @@)因此对所有模型答案进行修复: 移除 *** Begin Patch / *** End Patch标记,转换为标准的 unified diff 格式。
# 成绩详细信息
# 测评案例
题目介绍:
这个 PR(#351)修复的是 jieba 中的 del_word 函数的问题。PR 对 del_word 函数的实现进行了修改,确保它在删除词汇时能正确处理相关场景,避免出现错误或不符合预期的行为。
【构建prompt】:
【模型名称】:claude_opus_patch_applied
【得到模型原始回答】:
【提取模型答案中的patch并应用】:
【标得到已解决的结果】:
从报告中可以看到FAIL_TO_PASS和PASS_TO_PASS都success,因此该题目成功解决,得分记为1。
# 针对DeepSeek-v3.2正式版的成绩分析
|
|
简单 |
中等 |
困难 |
总通过 |
解题数 |
12/30 |
7/40 |
6/30 |
25/100 |
简单段(12/30)失败集中在black/nonebot/httpx 的格式或依赖问题。说明即便改动小,格式/子模块/依赖仍易挂。
中等段(7/40),black和pyecharts各有少量成功,多数中等实例在black/nonebot/httpx 仍未过,表明中档行数的任务也因逻辑/格式/依赖卡住。
困难段( 6/30),存在依赖冲突、异步加载、URL 边界、补丁上下文不匹配叠加。成功主要在black和pyecharts,显示模型偶有突破,但整体高难仍偏低。
总体:成功率随难度大致下降(简单最高),但中等段低于困难段,black/nonebot/httpx 在中等难度段依旧高失败,依赖/格式/异步场景仍是主要短板。
失败分布:55个“Tests Failed”、20个“Patch Application Failed”。测试失败里以逻辑/断言失败为主(约44%逻辑失败,23%断言失败);错误集中在 psf/black、nonebot2、pyecharts、httpx。
典型症状:psf__black-4331 diff 上下文/格式不符导致 git apply 连续失败;nonebot__nonebot2-1121 触发 pip 依赖冲突测试未跑;pyecharts__pyecharts-114 子模块拉取指定 commit 失败;black/httpx 多处在 AST/URL 编码边界断言不符。
模型优势:
补丁可套用率高:75 失败中仅 20 起因于 patch 应用错误,说明生成的 diff 大多能落地、上下文匹配度尚可。
通过用例覆盖面还算广:25 个成功跨越 pyecharts(7)、black(4)、sympy(3)、python-pinyin(3)、httpx(2)、nonebot2(2) 等,能处理一定程度的格式化、数学和网络逻辑问题。
对部分任务能给出结构化改动(如 nonebot 插件父子关系逻辑,见 nonebot__nonebot2-1121/run_instance.log 中的详细 AST/上下文调整)。
模型不足:
修复质量偏低:74% 的失败是测试未过,常见为只修到一半或忽略边界,black/httpx/sympy 场景尤甚。
diff 规范性不稳:25.7% 直接因 patch 应用失败(格式、路径、上下文),在 black/pyecharts/sympy 上更突出。
依赖/环境感知弱:多次触发 nonebot2 的 pip 依赖冲突,pyecharts 子模块缺失未预防,导致“未跑测试就失败”。
领域知识欠缺:格式化(AST/pep701)、异步框架(插件加载顺序)、URL 编码/Unicode 边界等场景下容易出逻辑偏差或漏测。
# 参与测评
参测流程
1.邮件申请
2.意向沟通
3.参测确认与协议流程
4.提供API接口或大模型
5.获得测评报告
邮件标题:SuperCLUE-SWE 「软件工程」中文测评申请,发送到contact@superclue.ai请使用单位邮箱,邮件内容包括:单位信息、大模型简介、联系人和所属部门、联系方式
联系我们

