SWE-bench：真实GitHub PR

可视化演示

演示SWE-bench从真实GitHub PR构建评测实例：PR筛选、issue提取、代码变更与测试用例生成，以及模型自主修复的评测机制。

数据渊源：题源从哪来

米其林评审委员会在选题时有个铁律：考题必须来自真实顾客的投诉记录，而不是评审员自己编造的假设场景。SWE-bench 遵循同样的哲学——它的每一道题，都源于 GitHub 上真实发生过的代码修复事件。GitHub 是全世界程序员共同维护代码的平台，每天都有成千上万的 Pull Request（简称 PR，即“代码修改请求”）被提交。一个开发者发现 bug、写好修复代码、提交 PR，维护者审核通过后把这个 PR 合并进项目主干，整个过程就像顾客投诉、厨师改进、主厨验收一样真实完整。

SWE-bench 团队走了一条“取材于真实”的路线：他们从 GitHub 上筛选出大量已合并的 PR，这些 PR 必须明确指向某个问题修复——也就是说，PR 的描述里要清楚地写着“这个改动修了哪个 bug”。举个例子，一个 PR 写着 “Fixes #1234：修复列表索引越界”，这就把一次代码改动和一次具体故障牢牢绑定。团队把这样的“故障-修复”配对记录下来，作为构建评测题目的原始素材。

与此同时，第一版 SWE-bench 聚焦 Python 语言的开源项目。为什么？因为 Python 生态拥有成熟统一的测试框架（如 pytest），测试用例可以标准化运行；而且 Python 的开源社区活跃，真实 bug 修复记录丰富。这相当于评审委员会只从菜品记录最完整、回访机制最成熟的餐厅取材——来源可靠，后续的验证才有说服力。

回到比喻：真实世界的投诉单哪怕不完美，也比虚构的考题更能看出厨师的真实水平。SWE-bench 坚持用真实 PR 做题库，正是为了让 AI 智能体面对的不是“温室里的习题”，而是开发者真正踩过的坑。

筛选标准：四道关卡

评审委员会收到海量投诉单后，不能全盘照收，必须经过严格的筛选。一道投诉要成为考题，得满足四个条件：顾客确实投诉过、投诉内容有据可查、能还原当时的场景、还得确认这个投诉不是偶发误会。SWE-bench 对 GitHub 上的 PR 也设置了类似的四道关卡。

第一道关卡是“合并状态”。一个 PR 只有被项目维护者正式合并进主干，才说明它的修复方案得到了人类专家的认可——这相当于一份被主厨签了字的处理记录。被关闭但未合并的 PR（比如方案被否了或者作者自己撤了），一律不采用。第二道关卡是“语义关联”。PR 必须在描述中明确引用对应的 issue 编号（如 "Fixes #1234"），确保这次代码改动和某个具体问题之间有清晰的因果关系，而不是顺手的无关重构。

第三道关卡是“可复现性”。每个候选 PR 必须包含配套的测试代码补丁——也就是 PR 作者在修复 bug 的同时写下的验证程序。没有测试，就无从判断修复是否真的有效，这类 PR 直接淘汰。第四道关卡是“高采样验证”。评测团队会在不同随机种子下反复运行测试，确认这些测试不是那种时好时坏的“运气测试”（即 flaky 测试）。这就像评审员要多次重现顾客说的“菜太咸”，确认不是那天厨师手抖的偶然事故。

这四道关卡依次过滤，把成千上万的 PR 压缩成几百个可靠的评测实例。看似严苛，却保证了基准测试的公信力——每一道题都经得起推敲，每一次评分都有据可依。

测试提取：双清单验收

投诉单被选中后，质检员要设计一套验收标准：怎么算改好了？怎么算没改坏？SWE-bench 的做法是从 PR 附带的测试补丁（test_patch）入手，把测试分成两组，对应两条验收标准。test_patch 就是 PR 作者在修复 bug 时写下的测试代码，这些测试像“探针”一样，专门检测那个 bug 是否还存在。

第一组叫 FAIL_TO_PASS，直译是“从失败到通过”。这些是在修复前代码上运行会失败、而应用了修复补丁后必须通过的测试。它们精确对应顾客投诉的痛点——如果修复后这组测试仍然失败，说明 bug 根本没修好。第二组叫 PASS_TO_PASS，直译是“从通过到保持通过”。这些是在修复前就正常通过、修复后也不允许被改坏的测试。它们守护的是既有功能——修复一个 bug 不能顺手弄坏另一个功能，就像厨师加盐补救一道菜，不能把别的菜也搞咸了。

分类方法说来直观：先把 test_patch 里的测试分别运行在“修复前代码”和“修复后代码”两份快照上，观察每个测试的状态变化。在修复前失败、修复后通过的，归入 FAIL_TO_PASS；在修复前通过、修复后依然通过的，归入 PASS_TO_PASS。这个双向验证的思路，构成了 SWE-bench 评测的核心机制。

回到米其林的场景：FAIL_TO_PASS 是“顾客抱怨的那道菜必须变好吃”，PASS_TO_PASS 是“菜单上其他菜必须保持原味”。两套清单同时核对，才敢给这次修复打上“通过”的印章。

任务构建：密封的考卷

筛选完素材、提取完测试，接下来要把这一切封装成一份标准化的“考卷”——也就是 SWE-bench 的一个评测实例（instance）。每个实例就像评审团递给厨师的一个密封信封，里面装好了全部材料，不许讨价还价。

信封里有什么？第一项是问题描述（problem statement），直接取自 GitHub issue 的原文，例如“当用户输入空列表时程序崩溃，期望返回空结果”。这是唯一会展示给 AI 智能体的信息——相当于顾客的原话投诉，Agent 必须自己读懂问题、自己定位代码。第二项是代码库快照（base commit 对应的仓库状态），也就是 bug 发生时仓库的完整代码。这是“后厨的现场还原”：食材、工具、半成品都摆在 bug 发生的那一刻。第三项是测试补丁和标准修复（gold patch）——注意，标准修复是评分时供对照的答案，绝不会提前交给智能体。提交后的验证方式，是把 Agent 生成的修复补丁应用在快照上，然后运行两组测试，用统一公式判定是否通过。

判定公式可以写成：

这就像评审团最后亮分：菜必须变好（F2P 全通过），别的菜不能出问题（P2P 全通过），任何一项不达标，整场修复都不算数。标准统一、过程透明，这就是 SWE-bench 能成为行业标尺的原因。

质量保障：守住底线

有了考卷和评分标准，还差最后一环：防止作弊和意外。米其林评审团最怕两件事——厨师提前拿到考题，或者抽到一道根本没法复现的“幽灵投诉”。SWE-bench 的质量保障就是冲着这两件事去的。

第一道防线是数据泄漏防护。AI 模型训练时可能会“背”过 GitHub 上的代码，如果评测用的 PR 恰好也在训练数据里，就相当于考生提前看过答案。SWE-bench 的处理方式是时间切分：按提交时间严格划分，保证评测实例的“修复提交时间”晚于模型训练数据的截止时间，从源头切断“背答案”的可能。第二道防线是高采样机制。前面提到的高采样不只是筛选用——在正式发布前，团队还会对每个实例进行多次重复运行，剔除 flaky 测试，确保“失败”不是因为偶发环境抖动，而是真的没修好。

第三道防线是可复现性机制。评测环境被固定在标准化的容器（如 Docker）中，依赖版本、系统环境全部锁定，保证同一个修复补丁在任何机器上跑出的结果一致。第四道防线是人工复核，标注者会逐个检查实例的问题描述是否清晰、测试分类是否合理、修复目标是否明确，把机器筛选的漏网之鱼再捞一遍。

这四道防线层层设卡，共同守护一个目标：公平。只有公平的考题，才能让不同团队、不同模型之间的分数有可比性；只有可复现的结果，才能让学术研究和工业落地的结论真正站得住脚。

应用价值：行业试金石

当一套评测体系足够真实、公平且可复现，它就会成为行业公认的试金石。正如米其林星级一旦被厨师界广泛接受，就变成了整个行业追逐的荣誉。SWE-bench 在 RAG 与 Agent 评测领域的地位正是如此。

在 RAG（检索增强生成）评测中，研究者希望知道“检索到的代码片段和文档，到底有没有帮智能体更好地定位和修复 bug”。SWE-bench 恰好提供了这样的实验场：Agent 先检索仓库信息、再生成修复补丁，用最终通过率倒推检索质量。在 Agent 评测中，SWE-bench 更是标准动作——几乎每一篇关于编程智能体的论文，都会报告模型在 SWE-bench 上的通过率，用它和其他模型横向对比。OpenAI、Anthropic、Meta 等机构的研发团队也在内部用它衡量模型的代码修复能力，并在技术报告中公开分数。

当然，SWE-bench 也有局限：它目前主要覆盖 Python 项目，聚焦“修复 bug”这一种任务形态，无法完全代表真实软件工程的全部场景。正因如此，社区陆续推出了多语言变体、多任务形态的新基准，但无论如何演进，SWE-bench 确立的“用真实 PR 构建评测实例”这一方法论始终是它们的基石。就像米其林标准也在变，但“由真实顾客的真实体验出发”这一根本原则从未动摇。

AI 应用场景

Python 演示

"""从真实GitHub PR构建SWE-bench评测实例并评估修复是否通过。""" class SWEBenchInstance:    def __init__(self, pr_number, problem, base_commit, fail_to_pass, pass_to_pass):        self.pr_number = pr_number        self.problem = problem        self.base_commit = base_commit        self.fail_to_pass = set(fail_to_pass)        self.pass_to_pass = set(pass_to_pass)     def is_solved(self, passed_tests):        return self.fail_to_pass.issubset(passed_tests) and self.pass_to_pass.issubset(passed_tests)  class SWEBenchEvaluator:    def __init__(self):        self.instances = []        self.solution_count = 0     def add_instance(self, instance):        self.instances.append(instance)     def run_one(self, instance, model_patch, run_tests):        passed_tests = run_tests(instance.base_commit, model_patch)        return instance.is_solved(passed_tests)     def run_suite(self, model_patch, run_tests):        self.solution_count = sum(            1 for inst in self.instances            if self.run_one(inst, model_patch, run_tests)        )        return self.solution_count / len(self.instances)  def demo_run_tests(base_commit, model_patch):    """模拟在某个提交上运行测试，返回通过的测试名集合。"""    passed = set()    if "fix" in model_patch:        passed.add("test_list_handle::test_no_crash")        passed.add("test_list_handle::test_original_ok")    return passed  if __name__ == "__main__":    evaluator = SWEBenchEvaluator()    instance = SWEBenchInstance(        pr_number=8825,        problem="列表越界访问导致崩溃，需要增加边界判断。",        base_commit="a1b2c3d",        fail_to_pass={"test_list_handle::test_no_crash"},        pass_to_pass={"test_list_handle::test_original_ok"},    )    evaluator.add_instance(instance)    score = evaluator.run_suite("add boundary check: fix", demo_run_tests)    print("评测通过率:", score)    print("评测实例数:", len(evaluator.instances))

1. self.fail_to_pass = set(fail_to_pass)把测试名列表转成集合，方便后续做“子集”判断。
2. return self.fail_to_pass.issubset(passed_tests) and self.pass_to_pass.issubset(passed_tests)这就是判定公式的实现：两个集合条件同时满足才返回 True。
3. passed_tests = run_tests(instance.base_commit, model_patch)把修复补丁应用在 base_commit 对应的代码快照上运行测试，模拟真实提交验证。
4. if "fix" in model_patch简化版模拟器：只有当模型补丁里包含 fix 相关改动时，测试才通过，用于演示而无需真实代码库。
5. score = evaluator.run_suite("add boundary check: fix", demo_run_tests)一次性跑完所有实例，得到最终通过率。

常见误区

面试题