2024年8月，OpenAI悄悄停止在官方页面上展示一个叫SWE-bench Verified的成绩。
这事儿当时没多少人大张旗鼓地讨论，但懂行的人都明白其中的尴尬：这个曾经被当作衡量AI编程能力的黄金标准,被发现最强的那批模型已经能直接"背"出标准答案了。不是因为它们真的多聪明，而是因为这些测试题目本身，早就被悄悄塞进了训练数据里。
这就像一场考试，题库用了三年没换,等你发现满分学生越来越多的时候,才意识到答案可能早就在课本的某个角落里印着了。
**这不是个例,而是整个编程基准测试领域正在面临的系统性危机。**
你可能会问,换一批新题不就行了?问题恰恰在这里。
测试题会"过期",但这不是唯一的麻烦
先说说这件事到底有多普遍。
像SWE-bench-Live、SWE-rebench这些后续出现的基准,确实想到了"用新鲜题目"这个解法,它们专门抓取模型训练截止日期之后才出现的GitHub问题。听起来挺聪明,但这里藏着一个更深的坑:这些题目来自人类开发者的日常issue,而人类开发者的日常issue,难度上限就摆在那儿。
换句话说,题目是新的,但题目有多难,是由人类程序员平时随手写的bug决定的,而不是由被测试的AI决定的。
打个比方。假设你是体育老师,想测试一群运动员的短跑能力。你每年换一批新的跑道、新的发令枪,题目确实"新鲜"了。但如果这些运动员的训练强度一年比一年猛,而你设定的100米距离永远是100米,终有一天所有人都能跑进10秒,你的测试就失去了区分度。
距离本身,得跟着运动员的能力一起变长。
另一条路是让模型自己生成测试任务,这个思路本身不新鲜。
**论文SWE-Duel: Towards a Self-Scaling Arena for Coding Agents** (以下简称SWE-Duel) 提到了两个先行者:BugPilot收集AI智能体在添加新功能时意外引入的bug,SwingArena则让两个大模型互相对抗,一个提交补丁、一个写测试去验证。
但这两者都没有彻底解决问题。
BugPilot生成的任务集是提前准备好、固定不变的,相当于题库虽然来自AI之手,但还是一次性打包好的,不会随着被测模型变强而变难。SwingArena虽然引入了对抗机制,但它的题目素材依然来自固定的人类GitHub issue池子,只是让AI去写测试用例,题目本身的难度上限,还是绕不开"人类随手写的bug有多难"这道坎。
新加坡管理大学的研究团队由此提出了一个直击要害的问题:我们能不能做一个基准测试,它的题目和答案都在评测的那一刻才被创造出来,而且题目难度由参赛选手自己的水平决定?
这就是SWE-Duel要回答的问题。
红蓝对决:一场没有裁判出题的比赛
SWE-Duel的核心设计,是让两个编程智能体在真实的代码仓库上玩一场"红方蓝方"游戏。
每一轮对决,红方要做三件事:先在一个真实的开源项目里挑一个模块,设计并实现一个新功能,附带测试用例证明功能是对的;然后,红方要在这个刚刚写好的功能代码里,悄悄埋入一个不容易被发现的bug,同时写一套只有这个bug存在时才会失败的"密封测试"。
接下来轮到蓝方登场。蓝方拿到的是一份看起来人畜无害的代码提交(Pull Request,以下简称PR
> **PR**:程序员向代码仓库提交修改请求的常见方式,相当于"我写好了这部分代码,请审核后合并进主干"。
),里面有新功能、有功能测试,但没人告诉蓝方这里面藏着bug。蓝方的任务就是审查这份代码,如果发现问题就修复,然后提交自己的修改版本。
胜负怎么判定?蓝方的修改版本必须同时通过三道关卡:原有仓库的回归测试不能破坏任何已有功能,新功能的测试必须继续通过说明没把新功能改坏了,还有那个蓝方压根不知道存在的密封bug测试也必须通过。三关全过,蓝方赢;只要有一关没过,红方赢。
这个设计里有个特别巧妙的地方:蓝方没法作弊。
如果蓝方偷懒,直接把这个PR整体撤销回原始版本,听起来省事,但这样一来新功能的测试肯定会失败,因为功能压根没实现。想赢,就必须老老实实地读代码、找bug、修bug。
这就像公司新来了一个审计员,检查一份刚刚完成装修的办公室验收报告。装修公司在报告里写明"新增了会议室、新增了茶水间",审计员不能图省事直接说"推倒重来",因为验收标准里明确写着"必须保留新增设施"。审计员必须真的走进那个会议室,摸摸墙角、检查电路,才能发现那个被精心隐藏的、不影响表面美观但会在三个月后漏水的接缝问题。
如果不设置"功能必须保留"这道门槛,蓝方最简单粗暴的作弊方式,就是直接把代码打回原形,这样所有bug自然消失,但代价是新功能也一起消失了,这不叫修bug,这叫逃避问题。而SWE-Duel通过把bug藏在新功能内部,从设计上就堵死了这条逃生通道。
红方制造任务的过程还没完。论文里设计了一道极其关键的"自证"关卡:红方在埋完bug之后,必须换一个全新的、没有记忆的会话,重新面对自己刚刚制造的、只包含公开信息的代码(也就是蓝方将来看到的那个版本),尝试在盲审状态下把这个bug修好。
> **会话隔离(context-isolated sessions)**:每次新会话都是一次"失忆重启",智能体不会记得之前自己做过什么,只能靠传入的信息重新判断。
只有当红方自己能在盲审状态下修复这个bug时,这个任务才会被正式收录进"任务库",否则就视为生成失败,直接丢弃重来。
这道关卡的意义在于防止出现"无解的题目"。
想象一家出版社收到一份离谱的脑筋急转弯投稿,编辑在采用之前,会先找一个完全不知道答案、也没参与过创作的审稿人试着解答一遍。如果连这个审稿人都想不出来,这道题大概率是出题人自己都没想清楚的死局,不该收录进题库里误导读者。
如果没有这道自证关卡会怎样?红方完全可能为了追求胜率,埋入一个连自己都解释不清楚、逻辑上根本无解的诡异bug。这样的任务对蓝方不公平,对整个评测体系的可信度也是一种伤害。
任务库:一次生成,反复使用,但有保质期
有了经过验证的任务之后,这些任务会被存进一个"任务库"里。
这里有个设计细节值得说一说。每个参赛者(论文里叫"参与者",由一个大模型加一个执行框架组成,比如GPT-5.5配上Codex CLI)在每个代码仓库上,最多可以尝试生成固定数量的任务槽位,每个槽位允许连续尝试五次。如果五次都没能造出一个合格的任务(也就是三道验证关卡,功能验证、bug验证、自证验证都没通过),这个槽位就被记为"空槽",永远不会被重新填补。
> **harness(执行框架)**:给大模型提供工具调用、上下文管理、命令执行能力的"外壳程序",论文里用到了mini-swe-agent、Codex CLI、Claude Code三种。同一个模型换不同框架,相当于换了不同的参赛资格,各自独立计分。
这个"空槽不补"的规则,看似小气,背后其实有讲究:能不能造出一个合格的任务,本身就是这个参赛者编程能力的一部分体现。如果允许无限重试直到成功,那"造题能力"这个指标就被稀释了,因为理论上尝试次数足够多,谁都能撞出一个合格的任务。
这个任务库一旦生成完毕,就在整场比赛期间保持不变,所有对手面对的都是同一批题目,保证了公平性。但论文也特别说明,这个任务库不能无限期对外公开,因为公开之后它就不再"新鲜"了,未来评测新模型时这批题目就失去了意义。所以论文建议每次复现研究都重新生成一批任务,被公开过的任务库应当标记为"退休",不能再用来评测未来发布的模型。
真刀真枪的较量:11个参赛者,1500个回合
研究团队找来了当时最前沿的11组"模型+框架"组合参赛,包括GPT-5.5(分别搭配Codex CLI和mini-swe-agent两种框架)、Claude Opus 4.8(搭配mini-swe-agent和Claude Code两种框架)、Kimi K2.7 Code、DeepSeek V4 Pro、GLM-5.2、Qwen3.7 Max、Nvidia Nemotron 3 Ultra、MiniMax M3,以及Gemini 3.1 Pro。
比赛场地选在15个真实的开源项目上,横跨Python、Java、Go、JavaScript、C/C++五种编程语言,包括Flask、SQLAlchemy、Express这些你可能听说过的知名项目。十个初始参赛者两两捉对厮杀,打了一场完整的循环赛,凑出45场比赛;之后Gemini 3.1 Pro作为"迟到选手"加入,又打了5场。每场比赛包含30个回合(15个仓库乘以红蓝互换两个方向),总共1500个回合的较量。
结果怎么判定输赢?论文用了一个叫Bradley-Terry的评分体系
> **Bradley-Terry评分**:一种通过两两对战结果反推每个选手"实力值"的统计方法,广泛用于竞技排名场景,比如聊天机器人评测平台Chatbot Arena就是用这套方法给大模型排名的。
来给所有参赛者算一个综合实力分。
结果挺有意思。
排名第一的是GPT-5.5搭配Codex CLI,实力分+2.82。但它的强项不是出题,而是解题:它复审别人埋的bug时,98.3%的情况下都能把问题修好。
排名第二的是Claude Opus 4.8搭配mini-swe-agent,实力分+2.46。但它的强项恰恰相反:它当红方出题的时候,胜率高达27.3%,是全场最高,比排名第一的GPT-5.5(两种框架分别是11.3%和10.4%)高出一倍还多。这说明它埋的bug更难被发现。
**同一个榜单的前两名,靠的是完全不同的两种能力。**
一个是极强的"找茬选手",一个是极强的"藏雷高手"。这个发现本身就挺值得玩味:在软件工程这件事上,会解决问题和会制造有价值的难题,居然是两种相对独立的能力。
排名垫底的是MiniMax M3和刚加入的Gemini 3.1 Pro,它们不光是解题能力弱,更关键的问题在于连造题这件事都做得不够好,导致经常连一个合格的任务都生产不出来,这直接拖累了综合得分。
新选手怎么加入一场已经开打的比赛
这是SWE-Duel设计里一个挺实用的细节。
正常的循环赛,如果有N个参赛者,要让新人加入就得打N场比赛才能和所有人较量一遍。参赛者越多,新人入场的成本就越高,这其实是很多竞技型评测体系的痛点,新人想加入门槛越来越贵。
SWE-Duel借用了Chatbot Arena的"主动采样"思路:新选手只需要打大约log?N+1场比赛(10个老选手的情况下大约是5场),对手是算法智能挑选出来的,而不是所有人挨个打一遍。
这就像一个新来的辩论队员想加入一个已经打了半个赛季的联赛。按常理,他得和联赛里所有队伍都打一场友谊赛才能定级,但联赛组织者有一个更聪明的办法:根据历史战绩,挑出五个"信息量最大"的对手(比如一个实力中上、一个实力中下、几个实力相近的),打完这五场,大致就能推算出这个新人在整个联赛里大概排第几位,而不需要把其他几十支队伍都陪他打一遍。
Gemini 3.1 Pro就是用这个办法入场的,只打了5场比赛,最终排在第11位(垫底),置信区间显示它的排名大概率落在第9到第11名之间。更关键的是,加入它之后,原本45场比赛产生的排名顺序完全没变(用Kendall's τ系数衡量,相关性是满分1.0),说明这套"少量精选对手"的入场机制确实靠谱,不会因为抽样不足而扰乱原有秩序。
论文还算了一笔账:这种精选对手的入场方式,花费大约243美元;如果按老办法和全部十个老选手都打一遍,预计要花380美元左右。省了大概三分之一的评测成本。
任务难度真的会随出题者变强而变难吗
这是整篇论文里我觉得最有说服力的一个实验。
前面说了SWE-Duel的设计初衷是让"任务难度由参赛者自己的水平决定",但光靠理论说不行,得拿数据说话。研究团队专门设计了一个对照实验:固定一个解题的裁判(DeepSeek-V4-Pro搭配mini-swe-agent),然后让同一个模型家族里三个不同世代的版本去出题,分别是GLM-5.1、GLM-5.2、GLM-5.3,版本号越大代表越新、理论上也越强。
这三个版本各自在同样的15个代码仓库上生成任务,然后统一交给那个固定的裁判去解。
结果是这样的:GLM-5.1出的题,裁判只有8.3%解不出来;GLM-5.2出的题,裁判0%解不出来,全部搞定;而最新的GLM-5.3出的题,裁判有42.9%解不出来。
这个跳跃挺惊人的。新版本出的题,裁判失败率是老版本的十倍以上。论文还专门做了统计检验(单边精确条件Cochran-Armitage趋势检验),p值是0.015,说明这个上升趋势不是随机波动。
研究团队没有止步于此,还让这三个版本互相出题、互相解题,打了一场内部小型循环赛。结果显示,GLM-5.3出的题能让GLM-5.1输掉一半的回合(7/14)、让GLM-5.2输掉接近三成的回合(4/14),而两个老版本出的题,几乎没法难倒GLM-5.3(各自只赢了一次)。
这组数据合在一起说明一件事:**任务难度确实跟着出题者的能力水涨船高,而且这种关系在统计上是显著的。**
这恰恰是整篇论文想验证的核心假设:一个能自我进化的评测场地,题目难度不该是固定的天花板,而应该是一面随时反映参赛者当前水平的镜子。镜子里的影像变了,是因为站在镜子前的人变了,不是镜子本身被人为磨高了分辨率。
如果没有这个自我进化的机制,评测体系迟早会变成前面提到的SWE-bench Verified的翻版:模型越来越强,题目却原地不动,最后大家一起"背答案",测试本身失去意义。
一些细节上的较真:这套体系靠谱吗
论文里还花了不少篇幅去验证这套评测机制本身是否可靠,这种自我审视的态度挺难得。
比如说,红方埋的那个bug,是不是真的靠谱,会不会存在"蓝方明明修对了但因为测试写得太刁钻而被判错"的情况?研究团队专门找了两位作者,人工检查了50个蓝方失败的案例,发现只有6%左右属于"假阴性",也就是蓝方其实修对了,但因为密封测试要求过于具体而被误判。这个比例不算高,说明整体评判机制还算公道。
再比如,红方那道"自证"关卡本身靠不靠谱?因为模型推理过程带点随机性,同一个任务反复测试,结果可能不完全一致。研究团队挑了44个已经收录的任务,每个再重复测试三次,结果显示91.7%的情况下任务能被稳定地解出来,只有一个任务三次测试全部失败,说明"侥幸过关"的情况确实存在,但非常罕见。
还有个挺有意思的发现:研究团队专门把"硬件框架"这个变量单独拎出来做了对照实验,用同一个模型分别套上mini-swe-agent、Codex CLI、Claude Code三种不同框架,结果发现三者之间的实力差距在统计上并不显著,置信区间全部重叠。这说明至少在这个实验规模下,选哪个执行框架对最终战绩的影响,比不上模型本身的差异来得明显。
代价:这套评测体系要花多少钱
跑完这场1500回合的比赛,总共花费2109美元的API调用费用,平均每场比赛大约26美元。
这笔钱里,670美元花在红方出题环节(包括所有失败重试),158美元花在盲审自证环节,剩下1281美元花在蓝方解题评测上。蓝方解题这一块占了六成多的开销,这也不难理解,因为每个参赛者都要当一次蓝方去解其他所有人出的题,计算量自然最大。
写在后面
读完这篇论文,我印象最深的其实不是那张排名榜,而是那个"自证关卡"的设计。
很多评测体系想解决的问题都是"怎么让题目更难",但SWE-Duel花了相当篇幅去解决一个更根本的问题,"怎么证明这道题确实有解"。这个思路挺少见的。大部分竞赛设计者默认出题人是权威的,题目天然正确,SWE-Duel却把出题人自己也拉下水,要求他必须先在盲审状态下证明自己出的题不是无理取闹。这种"出题人自证清白"的机制,某种程度上是把信任建立在可验证的行为上,而不是建立在出题人的身份权威上。
另一个让我反复琢磨的细节,是GPT-5.5和Claude Opus 4.8在这个榜单上呈现出的分裂人格。一个是修bug的王者,一个是埋bug的高手,但谁也没能两头都占。这让我想起一个老生常谈但在这里被重新验证的道理:发现问题和制造有价值的难题,根本就是两种不同的认知路径,前者是收敛式的分析,后者是发散式的设计。会修车的师傅不一定会设计出一辆让同行师傅都头疼的故障车,这两件事看起来相关,实际隔着一道不小的门槛。
论文里那个GLM版本阶梯实验给出的数据(8.3%到0%再到42.9%)确实提供了初步证据,但样本量只有十几个任务,置信区间也不算窄。这个结论严格来说还只是"初步证据",离"已经证实"还有距离,论文自己也坦诚承认了这一点。我倒是挺好奇,如果把这个阶梯实验扩展到几十个任务、覆盖更多模型家族,这个趋势会不会依然成立,又或者会不会在某个阈值之后出现饱和,毕竟没有什么增长曲线是永远线性向上的。
这篇论文留了一道没写完的题。当参赛者之间的解题能力差距越来越小,他们的出题能力差距会不会也跟着收窄?如果真到了那一天,整个擂台又该怎么往前走?
Q&A
Q1：SWE-Duel是什么？
A：SWE-Duel是一个让编程AI智能体互相出题、互相解题的自我进化评测体系,红方在真实代码仓库中实现新功能并暗藏bug,蓝方盲审修复,任务难度由参赛者自身水平决定,从根本上避免了题目被提前泄露到训练数据中的问题。
Q2：SWE-Duel和SWE-bench这类传统编程基准测试有什么区别？
A：传统基准测试的题目是提前固定、公开发布的,时间一长容易被模型"背答案",且难度上限受限于人类开发者日常写的bug难度。SWE-Duel的题目和标准答案都是在评测当下由参赛AI现场生成的,不存在提前泄露的可能,难度还会随参赛者水平提升而自动变难。
Q3：SWE-Duel的比赛结果显示了什么有趣现象？
A：排名第一的GPT-5.5(配Codex CLI)是最强的解题者,审查bug修复成功率达98.3%;排名第二的Claude Opus 4.8(配mini-swe-agent)却是最强的出题者,埋藏的bug让对手失手的概率高达27.3%,两项能力并不重合在同一个模型上。
