从 PR 构造 Benchmark 题目：SWE-bench 题目构造工程

概览

§ 1 为什么 PR 是天然的题目源

设计一个能客观评测 agent 能力的题目，需要 4 个要素：

1. 题面（问题描述）——给 agent 看的，要清晰、可执行
2. 答案（修复方案）——用于评分 + 训练参考，ground truth
3. 起点（基线状态）——agent 从这里开始改
4. 评测（怎么打分）——客观可重复的判分标准

§ 2 5 步构造流程

把一个真实 GitHub PR 转成 SWE-bench 题目，标准 5 步流程。

Step 1: 找候选 PR（issue + merged PR 配对）
        ↓
Step 2: 提取元数据（problem_statement / patch / test_patch / base_commit）
        ↓
Step 3: 隔离 test_patch（确保 F2P 在 pre-fix 状态 fail）
        ↓
Step 4: 验证 F2P / P2P（确保评测契约成立）
        ↓
Step 5: 入选数据集（写进 swe-bench.jsonl）

Step 1：找候选 PR（issue + merged PR 配对）

# GitHub GraphQL API：找 django/django 的 merged PR 中关联 issue 的
curl -H "Authorization: Bearer $GH_TOKEN" \
     -H "Content-Type: application/json" \
     -X POST https://api.github.com/graphql \
     -d '{
       "query": "{ search(query: \"repo:django/django is:pr is:merged fixes\", type: ISSUE, first: 50) { edges { node { ... on PullRequest { number title baseRefName mergedAt closingIssuesReferences(first: 1) { edges { node { number title body } } } } } } } }"
     }' \
     | jq '.data.search.edges[] | {pr: .node.number, title: .node.title, issue: .node.closingIssuesReferences.edges[0].node.number}'

Step 2：提取元数据（4 个字段）

import subprocess
import json

def extract_pr_metadata(repo, pr_number):
    # 1. 拿 PR 信息（merge commit SHA + base SHA + title）
    pr_info = subprocess.check_output([
        "gh", "pr", "view", str(pr_number),
        "--repo", repo, "--json",
        "number,title,body,mergeCommit,baseRefName,files"
    ])
    pr = json.loads(pr_info)
    merge_sha = pr["mergeCommit"]["oid"]
    base_sha = pr["baseRefName"]  # 实际是 base ref 名字，不是 SHA

    # 2. 拿 base_commit（merge commit 的父 commit）
    parents = subprocess.check_output([
        "git", "log", "-1", "--pretty=%P", merge_sha
    ]).decode().strip().split()
    base_commit = parents[0]   # merge commit 有 2 个父，第一个是 base

    # 3. 拿 patch（整 PR 的 diff，不含 merge commit 自己）
    patch = subprocess.check_output([
        "git", "diff", f"{base_commit}..{merge_sha}^1"
    ]).decode()

    # 4. 拿 test_patch（只含测试文件）
    test_patch = subprocess.check_output([
        "git", "diff", f"{base_commit}..{merge_sha}^1",
        "--", "**/test_*.py", "**/tests/**"
    ]).decode()

    return {
        "base_commit": base_commit,
        "patch": patch,
        "test_patch": test_patch,
    }

    # 5. problem_statement 从关联 issue 来
    # （需要先解析 PR body 里的 "fixes #N"，再调 gh issue view）

Step 3：隔离 test_patch（关键！）

test_patch 必须只包含"新增的测试文件 / 改动"，不能包含：

Step 4：验证 F2P / P2P（评测契约必须成立）

1. 在 base_commit 状态 apply test_patch：跑 test_patch 里列出的测试 → 期望fail（这就是 F2P）
2. apply test_patch + patch：再跑同一组测试 → 期望pass

def verify_f2p_p2p(instance):
    # 在容器里跑（隔离环境）
    container = build_container(base_commit=instance.base_commit).start()

    # Step A: apply test_patch（不动 patch）→ 跑测试
    apply_patch(container, instance.test_patch)
    pre_results = run_tests(container, instance.fail_to_pass + instance.pass_to_pass)

    # Step B: apply patch → 再跑
    apply_patch(container, instance.patch)
    post_results = run_tests(container, instance.fail_to_pass + instance.pass_to_pass)

    # 验证 fail_to_pass 确实是 "pre: fail, post: pass"
    for t in instance.fail_to_pass:
        assert pre_results[t] == "FAIL", f"F2P {t} didn't fail before fix!"
        assert post_results[t] == "PASS", f"F2P {t} didn't pass after fix!"

    # 验证 pass_to_pass 前后都 pass
    for t in instance.pass_to_pass:
        assert pre_results[t] == "PASS", f"P2P {t} didn't pass before!"
        assert post_results[t] == "PASS", f"P2P {t} broke after fix!"

    return True   # 全部通过，题目有效

Step 5：入选数据集

1. Step 4 验证通过——F2P / P2P 行为符合预期
2. 题面清晰——issue body 不是 "请帮我看看" 这种模糊描述
3. 答案不过大——patch < 1000 行（太大 agent 处理不了）

{"instance_id": "django__django-10914",
 "repo": "django/django",
 "base_commit": "a4e35c2f8b9d12e7c...",
 "version": "3.10",
 "problem_statement": "When I use FileSystemStorage, ...",
 "patch": "diff --git a/django/core/files/storage.py ...",
 "test_patch": "diff --git a/tests/file_storage/tests.py ...",
 "fail_to_pass": ["tests.file_storage.tests.FileStorageTests.test_file_upload_permissions_not_world_writable"],
 "pass_to_pass": ["tests.file_storage.tests.FileStorageTests.test_file_upload_permissions", ...]}

§ 3 7 个常见坑（哪些 PR 不能入选）

不是所有 PR 都能入选——以下是 7 个常见坑，踩中任意一个就放弃或修复。

§ 4 真实例子：django__django-10914 文件权限 bug

从真实 GitHub PR 一步步构造 SWE-bench 题目的完整 walk-through。

# 在 GitHub 上搜 django 的 merged PR 含 "fixes" + 改 test 文件
# 找到 PR #10914: "Fixed #30953: File upload permission default is unsafe on multi-user systems"

PR #10914
  Author:  Django Contributor X
  Title:   Fixed #30953: File upload permission default is unsafe on multi-user systems
  Base:    main (commit abc1234...)
  Merged:  2023-05-15
  Fixes:   #30953

# base_commit = merge commit 的父 commit
$ git log -1 --pretty=%P abc9876   # merge commit 的 SHA
deadbeef cafe5678                  # 两个父，deadbeef 是 base
# 所以 base_commit = "deadbeef..."

# patch = base_commit..head 的整 PR diff
$ git diff deadbeef..cafe5678
  # diff --git a/django/core/files/storage.py b/django/core/files/storage.py
  # -os.chmod(full_path, self.file_permissions_mode)
  # +os.chmod(full_path, self.file_permissions_mode & 0o777)
  # ...（约 5 行改动）

# test_patch = PR diff 中只含 test 文件的部分
$ git diff deadbeef..cafe5678 -- '**/tests/**'
  # diff --git a/tests/file_storage/tests.py b/tests/file_storage/tests.py
  # +def test_file_upload_permissions_not_world_writable(self):
  # +    ...（新测试函数，验证 world-writable 修复）

# problem_statement = 关联 issue #30953 的 body
$ gh issue view 30953 --json body
  "When using FileSystemStorage, the default FILE_UPLOAD_PERMISSION is 0o644..."

# 检查 test_patch 是否纯测试
$ grep -E "^diff --git" test.patch
  # diff --git a/tests/file_storage/tests.py  ✓ 只含 test 目录

# 如果含 src/ 文件，要剔除（用 git diff -- 'path' 重新过滤）

# 在容器里跑
1. apply test_patch（不动 patch）
   → pytest test_file_upload_permissions_not_world_writable
   → 期望：FAIL（这条测试在 base_commit 状态还没人写对应的修复，所以 fail）
2. apply patch
   → pytest test_file_upload_permissions_not_world_writable
   → 期望：PASS（patch 加了 & 0o777 屏蔽 world-writable 位）
3. apply test_patch + patch
   → pytest 整个 test_file_storage/tests.py
   → 期望：所有原有测试仍 pass（patch 没破坏其他功能）

验证结果：F2P 通过 / P2P 通过 → 题目有效

# 写入 jsonl 的一行
{"instance_id": "django__django-10914",
 "repo": "django/django",
 "base_commit": "deadbeefcafe...",
 "version": "3.10",
 "problem_statement": "When using FileSystemStorage, the default FILE_UPLOAD_PERMISSION is 0o644, which means other users on the same system can read uploaded files...",
 "patch": "diff --git a/django/core/files/storage.py b/django/core/files/storage.py\n@@ -290,7 +290,7 @@\n-        os.chmod(full_path, self.file_permissions_mode)\n+        os.chmod(full_path, self.file_permissions_mode & 0o777)",
 "test_patch": "diff --git a/tests/file_storage/tests.py b/tests/file_storage/tests.py\n@@ -50,6 +50,15 @@\n+    def test_file_upload_permissions_not_world_writable(self):\n+        # ...新测试...",
 "fail_to_pass": ["tests.file_storage.tests.FileStorageTests.test_file_upload_permissions_not_world_writable"],
 "pass_to_pass": ["tests.file_storage.tests.FileStorageTests.test_file_upload_permissions", "tests.file_storage.tests.FileStorageTests.test_save_overwrite", ...200+ 个]}

# 这道题被 SOTA 模型（如 Claude Sonnet 4）解决需要 ~3 分钟 / $0.05

§ 5 6 维度质量评估（题目"好不好")

题目入选数据集前，用 6 个维度打分，太差的丢弃或修复。

§ 6 题目审查清单（提交前必查）

把题目写进数据集前，按这张清单一项项勾——少一项就可能引入 bug。

1. ☐ 关联 issue 真实存在——gh issue view 验证
2. ☐ PR 是 merged 状态——gh pr view --json state,mergedAt 验证
3. ☐ PR 改了测试文件——git diff --stat 含 test_ / tests/
4. ☐ test_patch 纯测试——不混源码（grep ^diff --git 看路径）
5. ☐ base_commit 干净——apply test_patch 不报 merge conflict
6. ☐ F2P 真的 fail——apply test_patch 跑测试，期望 fail
7. ☐ F2P 真的 pass——apply test_patch + patch 跑测试，期望 pass
8. ☐ P2P 全部 pass——apply patch 后跑全仓库回归，期望 pass
9. ☐ issue 描述清晰——含复现步骤 + 期望行为
10. ☐ patch < 1000 行——避免 agent 处理不了

§ 7 上游 vs 本仓的题目构造对比

SWE-bench 官方"collect"流水线 vs 本仓"自建数据集"流程的差异。

SWE-bench 官方仓库的 swebench.collect 模块做上述全流程——自动爬 GitHub、提取 PR metadata、跑 F2P/P2P 验证、生成 jsonl。

引用与配套资料