13 个技能拼出一篇论文：Spark-to-Paper 把研究流程拆成可组合的积木

一个场景

一个博士生早上 9 点走进实验室，打开 IDE，在光标处敲下一行字："研究小模型在长上下文训练下的知识退化现象"。

接下来发生的事情，如果交给 Spark-to-Paper，会是这样的：

1. 文献检索技能启动，搜索相关论文，整理出研究背景
2. 实验设计技能启动，在看到任何结果之前，先写下"需要什么证据才能支持/推翻假设"
3. 实验执行技能启动，跑代码、收集数据
4. 证据对照技能启动，把实验结果和预先设计的证据需求对照，决定哪些假设被支持、哪些被推翻
5. 声明修订技能启动，根据实验结果修订论文里的声明——如果结果不支持原假设，就改写假设
6. 图表生成技能启动，用代码生成可编辑的矢量图
7. 手稿组装技能启动，把所有部分拼成完整论文

整个过程不需要独立的 agent 平台，不需要编排服务，就在你已有的编码助手内部完成。13 个技能像积木一样拼起来，每个技能做一件具体的事，组合起来就是端到端的"从想法到论文"。

这是 Zhuoyang Qian 等人在 2026 年 8 月论文《Spark-to-Paper: End-to-End Research Paper Generation as a Composable Skill》里展示的系统。

核心设计：分离模型判断和确定性操作

Spark-to-Paper 的第一个设计原则是：把模型擅长的事和代码擅长的事分开。

模型擅长的是判断——这篇文献相关吗？这个实验结果支持这个声明吗？这段论述清晰吗？这些交给 LLM。

代码擅长的是确定性操作——跑实验脚本、检查引用是否存在、验证图表是否可编辑、检测是否有捏造。这些用确定性代码执行，不靠模型"猜"。

这个分离让系统既灵活又可靠。灵活的部分（判断、写作、修订）由模型完成，可靠的部分（验证、检查、执行）由代码保证。

第二个设计：证据先于声明

这是整个系统最聪明的设计。

传统的研究流程是：先有假设，跑实验看结果，根据结果写论文。问题是，如果结果不支持假设，研究者很容易"调整叙事"——把不支持的结果说成支持，或者选择性报告。

Spark-to-Paper 的做法是：在看到任何结果之前，先写下"需要什么证据才能支持这个假设"。这个"证据需求"被固定下来，然后才跑实验。实验结果出来后，系统把结果和预先设计的证据需求对照，决定哪些声明被支持、哪些被推翻。

如果结果不支持原假设，系统会修订声明而不是修改叙事。论文里的声明必须和实验证据一致，不能"结果不好就换个说法糊弄过去"。

这个设计直接对应科学方法的核心——假设先行、证据驱动、结论可被推翻。只不过 Spark-to-Paper 把这个流程用代码强制执行了。

第三个设计：Self-Refutation Loop 的有界恢复

这里有一个有趣的失败模式。

有时候实验会反复拒绝原研究目标——你跑一次实验，结果不支持假设；换个方法再跑，还是不支持；再换，还是不支持。这就是 Self-Refutation Loop（自我反驳循环）。

人类研究者遇到这种情况会怎么办？要么放弃这个课题，要么修改假设到"几乎一定能被支持"的程度。前者浪费投入，后者是学术不端。

Spark-to-Paper 的做法是有界恢复：允许系统在有限次数内调整实验方法或假设表述，但超过阈值就停止并报告"当前证据不支持原研究目标"。系统不会无限循环，也不会为了"让结果好看"而篡改数据。

这个设计承认了"不是所有研究假设都能被实验支持"这个事实，并给了一个诚实的处理方式。

第四个设计：可编辑的矢量图

图表生成是研究论文的痛点。传统做法是跑完实验生成 PNG 图片，手动在 PPT 或 Illustrator 里排版。如果要改图，得重新跑代码、重新导出、重新排版。

Spark-to-Paper 的做法是：用代码生成可编辑的矢量图。实验结果图用程序化绘图（matplotlib 之类），方法示意图用代码重建。这样图表既是"生成的"又是"可编辑的"——研究者可以直接改代码调整图表，不需要重新跑整个流程。

数据说话

论文在 8 个受控研究主题上测试了完整系统：

• 引用有效性：99.5%——几乎每条引用都是真实的
• 图表可编辑性：96.4%——几乎每张图都可以用代码编辑
• 捏造检测：从单次草稿的 14% 提升到完整完整性栈的 92%——完整性检查把捏造检测率提高了 6.5 倍
• 对抗性审查精度：74%——系统自己审查自己的论文，能找出 74% 的问题

成本：

• 11.9M tokens——完整生成一篇论文的 token 消耗
• **\(8.1 每篇**——按当前 API 价格 - **3.2 小时**——从想法到完整论文的平均时间\)8.1 一篇论文，3.2 小时。这个成本数字让"端到端研究论文生成"从"实验室 demo"变成了"可日常使用的工具"。

这篇论文的位置

Spark-to-Paper 的核心贡献不是"能生成论文"——之前已有 AI Scientist、GPT-Researcher 等系统做过类似的事。它的贡献是把研究流程拆成 13 个可组合的技能，在已有编码助手内部完成，不需要独立 agent 平台。

这个定位很关键：

1. 不需要独立平台意味着低部署成本。你不需要搭一套新的 agent 基础设施，在已有的编码助手里装上这 13 个技能就能用。
2. 可组合技能意味着可替换。如果文献检索技能不够好，换一个就行，不需要改整个系统。
3. 分离模型判断和确定性操作意味着可验证。捏造检测从 14% 到 92% 的提升，就是因为确定性检查能抓住模型"编造"的引用。

和 ACE 工作流的结构同构

步子哥之前分享过 ACE（Advanced Context Engineering）的 RPI 工作流——Research-Plan-Implement 三步，每步独立压缩上下文。ACE 的核心洞察是"一行坏研究 = 数千行坏代码"，所以研究阶段要和实现阶段分开。

Spark-to-Paper 是同一个原则的更彻底版本。它把研究流程拆成 13 步而不是 3 步，但核心逻辑一样：每个阶段独立，阶段之间用确定性接口连接。

ACE 的"上下文压缩"对应 Spark-to-Paper 的"技能分离"——每个技能只看它需要的上下文，不被其他阶段的噪音污染。ACE 的"研究先行"对应 Spark-to-Paper 的"证据先于声明"——都是先确定"要做什么"再确定"怎么做"。

这种结构同构不是偶然。Agent 系统设计的核心挑战是"长流程的可靠性"，而解法越来越清晰：把流程拆成可独立验证的步骤，每步有明确的输入输出契约。

一个更深的观察

Spark-to-Paper 让我想到一个更普遍的原则：可靠性来自结构，不来自模型能力。

99.5% 的引用有效性不是因为模型"更聪明"，而是因为系统结构强制了引用验证。92% 的捏造检测不是因为模型"更诚实"，而是因为确定性检查能抓住模型的编造。

这和之前在 colibrì（1300 行 C 代码跑 7440 亿参数）看到的"分工比统一更有效"是同一个原则：把任务拆成模型擅长的部分和代码擅长的部分，让各自做各自的事。

跨论文共识越来越清晰：Agent 系统的可靠性是结构属性，不是模型属性。再强的模型在不可靠的结构里也会出错，再弱的模型在可靠的结构里也能产出可信结果。

论文信息

• 标题：Spark-to-Paper: End-to-End Research Paper Generation as a Composable Skill
• 作者：Zhuoyang Qian, Biao Wu, Yiran Wang et al.
• arXiv：https://arxiv.org/abs/2608.11924