想象你开了一家驾校，想测出学员最真实的开车水平。如果直接把他们丢到市中心马路上考试，车流、行人、天气全都不可控，学员会抱怨“这成绩不算数”。于是车管所建了标准化的科目二考场：统一车型、统一桩位、统一评判标准，谁也别想钻空子。SWE-bench 就是 AI 编程界的“科目二考场”——它从真实开源项目里收集开发者的 bug 报告（issue），装进统一配置的容器环境，要求 AI 像人类工程师一样阅读代码、动手修补，再由预设的测试科目逐一打分。读完这篇文章，你能完整看懂这个“考场”如何出题、如何布置、如何监考、如何算分，以及它为什么能成为衡量模型真实代码能力的主流标尺。

岗位关联

对 AI 从业者价值：掌握 SWE-bench 集成评测，你就能用可复现、可对比的方法量化模型代码能力，无论是模型选型、研发迭代还是内部质量把关，都有了客观依据。

目录
  1. 可视化演示
  2. 科目二考场：评测定位
  3. 考官出题：实例筛选
  4. 统一考车：环境配置
  5. 上车操作：集成流程
  6. 双重计分：评分机制
  7. 统计成绩：指标计算
  8. 驾校排行榜：基线验证
  9. 考前准备：实践要点
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

演示SWE-bench真实GitHub issue修复评估框架：四阶段评测流程、多文件协同修改与功能/性能/质量评测维度，展示软件工程能力量化方法，支持三模式切换。

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

四阶段评测流程 问题提取构建评测问题 环境构建+代码生成+验证评估 真实issue驱动的可复现评测

科目二考场：评测定位

车管所如果把学员直接丢到市中心马路上考试，车流、行人、天气全不可控，谁也说不清成绩到底公不公平。于是他们把真实驾驶技能抽象成倒库、侧方停车、坡道起步这些标准化科目，在封闭考场里逐一验证。SWE-bench 的出发点完全一样：真实世界的 GitHub issue 最能代表工程师日常遇到的“真问题”，比 LeetCode 那种给定函数签名的算法题接地气得多。

但真实 issue 零散且依赖环境，不能直接拿来评测。于是 SWE-bench 团队把每个 issue 包装成一个结构化的“考试实例”：来自哪个仓库、代码锁定在哪个提交、问题如何描述、人类最终如何修复、配套测试长什么样。五样东西齐全，AI 才有了一份可解释、可比较的“考题”。

有了这张考试单，后续的环境配置、模型作答和自动判分都有了统一的抓手，就像考场工作人员拿着同一张项目单给每辆考试车做检查一样。

I=(R, Cbase, Q, Pgold, T)\displaystyle I = \left(R,\ C_{\text{base}},\ Q,\ P_{\text{gold}},\ T\right)
这个元组就是一张“科目二考试单”：一个 SWE-bench 实例由仓库、基准提交、问题描述、黄金补丁和测试补丁五个要素构成。
  1. R仓库：指明该 issue 所属的开源项目，例如 Django 或 SymPy，相当于科目二考场的“场地类型”。
    R\displaystyle R
  2. C_base基准提交：代码库被锁定的那个 commit 快照，保证所有考生面对同一版本代码。
    Cbase\displaystyle C_{\text{base}}
  3. Q问题陈述：开发者提交的 issue 原文，就是 AI 读到的“考题描述”。
    Q\displaystyle Q
  4. P_gold黄金补丁：人类开发者最终合入的修复代码，是标准答案。
    Pgold\displaystyle P_{\text{gold}}
  5. T测试补丁：本次修复配套的测试用例，用来验证修复是否真实有效。
    T\displaystyle T

考官出题：实例筛选

科目二考的不是你能开多快，而是那些“有区分度、可判定、可复现”的技术动作。SWE-bench 出题同样有严格的过滤规则：问题必须能被自动化复现，仓库里必须有现成的测试基础设施，人类 PR 必须清楚地修复了该问题，且不同 issue 之间不能互相纠缠。这是为了保证每个实例都能独立评分，不会出现“这题修复了、那题又被改坏了”的扯皮。

经过层层筛选，原始池里的数万个 issue 最后留下 2294 个高质量实例，覆盖 Django、SymPy、scikit-learn 等 12 个主流 Python 仓库。官方又从中挑出最简洁、任务描述最清晰的 300 个构成了 SWE-bench Lite，方便研究者在资源有限时快速验证想法——相当于驾校为新手教练准备的“精简练习场”。

出题环节的质量决定了整个评测的可信度——如果题目本身模棱两可，后面再标准的考场也白搭。

Dfiltered={ I∈Draw  |  resolveable(I)∧testable(I) }\displaystyle D_{\text{filtered}} = \left\{\, I \in D_{\text{raw}} \;\middle|\; \text{resolveable}(I) \wedge \text{testable}(I)\,\right\}
这个式子说的是：SWE-bench 保留的实例，必须同时满足“可解决”与“可测试”两个条件，缺一不可。
  1. D_raw原始问题池：所有被收集到的真实 issue 集合，数量庞大但良莠不齐。
    Draw\displaystyle D_{\text{raw}}
  2. resolveable可解决性：该 issue 确实有清晰修复方案，人类已经提交过有效的修复补丁。
    resolveable(I)\displaystyle \text{resolveable}(I)
  3. testable可测试性：仓库具备运行测试的条件，能自动判断修复对错。
    testable(I)\displaystyle \text{testable}(I)
  4. ∧同时满足：两个硬条件必须同时成立，实例才能进入最终数据集。
    ∧\displaystyle \wedge

统一考车：环境配置

考场的第一个原则是“公平”：所有考试车必须调成同一配置。SWE-bench 在环境配置上做了三件关键的事。首先，用 Docker 镜像把操作系统、Python 版本和系统依赖一次性固定下来，相当于把整间考场装进一个集装箱。其次，项目依赖的精确版本被锁定在 base_commit 对应的状态，避免“我本地能跑、你本地跑不了”的经典问题。最后，每个实例都附带一个复现脚本，能在干净环境里稳定重现 bug 现象。

这套设计回答了一个关键问题：为什么不能直接在原始仓库上评测？因为真实项目的依赖随时在变，今天能复现的 bug 明天可能就被某次依赖升级掩盖了。只有把所有变量焊死，模型之间、论文之间的结果才可复现、可对比。

考车统一之后，考官才能放心地按同一套标准给所有学员打分——这是整个评测体系可信度的地基。

Env(I)=Docker(Python, deps(Cbase))\displaystyle \text{Env}(I) = \text{Docker}\left(\text{Python},\ \text{deps}(C_{\text{base}})\right)
环境函数把每个实例包装成一个自包含的 Docker 容器，内部是固定 Python 版本和与基准提交严格对应的依赖集合。
  1. Env环境函数：给定实例 I 生产出完全隔离的运行环境。
    Env(I)\displaystyle \text{Env}(I)
  2. Docker容器引擎：操作系统级别的虚拟化工具，保证环境与宿主机及外部网络完全隔离。
    Docker\displaystyle \text{Docker}
  3. deps(C_base)依赖锁定：根据基准提交解析出该版本项目依赖的精确版本列表。
    deps(Cbase)\displaystyle \text{deps}(C_{\text{base}})
  4. 统一结果任何模型在任何机器上拿到同一个 Env(I)，看到的代码和依赖完全一致。
    Env(I)=Env′(I)\displaystyle \text{Env}(I) = \text{Env}'(I)

上车操作：集成流程

考试开始了。学员上车后按照“听指令、操作、下车”的流程完成所有项目。SWE-bench 的集成流程对应着四步：第一，从数据集加载一个实例，把 issue 描述和基准代码库交给模型；第二，模型阅读代码并生成补丁（patch），也就是“作答”；第三，把补丁应用到基准代码上，模拟人类工程师的实际修改；第四，运行测试补丁，验证修复效果。

整个流程由评测框架自动串联，不需要人工干预。研究者既可以让模型一次性生成完整补丁，也可以让模型以 agentic 的方式多轮探索代码库、运行局部测试、根据报错反复修改，直到拿出最终补丁——就像科目二里，有的学员一把倒进去，有的学员要微调好几把方向。

集成流程的关键在于“自动化”：从发卷到验卷全链路无人为干预，任何模型在这样的考场上成绩都真实可信。

Verdict(I)=Test(Cbase⊕Pmodel, T)\displaystyle \text{Verdict}(I) = \text{Test}\left(C_{\text{base}} \oplus P_{\text{model}},\ T\right)
对实例 I 的最终判定，等于把模型生成的补丁应用到基准代码后，再运行测试补丁 T 所得到的结果。
  1. P_model模型补丁：被评测的 AI 输出的代码修改方案，是这场考试的“答卷”。
    Pmodel\displaystyle P_{\text{model}}
  2. ⊕应用补丁：把模型补丁合并进基准代码库，模拟真实开发中的一次代码修改。
    ⊕\displaystyle \oplus
  3. C_base ⊕ P_model修改后的代码：应用补丁后得到的新代码快照。
    Cbase⊕Pmodel\displaystyle C_{\text{base}} \oplus P_{\text{model}}
  4. Test(·, T)测试执行：在修改后的代码上运行测试补丁，输出每个测试用例的通过或失败。
    Test(⋅, T)\displaystyle \text{Test}(\cdot,\ T)

双重计分：评分机制

科目二为什么比科目三难考？因为倒库、坡起每个项目都有硬性点位，压线就扣分。SWE-bench 的评分也设计了双重硬约束。第一个叫 FAIL_TO_PASS（失败转通过）：这些测试在修复前必然失败，修复后必须全部通过——它们证明了 bug 真的被修好了。第二个叫 PASS_TO_PASS（通过仍通过）：这些测试在修复前本来就通过，修复后也必须继续通过——它们防止模型手忙脚乱把原本正常的功能改坏。

如果一个实例的模型补丁通过了所有 FAIL_TO_PASS，但弄挂了一个 PASS_TO_PASS，这个实例依然判为失败。这正是 SWE-bench 防止“假修复”和“回归破坏”的巧妙之处：它不只看你修好了什么，还要看你有没有弄坏什么。

这套双重计分机制就像科目二的“压线即扣分”：点位没压对要扣分，方向盘多打半圈压线也要扣分，整体下来才是真本事。

resolved(I)=⋀t∈TF2PTest(t)  ∧  ⋀t∈TP2PTest(t)\displaystyle \text{resolved}(I) = \bigwedge_{t \in T_{\text{F2P}}} \text{Test}(t) \;\wedge\; \bigwedge_{t \in T_{\text{P2P}}} \text{Test}(t)
一个实例被判为已解决，必须满足两个条件：所有“失败转通过”测试通过，并且所有“通过仍通过”测试也通过。
  1. T_F2P失败转通过集合：修复前是红色失败、修复后必须变绿的测试集合。
    TF2P\displaystyle T_{\text{F2P}}
  2. T_P2P通过仍通过集合：修复前是绿色通过、修复后不允许变红的测试集合。
    TP2P\displaystyle T_{\text{P2P}}
  3. ∧逻辑与：集合中的每个测试都必须通过，一个都不能挂。
    ⋀t∈TF2PTest(t)\displaystyle \bigwedge_{t \in T_{\text{F2P}}} \text{Test}(t)
  4. resolved已解决判定：两个集合全部通过时，实例才标记为“已解决”。
    resolved(I)\displaystyle \text{resolved}(I)

统计成绩：指标计算

考完所有项目，驾校要统计这一批学员的合格率。SWE-bench 最常用的指标是 pass@1：给定每个 issue，模型只生成一次补丁，能解决的实例数占总实例数的比例。为什么强调“只生成一次”？因为它最贴近真实开发者的使用方式——写一次代码就要能跑，不能偷偷试很多次。

在学术对比中，研究者也会报告 pass@k，即允许模型为同一个 issue 生成 n 个候选补丁，只要其中至少一个通过测试就算成功。这相当于“补考允许带小抄”的宽松版规则。多模型对比时，大家必须跑同一组实例、使用同一个评测脚本，否则成绩就像不同考场硬凑出来的合格率，毫无可比性。

成绩单一出，谁强谁弱一目了然。但指标本身也有局限，需要结合任务难度分布一起看，分数才能真正说明问题。

pass@1=∣{ I∈D  |  resolved(I) }∣∣D∣\displaystyle \text{pass@1} = \frac{ \left| \left\{\, I \in D \;\middle|\; \text{resolved}(I)\,\right\} \right| }{ |D| }
pass@1 就是“一次作答的解决率”：数据集 D 中被判定为已解决的实例数除以总实例数，结果越接近 1 说明模型代码修复能力越强。
  1. D评测数据集：全部参与打分的实例集合。
    D\displaystyle D
  2. 结构描述分子里的集合表示所有满足 resolved(I) 的实例。
    { I∈D  |  resolved(I) }\displaystyle \left\{\, I \in D \;\middle|\; \text{resolved}(I)\,\right\}
  3. |·|集合计数：统计通过实例的数量。
    ∣ ⋅ ∣\displaystyle \left|\,\cdot\,\right|
  4. 比值计算通过数除以总数，得到标准化的解决率指标。
    通过数总数\displaystyle \frac{\text{通过数}}{\text{总数}}

驾校排行榜：基线验证

一张可信的排行榜需要长期积累数据。SWE-bench 发布后，各大模型陆续“进场考试”，成绩单也被反复刷新。早期 GPT-4 等模型在全集上的 pass@1 只有个位数，说明真实大型代码库里的修复任务远比想象中复杂——找 bug 本身就难，改完不引入新问题更难。

随后研究者发现，把模型的推理方式从“一次生成补丁”升级为 agentic 工作流之后，成绩出现了大幅跃升。所谓 agentic，就是让模型像人类工程师一样多次浏览代码、运行测试、根据报错信息调整修复策略。到 2024 年底，以 Claude 3.5 Sonnet 为代表的模型配合 agentic 流程，已经能在 SWE-bench Verified 上逼近 50% 的解决率。这条上升曲线传递了一个明确信号：模型的代码能力不仅取决于参数规模，更取决于“如何与代码库互动”。

排行榜的意义不是制造焦虑，而是给行业一个客观参照：模型离“真正能接手的软件工程师”还有多远，以及哪条技术路线最值得投入。

pass@k=1−(n−ck)(nk)\displaystyle \text{pass@k} = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}
pass@k 的统计校正公式：从 n 个候选补丁中允许挑 k 个，至少命中一个成功补丁的概率，等价于 1 减去“全部错过”的概率。
  1. n候选总数：模型为同一 issue 生成的补丁数量。
    n\displaystyle n
  2. c成功补丁数：其中能够通过全部测试的补丁数量。
    c\displaystyle c
  3. C(n-c,k)全部失败抽样：从失败补丁里抽出 k 个的组合数。
    (n−ck)\displaystyle \binom{n-c}{k}
  4. C(n,k)全部抽样：从所有补丁里抽出 k 个的组合数。
    (nk)\displaystyle \binom{n}{k}
  5. 1 减比值拿“至少一次成功”的概率补集，得到最终 pass@k。
    1−(n−ck)(nk)\displaystyle 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}}

考前准备：实践要点

如果你真正负责在团队里把 SWE-bench 跑起来，有几条“考前须知”值得记牢。第一，Docker 镜像体积很大，每个实例动辄数 GB，务必提前批量预拉取并做好缓存，否则评测会卡在网络下载上。第二，模型输出的补丁必须转成严格的 git diff 格式才能被评测框架应用，格式一错，满盘皆输。第三，完整评测 2294 个实例需要大量 GPU 算力和时间，建议先用 Lite 子集验证流程，再逐步扩展到全量。

更隐蔽的坑是数据污染：训练集若包含这些 issue 或相近代码，分数会虚高。所以在解读任何“刷榜”成绩之前，先确认模型训练数据的时间线和评测集没有重叠。最后，记录每次评测的 commit 和依赖哈希，这是结果可复现的底线。

集成 SWE-bench 的实践，本质上是在把工程师的“考场直觉”沉淀成一套工程规范：环境一致、格式严格、数据干净、流程可回溯。做到这四点，你的评测结果才敢写进技术报告里给全行业看。

AI 应用场景

代码智能体发行前的“科目二”回归测试

阶段：模型评估与发布门禁

解决的问题：代码智能体在版本迭代时，经常面临“修好一个 bug、弄坏一片功能”的风险。传统做法靠人工抽查几个仓库，既慢又不全面。SWE-bench 集成后的评测流程可以把历史真实 issue 变成自动化回归集，每次模型更新都跑一遍，确保 F2P 持续通过、P2P 不退化。

具体案例：某 AI 编程助手团队在每次发布新版本前，从 SWE-bench 中抽 200 个与目标语言匹配的实例组成“考场”，用 Docker 并行起 200 个容器跑双测试约束。若解决率相比上一版下降超过 3%，发布流程自动阻断，让研发定向排查。

企业采购代码模型时的标准化对比

阶段：模型选型评估

解决的问题：企业想为内部开发者选一款代码能力最强的模型，供应商都说自己“最好”，但口径不一。传统做法是比 Demo 手感，主观且不可复现。用 SWE-bench 同一套实例，所有候选模型在相同环境里跑出 pass@1，成绩单一目了然。

具体案例：一家金融科技公司在选型时，让 GPT-4、Claude 和自研模型在同一组 300 个 SWE-bench Lite 实例上完成评测，同时记录耗时和 token 成本，最终结合解决率和单任务成本选择了最匹配自身预算的模型。

私有代码库的缺陷修复闭环验证

阶段：AI 辅助开发流程集成

解决的问题：企业内部私有代码库无法直接用 SWE-bench 的公开数据评测，但其“真实 issue + 自动测试验证”的机制可以完整复制到私有场景。把 JIRA 历史 bug 整理成实例集，就能持续验证内部代码助手修复能力。

具体案例：某电商团队把过去一年修复过的 500 个 Java 缺陷做成私有评测集，其中包含多文件修改的复杂问题。每次代码助手模型迭代，自动化跑一遍“生成补丁 → 跑单测 → 查回归”，将人工 code review 的工作量减少了约三成。

Python 演示

python104 行
import jsonimport subprocessimport tempfilefrom pathlib import Path CALC_CODE = """\def add(a, b):    return a - b  # bug: should be a + b def subtract(a, b):    return a - b def multiply(a, b):    return a * b""" TEST_CODE = """\import json def run_all():    from calc import add, subtract, multiply    tests = [        ("test_add_positive", lambda: add(1, 1) == 2),        ("test_add_negative", lambda: add(-2, -3) == -5),        ("test_subtract", lambda: subtract(5, 3) == 2),        ("test_multiply", lambda: multiply(4, 5) == 20),    ]    passed = []    failed = []    for name, fn in tests:        try:            assert fn()            passed.append(name)        except AssertionError:            failed.append(name)    print(json.dumps({"passed": passed, "failed": failed}))""" class SimplifiedSWEBench:    def __init__(self, tasks):        self.task_list = tasks        self.total_cnt = len(tasks)        self.passed_cnt = 0        self.result_list = []     def _create_workspace(self, code):        ws = Path(tempfile.mkdtemp(prefix="swe_demo_"))        (ws / "calc.py").write_text(code, encoding="utf-8")        (ws / "test_demo.py").write_text(TEST_CODE, encoding="utf-8")        return ws     def _run_tests(self, ws):        script = (            'import sys, json; '            'sys.path.insert(0, r"%s"); '            'from test_demo import run_all; '            'print(json.dumps(run_all()))' % ws        )        proc = subprocess.run(["python", "-c", script],                              capture_output=True, text=True, timeout=10)        if proc.returncode != 0:            return [], []        data = json.loads(proc.stdout.strip())        return data["passed"], data["failed"]     def generate_patch(self, issue_text, code):        # simulate model: understand issue and fix add function        return code.replace("return a - b", "return a + b")     def evaluate(self):        f2p = {"test_add_positive", "test_add_negative"}        p2p = {"test_subtract", "test_multiply"}        for idx, (issue, code) in enumerate(self.task_list):            ws = self._create_workspace(code)            patched = self.generate_patch(issue, code)            (ws / "calc.py").write_text(patched, encoding="utf-8")            passed, _ = self._run_tests(ws)            passed_set = set(passed)            resolved = f2p.issubset(passed_set) and p2p.issubset(passed_set)            self.result_list.append(resolved)            if resolved:                self.passed_cnt += 1            tag = "RESOLVED" if resolved else "UNRESOLVED"            print("Task {}: {}".format(idx + 1, tag))  def main():    task_add = (        "add(1, 1) returns 0, expected 2, please fix addition.",        CALC_CODE,    )    task_add_and_mult = (        "add(1, 1) returns 0, expected 2, please fix addition.",        CALC_CODE.replace("return a * b", "return a + b  # bug"),    )    bench = SimplifiedSWEBench([task_add, task_add_and_mult])    bench.evaluate()    print("Detail: {}".format(bench.result_list))    rate = bench.passed_cnt / bench.total_cnt    print("pass@1 = {}/{} = {:.2f}".format(bench.passed_cnt, bench.total_cnt, rate))  if __name__ == "__main__":    main()
目的：用两个迷你 issue 模拟 SWE-bench 的评测闭环，展示“生成补丁 → 应用补丁 → 跑 F2P/P2P 测试 → 统计 pass@1”的完整流程。
  1. self.task_list = tasks存放待评测的真实问题列表，对应 SWE-bench 的数据集加载阶段。
  2. (ws / "calc.py").write_text(code, encoding="utf-8")在临时工作区写代码文件，模拟 Docker 隔离环境里的基准代码。
  3. (ws / "test_demo.py").write_text(TEST_CODE, encoding="utf-8")写入测试补丁，其中同时包含 F2P 与 P2P 两类测试。
  4. script = ('import sys, json; ' ... )构造子进程脚本，让测试在独立进程中运行，环境互不干扰。
  5. proc = subprocess.run(["python", "-c", script], capture_output=True, text=True, timeout=10)执行测试并捕获输出，超时控制防止死循环。
  6. def generate_patch(self, issue_text, code):模拟模型根据 issue 理解需求后生成的补丁。
  7. patched = self.generate_patch(issue, code)模型产出补丁，对应 SWE-bench 中的模型推理阶段。
  8. (ws / "calc.py").write_text(patched, encoding="utf-8")把补丁应用到基准代码上，对应补丁应用阶段。
  9. resolved = f2p.issubset(passed_set) and p2p.issubset(passed_set)评分核心：F2P 和 P2P 必须全部通过才算 resolved。
  10. rate = bench.passed_cnt / bench.total_cnt计算 pass@1 指标，即解决的实例数除以总实例数。

常见误区

误区我一开始以为 SWE-bench 就是一堆算法题，模型只要会写排序、动态规划就能得高分，所以拿刷题模型的成绩去预估 SWE-bench 分数，结果完全对不上。

正解SWE-bench 考的是真实的大型开源项目问题，模型需要理解几千行代码的仓库结构，经常要跨多个文件协同修改，甚至需要先复现 bug 再定位根因。这好比科目二要求在真实街区里完成一次包含找车位、倒库、让行人的综合驾驶，而不是单独测一把原地打方向盘。LeetCode 是定点动作，SWE-bench 是综合路况评估。

为何常见：因为大多数人对代码评测的认知停留在“算法刷题就是编程”的层面，忽略了真实工程里上下文理解、多文件协调和回归防护的重要性。

误区我写补丁时只盯着 FAIL_TO_PASS 看，觉得那几个红测试变绿就大功告成，结果提交到评测系统里却判失败，一度以为是环境问题。

正解SWE-bench 的判定是 F2P 和 P2P 双双全过。即使你修好了新 bug，只要弄挂了一个原本通过的测试，实例依然判为失败。这就像倒库压线会扣分，出库时撞到旁边的锥桶同样挂科。真正的修复不仅要解决眼前问题，还要保证原有功能完好无损，P2P 就是专门拦截“顾此失彼”式修法的。

为何常见：因为人脑天然关注“从红变绿”的成就感，容易忽略“保持绿别变红”的防守性指标，而这恰恰是工程代码最看重的稳健性。

误区我看两个模型 pass@1 都是 30%，就断定它们代码能力旗鼓相当，后来发现它们擅长的任务类型完全不同，一个擅长修 Django 一个擅长修 SymPy。

正解分数相同只代表平均解决率一致，但实例之间的难度差异巨大。有的问题是单函数变量改名，有的要跨五个文件改接口。评分时可以按仓库、按问题类型分层对比，就像两个教练的学员平均通过率一样，但一个擅长教倒库、另一个擅长教坡起，具体分布才是关键。还要关注是否出现数据污染，否则分数虚高没有任何参考价值。

为何常见：人脑天生喜欢用单一数字做决策，把复杂能力压缩成一个平均值，自然会丢掉任务分布、难度分层这些重要信息。

误区我为了省事，没拉 Docker 镜像，直接在本地已有的仓库环境里跑评测，结果同一个模型在自己的机器上过了，换一台机器就挂了。

正解SWE-bench 对环境的执着不是洁癖：依赖版本一漂移、基准 commit 一变化，bug 可能根本复现不了，黄金补丁也可能失效，整个评测结果瞬间变成废纸。科目二为什么非要用统一车型？因为不同车的离合器深度、方向盘圈数都不一样，考试结果没法横比。环境锁定是结果可复现的底线，任何结论都要附带环境指纹才能成立。

为何常见：因为“在我的机器上能跑”是程序员的经典侥幸心理，本地复现成功就误以为全局成立，忽略了环境差异造成评测不可比的风险。

面试题

Q1. SWE-bench 评测的核心任务是什么？

单选题 · easy

  • A.生成高质量的代码注释
  • B.修复真实开源项目的问题← 正确答案
  • C.编写完整的单元测试套件
  • D.自动部署大型线上服务

答案：B。SWE-bench 把真实 GitHub issue 交给模型，要求它阅读代码库后生成修复补丁，再通过测试验证。生成注释、写单测、做部署都不是它的核心任务，唯有“修真实 bug”才符合“科目二考真实驾驶技能”的定位。

Q2. SWE-bench 的任务实例来自哪里？

单选题 · easy

  • A.人工虚构的编程练习题
  • B.算法竞赛的经典真题
  • C.真实GitHub的issue和PR← 正确答案
  • D.企业内部的需求文档

答案：C。SWE-bench 的数据全部来自真实开源项目，是开发者实际提出并修复过的 issue。人工练习题和竞赛题缺乏真实工程的上下文复杂度，企业内部需求则没有公开的标准化补丁做“黄金答案”，因此都不是数据来源。

Q3. FAIL_TO_PASS 测试的准确含义是什么？

单选题 · mid

  • A.修复前通过、修复后失败
  • B.修复前失败、修复后必须通过← 正确答案
  • C.无论是否修复都会一直失败
  • D.与修复无关的随机失败测试

答案：B。FAIL_TO_PASS 是“失败转通过”测试，修复前必须失败，修复后必须通过，用来证明 bug 被真正修好。它是 F2P 的核心判定依据；如果修复前就通过，它就没有验证意义，自然也不会被选入 F2P 集合。

Q4. PASS_TO_PASS 测试的作用是什么？

单选题 · mid

  • A.确保原有功能不发生回归← 正确答案
  • B.增加基准测试的难度门槛
  • C.衡量模型生成代码的速度
  • D.用人工评审替代自动化验证

答案：A。PASS_TO_PASS 在修复前是通过的，修复后也必须保持通过，专门用来拦截“修好新 bug、弄坏旧功能”的回归问题。增加难度或测速度都不是它的目的，它守护的是工程代码最看重的稳定性和非破坏性。

Q5. 一个 SWE-bench 实例被判定为 resolved 需要满足什么条件？

单选题 · mid

  • A.所有F2P测试中过半通过即可
  • B.所有P2P测试全部通过即可
  • C.F2P与P2P测试必须全部通过← 正确答案
  • D.任意一个测试通过即可判定

答案：C。resolved 是严格的双重判定：F2P 全过证明 bug 被修复，P2P 全过证明没有引入回归。任何一类测试只要有一个通过失败，实例就判为未解决。放宽到过半或只看任意一个测试，都会让“假修复”和“破坏性修复”蒙混过关。

Q6. pass@1 指标最准确的定义是什么？

单选题 · mid

  • A.只生成一次补丁就能解决任务的比率← 正确答案
  • B.多次生成补丁取最优结果的比率
  • C.单条测试用例通过的比率
  • D.模型单次推理成功的概率

答案：A。pass@1 强调“只给一次机会”：每个 issue 模型只能生成一次补丁，解决就算成功，未解决就记零分。它最贴近真实开发场景，因此成为 SWE-bench 报告里的主力指标。多次采样取最优是 pass@k，单测通过率则是测试层面的细粒度指标。

Q7. SWE-bench 在环境配置上做了哪些统一？

多选题 · mid

  • A.使用Docker镜像隔离评测环境← 正确答案
  • B.锁定项目依赖的精确版本← 正确答案
  • C.固定代码仓库的基准提交commit← 正确答案
  • D.为不同模型设置不同随机种子

答案：ABC。Docker 镜像、依赖锁定、固定 base_commit 三者共同保证所有模型面对完全一致的“考试车”。随机种子与评测环境无关，且评测应保证公平性而非为模型定制随机条件，因此 D 不属于环境统一的措施。

Q8. 以下哪些做法能提升模型在 SWE-bench 上的表现？

多选题 · hard

  • A.让模型多轮检索并探索代码库← 正确答案
  • B.根据测试失败信息迭代修改补丁← 正确答案
  • C.只扩大训练数据不改变推理策略
  • D.调用静态分析工具定位可疑代码← 正确答案

答案：ABD。agentic 式多轮探索、根据测试反馈迭代补丁、调用工具定位代码，都是在“模型如何与代码库互动”层面做改进，已被验证能大幅提升解决率。只扩大训练数据而不改变推理策略，无法应对新 issue 的上下文推理需求，因此不能有效提升 SWE-bench 得分。

Q9. SWE-bench Lite 与全量数据集的主要区别是什么？

单选题 · easy

  • A.只包含Python语言的任务
  • B.精选出的小规模验证子集← 正确答案
  • C.难度更高的大规模挑战集
  • D.全部无需Docker的轻量任务

答案：B。SWE-bench Lite 从全集中挑出约 300 个任务描述最清晰、难度分布合理的实例，让研究者能用较少算力快速验证想法。它也是 Python 仓库的任务，仍需 Docker 环境，也不是比全集更难，而是更轻量、更高效。

Q10. 关于 SWE-bench 评测，下列说法正确的有哪些？

多选题 · extreme

  • A.环境不固定会导致结果不可复现← 正确答案
  • B.训练数据污染会影响评测公平性← 正确答案
  • C.只要F2P通过即可判定为resolved
  • D.评测框架包含生成与应用补丁流程← 正确答案

答案：ABD。环境固定是复现的底线，数据污染会使分数虚高，评测框架本身要串联加载实例、生成补丁、应用补丁、执行测试四个环节。C 的错误在于忽略 P2P：只有 F2P 与 P2P 全部通过才能判为 resolved，这正是 SWE-bench 防回归的核心机制。