中文场景软件工程测评升级 |SuperCLUE-DeepSWE

# 测评背景
SuperCLUE-DeepSWE是面向中文真实开发场景的长程软件工程基准,重点评测大模型在智能体框架驱动下从需求理解、仓库探索到代码实现、测试验证和完整交付的能力,测评智能体框架统一使用Claude Code。
SuperCLUE-DeepSWE以DeepSWE 的任务组织形式为参考框架,围绕国际高星Github开源仓库设计跨文件、跨模块的中文原创长程任务。智能体在隔离的 Docker 容器中运行,无网络访问。
每道题均经过原创查重、环境固化、多轮 Oracle 验证、正反例校验与独立复核,以确保任务可解、评分准确、结果可复现。
# SuperCLUE-DeepSWE 测评流程

# 基准升级点
1.从“公开修复复现”升级为“原创问题求解”
SuperCLUE-SWE主要评测 Agent 对公开 Issue 和 PR 中已有问题的修复能力;SuperCLUE-DeepSWE 则在真实开源仓库中设计没有公开答案的中文原创新功能。Agent 需要自主理解需求、探索仓库并完成跨模块实现,重点考查原创长程工程问题的求解能力,详细对比如下表所示。

2.从“短补丁”升级为“长程工程链路”:
SuperCLUE-DeepSWE 的题目不是只改一个函数或提交一段局部补丁,而是要求 Agent 在现有开源仓库中完整实现一项原创新功能。每道题通常涉及多个文件和模块,需要新增或修改数百行代码;Agent 需要从中文需求出发,自主定位相关模块,理解仓库已有约束,完成接口设计、核心实现、跨模块接入、兼容性处理和测试验证。
3. 从“匹配某个历史实现”升级为“验证可观察行为”
SuperCLUE-DeepSWE 围绕每道题的中文需求单独编写行为验证器,从公开 API、程序输出、文件系统副作用和资源生命周期等外部可观察结果判断新功能是否正确,并通过原有功能测试检查是否引入回归。评分不比较候选代码与参考补丁,也不要求使用固定的私有 helper、文件路径或实现结构;只要完整满足题面约定的功能行为,并且不破坏原有功能,不同的设计和实现方式都可以通过。
# 基准创新点
1. 中文需求与国际代码库的跨语言工程评测
使用中文描述真实开发需求,设计长程任务,评测模型能否将中文产品语义准确转化为跨模块工程实现。
2. 用完整功能开发替代零散代码修改
传统代码题通常只要求修改一个函数,SuperCLUE-DeepSWE 则要求模型像真实工程师一样,在大型项目中完成一项可交付的新功能,覆盖接口设计、跨模块开发、兼容处理和测试验证。
3. 专门检验模型能否把复杂需求“做全、做对”
题目不仅测试主功能,还加入边界情况、异常流程和新旧功能兼容等真实工程难点,能够识别“看起来已经完成、实际上仍遗漏关键要求”的答案。
# 基准任务介绍
SuperCLUE-DeepSWE面向真实开源仓库设计原创软件工程任务,以实现原创新功能为主,覆盖前端、开发者工具、Web 基础设施、数据库、文件系统、分布式系统、数据校验和算法等技术领域。每道题归入一个主要领域,并根据实际考查内容标注事务、并发、状态机、资源治理、API 设计等能力标签。
仓库的选择标准为:
- ⭐ Star 数超过 4,000
- 💻 覆盖 Python、TypeScript、Go、Rust、Java、JavaScript等语言
- 🧪 具备单元测试和 CI
- 🌏 适合设计中文原创需求
- 📄 许可证允许评测和分发
- 📦 环境及依赖可固定复现
- 🚫 不依赖真实云服务或专用硬件
包括但不限于以下技术领域和参考仓库:

SuperCLUE-DeepSWE 以困难题为主。题目通常需要跨多个文件和模块(至少4个)进行修改,并新增或调整数百行代码(至少400行)。
# 测评流程与评分方法
测评流程
下图展示了SuperCLUE-DeepSWE从任务准备、智能体作答到独立验证与评分的完整流程。智能体首先在隔离的无网络Docker环境中根据任务描述修改代码,系统随后提取代码补丁,并在全新的无网络Docker容器中运行隐藏的 F2P 功能测试和 P2P 回归测试。
评分方法
每个任务采用二元评分:只有全部 F2P 测试(验证功能修复)和全部 P2P 测试(验证无功能回归)均通过时得 1 分,否则得 0分;补丁无法应用、测试缺失或被跳过也视为失败。F2P、P2P 通过率和 partial 仅用于诊断,不计入最终成绩。模型最终成绩为所有任务得分的平均值,即:
最终成绩的计算
最终成绩= 得分为1的任务数/ 参评任务总数*100%
# 示例展示
【语言】:rust
【标签】:Rust,Deno,锁文件,依赖图,包管理,平台兼容
【输入指令内容】:
我们有一个 Rust 构建服务,直接使用仓库里的 `deno_lockfile`。一个 monorepo 共用 `deno.lock`,但每个部署镜像只需要其中几个 workspace 成员。现在手工删 JSON 很容易漏掉 JSR 转 npm 的依赖、npm alias/peer 实例或平台相关依赖;保留整个锁文件又会让无关服务的升级影响部署产物。请给这个库增加一个纯内存的部署投影 API。调用方需要以下公开接口(从 crate 根导出);类型至少实现 `Debug`、`Clone`,options 还要有 `Default`,默认所有集合为空、`include_root` 为 false、`target` 为 None:```rustpub struct LockfileProjectionTarget { pub os: String, pub cpu: String,}pub struct LockfileProjectionOptions { pub include_root: bool, pub members: Vec<String>, pub links: Vec<String>, pub specifiers: Vec<deno_semver::jsr::JsrDepPackageReq>, pub remote_roots: Vec<String>, pub target: Option<LockfileProjectionTarget>,}impl Lockfile { pub fn project( &self, options: &LockfileProjectionOptions, ) -> Result<Lockfile, LockfileProjectionError>;}```使用场景例如选择 `members: vec!["services/api".into()]`,额外加入构建器发现的 registry specifier 和 HTTP 模块入口,再指定 `linux` / `x64`。请按下面的约定实现:- `members`、`links` 精确匹配锁文件 workspace 中的键;未知键报错,重复选择无影响。root 只由 `include_root` 选择。每个被选成员的 Deno 和 package.json dependencies 都是入口。links 是调用方明确提供的额外入口:锁文件没有足够信息推断路径归属,不要把所有 links 或 root 自动加入。保留被选 workspace 记录,去掉未选记录;root 的 overrides 仅在选择 root 时保留。- 只用已有锁定结果计算闭包,不查询 registry、不重新解版本。保留实际用到的 specifier 映射、JSR 包及其依赖、npm 普通/optional/optional-peer 依赖;同一包的不同 peer 上下文是不同实例,npm 依赖的别名也必须保留。完整 npm ID 是不透明标识,实际依赖边来自记录,不能仅靠拆 peer 后缀猜依赖。没有用到的 specifier 映射即使指向已保留包也应删除。环和共享子图必须正确处理,深链不能导致栈溢出。- 不指定 target 时保留所有平台的可选依赖。指定时,os/cpu 分别匹配后取交集:空列表不限制,`!value` 否决该值;存在正项时还必须命中一个正项。值按 Node 平台名精确匹配。只允许删除直接指向不兼容包的 optional/optional-peer 边,并同步删除这条边的记录;该包若仍从必需边或入口可达则必须报错。一个兼容的可选包内部的必需依赖仍按必需边处理。被选 link 的 optionalDependencies,以及 peerDependenciesMeta 中 `optional: true` 的 peer,也遵守此规则;去掉后者时同步移除其 meta 条目。meta 用带 scheme、无版本的键(如 `npm:/peer`),与该 link 中同 scheme、同包名的 peer 对应。不要访问已被过滤分支里的依赖。- 被选入口或保留边缺失 specifier 映射、包记录时都报错,包括可选边:缺记录不能被当作平台不兼容。未被访问的无关残留记录不能让投影失败。错误实现 `std::error::Error`,信息能区分原因并指出出错的键/请求/包或 URL。- `remote_roots` 是调用方收集的所有 HTTP 模块入口,用锁文件现有 redirects 一直跟到 remote checksum;只保留经过的重定向与终点 checksum,支持共享尾部,遇到环或缺失终点报错。URL 键精确匹配;一个键若同时有 redirect 和 checksum,优先跟 redirect。不要推测锁文件没有记录的 HTTP import 边。- 保留下来的 integrity、tarball、安装标志、平台约束及未被删除的 workspace/link 元数据保持原样。输出沿用现有标准锁文件格式,可被现有 reader 读回;重复投影和输入选择顺序变化应产生相同字节。空选择得到空锁文件。成功与失败都不能改变原对象、写磁盘或访问网络;结果保留 filename/overwrite,`has_content_changed` 等于原有标记或序列化内容发生变化,并继续遵守 `resolve_write_bytes` 的行为。这次范围是库 API,不需要新增 Deno CLI 命令。请在现有库结构中完成可维护的实现、补充使用文档和相关测试,保持已有读取、升级格式、配置变更清理及序列化测试通过。实现结构和错误类型的具体组织由你决定;遇到未约定的兼容性问题可以提出权衡。仓库在 `/app`;环境已准备好 Rust 工具链与该库的离线依赖,可用 `cargo test --locked --offline -p deno_lockfile` 验证。请提交你的改动到 git,评测会收集相对于固定基线的已提交补丁。
【DeepSeek-V4.1-Flash(max)在Clude Code中最终的回复内容为】:
已完成。投影 API 已实现、测试、补充文档并提交。> ## 新增内容> **`libs/lockfile/projection.rs`**(新增)——包含全部核心逻辑以及 21 个单元测试:> - 新增 `LockfileProjectionTarget`、`LockfileProjectionOptions` 和 `LockfileProjectionError`。 - 新增 `Lockfile::project(&self, options) -> Result<Lockfile, LockfileProjectionError>`。该操作不会修改源对象、访问磁盘或使用网络;它会保留 `filename` 和 `overwrite`,更新 `has_content_changed`,并保持 `resolve_write_bytes()` 的原有行为。 - 遍历采用迭代式工作队列,因此深链和环不会导致栈溢出。npm ID 被视为不透明标识,alias 和带 peer 上下文的实例会得到保留,并且只保留实际使用的 specifier 映射。 - 平台过滤只移除指向不兼容包的 optional 或 optional-peer 边。兼容的可选包会保留其必需依赖;如果某条被删除的可选边在其他位置仍属于必需依赖,则返回错误。过滤 link 的 optional peer 时,会同步删除对应的 `peerDependenciesMeta` 条目。 - `remote_roots` 会沿重定向继续解析;重定向优先于 checksum,共享尾部会被去重,遇到环或缺失终点时返回错误。> **`libs/lockfile/lib.rs`**——加入 projection 模块,并重新导出上述三个公开类型。> **`libs/lockfile/tests/projection_test.rs`**(新增)——加入 3 个仅通过公开 API 执行的集成测试,覆盖 member/link/remote 选择、root inclusion、目标平台过滤、幂等性和错误类型。> **`libs/lockfile/README.md`**——加入使用示例,并说明相关语义和行为保证。> ## 验证结果> `cargo test --locked --offline -p deno_lockfile`:45 + 3 + 3 + 37 + 1 个文档测试全部通过。`cargo clippy -p deno_lockfile --all-targets` 检查无误。> 已在 `feat/lockfile-projection` 分支提交为 `4e10652f`,当前工作树干净。
【对其的评测结果为】:
"parser_results": { "empty_selection_and_default_flags": "passed", # 默认配置与空投影正确 "workspace_selection_closes_mixed_cycle_and_preserves_metadata": "passed", # workspace、JSR/npm 混合环及元数据正确 "multi_root_preserves_distinct_peer_instances_and_alias_edges": "passed", # 多入口、peer 实例和 alias 正确 "root_links_and_extra_specifiers_are_independent": "passed", # root、link、额外 specifier 相互独立 "unknown_selectors_are_exact_and_diagnostic": "passed", # 未知选择器的精确匹配与错误信息正确 "only_used_specifiers_survive_even_when_same_resolved_package_is_kept": "passed", # 只保留实际使用的映射 "required_platform_conflict_is_not_optional": "passed", # 同一包同时作为入口和可选依赖时能发现冲突 "ordinary_edge_to_incompatible_package_errors": "failed", # 普通必需边指向平台不兼容包时没有报错 "compatible_optional_package_keeps_its_required_edges_required": "failed", # 兼容可选包内部的不兼容必需依赖被错误接受 "excluded_optional_branch_does_not_validate_broken_descendants": "passed", # 被过滤分支未被继续访问 "missing_optional_records_cannot_be_silently_skipped": "passed", # 缺失可选记录时正确报错 "platform_lists_use_veto_and_positive_intersection_without_order_dependence": "passed", # OS/CPU 正负规则正确 "link_optional_and_peer_metadata_are_projected_together": "passed", # link optional peer 与 meta 同步正确 "missing_link_optional_mapping_is_an_error": "passed", # link 可选映射缺失时正确报错 "link_required_peer_incompatibility_errors": "failed", # link 的必需 peer 平台不兼容时没有报错 "missing_selected_registry_records_are_errors_but_unreachable_damage_is_not": "passed", # 缺失记录与无关残留处理正确 "malformed_visited_jsr_resolution_is_diagnostic": "passed", # 非法 JSR resolution 的诊断正确 "remote_shared_tail_and_direct_root_preserve_only_reachable_checksums": "passed", # HTTP redirect 共享尾部正确 "redirect_precedes_checksum_and_errors_are_atomic": "passed", # redirect 优先级与失败原子性正确 "missing_direct_remote_root_and_self_loop_fail": "passed", # 缺失 remote 与自环正确报错 "dirty_and_overwrite_flags_follow_existing_write_protocol": "passed", # dirty/overwrite/write 状态正确 "long_package_and_redirect_chains_are_iterative": "passed", # 12,000 节点深链无栈溢出 "generated_graph_closure_matches_independent_reachability_model": "passed", # 生成图闭包与独立模型一致 "peer_suffix_is_identity_not_an_additional_dependency_source": "passed", # peer 后缀未被误当作依赖边 "all_root_categories_combine_as_a_union": "passed" # 所有根类别能够正确取并集}"summary": { "new_feature_tests": "22/25", # 25 个新功能测试中通过 22 个 "upstream_regression_tests": "64/64", # 64 个上游原有功能测试全部通过 "new_feature_completion_rate": "88%", # 新功能测试通过率为 88% "regression_preservation_rate": "100%", # 未破坏任何被测的原有功能 "diagnostic_partial": "96.63%", # 新功能与回归测试合计通过 86/89,仅作诊断参考 "final_reward": 0 # 采用严格全通过规则,存在失败项,因此最终得分为 0}
评测结果显示,DeepSeek-V4.1-Flash(max)通过了 22/25 个新功能测试和全部 64 个原有功能测试。主要缺陷是平台兼容性检查只覆盖了 optional/optional-peer 边,普通依赖、必需 peer 以及可选包内部的必需依赖会被直接保留。若这些包与目标 OS/CPU 不兼容,正确行为应是报错,而模型仍返回了成功结果,因此与必需依赖平台兼容性相关的 3 个检查点未能通过
按照评测规则,新功能测试和原有功能测试必须全部通过;只要存在错误或未通过项,最终得分即为 0 分。
# 参与测评
参测流程
1.邮件申请
2.意向沟通
3.参测确认与协议流程
4.提供API接口或大模型
5.获得测评报告
邮件标题:智能体终端任务测评SuperCLUE-DeepSWE申请,发送到contact@superclue.ai请使用单位邮箱,邮件内容包括:单位信息、大模型简介、联系人和所属部门、联系方式
联系我们

