研究提案

论文代码复现：构建科研版 SWE-bench，训练「用代码做科学」的执行能力

Papers with Code 上 10 万+ 论文是天然的训练数据素材。给模型论文 + 代码仓库，要求它复现核心实验、结果和原论文对齐——产出的执行轨迹是目前质量最高的科研能力训练数据，直接对应 terminal-level 的科研执行能力。

2026年3月29日论文复现代码执行 SWE-bench 科研执行中训练数据 Papers with Code Terminal Science

核心想法

Papers with Code 上有超过 10 万篇论文，每篇都有对应的开源代码仓库和可验证的实验结果。

这是天然的「科研版 SWE-bench」素材库。

SWE-bench 的任务是：给 GitHub issue，要求模型写代码修复，有测试用例验证。

这条路线的任务是：给论文 + 代码仓库，要求模型复现核心实验，以原论文的 Table / Figure 数值验证——模型不只是读懂论文，还要真正「用代码把实验跑出来」。

产生的执行轨迹是前两个提案无法达到的质量层级：不是模型自说自话的文字推理，而是有真实执行反馈的迭代过程。

一、为什么这条路线不同于前两个

前两个提案都在文字层面工作：

反向假设生成：给论文课题，要求推导出论文——输出是文字推论
综述反向构建：给原始论文集合，要求写综述——输出是结构化文字

论文代码复现在执行层面工作： 模型必须写代码、跑实验、看数字、和论文对比、诊断差距、修正。

这个「写代码→执行→观察结果→诊断→修正」的循环，产生的轨迹质量有本质差别——每一步都有外部现实（代码执行结果）作为锚点，不允许「自洽的错误推导」存在。

这是训练「可证伪性」的数据。

科学方法论的核心是可证伪性（falsifiability）——一个好的科学主张，必须能被实验反驳。模型在纯文字空间里可以无限自洽，但面对跑出来的数字，自洽就行不通了。这种压力是让模型真正具备科研能力的关键训练信号。

二、任务设计

2.1 基本框架

输入：
  - 论文全文（重点：实验设计、评估方法、核心 Table/Figure）
  - 对应的代码仓库（GitHub）
  - 实验环境规格（硬件、依赖版本）

任务：
  - 分析论文的核心实验设计
  - 理解代码结构和实现
  - 修改/配置代码，设计复现实验
  - 执行实验，获取结果
  - 与论文数据对比，分析一致性和差距

验证：
  - 核心指标与原论文偏差 < X%（可配置）
  - 完整的复现报告（方法、结果、差距分析）

2.2 三种难度层级

L1：配置复现（最基础）

代码仓库完整，有官方复现脚本，只需要正确配置环境和参数。

任务：读 README → 配置依赖 → 运行脚本 → 对比结果
技能：环境管理、参数理解、结果解读
适合领域：有完善复现文档的论文（如 NeurIPS/ICML 的代码仓库）

L2：局部实现（中等）

代码仓库存在但不完整，需要模型补全某个关键模块或实验。

任务：理解现有代码 → 识别缺失部分 → 实现缺失模块 → 验证整体跑通
技能：代码理解、模块设计、调试
适合领域：提供了基础框架但需要补全的论文

L3：从论文重新实现（最难）

只给论文，不给代码（或代码仅供事后验证）。

任务：读论文方法描述 → 独立实现 → 运行 → 与论文数据对比 → 迭代
技能：算法理解、端到端实现、科研级调试
适合领域：方法描述清晰、核心算法不过于复杂的论文

2.3 轨迹捕捉的关键环节

执行过程中产生的这些轨迹是数据的核心价值：

读论文阶段：

「核心实验是表 2 的第 3 行，评估方法是 BLEU-4 和 ROUGE-L」
「方法描述里有一个关键超参数 α，默认值在附录 B.2」

代码分析阶段：

「train.py 的第 127 行是模型的核心 forward pass，对应论文公式 (3)」
「config.yaml 里的 batch_size 需要根据显存调整，论文用的是 A100 80G」

实验执行阶段：

「第一次跑出来 BLEU-4 是 28.3，论文报告的是 31.7，差距较大」
「检查发现数据预处理步骤里 tokenization 方式不对，论文用的是 BPE 而不是 WordPiece」

诊断修正阶段：

「修正 tokenization 后结果是 30.9，和论文 31.7 差距缩小，剩余差距可能来自随机种子或硬件差异」
「在可接受误差范围内，复现成功」

这四个阶段的轨迹，完整呈现了「从理解实验设计到跑通实验」的全过程——这是目前训练数据里最稀缺的认知过程。

三、与 SWE-bench 的对比

维度	SWE-bench	论文代码复现
任务定义	修复 GitHub issue	复现论文核心实验
验证方式	单元测试通过	实验数值与论文对齐
成功标准	二元（通过/失败）	连续（偏差百分比）
所需能力	代码理解 + Bug 定位 + 修复	论文理解 + 实验设计 + 代码实现 + 科研判断
数据来源	GitHub issues	Papers with Code
数量规模	~2000 个任务	10 万+ 论文（可大规模扩展）
领域覆盖	主要是软件工程	全 AI/ML 子领域

SWE-bench 代表了「让模型能修软件 bug」，本方案代表了「让模型能做科研实验」。前者的数据规模有限且构建成本高，后者有 Papers with Code 这个天然的大规模数据源。

四、数据价值：为什么是「质量最高」的科研数据

1. 不可自洽的外部验证

文字推理可以「自说自话」，代码执行不行——数字是数字，差 10% 就是差 10%。这让每条轨迹都有无法绕过的现实锚点。

2. 多步骤有依赖的推理链

读论文→理解代码→配置实验→执行→对比→诊断→修正，每一步都依赖上一步的输出。这种有内在依赖的长推理链，是中训练最稀缺的数据类型。

3. 领域知识与工程能力的交叉

这类任务同时需要：理解论文中的算法原理（科学知识）+ 写出能跑的代码（工程能力）+ 判断结果是否合理（科研判断力）。三者交叉才能完成任务，产出的数据覆盖了模型能力的多个维度。

4. 难度可系统化分层

L1/L2/L3 的难度分层，加上论文本身的复杂度（方法是否清晰、代码是否完整、复现难度如何），可以构建从基础到高难度的系统化课程。

五、工程挑战与应对方案

这条路线的工程难度显著高于前两个，主要挑战：

5.1 代码执行沙箱

挑战：执行模型生成的代码，必须在隔离环境中，防止恶意代码、无限循环、资源耗尽。

方案：

参考 SWE-bench 和 TerminalBench 的沙箱设计
Docker 容器隔离 + 资源限制（CPU / 内存 / 时间上限）
文件系统只读（除指定输出目录）
网络隔离，仅允许访问预下载的数据集

5.2 依赖环境管理

挑战：不同论文的代码依赖差异极大，自动配置环境是最大的工程难点。

方案：

优先选择有完整 requirements.txt / environment.yml 的论文
使用 conda + Docker 实现依赖隔离
维护常见框架（PyTorch / TensorFlow / JAX）的基础镜像，减少配置成本
对依赖配置失败的案例，标注为「L3 级别任务」（需要模型自己排查依赖问题）

5.3 执行规模控制

挑战：Full training run 可能需要数天，无法用于数据生成。

方案：

只复现论文的「核心小实验」而非完整训练
优先选择有「quick demo」或「ablation study」的论文（通常小时级跑完）
对于训练时间过长的论文，使用「小数据集代理」验证方法正确性
设定硬性时间上限（如 2 小时/任务），超时标记为不可用

5.4 结果对齐标准

挑战：实验结果受随机种子、硬件差异影响，不同机器跑出来的数值本来就不完全相同。

方案：

以「数量级对齐」而非「完全复现」为标准（偏差 < 5% 视为成功）
记录环境差异（硬件、随机种子），纳入轨迹元数据
复现报告必须包含「合理的差距解释」

六、数据来源与选题策略

Papers with Code 的利用

Papers with Code 提供了：

10 万+ 论文 + 代码的关联
各论文在标准 benchmark 上的结果（方便自动评估）
按任务类型、数据集、方法分类的结构化检索

选题优先级：

优先级	标准	理由
⭐⭐⭐	有官方代码 + 有复现记录 + 核心实验 < 2h	成功率高，数据质量稳定
⭐⭐	有代码 + benchmark 结果可验证	有自动评估锚点
⭐	代码存在但环境配置复杂	成功率较低，但 L3 任务价值高

三个条件的实际筛选方法

条件一：有官方代码——Papers with Code API 直接过滤 is_official=True。启发式补充：仓库 owner 与论文作者同名，或 README 含「Official implementation」字样。

条件二：有复现记录——社区已复现过，说明代码可以跑通。检测信号按可靠性排序：

信号	获取方式
Papers with Code 有 Results 表（社区复现数值）	直接查 API
GitHub Stars > 50	有人真的用过
Issues 里含「reproduced」「results match」关键词	搜 issue 标题/正文
有 `reproduction.md` 或 `REPRODUCE.md`	仓库文件检索
有预训练 checkpoint（releases 或 HuggingFace 链接）	说明作者自己跑过完整实验

条件三：核心实验 < 2h——没有直接字段，用代理指标组合估算：

代理指标	获取方式	逻辑
论文标注的 GPU 机时	解析 Experiments 章节	直接来源，但不是所有论文都写
数据集规模	Papers with Code dataset 字段	小数据集 → 实验快
有 `eval_only.sh` / `quick_start.sh` / `demo.py`	GitHub 文件检索	存在快速评估路径
Ablation study 有「each row takes X GPU hours」注释	解析表格 caption	可直接估算单次实验时长
仓库有预训练权重可下载	检索 `.pt` / `.ckpt` / HuggingFace 链接	跳过训练，只跑 inference 评估

最可靠的实践路径：有预训练权重 + 只跑评估脚本。把训练阶段换成加载官方 checkpoint，只验证 inference 结果和论文对齐——大多数 NLP/CV 论文可以在 30 分钟内跑完一个核心指标。

完整筛选 pipeline（可自动化）：

Papers with Code API
  → is_official = True
  → has_results_table（社区已有复现数值）
  → GitHub stars > 50
  → 有预训练 weights（搜索 .pt / .ckpt / huggingface.co 下载链接）
  → 有 eval_only 脚本 OR 数据集 < 10GB

10 万篇论文经过这套过滤，预计剩余几千篇高可用论文，是 L1 数据集的核心素材库。

领域分配（初期建议）：

NLP 方法论类（40%）：代码规范、复现文档完善
计算机视觉（20%）：实验规模可控
强化学习（20%）：有独特的执行反馈信号
其他 AI/ML 子领域（20%）：保持多样性

七、与三个提案的整体关系

三个方案合在一起，构建的是一套完整的「科研能力」训练数据体系：

                    科研能力
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   推理链能力      整合能力        执行能力
（单点深推）   （多源聚合）    （代码+现实）
        │              │              │
  反向假设生成   综述反向构建   论文代码复现
  （本系列一）  （本系列二）  （本系列三）
        │              │              │
   纯文字轨迹    纯文字轨迹    代码执行轨迹
   中等难度      较高难度      最高难度

三者的数据质量递增，工程复杂度也递增。可以按这个顺序逐步推进，每一个都有独立的价值，不需要等前一个完成才能启动后一个。

八、实施路径

阶段一：可行性验证（1-2 周）

从 Papers with Code 选取 20 篇 L1 级论文（有完整复现文档）
手动验证这 20 篇在 2 小时内可以跑通
设计评估框架：复现成功率 + 结果偏差分布
构建基础沙箱环境（Docker + 资源限制）
让当前最强模型跑 5 篇，观察执行轨迹质量

验证目标：沙箱稳定、20 篇论文中 ≥ 15 篇可以在 2 小时内跑通

阶段二：数据规模化（3-5 周）

扩展到 200 篇（L1：L2：L3 = 5:3:2）
自动化 pipeline：论文筛选 → 环境配置 → 执行 → 结果对比 → 轨迹收集
质量筛选：执行轨迹完整 + 结果偏差在合理范围内
按难度分层，构建训练集

阶段三：中训练实验（4-8 周）

以 Qwen2.5-7B 做消融实验
对比：无代码执行数据 / 加代码数据（静态，不含执行轨迹）/ 加代码执行轨迹
评估：SWE-bench / TerminalBench + 内部科研执行评测

九、核心价值总结

论文代码复现方案解决的是一个核心问题：模型能不能真正「用代码做科学」，而不只是「谈论科学」。

这两者之间有巨大的鸿沟。当前模型能写出看起来合理的科研推导，但面对真实的代码执行结果时往往表现退化。原因很简单：没有这类训练数据。

Papers with Code 提供了一个独特的机会——把已有的 10 万+ 论文变成高质量的执行型科研训练数据，系统性地填补这个空白。

本提案是「科学推理能力中训练数据」系列的第三篇：
· 反向假设生成（系列一）
· 综述反向构建（系列二）
· 论文代码复现（本文，系列三）

参考：Papers with Code | SWE-bench | TerminalBench

本提案基于 2026-03-29 讨论整理。