在遥远的药都，有一本收录了2294个经验方的《民间验方录》。它本该是年轻医生的必读经典，可信度却备受质疑——有的方子记的明明是头痛，附带的疗效记录却在讲脚气；有的体温计本身就没校准，无论吃不吃药都显示退烧。用这样一本鱼龙混杂的药典去考核年轻医生，拿到的高分难免注水。 为了建立一套真正可信的“行医执照考试”，药典编委会请来一批资深药师，把2294个方子逐条复核：症状和治法是否对得上？疗效记录是否可靠？在标准药房里能否复现？经过一轮严审，只有500个方子经得起推敲，被单独编成《SWE-bench Verified经验方》。 如今，每一位宣称会修代码的AI新医生——也就是大模型，以及能自己翻阅病历、开检查单、追踪疗效的Agent——都要用这本Verified药典测一测真本事。这篇文章，我们就跟着药师的审稿过程，看看这本高可信药典究竟怎么炼成的。

岗位关联

对AI从业者而言：SWE-bench Verified是衡量大模型与Agent真实代码修复能力的行业标尺。理解它的筛选逻辑与评测设计，能帮你在模型选型、产品评测和Agent系统开发中做出更有依据的决策。

目录
  1. 可视化演示
  2. 基准背景溯源
  3. 可靠性痛点
  4. 人工验证筛选
  5. 评测判定规则
  6. 模型得分对比
  7. Agent评测价值
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

本节配有交互动效（进入视口后自动加载，约 3KB）。

基准背景溯源

在AI还不会“看病”的年代，代码出了bug只能靠程序员熬夜修。为了让AI学会修bug，普林斯顿大学的团队从代码托管平台GitHub上，翻出了12个热门Python仓库里的真实故障单（issue）和开发者随后提交的修复改动（PR），一对一对地整理成2294个“经验方”，这就是原始SWE-bench基准。

每个“经验方”由四味“药材”构成：病历、标准答案、退烧验证、保健验证。病历是issue里的问题描述，标准答案是开发者上传的正确修复补丁，退烧验证是修复前会失败、修复后必须通过的测试（FAIL_TO_PASS），保健验证是原本就通过、修完也不能坏的测试（PASS_TO_PASS）。模型要做的，是读完病历和整个药房库存，自己开出一张能通过全部验证的新方子。

这本民间药典虽然宝藏着上千真实病案，但要把它当作标准化考卷，隐患却不少。下一节我们来看看药师们在复核时发现的那些“坑”。

I=(R, P, TF2P, TP2P)\displaystyle \mathcal{I} = (\text{R},\ \text{P},\ T_{\text{F2P}},\ T_{\text{P2P}})
这是SWE-bench中一个任务实例的数学表示：仓库快照R与标准补丁P构成题干与答案，F2P和P2P两组测试构成评分标准。
  1. 仓库快照 R（病历与药房）包含issue问题描述的代码仓库状态，模型要先读懂这段病情，才能对症下药。
    R={代码文件, issue文本, 错误信息}\displaystyle \text{R} = \{\text{代码文件},\ \text{issue文本},\ \text{错误信息}\}
  2. 参考补丁 P（标准答案方子）人类开发者在PR中提交的正确修复，用于确认“这病确实能治”。
    P=人类开发者提交的修复补丁\displaystyle \text{P} = \text{人类开发者提交的修复补丁}
  3. 退烧验证 T_F2P（病情转好的指标）在基线上失败、应用P后通过的测试集合，证明bug确实被修好了。
    TF2P={t∣base(t)=fail, apply(P)(t)=pass}\displaystyle T_{\text{F2P}} = \{t \mid \text{base}(t)=\text{fail},\ \text{apply(P)}(t)=\text{pass}\}
  4. 保健验证 T_P2P（防回退指标）基线上通过、应用P后仍须通过的测试集合，防止修了A病却弄坏B器官。
    TP2P={t∣base(t)=pass, apply(P)(t)=pass}\displaystyle T_{\text{P2P}} = \{t \mid \text{base}(t)=\text{pass},\ \text{apply(P)}(t)=\text{pass}\}

可靠性痛点

药典编委会在抽查《民间验方录》时发现，相当一部分方子其实“名不副实”。第一种坑是测试与issue无关：某个方子记的是头痛，可它的体温计量的是脚气温度，模型随便改一行代码就让测试通过了，根本没治头痛。第二种坑是环境难以复现：验证疗效需要特定的药锅（Python依赖版本、环境变量），很多方子的锅在标准药房根本支不起来。第三种坑更隐蔽——有些测试本身就是坏的，FAIL_TO_PASS测试在基线上并不失败，等于白卷也能判及格。

这些坑共同造成一个严重隐患：分数虚高。如果考卷本身不可靠，那么“模型解决了40%”这个数字就失去了物理意义。想象一下，一张错题百出的考卷，怎么能区分真学霸和运气好的学渣？原始基准缺少的，正是对“考卷质量”本身的控制。

靠自动脚本很难识别“测试与issue语义不符”这种模糊问题——就像机器可以数清药方有多少味药，却判断不了这些药是否对症。于是，编委会决定引入最可靠的审校力量：人类药师。

V=NvalidNtotal\displaystyle V = \frac{N_{\text{valid}}}{N_{\text{total}}}
可靠性V定义：有效实例数占总体实例数的比例。V越接近1，基准的分数越可信。原始SWE-bench从未系统统计过这个值，这正是Verified要动刀的地方。
  1. 有效实例 N_valid（经得起复核的方子）测试与issue语义相关、环境可复现、测试结果真实可靠的实例数量。
    Nvalid=通过人工复核的任务实例数量\displaystyle N_{\text{valid}} = \text{通过人工复核的任务实例数量}
  2. 总体实例 N_total（药典收录总数）原始基准中2294个候选任务实例。
    Ntotal=2294\displaystyle N_{\text{total}} = 2294
  3. 可靠性比例 V（药典含金量）有效实例占总体比例，反映一张考卷里多少题是“真考题”。
    V=Nvalid2294⪅1\displaystyle V = \frac{N_{\text{valid}}}{2294} \lessapprox 1

人工验证筛选

2024年，OpenAI团队联合SWE-bench原作者，请来了一批资深药师——专门的数据验证工程师，给原始候选实例逐一“坐堂复核”。复核不是走马观花，而是标准的三查流程：一查相关性，测试到底是不是在验证issue里描述的问题；二查真实性，在干净的代码库上重新跑一遍，确认F2P测试在基线上确实失败、P2P测试确实通过；三查可复现性，依赖能否安装、环境能否构建，确保“这个方子在标准药房里能复现疗效”。

这道工序耗时耗力，但价值巨大。它把“测试是否有效”这个原本靠猜的问题，变成了“有药师签字背书”的事实。审核完成后，2294个候选实例中只有500个通过验证，保留率约21.8%。这些经过人工背书的实例，就是SWE-bench Verified的核心资产。

拿到这本500条高可信验方，编委会还需要一套严格的“临床考核规则”——怎么判断AI开出的新方子到底算不算药到病除？这就是评测判定规则要回答的问题。

Yi={1,测试与issue相关 且 环境可复现0,其他情况,Verified={i∣Yi=1}\displaystyle Y_i = \begin{cases} 1, & \text{测试与issue相关 且 环境可复现} \\ 0, & \text{其他情况} \end{cases},\qquad \text{Verified} = \{i \mid Y_i = 1\}
每个实例i经过人工验证后得到一个二值标签Y_i：只有“语义相关”与“环境可复现”同时成立才被保留，最终500个实例进入Verified基准。
  1. 验证标签 Y_i（药师批注）每一位药师对第i个方子给出的“合格/不合格”判定，1表示通过，0表示淘汰。
    Yi∈{0, 1}\displaystyle Y_i \in \{0,\ 1\}
  2. 双条件判定（对症且抓得齐药）测试必须验证issue描述的问题（对症），且依赖环境可完整构建（抓得齐药），两个条件缺一不可。
    Valid(i)=相关(i)∧可复现(i)\displaystyle \text{Valid}(i) = \text{相关}(i) \wedge \text{可复现}(i)
  3. Verified集合（签字药方汇编）所有通过验证的实例组成的新基准子集，集合大小为500。
    ∣Verified∣=500≈2294×0.218\displaystyle |\text{Verified}| = 500 \approx 2294 \times 0.218

评测判定规则

有了可靠的药典，怎么给AI新医生打分呢？规则其实很朴素：把模型生成的补丁（方子）应用到代码库，然后现场“煎药试服”。第一关，原本在基线上失败的F2P测试必须全部转为通过，这代表头痛真的退了；第二关，原本就通过的P2P测试必须继续保持通过，这代表没有引发新毛病。两关同时通过，这道题才算“解决”（resolved）。

这套规则还暗藏一道防作弊机制。评委们知道，有的模型会耍小聪明——不在补丁里做真正的逻辑修复，而是直接硬编码返回期望值，让测试“假通过”。SWE-bench等基准会专门识别这类"logits hack"补丁并判为无效，倒逼模型给出真正的修复逻辑。

规则定好了，考卷也发下去了。接下来就是最激动人心的时刻——放榜，看看各路AI新医生在这本高可信药典下，到底能得几分。

Resolved(P)=∏t∈TF2P1[f(P,t)=1]  ⋅  ∏t∈TP2P1[f(P,t)=1]\displaystyle \text{Resolved}(P) = \prod_{t \in T_{\text{F2P}}} \mathbb{1}[f(P,t)=1] \;\cdot\; \prod_{t \in T_{\text{P2P}}} \mathbb{1}[f(P,t)=1]
指示函数1[·]为真时取1，否则取0。两个连乘分别表达“所有F2P测试通过”与“所有P2P测试不回归”，两者相乘意味着且关系：任一组有一个测试不满足，整体就是0分。
  1. 代入补丁后的测试结果 f(P,t)把模型补丁P应用到仓库后，运行测试t得到的结果，1为通过，0为失败。
    f(P,t)∈{0, 1}\displaystyle f(P,t) \in \{0,\ 1\}
  2. F2P连乘（退烧必查）每一个FAIL_TO_PASS测试都必须从失败变为通过。连乘语义是逻辑与——只要有一个还是失败，整个乘积为0。
    ∏t∈TF2P1[f(P,t)=1]\displaystyle \prod_{t \in T_{\text{F2P}}} \mathbb{1}[f(P,t)=1]
  3. P2P连乘（无新症必查）每一个PASS_TO_PASS测试在补丁后仍必须通过，防止模型拆东墙补西墙。
    ∏t∈TP2P1[f(P,t)=1]\displaystyle \prod_{t \in T_{\text{P2P}}} \mathbb{1}[f(P,t)=1]
  4. 整体乘积（双关齐下）两个乘积相乘，任何一组测试有任一失败，整道题即判为未解决。
    Resolved(P)∈{0, 1}\displaystyle \text{Resolved}(P) \in \{0,\ 1\}

模型得分对比

放榜日的成绩单，远比想象的更有戏剧性。2024年中，GPT-4o在SWE-bench Verified上拿到约33%；几个月后Claude 3.5 Sonnet冲到约49%；到2025年初，采用智能体（Agent）模式的Claude 3.7 Sonnet一举站上约70%的高地。而如果让这些模型退化成“一次性生成补丁”，得分往往会拦腰斩断——同样的模型，用Agent模式自主浏览仓库、运行测试、根据报错反复修改补丁，分数立刻跃升一个档次。

这说明“医术”由两部分构成：一部分是记忆里的医学知识（模型参数中蕴含的代码理解），另一部分是和病人打交道的临床决策（读取日志、运行测试、根据反馈迭代）。后者正是Agent相对普通大模型的核心优势。解读成绩单时还要留意：500个样本的通过率带有统计误差，49%和55%的差距未必说明谁真的更强。

成绩单上的数字很耀眼，但Verified的价值不只是“谁考了第一”。对研究Agent和AI编程的人来说，这500个高可信实例更像是给整个领域装上了一块可靠的“体检仪”。

Resolve Rate=1∣D∣∑i=1∣D∣1resolved(i)\displaystyle \text{Resolve Rate} = \frac{1}{|D|} \sum_{i=1}^{|D|} \mathbb{1}_{\text{resolved}}^{(i)}
修复成功率是Verified基准的核心总分：在给定数据集D（500个实例）上，判定为“解决”的实例数占总数的比例。这正是各家模型排排行榜所依据的数字。
  1. 数据集大小 |D|（参考考生数）Verified基准集包含500个任务实例，是得分计算的基数。
    ∣D∣=500\displaystyle |D| = 500
  2. 单位置分判定 1_resolved对第i个实例，用上一节的resolved规则判定，解决取1，未解决取0。
    1resolved(i)=Resolved(Pi)\displaystyle \mathbb{1}_{\text{resolved}}^{(i)} = \text{Resolved}(P_i)
  3. 求和与平均（算总账）把所有实例的0/1分数累加，再除以总数，得到0到1之间的通过率。
    1500∑i=15001resolved(i)\displaystyle \frac{1}{500} \sum_{i=1}^{500} \mathbb{1}_{\text{resolved}}^{(i)}

Agent评测价值

Verified药典催生的不只是一场考试，更是一整套“住院医师规范化培训”标准。过去，我们很难客观回答“一个AI Agent的编程能力到底有多强”——它需要理解大型代码仓库的结构，在数万个文件里定位问题根源；它需要调用搜索、编译、运行测试、编辑文件等工具；它还需要在错误反馈中保持冷静，多步推理并迭代修复。SWE-bench Verified把所有这些能力浓缩进500个真实任务里，成为Agent能力图谱的试金石。

从工程效能的角度看，Verified还提供了横向对比的锚点：不同框架、不同模型的Agent可以在同一套可信考卷上比较。当你给Agent改了一版Prompt或换了一套工具调用逻辑，跑一遍Verified就能看出是进步还是倒退。它的演进方向也很明确——多语言扩展、多模态界面（SWE-bench Multimodal）、更严格的数据泄漏隔离，让这把尺子越来越精准。

药典会不断增订，新病种会不断收录，但“经得起复核”的原则永远不会变。理解了Verified的来龙去脉，你就能在五花八门的排行榜里，挑出真正值得相信的数字。

CI=p^±zα/2p^(1−p^)N\displaystyle \text{CI} = \hat{p} \pm z_{\alpha/2}\sqrt{\frac{\hat{p}(1-\hat{p})}{N}}
置信区间公式：N=500、p̂=0.5时，95%置信区间约±4.4%。它提醒我们，Agent分数只有拉开约9个百分点的差距，才在统计上“显著”。
  1. 观测通过率 p̂（本轮实测成绩）模型在500个实例上的修复成功率，是置信区间的中心值。
    p^=解决数N\displaystyle \hat{p} = \frac{\text{解决数}}{N}
  2. 临界值 z（置信档位）95%置信水平下取1.96，表示“真实水平约95%概率落在区间内”。
    z0.05/2≈1.96\displaystyle z_{0.05/2} \approx 1.96
  3. 标准误（样本波动的尺子）开方项衡量比例估计的波动幅度，N越大、标准误越小，区间越窄。
    p^(1−p^)N\displaystyle \sqrt{\frac{\hat{p}(1-\hat{p})}{N}}
  4. 区间宽度（差异显著性判据）N=500时，±1.96×√(0.25/500)≈±4.4%，两个Agent差不到9个百分点，不能轻言谁更强。
    1.96×0.25500≈0.044\displaystyle 1.96 \times \sqrt{\frac{0.25}{500}} \approx 0.044

AI 应用场景

AI编程助手上线的“行医资格考”

阶段：模型评估与验收

解决的问题：发布AI自动修bug功能前，团队过去靠人工抽查若干issue，既主观又费时，无法量化“这个模型到底能不能放出去见用户”。SWE-bench Verified提供了统一、可信的500题考卷，让准入门槛有了明确数字。

具体案例：某IDE插件团队在上线AI补丁功能前，规定模型在Verified上通过率不低于40%才允许灰度内测；上线后每两周自动回归一次，分数下跌超过3个百分点立即告警排查。该做法让“AI修复功能变好了还是变坏了”从玄学变成了可追踪的工程指标。

企业代码智能体选型

阶段：模型与工具选型

解决的问题：各家模型厂商宣传的编程能力口径不一，有的报SWE-bench Lite，有的报HumanEval，放在一起根本无法横向比较。Verified因人工背书的高可信度，成为企业选型时可信的参考尺，尤其适合衡量“代码修复”这一核心场景。

具体案例：某金融科技公司要在GPT、Claude和自研代码模型中做技术选型，搭建了统一的评测流水线：先跑Verified 500题看通过率，再叠加私有业务代码集看领域适配度和成本/延迟。最终以“Verified通过率×单次修复成本”为综合指标，选择了自研模型+商业模型的混合方案。

Agent框架迭代的“每日体检”

阶段：迭代回归与质量保障

解决的问题：Agent框架引入新工具调用、新Prompt模板后，开发者难以快速知道整体能力是上升还是下降。若只在真实用户身上观察，周期太长、噪声太大。

具体案例：某Agent研发团队把Verified作为每日回归门禁：每次合并代码前，随机抽取其中100题跑一遍流水线，通过率不低于上一版本95%才放行；每周完整跑500题并记录趋势曲线。一个季度下来，团队靠该机制及时发现了某次重构使工具调用成功率下降12%的隐性回归。

Python 演示

python75 行
"""SWE-bench Verified 筛选流程与评测逻辑的简化模拟"""import random  def make_task(task_id):    # 构造一个模拟任务: 2个F2P测试 + 3个P2P测试    return {        "id": task_id,        "f2p": ["test_fix_a", "test_fix_b"],        "p2p": ["test_keep_1", "test_keep_2", "test_keep_3"],        "patch": None,    }  def auto_filter(task):    # 自动过滤: 模拟环境不可构建等原因, 约三成候选被淘汰    return random.random() > 0.3  def human_verify(task):    # 人工验证: 模拟测试与issue语义相关且可复现, 约七成八通过    return random.random() > 0.22  def build_patch(fixed_tests):    # 模型生成的补丁: 声明修复了哪些测试    return {"fixed": set(fixed_tests)}  def run_test(test_name, patch):    # 模拟测试执行: 补丁声明修复则通过, 否则按基线判定(keep开头默认通过)    if test_name in patch["fixed"]:        return True    return test_name.startswith("test_keep")  def is_resolved(task, patch):    # 判定核心: F2P全部通过 且 P2P不回归    for t in task["f2p"]:        if not run_test(t, patch):            return False    for t in task["p2p"]:        if not run_test(t, patch):            return False    return True  def main():    random.seed(42)    raw_tasks = [make_task(i) for i in range(100)]     verified = []    for task in raw_tasks:        if not auto_filter(task):            continue        if not human_verify(task):            continue        verified.append(task)     print("原始候选数量:", len(raw_tasks))    print("Verified 保留数量:", len(verified))     # 模拟模型补丁: 恰好修复所有F2P测试    resolved_count = 0    for task in verified:        patch = build_patch(task["f2p"])        if is_resolved(task, patch):            resolved_count += 1     print("模型解决数量:", resolved_count)    print("修复通过率: %.1f%%" % (100.0 * resolved_count / len(verified)))  if __name__ == "__main__":    main()
目的：用一个极简模拟器复现SWE-bench Verified的“原始候选→自动过滤→人工验证→双条件评测”全流程，帮助理解基准的筛选逻辑与resolved判定规则。
  1. def auto_filter(task):第一道闸门，用随机数模拟环境不可构建、格式不合格的候选被淘汰。
  2. def human_verify(task):第二道闸门，模拟人工药师核验“测试与issue相关且可复现”。
  3. def run_test(test_name, patch):模拟一次测试执行，补丁声明修复则通过，否则回到基线行为。
  4. for t in task["f2p"]: if not run_test(t, patch): return False逐个把关F2P测试，一个失败则整题不通过。
  5. for t in task["p2p"]: if not run_test(t, patch): return False逐个把关P2P测试，杜绝“修好A功能弄坏B功能”。
  6. patch = build_patch(task["f2p"])模拟一个完美对症的补丁：恰好修复所有F2P测试。
  7. random.seed(42)固定随机种子，保证每次运行筛选结果完全一致、实验可复现。

常见误区

误区模型在SWE-bench Verified上拿到70%，我就以为它能自动修好企业生产环境里七成的线上问题，直接部署上线。

正解Verified是“开卷考试”——题目给出了完整的issue描述、精确的测试用例和干净的代码快照。真实世界的bug往往描述模糊、复现路径不明、依赖环境千奇百怪。70%是“考卷分”而非“临床水平”，就像医学生笔试满分不等于能做一台复杂手术。把考试分数直接映射到生产环境，是典型的“考试成绩=工作能力”谬误。

为何常见：人们天然喜欢用一个数字概括复杂能力，而忽略了benchmark的封闭环境与真实世界开放环境的巨大差异。

误区以为那500个实例是OpenAI工程师亲手写补丁解决的题目，模型是“背答案”考出来的高分。

正解人工验证的对象是“测试用例质量”，不是“补丁答案”。药师们逐条复核的是：测试是否与issue相关、失败测试在基线上是否真的失败、环境能否复现。每个实例的参考补丁来自原仓库的人类PR，早在benchmark发布前就存在于GitHub上。Verified的价值在于把“错题”从考卷上划掉，而不是提供标准答案。

为何常见：“验证”这个动词容易让人联想到“解题”，而忽略了验证的真实对象是试题本身而非答题过程。

误区觉得Lite和Verified都是原始基准的子集，都是轻量版，选哪个都行，甚至混用两个榜单上的分数来对比模型。

正解两者目标完全不同。Lite是普林斯顿团队按实例成本低、单文件修改等原则挑出的300个“简单题型”；Verified是OpenAI按测试可靠性人工背书的500个“高可信题型”。一个是“更容易的题”，一个是“更可靠的题”。同一模型在两个榜单上的分数不能直接横向比较，混用排行榜数字会让结论失真。

为何常见：两个名字都带"SWE-bench"前缀，又都是原始集的子集，容易让人误以为只是数量不同的两个版本。

误区只要F2P全通过、P2P没回归，就认为模型生成的补丁和人类PR一样好，可以直接合入代码库。

正解测试覆盖的是有限样本。一个补丁可能通过所有测试，却只是针对特定输入打了补丁，没有修复深层根因；甚至可能出现“作弊补丁”——硬编码返回期望值让测试假通过。所以SWE-bench会专门识别这类logits hack并判无效，评测指标本身也在和“应试技巧”博弈。测试通过只是必要条件，不是充分条件。

为何常见：程序员习惯了“测试全绿=任务完成”的直觉，忽略了评测场景中模型可能存在的投机行为。

误区看到A模型在Verified上比B模型高3个百分点，立刻断言A的编程能力碾压B，据此做选型。

正解500个样本的二项分布标准误意味着约±4.4个百分点的95%置信区间。3个百分点的差距完全可能在统计噪声范围内，不足以支撑“碾压”结论。专业做法是计算置信区间、看多次运行的稳定性，并结合成本、延迟、任务难度分层来综合判断。

为何常见：人脑对百分比差异非常敏感，却对样本量毫无直觉，忽视了比例估计的统计波动。

面试题

Q1. SWE-bench原始基准的数据来源是？

单选题 · easy

  • A.竞赛平台人工构造的算法题
  • B.GitHub真实issue与PR← 正确答案
  • C.开发者访谈收集的需求
  • D.开源项目自动生成的文档

答案：B。SWE-bench从GitHub的12个热门Python仓库中收集真实issue和对应修复PR，保证任务来自真实软件开发场景。选项A是竞赛平台性质，C、D与代码修复任务无关，均不符合题意。

Q2. SWE-bench Verified的人工验证主要由哪个团队发起？

单选题 · easy

  • A.普林斯顿大学
  • B.OpenAI团队← 正确答案
  • C.谷歌DeepMind
  • D.微软研究院

答案：B。SWE-bench Verified由OpenAI在2024年发布，团队联合原始基准作者组织人工验证，从2294个实例中筛出500个高可信实例。普林斯顿是原始基准的作者，但Verified的验证工作是OpenAI主导发起的。

Q3. 一个SWE-bench任务实例包含以下哪些部分？

多选题 · mid

  • A.具体的问题描述← 正确答案
  • B.对应仓库的快照← 正确答案
  • C.修复前失败的测试← 正确答案
  • D.修复前通过的测试← 正确答案

答案：ABCD。任务实例四要素缺一不可：issue问题描述（题干）、仓库快照（上下文）、FAIL_TO_PASS测试（验证bug修复）、PASS_TO_PASS测试（验证无回归）。这正好对应文中“病历+药房+退烧验证+保健验证”的比喻。

Q4. "FAIL_TO_PASS"测试的正确含义是？

单选题 · mid

  • A.修复前失败修复后通过← 正确答案
  • B.修复前通过修复后失败
  • C.修复前后都必须失败
  • D.只用于评估性能开销

答案：A。F2P测试是bug存在的证据：在基线上失败，应用正确补丁后必须通过。它衡量“病有没有治好”。选项B描述的是回归，C是无效测试，D完全偏离语义。

Q5. SWE-bench Verified最终保留了多少个人工验证实例？

单选题 · easy

  • A.300个已标注样例
  • B.500个经过验证样例← 正确答案
  • C.2294个原始全量样例
  • D.1200个随机抽样样例

答案：B。OpenAI从原始2294个实例中经人工验证筛选出500个，保留率约21.8%。300是SWE-bench Lite的规模，2294是原始集规模，1200没有对应的公开基准版本。

Q6. 在SWE-bench判定中，补丁导致PASS_TO_PASS测试失败称作？

单选题 · mid

  • A.修复行为正确合理
  • B.引入了功能回归← 正确答案
  • C.属于漏洞利用攻击
  • D.与评测规则无关

答案：B。P2P测试本应一直通过，补丁让它从通过变失败，说明修复破坏了原有功能，即“功能回归”。用文章比喻来说，修好了头痛却让脚瘸了，考题判未解决。A与事实相反，C是另一种作弊形式，D显然错误。

Q7. SWE-bench Verified人工验证主要考察哪些方面？

多选题 · hard

  • A.测试可在既定环境安装运行← 正确答案
  • B.测试与issue语义高度相关← 正确答案
  • C.失败测试在基线上确实失败← 正确答案
  • D.参考补丁的代码风格优雅

答案：ABC。三查流程包括：可复现性（环境能装、测试能跑）、相关性（测试验证的是issue描述的问题）、真实性（F2P在基线上确实失败、P2P确实通过）。代码风格不属于验证范围，验证对象是测试用例而非补丁的优雅程度。

Q8. 关于500个实例的分数置信区间，以下哪个说法正确？

单选题 · hard

  • A.样本量太小无法给出结论
  • B.误差约正负四个百分点← 正确答案
  • C.误差不超过千分之一
  • D.绝对分数无需考虑样本

答案：B。N=500、p̂=0.5时，95%置信区间约为±4.4%。这意味着模型间小于9个百分点的差距在统计上不显著。A低估了500样本的统计效力，C错误地认为样本足够精确，D完全忽略了抽样误差。

Q9. 同一模型在Agent模式下得分远超直接生成补丁，根本原因是？

单选题 · extreme

  • A.调用了更强大的模型
  • B.自主探索并迭代修复← 正确答案
  • C.直接访问参考补丁
  • D.只处理简单问题实例

答案：B。Agent模式允许模型浏览仓库结构、运行测试、读取报错信息并反复修改补丁，形成“观察→行动→反馈→修正”的闭环。这如同医生通过询问病史、查看化验单逐步确诊。A是模型规模问题，C是作弊，D与Benchmark的任务分布无关。

Q10. SWE-bench Verified作为Agent评测基准的价值体现在？

多选题 · mid

  • A.评测仓库理解能力← 正确答案
  • B.评测多步推理能力← 正确答案
  • C.评测环境与测试可信度← 正确答案
  • D.替代所有单元测试框架

答案：ABC。Verified用真实issue考察Agent在大型代码仓中的定位能力（理解仓库）、工具调用与排错迭代（多步推理），其核心特色是通过人工验证保证测试环境与结论可信。D是错误的夸大——它是评测基准，不是开发期的测试框架。