最强AI编程模型在SWE-bench Verified上刷到了96%的高分，但换到SWE-Bench ProMax，同样的模型只拿下了41.2%。
这不是同一个基准测试的版本迭代，而是两个世界的差距。
2026年8月10日，由香港科技大学、南方科技大学等机构联合完成的论文《SWE-Bench ProMax: Benchmarking Agents on Large-Scale Multilingual Code Refactoring》被提交至arXiv，并被COLM 2026收录为会议论文。这篇论文带来的不只是一个新的基准测试，更是一份关于AI编程智能体真实能力的验尸报告。
基准测试的信任危机
在讨论SWE-Bench ProMax之前，必须理解它诞生的背景——一个正在蔓延的基准测试信任危机。
2026年2月，OpenAI发布了对SWE-bench Verified的审计报告。结果令人不安：在未被解决的实例中，近60%包含有缺陷的测试。这些缺陷分为两类——过于狭窄的测试会拒绝正确的解决方案，过于宽泛的测试则检查了未说明的要求。换句话说，模型可能写出了正确的代码，却被错误的测试判了不及格；也可能恰好猜中了测试的偏好，而非真正解决了问题。
更严重的问题紧随其后。2026年7月8日，OpenAI再次发布审计报告，这次对准了SWE-bench Pro。在731个任务中，约27%到34%存在缺陷。审计还发现，前沿模型能够从训练数据中逐字复现黄金补丁——这意味着部分高分并非来自真正的推理能力，而是来自数据污染。
这一发现直接导致OpenAI在2026年2月撤回了对SWE-bench Verified的推荐。一个由自己构建并长期推广的基准测试，最终被自己亲手拉黑。
行业的反应更为剧烈。多个独立追踪器显示，SWE-bench Verified的头部模型得分逼近96%的饱和点，亚分之差已毫无意义。正如一位行业观察者所言：饱和的基准测试告诉你的，不是你的智能体有多强，而是那套考卷已经没用了。
SWE-Bench ProMax：什么是真正的难
正是在这种背景下，SWE-Bench ProMax选择了与现有基准测试完全不同的方向。
现有基准测试的核心任务是修复Bug——给定一个GitHub issue，模型需要定位并修复代码中的错误。这是一个重要但已经被过度优化的能力。SWE-Bench ProMax瞄准的是另一类更有挑战性的任务：代码重构。
什么是代码重构？它不是修Bug，而是对现有代码进行结构性的调整——重命名变量、拆分函数、重组模块、统一API接口——同时保证代码的外部行为完全不变。这就像在高速行驶的汽车上更换引擎：你不能让车停下来，不能让乘客感觉到任何颠簸，但引擎内部已经面目全非。
这种任务对AI编程智能体提出了三个维度的考验。
第一个维度是理解。模型必须理解整个代码库的结构，而不仅仅是一个函数或一个文件。引用调用链、接口依赖关系、类型系统——这些信息散布在多个文件中，模型需要像一位资深工程师一样建立起全局认知。
第二个维度是协调。重构通常涉及大量跨文件的修改。SWE-Bench ProMax的每个实例平均需要修改11.4个文件、261.6行代码。相比之下，SWE-bench Verified的典型任务只涉及1到2个文件的修改。一个数量级的差距。模型必须确保所有修改同步进行、相互一致，而不是逐个文件地打补丁。
第三个维度是保鲜。重构的核心约束是行为保持——修改后的代码必须通过所有现有测试。这意味着模型不能只看起来改对了就交差，它必须确保每一次修改都是精确的、可验证的，且不破坏任何已有功能。
170个实例，7种语言，一场被骗不到了的考试
SWE-Bench ProMax的构建过程本身，就是对现有基准测试方法论的一次系统性反思。
研究团队从真实世界的GitHub提交中提取了170个重构任务，覆盖Python、Java、TypeScript、Go、C、C++和Rust七种编程语言。每个实例都经历了严格的多阶段筛选。研究团队从真实开源项目中提取重构提交，确保每个任务都来自真实的开发场景。然后为每个任务构建可复现的Docker执行环境，确保评测的公平性和可重复性。
最关键的一步是过滤与重写。研究团队手动重写了所有问题描述，确保规格说明精确无歧义。测试套件经过人工审查，移除了过于狭窄和过于宽泛的测试用例。复杂度不足或跨文件范围有限的任务被直接过滤掉。
这种清场式过滤的直接后果是：SWE-Bench ProMax的规模只有170个实例，远小于SWE-bench Pro的731个。但质量远高于数量——每个实例平均涉及11.4个文件修改和261.6行代码变更，远超现有基准测试的规模。
我们不需要更多的测试题目，我们需要的是每道题都真正能测出能力。这或许是SWE-Bench ProMax最核心的设计哲学。
41.2%：最强模型也只答对了四成
实验结果印证了设计者的判断。
研究团队在两种Agent框架上测试了多款前沿模型。结果令人深思。
GPT-5.2以41.2%的解决率位居榜首，但这距离SWE-bench Verified上75%以上的水平相距甚远。论文给出的评价是：SWE-Bench ProMax为当前AI编程智能体提出了一个有意义的、尚未饱和的挑战。
但更有趣的数据隐藏在成本分析中。
Claude Sonnet 4.6平均每次运行花费4.77美元，解决率为38.8%。而GLM-5——一个开源权重模型——平均每次运行仅花费0.24美元，解决率却达到了36.5%。两者的性能差距不到2.4个百分点，但成本差距将近20倍。
这组数据释放了一个清晰的信号：在代码重构这个高难度任务上，性价比正在成为比绝对性能更重要的指标。对于需要大规模部署AI编程智能体的企业而言，选择最贵的模型可能不是最优解。
失败的本质：为什么重构这么难
SWE-Bench ProMax最有价值的贡献，或许不是成绩单本身，而是对失败模式的深入分析。
研究团队对Agent轨迹的分析显示，失败的尝试一致地修改了比黄金补丁更少的文件，同时消耗了更多的交互轮次。这指向了一个核心问题：跨文件协调不完整。
AI编程智能体在处理多文件重构时，表现出一种局部优化的幻觉——它可能精确地修改了A文件中的某个函数，却没有意识到B文件中的调用点也需要同步更新。就像一位装修工人只换了客厅的墙纸，却没注意到卧室的墙纸已经被撕掉了一半。
这种失败模式在技术上被称为跨文件依赖漏报。当一个重构操作涉及5个以上的文件时，模型的失败率急剧上升。这不是简单的规模越大越难，而是存在一个明确的认知阈值——当需要协调的文件数量超过这个阈值，模型的推理能力就会出现系统性崩溃。
这解释了为什么SWE-Bench ProMax能够保持未饱和状态。现有的基准测试通常只需要局部推理，而重构需要全局推理。前者可以被数据量和参数规模暴力破解，后者则触及了当前AI架构的深层局限。
语言差异：不是所有代码都生而平等
SWE-Bench ProMax的另一个独特贡献是跨语言能力分析。
七种编程语言的覆盖使研究团队能够观察到一个现象：模型在不同语言上的表现差异显著。Python任务的表现普遍优于C++和Rust任务。这并非偶然——Python的简单类型系统和动态内存管理降低了重构的认知负担，而C++和Rust的复杂类型系统、生命周期管理和所有权模型则大幅增加了重构的难度。
这组数据对企业和开发者有直接的实践意义。如果你的代码库主要使用Python，AI编程智能体已经能够胜任相当一部分重构工作。但如果你的核心基础设施由C++或Rust编写，AI编程智能体目前的能力还远远不够。
终结刷榜游戏
SWE-Bench ProMax的出现，可能标志着AI编程智能体评估进入了一个新的阶段。
从SWE-bench诞生到SWE-bench Verified，再到SWE-bench Pro，最后到SWE-Bench ProMax——基准测试的演进史，本质上是一场攻防战：模型开发者不断优化模型去适应基准测试，而基准测试设计者则不断寻找新的防刷维度。
SWE-Bench ProMax的防刷策略是选择代码重构这个特定任务。重构的天然属性——跨文件协调、行为保持约束、多语言覆盖——使得简单地背答案或猜测试变得几乎不可能。研究团队还对问题描述进行了人工重写，彻底消除了语义歧义，进一步压缩了钻空子的空间。
但对整个行业而言，比基准测试本身更重要的，是一个正在成形的事实：AI编程智能体已经不再是一个能不能写代码的问题，而是一个能处理多大规模的工程问题的问题。
从单函数补全，到单文件Bug修复，再到多文件代码重构——这条能力的阶梯正在被一步步搭建。SWE-Bench ProMax告诉我们，当前AI编程智能体站在了重构这级台阶上，距离顶端还有很长的路。
当AI编程智能体学会了写代码，真正的考验才刚刚开始——因为工程从来不是从零开始，而是把别人的代码改对、改好、改得不留痕迹。
快报