跳转到内容
Auto-Research 调研

Spark-to-Paper

一句话定位

跳转到“一句话定位”一节

Spark-to-Paper 是一个 Claude Code 插件，由 1 个编排 skill（ts-paper）和 13 个可组合的 skill 组成。它把一个 idea、一份 proposal，或者“proposal + 真实数据”，变成一篇编译好的 LaTeX 论文，附带引用检查、可编辑的矢量图和确定性的诚信 gate。

它本质上是写作和打包引擎，自动实验只是可选的最后一步。不要把它当成能自己做出新发现的 AI 研究员。

基本信息

跳转到“基本信息”一节
项目 内容
仓库 Spark-To-Paper-Skills/spark-to-paper-skills
许可证 MIT
论文 Spark-to-Paper: End-to-End Research Paper Generation as a Composable Skill，arXiv:2608.11924，2026-08-12。README 称它在 2026-08-13 登上 Hugging Face Daily Papers 第 1 名
GitHub star（2026-10-15） 1,234
创建时间 2026-06-18
最近提交 2026-08-18（共 91 个 commit，此后约 2 个月没有活动）
维护者 Spark-To-Paper-Skills 组织，小团队。论文作者来自 Vast Intelligence Lab 和 University of Technology Sydney
版本 v1.0、v1.0.1、v1.1.0（均为 2026-06-26，v1.1.0 起支持插件安装）；v1.2（2026-08-07，加入 PaperBanana+ 图形引擎）
Issues 只有 2 个，都未关闭，都来自第三方

架构与阶段

跳转到“架构与阶段”一节

Stage 0：输入分流

跳转到“Stage 0：输入分流”一节

编排 skill ts-paper 先判断输入属于哪一类：

输入 路线 结果模式
一句话 idea 先用 ts-idea2story 扩成研究故事，再进入规划 proposal
proposal（有问题、方法和评估，但没有实测结果） 直接规划 proposal
proposal + 真实结果或数据文件 规划后交给 ts-paper-data data-aware
已有的 story.json 跳过 idea 步骤 proposal

七个阶段，外加自动实验

跳转到“七个阶段，外加自动实验”一节
  1. ts-paper-plan：生成 blueprint.json，包括标题、关键词、贡献、符号和字数目标。
  2. ts-paper-cite：通过 WebSearch 和 Crossref 建参考文献库，至少 40 条真实文献。
  3. ts-paper-write：一次写完所有章节。
  4. ts-paper-refine：调整篇幅，去掉 AI 腔，自查逻辑。
  5. ts-paper-review：N 个相互隔离的对抗审稿人通读全文，每条意见都必须逐字引用原文，防止略读。随后由立场不同的 skeptic 尝试驳倒每条意见，循环到不再出现新问题为止。
  6. ts-paper-figure：数据图用 matplotlib 画。示意图走 ts-figure-svg（“PaperBanana+”）：官方 PaperBanana 先渲染候选图，再按论文内容原生重绘成 SVG，并用只依赖 Python 标准库的几何审计脚本 audit_svg.py 反复检查。
  7. ts-paper-latex：组装并编译 PDF。
  8. ts-paper-experiment（自动）：在你提供的数据或代码上跑“可行”的实验，填好结果表，再重新编译。

上游还有一个可选的 ts-kg-build，从语料构建知识图谱，用于检索。

诚信机制

跳转到“诚信机制”一节
  • proposal 模式下，结果单元格一律留空（--），不编数字。
  • data-aware 模式下，正文里的数字必须能追溯到 results.facts.json。
  • run_gates.py 按 all 跑完全部确定性检查并返回 0，论文才算完成。
  • 作者把一种失败模式称为 Self-Refutation Loop：系统反复判定自己的实验不足以支持原假设，却仍在同一方向上修改。因此“实验—批评—修改”循环最多 7 轮，到上限后写一份失败报告，换一个新 idea 重来。
  • 每个阶段都把 INPUT、DECISIONS、OUTPUT 记到 logs/*.io.md，事后可以逐步审计。

Claude Code 与 Codex 的角色

跳转到“Claude Code 与 Codex 的角色”一节
  • Claude Code 是整个运行时。规划、引用、写作、精修、对抗审稿、图表评审和实验执行这些需要判断的步骤，都由 Claude Code 里的 Claude 完成。Python 脚本只做 lint、组装、画图和审计。
  • 论文没有给出具体模型。原文只写 “runs inside Claude Code using a model from the Claude family”，这句话引用的是 Claude 3 的 model card、Claude Agent SDK 概览和 Claude Code 文档。作者说这套设计也能移植到能力相当的其他 coding agent，但没有提供移植版本。
  • 没有 Codex 支持。仓库里没有 Codex 版本，也没有相关设置。OpenAI 的 key 只用于图表的视觉质检（OPENAI_API_KEY、VISION_MODEL），OpenRouter 的 key 只用于 PaperBanana 的出图 agent（OPENROUTER_API_KEY）。

安装与运行

跳转到“安装与运行”一节

安装（任选一种）

跳转到“安装（任选一种）”一节

A. 作为 Claude Code 插件安装（README 推荐）。下次启动会话时自动加载，skill 以 /spark-to-paper:ts-paper 这样的形式出现：

终端窗口
git clone https://github.com/Spark-To-Paper-Skills/spark-to-paper-skills.git ~/.claude/skills/spark-to-paper-skills

B. 不安装，先试用：

终端窗口
git clone https://github.com/Spark-To-Paper-Skills/spark-to-paper-skills.git
claude --plugin-dir ./spark-to-paper-skills

C. 只复制 skill（没有命名空间）：

终端窗口
cp -r spark-to-paper-skills/skills/ts-* ~/.claude/skills/

D. 作为 git submodule：

终端窗口
git submodule add https://github.com/Spark-To-Paper-Skills/spark-to-paper-skills.git .claude/skills/spark-to-paper-skills

README 还说明，这套工具每次运行都会查询 GitHub Releases，检查有没有新版本（有 24 小时缓存）。

依赖

跳转到“依赖”一节
  • Claude Code（这套工具是一个插件）。
  • Python 3.10+，并执行 pip install -r skills/ts-figure-optimize/requirements.txt。
  • LaTeX：latexmk 加一个 TeX 发行版。
  • 可选：本地 raster fallback 运行时（约 4 GB）、图像模型端点、LibreOffice。

可选密钥

跳转到“可选密钥”一节

把 .env.example 复制成 .env，只填你要用的项：

用途 变量
用图像模型渲染示意图 TS_FIG_API_KEY、TS_FIG_BASE_URL、TS_FIG_MODEL
图表视觉质检 OPENAI_API_KEY、VISION_MODEL
知识图谱检索用的 embedding TS_EMBED_*
下载本地 raster fallback 的权重 HF_TOKEN
同步 Overleaf OVERLEAF_GIT_URL、OVERLEAF_TOKEN

用 PaperBanana 出图时，README 给出的准备步骤：

终端窗口
python skills/ts-figure-svg/scripts/setup_paperbanana.py
export OPENROUTER_API_KEY="sk-or-v1-..."
python skills/ts-figure-svg/scripts/audit_svg.py --selftest

运行与验收

跳转到“运行与验收”一节

在 Claude Code 里输入下面这句话，再把 idea、proposal 或 proposal + 数据贴在后面；也可以直接调用 /spark-to-paper:ts-paper：

Run ts-paper on this proposal.

检查是否真的完成（退出码不为 0 就是没完成）：

终端窗口
python skills/ts-paper/scripts/run_gates.py <workdir> all

模板：默认是 ts_iieta（Traitement du Signal 期刊格式），另带 neurips（社区版）和 neurips_official（NeurIPS 2025 官方 .sty）。其他会议可以在 templates/<name>/ 下自行添加。

人工检查点与自主模式

跳转到“人工检查点与自主模式”一节
  • 没有交互式关口。触发之后，它会一路跑完整条链。
  • 主要靠输入控制。proposal 模式不会编数字，结果格留空；data-aware 模式报告你提供的真实结果。
  • 可以分段使用。skill 可以单独调用，比如只跑 ts-paper-cite 或 ts-paper-review，你可以在两个阶段之间介入。
  • 过程可审计。每个阶段的日志都记录了输入、决定和输出。
  • “完成”有硬标准。README 的定义包括：PDF 已生成、LaTeX 零错误、每个 \cite{} 都对应完整的 refs.bib 条目、没有编造的数字、每张图都以可编辑的矢量 PDF 嵌入、对抗审稿阶段跑过，并且 run_gates.py 返回 0。

成本与算力

跳转到“成本与算力”一节
项目 数字 来源
完整流程，每篇 $8.1（区间 $6.9–9.6）、11.9M token、3.2 小时（2.6–3.9） 论文，8 个预注册题目的平均值（开发方评测）
仓库简介里的说法 每篇通常约 $10 API 费用 自报
单次起草（同一底模，不加 gate） $0.66、16 分钟，但参考文献可解析率只有 81% 论文，3 个配对题目
各层质量控制的增量成本 加 gate：+8.1M token、+$5.3；再加自审：+1.1M、+$0.6；再加对抗审稿：+2.6M、+$1.6 论文消融表，3 个配对题目
  • 成本的大头在 gate 这一层。
  • GPU：README FAQ 说只有可选的本地 raster fallback 才用得上，而且它也能在 CPU 上跑。matplotlib 画的数据图本身就是矢量图，不经过这一步。
  • 出图可能额外产生 OpenRouter 或 OpenAI 视觉模型的费用。

质量证据

跳转到“质量证据”一节

证据强度：弱。没有人评审过这些稿件的科研质量（新颖性、可靠性），论文也没有报告投稿结果（README 自称的期刊接收见下表最后一行）。只有引用和图表卫生这一窄项有开发方的对照实验，单看这一项可以算中等。

证据 结果 类型 要注意的地方
参考文献书目可解析率 99.5%（8 篇论文，共 384 条参考文献）。对照：抽样的人类预印本 97.8%，单次起草 81%，AI Scientist、AI Scientist-v2、Agent Laboratory 公开发布的论文为 91–96% 开发方评测 只说明文献存在、元数据对得上，不代表引用支撑了对应论断。其他系统的数字来自审计它们公开发布的论文，没有重跑
图表元素可编辑率 96.4% 开发方评测 衡量的是图能不能编辑，与科研质量无关
植入的无依据结论的检出率 单次起草 14%（5/36）→ 加 gate 69% → 再加自审 81% → 再加对抗审稿 92%（33/36） 开发方评测 测的是整套 gate 流程对 36 个人为植入探针的检出；样本小（36 个探针，消融只用了 3 个配对题目）；没有研究单独测过预注册本身的作用
对抗审稿意见的精确率 74%（42/57），由盲评人员核对 开发方评测 评的是审稿意见是否属实，不是论文好坏
7 篇示例论文 覆盖环境监测、能源预测、环境 AI、计算机视觉、临床 AI、轴承故障诊断 6 个领域 自报 论文自己说这是存在性证据，不是基准结果
期刊接收 README 的 Citation 一节称有一篇端到端生成的论文被 “SCI-indexed Q2 journal” 接收 自报 没有给出期刊名，无法核实

论文称：题目、模型配置和评估标准在生成前就已固定，评估协议做了外部时间戳登记，并报告了全部结果。但这些仍然是开发方自己的测量，没有第三方复现。

已知问题

跳转到“已知问题”一节
  • Issues 页面：公开记录很少，只有 2 个 issue，都来自第三方（#9 请求支持新的模型路由，#10 邀请项目收录进一份 AI auto-research 综述合集）。没有用户提交的 bug 报告，所以关于它在真实使用中怎么出错，几乎没有公开证据。
  • #9：请求支持 OrcaRouter。这也说明这套工具绑定在 Claude Code，以及特定的出图和视觉端点上。
  • Self-Refutation Loop（论文记录的失败模式）：长时间运行时，系统可能反复判定实验不支持原假设，却一直在同一方向上修改。上限是 7 轮，之后写失败报告、换新 idea。所以只给一个 idea 时，最后拿到的可能是一份“失败轨迹”报告，而不是论文。
  • README FAQ：data-aware 模式下，正文数字会对照 results.facts.json 检查，但结果表格只覆盖到当前 gate 代码已经实现的范围。

适合与不适合

跳转到“适合与不适合”一节

适合：

  • 手里已有 proposal 加结果或数据，想用大约 3 小时、$8–10，得到一份引用经过校验、配可编辑矢量图的 LaTeX 稿件。
  • 应用型 ML 和信号处理方向的期刊论文。
  • 作为写作层，接在其他 pipeline 或你自己的实验结果之后。

不适合：

  • 产出新的 ML 发现。实验只限于在你提供的数据或代码上跑“可行”的实验。
  • GPU 密集的研究。
  • Codex 用户。
  • 手里只有一个想法。proposal 模式会把结果格留空。
  • 需要活跃维护者或社区使用记录的场景。

结论

跳转到“结论”一节

在本调研深挖的几个 pipeline 里，Spark-to-Paper 在写作环节报告的诚信指标最好。但这些数字都是开发方自评，而且只覆盖引用、图表和植入错误的检出，不涉及科研质量。

把它当作打包引擎，不要当作自主的 AI 研究员。它不会自己产出一篇好的前沿 ML 论文；喂给它真实结果，它能以很低的成本整理出一份整洁、正文数字可追溯的初稿。投稿前仍要核对每条关键引用是否真的支撑论断，并逐个核对主要数字，对应推荐流水线的 S8（独立诚信审计）和 S10（人工终审）。

下一步：怎么选 pipeline · 推荐流水线（S0–S10）