Paper2Code：将论文变成代码的 AI 流水线

一个困扰无数研究者的痛点

想象一下这样的场景：你读到一篇 2024 年的顶会论文，论文提出了一个精妙的注意力变体，实验效果远超基线。你想快速验证它的效果，但现实是残酷的——论文只给出了数学公式和伪代码，从公式到可运行的 PyTorch 代码，中间还隔着无数个坑：维度对齐、Mask 机制、特殊归一化、训练调度……一个博士生往往需要花 2-3 周才能复现一篇论文的代码。

这就是 Paper2Code 要解决的问题。

背景：从 Paper2Code 论文到 PaperCoder 系统

Paper2Code 是一篇发表于 ICLR 2026 的学术论文，由首尔国立大学的研究团队 Minju Seo、Jinheon Baek、Seongyun Lee 和 Sung Ju Hwang 完成。团队从 2024 年就开始思考：能不能让大语言模型像人类研究员一样阅读论文、理解算法、自动写出可运行的代码？

他们的答案是 PaperCoder——一个三阶段多智能体（Multi-Agent）LLM 系统。与此前将代码生成视为"一步到位"的单次调用不同，PaperCoder 将论文转代码拆解为规划（Planning）、分析（Analyzing）、编码（Coding）三个阶段，每个阶段由专门的 LLM 智能体负责，阶段之间通过结构化输出传递上下文。

图1：PaperCoder 三阶段流水线：规划 → 分析 → 编码（含调试）

核心创新点

1. 多智能体分工，而非单一提示词

传统方案是"把论文喂给 GPT-4，让它写代码"——这往往产出注释丰富但结构混乱、细节缺失的"玩具代码"。PaperCoder 则模拟了人类研究员的分工：

• 规划智能体：理解论文整体结构，制定"复现计划"（含实验设置、超参数、评估指标）
• 分析智能体：深度理解具体模块的算法细节，拆解为具体任务清单（Task List）
• 编码智能体：按任务清单逐个生成代码文件
• 调试智能体：运行测试，若出错则生成 SEARCH/REPLACE 补丁修复

2. 支持两种输入格式

• JSON 格式（推荐）：使用 s2orc-doc2json 将 PDF 转为结构化 JSON，保留段落、表格、公式的层级结构
• LaTeX 源码：直接读取论文的 LaTeX 源文件，公式和伪代码保留更多语义

3. 灵活的模型后端

用户可以在 OpenAI API（o3-mini，约 $0.50-0.70 单篇论文成本）和本地 vLLM 推理（默认 DeepSeek-Coder-V2-Lite-Instruct）之间选择，无需绑定特定模型。

技术架构：Python + Transformers + vLLM

Paper2Code 主体用 Python 编写，核心依赖：

依赖	用途
openai ≥1.65.4	OpenAI API 调用
vllm ≥0.6.4	本地推理引擎
transformers ≥4.46.3	Tokenizer 和模型加载
tiktoken ≥0.9.0	OpenAI 兼容 Token 计数

项目结构清晰：

codes/
  1_planning_llm.py      # 规划阶段（支持 vLLM）
  1_planning.py          # 规划阶段（通用接口）
  2_analyzing_llm.py     # 分析阶段
  3_coding_llm.py        # 编码阶段
  4_debugging.py         # 调试修复阶段（SEARCH/REPLACE 模式）
  utils.py               # 工具函数：JSON 解析、代码提取、成本统计

scripts/
  run.sh                 # OpenAI API 方式（PDF JSON）
  run_llm.sh             # vLLM 本地推理（PDF JSON）
  run_latex.sh           # OpenAI API 方式（LaTeX 源码）
  run_latex_llm.sh       # vLLM 本地推理（LaTeX 源码）

data/
  paper2code/            # 基准测试数据集（HuggingFace 同名数据集）
  prompts/               # 各阶段提示词模板

examples/
  Transformer.json       # Attention Is All You Need 的处理结果示例

编码智能体的代码提取机制

utils.py 中实现了从 LLM 输出中精准提取代码块的逻辑，支持多种格式（python、、纯文本代码片段），并有 JSON 解析的多次降级策略（content_to_json → content_to_json2 → content_to_json3），这是因为 LLM 生成的 JSON 经常带有注释和格式瑕疵，纯 json.loads 容易失败。

调试智能体（4_debugging.py）则使用了 Git 的 conflict marker 风格格式（<<<<<<< SEARCH ... ======= ... >>>>>>> REPLACE）来描述代码修改，文件级别的 Search/Replace 替换非常清晰。

上手体验：命令行门槛较高，但有示例可循

使用前提：

1. 安装 openai 或 vllm：pip install openai 或 pip install vllm
2. 准备论文（PDF → JSON 或 LaTeX 源码）
3. 设置 API Key 或启动 vLLM 服务
4. 修改 scripts/run.sh 中的论文路径和 API Key
5. 执行 bash scripts/run.sh

门槛分析：

• 纯 CLI 界面，没有 Web UI，需要熟悉命令行
• PDF → JSON 转换依赖外部工具 s2orc-doc2json（需要 Java/Gradle 环境）
• vLLM 推理需要 NVIDIA GPU（16GB+ VRAM），CPU 推理不现实
• 论文格式敏感：JSON 和 LaTeX 的处理脚本不同，选错格式会报错

适合人群： 有 ML 研究背景、熟悉 Linux 命令行、有 GPU 资源的工程师或研究员。

局限与争议

1. API 成本不可忽视

使用 o3-mini 处理单篇论文约 $0.50-0.70，对于大规模论文代码化场景（benchmark 动辄 200+ 篇），成本累积显著。本地 vLLM 虽然零 API 成本，但 GPU 硬件投入是门槛。

2. 生成代码质量依赖论文表述质量

如果论文算法描述模糊、公式不完整，PaperCoder 生成的代码也会存在缺陷。论文质量直接决定了代码质量上限——这与人类的"论文复现"困境一致。

3. 仅支持 ML/AI 论文

项目聚焦于机器学习领域的论文，对于非 ML 领域（如系统论文、网络论文）缺乏针对性优化，生成效果未知。

4. 基准测试覆盖有限

论文在 Paper2Code Benchmark 和 PaperBench 上评测，但 benchmark 的论文选择是否足够代表真实场景，学界仍有讨论。

行业意义：从"论文到代码"的自动化加速

Paper2Code 代表了一个重要趋势：用 AI 加速 AI 研究的基础设施建设。随着 LLM 在代码生成上的能力越来越强，"让 AI 读论文写代码" 从不可能变成了可能。这个方向有望在未来几年大幅降低科研复现的门槛。

从 GitHub 数据看，项目发布后在短时间内积累了 4801 颗 star，说明社区对这类工具有强烈的需求。ICLR 2026 的发表也印证了学术界的认可——这是近年来少见的以"AI 科研工具"为主题被顶会接收的工作。

增长趋势： 作为 2025-2026 年的新兴工具，Paper2Code 正处于社区快速采用期，预计随着模型能力的进一步提升和 vLLM 易用性的改善，使用门槛会逐步降低。