{/* This page is auto-generated from the skill's SKILL.md by website/scripts/generate-skill-docs.py. Edit the source SKILL.md, not this page. */}

Research Paper Writing

为 NeurIPS/ICML/ICLR 撰写 ML 论文：设计→投稿。

Skill 元数据

参考：完整 SKILL.md

论文写作流水线

端到端流水线，产出可投稿的 ML/AI 研究论文，目标会议为 NeurIPS、ICML、ICLR、ACL、AAAI 和 COLM。本 skill 覆盖完整研究生命周期：实验设计、执行、监控、分析、论文写作、评审、修改与投稿。

这不是一条线性流水线——它是一个迭代循环。结果触发新实验，评审触发新分析。agent 必须处理这些反馈回路。

┌─────────────────────────────────────────────────────────────┐
│                    RESEARCH PAPER PIPELINE                  │
│                                                             │
│  Phase 0: Project Setup ──► Phase 1: Literature Review      │
│       │                          │                          │
│       ▼                          ▼                          │
│  Phase 2: Experiment     Phase 5: Paper Drafting ◄──┐      │
│       Design                     │                   │      │
│       │                          ▼                   │      │
│       ▼                    Phase 6: Self-Review      │      │
│  Phase 3: Execution &           & Revision ──────────┘      │
│       Monitoring                 │                          │
│       │                          ▼                          │
│       ▼                    Phase 7: Submission               │
│  Phase 4: Analysis ─────► (feeds back to Phase 2 or 5)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

何时使用此 skill

在以下情况使用本 skill：

• 从现有代码库或想法开始一篇新论文
• 设计并运行实验以支撑论文主张
• 撰写或修改研究论文的任意章节
• 准备投稿到特定会议或 workshop
• 回复评审，补充实验或修改
• 在不同会议格式之间转换论文
• 撰写非实证论文——理论、综述、基准或立场论文（见实证 ML 之外的论文类型）
• 为 NLP、HCI 或对齐研究设计人工评估
• 准备接收后的交付物——海报、报告、代码发布

核心理念

1. 主动。 交付完整草稿，而不是一堆问题。科学家很忙——先产出具体的东西让他们能提意见，然后迭代。
2. 绝不编造引用。 AI 生成的引用错误率约 40%。始终用程序拉取。无法核实的引用标记为 [CITATION NEEDED]。
3. 论文是一个故事，不是实验堆砌。 每篇论文都需要一句话能说清的一个清晰贡献。说不清，就还没准备好。
4. 实验服务于主张。 每个实验都必须明确说明它支撑哪条主张。绝不跑与论文叙事无关的实验。
5. 早提交、勤提交。 每完成一批实验、每次更新草稿——都写描述性消息提交。Git log 就是实验史。

主动性与协作

默认：主动。先起草，带着草稿提问。

仅在以下情况才停下等待输入：目标会议不明、存在多种相互矛盾的框定、结果看似不完整、用户明确要求先评审。

阶段 0：项目搭建

目标：建立工作区、理解已有工作、识别贡献。

步骤 0.1：探查仓库

# 理解项目结构
ls -la
find . -name "*.py" | head -30
find . -name "*.md" -o -name "*.txt" | xargs grep -l -i "result\|conclusion\|finding"

寻找：

• README.md — 项目概览与主张
• results/、outputs/、experiments/ — 已有发现
• configs/ — 实验设置
• .bib 文件 — 已有引用
• 草稿文档或笔记

步骤 0.2：组织工作区

建立一致的工作区结构：

workspace/
  paper/               # LaTeX 源码、图、编译后的 PDF
  experiments/         # 实验运行脚本
  code/                # 核心方法实现
  results/             # 原始实验结果（自动生成）
  tasks/               # 任务/基准定义
  human_eval/          # 人工评估材料（如需要）

步骤 0.3：设置版本控制

git init  # 如尚未初始化
git remote add origin <repo-url>
git checkout -b paper-draft  # 或 main

Git 纪律：每完成一批实验就写描述性消息提交。示例：

Add Monte Carlo constrained results (5 runs, Sonnet 4.6, policy memo task)
Add Haiku baseline comparison: autoreason vs refinement baselines at cheap model tier

步骤 0.4：识别贡献

动笔之前，先讲清楚：

• 贡献是什么：这篇论文到底贡献了哪一件事？
• 依据是什么：有什么证据支撑？
• 意义是什么：读者为什么要关心？

向科学家提议：“据我理解，主要贡献是：[一句话]。关键结果显示 [Y]。这是你想要的框定吗？”

步骤 0.5：创建 TODO 清单

用 todo 工具创建结构化项目计划：

论文 TODO：
- [ ] 定义一句话贡献
- [ ] 文献综述（相关工作 + 基线）
- [ ] 设计核心实验
- [ ] 运行实验
- [ ] 分析结果
- [ ] 写初稿
- [ ] 自审（模拟评审人）
- [ ] 按评审修改
- [ ] 投稿准备

在整个项目中持续更新。它跨会话充当持久状态。

步骤 0.6：估算算力预算

跑实验前，估算总成本与时间：

算力预算清单：
- [ ] API 费用：（每 token 模型价格）×（每次运行预估 token）×（运行次数）
- [ ] GPU 小时：（每次实验时间）×（实验数）×（种子数）
- [ ] 人工评估费用：（标注员）×（小时）×（时薪）
- [ ] 总预算上限与备用金（为重跑加 30-50%）

实验运行时跟踪实际花费：

# 简单成本跟踪模式
import json, os
from datetime import datetime

COST_LOG = "results/cost_log.jsonl"

def log_cost(experiment: str, model: str, input_tokens: int, output_tokens: int, cost_usd: float):
    entry = {
        "timestamp": datetime.now().isoformat(),
        "experiment": experiment,
        "model": model,
        "input_tokens": input_tokens,
        "output_tokens": output_tokens,
        "cost_usd": cost_usd,
    }
    with open(COST_LOG, "a") as f:
        f.write(json.dumps(entry) + "\n")

预算紧张时：先跑试点实验（1-2 个种子、任务子集），再决定是否全量扫参。调试流水线用便宜模型，最终运行再换目标模型。

步骤 0.7：多作者协调

大多数论文有 3-10 位作者。尽早建立工作流：

章节归属：每章指定一位主笔。其他人评论但不直接改。避免合并冲突和风格不一致。

作者协调清单：
- [ ] 商定章节归属（谁写什么）
- [ ] 建立共享工作区（Overleaf 或 git 仓库）
- [ ] 约定记号规范（在任何人动笔之前）
- [ ] 安排内部评审轮（不只在最后）
- [ ] 指定一人做最终格式统一
- [ ] 在画图前商定图风格（颜色、字体、尺寸）

应尽早商定的 LaTeX 约定：

• \method{} 宏，统一方法命名
• 引用风格：\citet{} vs \citep{} 用法
• 数学记号：向量用小写粗体、矩阵用大写粗体等
• 英式 vs 美式拼写

阶段 1：文献综述

目标：找相关工作、定基线、收集引用。

步骤 1.1：识别种子论文

从代码库已引用的论文开始：

# 通过 terminal：
grep -r "arxiv\|doi\|cite" --include="*.md" --include="*.bib" --include="*.py"
find . -name "*.bib"

步骤 1.2：搜索相关工作

加载 arxiv skill 做结构化论文发现：skill_view("arxiv")。它提供 arXiv REST API 搜索、Semantic Scholar 引用图谱、作者主页和 BibTeX 生成。

用 web_search 做广泛发现，web_extract 抓取特定论文：

# 通过 web_search：
web_search("[主技术] + [应用领域] site:arxiv.org")
web_search("[基线方法] comparison ICML NeurIPS 2024")

# 通过 web_extract（特定论文）：
web_extract("https://arxiv.org/abs/2303.17651")

可尝试的其他搜索词：

搜索词：
- "[主技术] + [应用领域]"
- "[基线方法] comparison"
- "[问题名] state-of-the-art"
- 已有引用中的作者名

推荐：安装 Exa MCP 做实时学术搜索：

claude mcp add exa -- npx -y mcp-remote "https://mcp.exa.ai/mcp"

步骤 1.2b：深化搜索（先广度后深度）

平铺搜索（一轮查询）通常会漏掉重要相关工作。借鉴深度研究流水线，采用迭代的先广后深模式：

迭代文献搜索：

第 1 轮（广度）：4-6 个并行查询，覆盖不同角度
  - "[方法] + [领域]"
  - "[问题名] state-of-the-art 2024 2025"
  - "[基线方法] comparison"
  - "[替代方法] vs [你的方法]"
  → 收集论文，提取关键概念和术语

第 2 轮（深度）：从第 1 轮所学生成跟进查询
  - 第 1 轮论文里发现的新术语
  - 最相关第 1 轮结果所引用的论文
  - 需要深究的矛盾发现
  → 收集论文，识别剩余空白

第 3 轮（定向）：填补具体空白
  - 第 1-2 轮发现缺失的基线
  - 同期工作（近 6 个月、同一问题）
  - 关键负面结果或失败方法
  → 当新查询大多返回你已见过的论文时停止

何时停：若一轮返回 >80% 已在你收集中的论文，说明搜索已饱和。通常 2-3 轮足够。综述论文预期 4-5 轮。

基于 agent 的工作流：通过 delegate_task 并行派每轮查询。收集结果、去重，再从合并所学生成下一轮查询。

步骤 1.3：核实每条引用

绝不凭记忆生成 BibTeX。始终用程序拉取。

对每条引用，遵循强制 5 步流程：

引用核实（每条引用强制）：
1. 搜索 → 用具体关键词查 Semantic Scholar 或 Exa MCP
2. 验证 → 在 2+ 来源确认论文存在（Semantic Scholar + arXiv/CrossRef）
3. 取回 → 通过 DOI 内容协商拿到 BibTeX（程序化，不凭记忆）
4. 确认 → 确认你引用的主张确实出现在论文中
5. 添加 → 把核实过的 BibTeX 加入参考文献
任一步失败 → 标为 [CITATION NEEDED]，告知科学家

# 通过 DOI 取 BibTeX
import requests

def doi_to_bibtex(doi: str) -> str:
    response = requests.get(
        f"https://doi.org/{doi}",
        headers={"Accept": "application/x-bibtex"}
    )
    response.raise_for_status()
    return response.text

若无法核实某条引用：

\cite{PLACEHOLDER_author2024_verify_this}  % TODO: 核实此引用是否存在

务必告诉科学家：“我已把 [X] 条引用标记为待核实占位符。”

完整 API 文档和 CitationManager 类见 references/citation-workflow.md。

步骤 1.4：组织相关工作

按方法分组论文，而非逐篇罗列：

好：“一支工作采用 X 的假设 [refs]，而我们用 Y 的假设，因为……” 差：“Smith 等人提出 X。Jones 等人提出 Y。我们把两者结合。”

阶段 2：实验设计

目标：设计直接支撑论文主张的实验。每个实验必须回答一个具体问题。

步骤 2.1：把主张映射到实验

建立显式映射：

规则：若某个实验映射不到任何主张，就别跑。

步骤 2.2：设计基线

强基线是录用与拒稿的分水岭。评审人会问：“他们和 X 比过吗？”

标准基线类别：

• 朴素基线：最简单可行方法
• 强基线：已知最好的现有方法
• 消融基线：你的方法去掉一个组件
• 算力对等基线：相同算力预算、不同分配

步骤 2.3：定义评估协议

动手前先明确：

• 指标：测什么、方向符号（越高/越低越好）
• 聚合：跨运行/任务如何合并结果
• 统计检验：用什么检验确立显著性
• 样本量：多少运行/题目/任务

步骤 2.4：编写实验脚本

遵循成功研究流水线的这些模式：

增量保存——每步后存结果以便崩溃恢复：

# 每道题/任务后保存
result_path = f"results/{task}/{strategy}/result.json"
if os.path.exists(result_path):
    continue  # 跳过已完成
# ... 跑实验 ...
with open(result_path, 'w') as f:
    json.dump(result, f, indent=2)

产物留存——保存所有中间输出：

results/<experiment>/
  <task>/
    <strategy>/
      final_output.md          # 最终结果
      history.json             # 完整轨迹
      pass_01/                 # 逐轮产物
        version_a.md
        version_b.md
        critic.md

关注点分离——生成、评估、可视化分开：

run_experiment.py              # 核心实验运行器
run_baselines.py               # 基线对比
run_comparison_judge.py        # 盲评
analyze_results.py             # 统计分析
make_charts.py                 # 可视化

完整设计模式、cron 监控和错误恢复见 references/experiment-patterns.md。

步骤 2.5：设计人工评估（如适用）

许多 NLP、HCI 和对齐论文需要人工评估作为主要或补充证据。在跑自动化实验之前设计它——人工评估往往前置周期更长（IRB 审批、招募标注员）。

何时需要人工评估：

• 自动化指标捕捉不到你关心的东西（流畅度、有用性、安全性）
• 你的贡献关乎面向人的品质（可读性、偏好、信任）
• NLP 会议（ACL、EMNLP）评审对生成任务期望有人评

关键设计决策：

标注指南清单：

- [ ] 清晰的任务说明，带示例（好的和坏的）
- [ ] 模糊情形的判定标准
- [ ] 每类至少 2 个示例
- [ ] 注意力检查/金标准条目（占总数 10-15%）
- [ ] 资格任务或筛选轮
- [ ] 每条预估时间与公平报酬（≥ 当地最低工资）
- [ ] 如机构要求，做 IRB/伦理审查

报告要求（评审会逐项查）：

• 标注员数量及其资质
• 标注员间一致性（具体指标与数值）
• 报酬细节（金额、预估时薪）
• 标注界面描述或截图（附录）
• 总标注时长

完整指南（含人工评估数据的统计检验、众包质量控制模式、IRB 指引）见 references/human-evaluation.md。

阶段 3：实验执行与监控

目标：可靠地跑实验、监控进度、从失败恢复。

步骤 3.1：启动实验

长时间实验用 nohup：

nohup python run_experiment.py --config config.yaml > logs/experiment_01.log 2>&1 &
echo $!  # 记录 PID

并行执行：同时跑独立实验，但注意 API 限流。同一 API 上 4+ 并发实验会互相拖慢。

步骤 3.2：设置监控（Cron 模式）

长时间实验设置周期性状态检查。cron prompt 应遵循此模板：

监控 Prompt 模板：
1. 检查进程是否还在：ps aux | grep <pattern>
2. 读日志最后 30 行：tail -30 <logfile>
3. 检查已完成结果：ls <result_dir>
4. 若有结果，读并报告：cat <result_file>
5. 若全部完成，提交：git add -A && git commit -m "<描述性消息>" && git push
6. 以结构化格式报告（含关键指标的表格）
7. 回答本实验的关键分析问题

静默模式：若自上次检查以来无变化，回复 [SILENT] 以抑制对用户的通知。有消息才报告。

步骤 3.3：处理失败

常见失败模式与恢复：

关键：脚本应始终检查已有结果并跳过已完成。这让重跑安全高效。

步骤 3.4：提交已完成结果

每批实验完成后：

git add -A
git commit -m "Add <实验名>: <关键发现一行>"
git push

步骤 3.5：维护实验日志

Git 提交记录了发生了什么，但不记录探索树——基于所学决定下一步试什么。维护结构化实验日志来捕捉这棵树：

// experiment_journal.jsonl — 每次实验尝试追加一条
{
  "id": "exp_003",
  "parent": "exp_001",
  "timestamp": "2025-05-10T14:30:00Z",
  "hypothesis": "Adding scope constraints will fix convergence failure from exp_001",
  "plan": "Re-run autoreason with max_tokens=2000 and fixed structure template",
  "config": {"model": "haiku", "strategy": "autoreason", "max_tokens": 2000},
  "status": "completed",
  "result_path": "results/exp_003/",
  "key_metrics": {"win_rate": 0.85, "convergence_rounds": 3},
  "analysis": "Scope constraints fixed convergence. Win rate jumped from 0.42 to 0.85.",
  "next_steps": ["Try same constraints on Sonnet", "Test without structure template"],
  "figures": ["figures/exp003_convergence.pdf"]
}

为什么要日志，而不只是 git？ Git 跟踪文件变化。日志跟踪推理：为什么试 X、学到了什么、对下一个实验意味着什么。写论文时，这棵树对方法章节（“我们观察到 X，由此促使 Y”）和诚实报告失败都极有价值。

选最佳路径：当日志显示分支树（exp_001 → exp_002a、exp_002b、exp_003）时，找出最支撑论文主张的路径。把死胡同分支作为消融或负面结果写进附录。

每个实验快照代码：每次运行后复制实验脚本：

cp experiment.py results/exp_003/experiment_snapshot.py

这样即使后续代码改动也能精确复现。

阶段 4：结果分析

目标：提取发现、计算统计量、找出故事。

步骤 4.1：聚合结果

写分析脚本：

1. 加载一批的所有结果文件
2. 计算逐任务与聚合指标
3. 生成汇总表

# 标准分析模式
import json, os
from pathlib import Path

results = {}
for result_file in Path("results/").rglob("result.json"):
    data = json.loads(result_file.read_text())
    strategy = result_file.parent.name
    task = result_file.parent.parent.name
    results.setdefault(strategy, {})[task] = data

# 计算聚合指标
for strategy, tasks in results.items():
    scores = [t["score"] for t in tasks.values()]
    print(f"{strategy}: mean={np.mean(scores):.1f}, std={np.std(scores):.1f}")

步骤 4.2：统计显著性

始终计算：

• 误差棒：标准差或标准误，注明是哪个
• 置信区间：关键结果给 95% CI
• 成对检验：McNemar 检验比较两种方法
• 效应量：Cohen d 或 h，评估实际显著性

McNemar 检验、bootstrap CI、Cohen h 的完整实现见 references/experiment-patterns.md。

步骤 4.3：找出故事

分析后，明确回答：

1. 主发现是什么？ 一句话。
2. 什么让你意外？ 意外结果往往成就最好的论文。
3. 什么失败了？ 失败的实验可能信息量最大。诚实报告失败能增强论文。
4. 需要什么跟进实验？ 结果常引出新问题。

处理负面或零结果

当假设错误或结果不明确时，你有三个选择：

如何写负面结果论文：

• 开头讲社群目前相信什么、为什么值得检验
• 描述严谨方法（必须无懈可击——评审会更苛刻）
• 用统计证据清晰呈现零结果
• 分析为什么预期结果没出现
• 讨论对领域的意义

明确欢迎负面结果的发表处：NeurIPS（Datasets & Benchmarks track）、TMLR、ML Reproducibility Challenge、各大会议 workshop。有些 workshop 专门征负面结果。

步骤 4.4：制作图表

图：

• 所有图用矢量图（PDF）：plt.savefig('fig.pdf')
• 色盲友好配色（Okabe-Ito 或 Paul Tol）
• 自包含标题——不看正文也能懂
• 图内不放标题——标题由 caption 承担

表：

• 用 booktabs LaTeX 宏包
• 每个指标的最优值加粗
• 带方向符号（越高/越低越好）
• 一致的小数精度

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
Method & Accuracy $\uparrow$ & Latency $\downarrow$ \\
\midrule
Baseline & 85.2 & 45ms \\
\textbf{Ours} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

步骤 4.5：决定——更多实验还是开写？

步骤 4.6：写实验日志（通往写作的桥）

进入写作前，创建结构化实验日志，把结果桥接到文字。这是实验与写作之间最重要的结缔组织——没有它，写作 agent 就得从原始结果文件重新推导故事。

创建 experiment_log.md，结构如下：

# 实验日志

## 贡献（一句话）
[论文主主张]

## 已跑实验

### 实验 1：[名]
- **测试的主张**：[支撑哪条论文主张]
- **设置**：[模型、数据集、配置、运行次数]
- **关键结果**：[一句话带数字]
- **结果文件**：results/exp1/final_info.json
- **生成的图**：figures/exp1_comparison.pdf
- **意外发现**：[任何意外]

### 实验 2：[名]
...

## 图
| 文件名 | 描述 | 归属章节 |
|--------|------|----------|
| figures/main_comparison.pdf | 在基准 X 上对比所有方法的柱状图 | 结果，图 2 |
| figures/ablation.pdf | 移除组件 A、B、C 的消融 | 结果，图 3 |
...

## 失败实验（诚实记录）
- [试了什么、为何失败、告诉我们什么]

## 开放问题
- [结果引出的、论文应处理的任何问题]

为什么重要：起草时，agent（或委派的子 agent）可以同时加载 experiment_log.md 和 LaTeX 模板，产出扎根于真实结果的初稿。没有这座桥，写作 agent 必须解析原始 JSON/CSV 并推断故事——这是编造或错报数字的常见根源。

Git 纪律：把这份日志和它描述的结果一起提交。

迭代优化：策略选择

本流水线中的任何产出——论文草稿、实验脚本、分析——都可迭代优化。autoreason 研究为每种优化策略何时有效、何时失败提供了实证依据。用本节选对方法。

快速决策表

生成-评估差距

核心洞见：Autoreason 的价值取决于模型生成能力与自评能力之间的差距。

Model Tier        │ Generation │ Self-Eval │ Gap    │ Autoreason Value
──────────────────┼────────────┼───────────┼────────┼─────────────────
Weak (Llama 8B)   │ Poor       │ Poor      │ Small  │ None — can't generate diverse candidates
Mid (Haiku 3.5)   │ Decent     │ Poor      │ LARGE  │ MAXIMUM — 42/42 perfect Borda
Mid (Gemini Flash)│ Decent     │ Moderate  │ Large  │ High — wins 2/3
Strong (Sonnet 4) │ Good       │ Decent    │ Medium │ Moderate — wins 3/5
Frontier (S4.6)   │ Excellent  │ Good      │ Small  │ Only with constraints

这个差距是结构性的，不是暂时的。随着成本下降，今天的前沿就是明天的中端。甜点会移动，但永不消失。

Autoreason 循环（概述）

每一轮从全新、隔离的 agent 产出三个候选：

1. Critic → 找现任 A 的问题（不改）
2. Author B → 按批评修改 A
3. Synthesizer → 合并 A 和 B（标签随机化）
4. Judge Panel → 3 个盲 CoT 裁判用 Borda 计数给 A、B、AB 排序
5. 收敛 → A 连续 k=2 轮胜出 → 结束

关键参数：

• k=2 收敛（k=1 过早，k=3 太贵且无质量增益）
• 始终用 CoT 裁判（收敛快 3 倍）
• 作者温度 0.8，裁判 0.3
• 保守平局：现任胜
• 每个角色都是无共享上下文的全新 agent

应用于论文草稿

用 autoreason 优化论文本身时：

• 给 critic 提供真值：真实实验数据、结果 JSON、统计输出。否则模型会编造消融研究和假置信区间。
• 至少用 3 个工作裁判：裁判解析器坏了不是加噪声——它会彻底阻止均衡。
• 范围约束修改：“处理这些具体弱点”，而不是“改进论文”。

失败模式

完整 prompt、Borda 打分细节、模型选择指南、范围约束设计模式和算力预算参考见 references/autoreason-methodology.md。

阶段 5：论文起草

完整起草流程（逐章节顺序、LaTeX 脚手架、图表约定、摘要与引言公式、相关工作定位）在 references/phase5-paper-drafting.md——到达本阶段时用 read_file 加载它。 配合 references/writing-guide.md 使用，获得行文层面的风格规则。

阶段 6：自审与修改

目标：投稿前模拟评审。尽早抓住弱点。

步骤 6.1：模拟评审（集成模式）

从多个视角生成评审。自动化研究流水线（尤其 SakanaAI 的 AI-Scientist）的关键洞见：带元评审的集成评审，比单轮评审产出校准得多的反馈。

第 1 步：生成 N 份独立评审（N=3-5）

用不同模型或温度。每个评审人只看论文，不看其他评审。默认带负面偏置——LLM 在评估中有据可查的正向偏置。

你是 [会议] 的资深评审。你严格而彻底。
若论文有弱点或你对某主张存疑，明确标出，并反映在分数里。
不要轻易放行。

按官方评审指南评审此论文。评估：

1. 可靠性（主张是否有充分支撑？基线是否公平而强？）
2. 清晰性（论文写得好吗？专家能复现吗？）
3. 重要性（对社群重要吗？）
4. 原创性（新洞见，不只是增量组合？）

以结构化 JSON 给出评审：
{
  "summary": "2-3 句摘要",
  "strengths": ["优势 1", "优势 2", ...],
  "weaknesses": ["弱点 1（最关键）", "弱点 2", ...],
  "questions": ["给作者的问题 1", ...],
  "missing_references": ["应引的论文", ...],
  "soundness": 1-4,
  "presentation": 1-4,
  "contribution": 1-4,
  "overall": 1-10,
  "confidence": 1-5
}

第 2 步：元评审（领域主席聚合）

把 N 份评审喂给元评审人：

你是 [会议] 的领域主席。你收到了某论文的 [N] 份独立评审。
你的工作是：

1. 识别评审间共识的优势与弱点
2. 通过直接查看论文解决分歧
3. 产出代表聚合判断的元评审
4. 使用所有评审的平均分

保守些：若评审人对某弱点是否严重有分歧，
在作者解决之前，按严重处理。

评审：
[review_1]
[review_2]
...

第 3 步：反思循环（可选，2-3 轮）

每个评审人在看到元评审后可修改其评审。用早停哨兵：若评审人回复“我完成了”（无改动），停止迭代。

评审的模型选择：评审最好用可用最强模型，即使你写论文用的是便宜模型。评审模型应独立于写作模型选择。

Few-shot 校准：若可，附 1-2 份目标会议真实已发表评审作示例。这显著改善分数校准。示例评审见 references/reviewer-guidelines.md。

步骤 6.1b：可视化评审（VLM）

纯文本评审会漏掉一整类问题：图质量、排版、视觉一致性。若可用视觉模型，对编译后的 PDF 单独跑一次可视化评审：

你在评审此研究论文 PDF 的视觉呈现。
检查：
1. 图质量：图可读吗？标签清晰吗？颜色可区分吗？
2. 图-标题对齐：每个 caption 准确描述其图吗？
3. 排版问题：孤行章节标题、尴尬分页、图远离其引用
4. 表格格式：列对齐、小数精度一致、最优值加粗
5. 视觉一致性：所有图配色一致、字体大小一致
6. 灰度可读：黑白打印图还能懂吗？

每个问题注明页码和确切位置。

这能抓住文本评审抓不到的问题：轴标签看不清的图、放在距首次引用 3 页之外的图、图 2 与图 5 配色不一致、明显宽于栏宽的表。

步骤 6.1c：主张验证

模拟评审后，单独跑一遍验证。这抓住评审可能漏掉的事实错误：

主张验证协议：
1. 从论文提取每个事实主张（数字、对比、趋势）
2. 对每个主张，追溯到支撑它的具体实验/结果
3. 核实论文中的数字与实际结果文件一致
4. 把无迹可查的主张标为 [VERIFY]

基于 agent 的工作流：把验证委派给一个全新子 agent，它只收到论文文本和原始结果文件。全新上下文防止确认偏误——验证者不“记得”结果本该是什么。

步骤 6.2：给反馈排序

收集评审后分类：

步骤 6.3：修改循环

对每个关键/高优先级问题：

1. 识别受影响的具体章节
2. 起草修复
3. 验证修复不破坏其他主张
4. 更新论文
5. 对照评审人的关切复查

步骤 6.4：写 Rebuttal

回复真实评审（投稿后）时，rebuttal 是与修改不同的技能：

格式：逐点。对每个评审关切：

> R1-W1：“论文缺少与方法 X 的对比。”

我们感谢评审的建议。我们已在表 3（修订版）加入与方法 X 的对比。
我们的方法在 [指标] 上比 X 高 3.2pp（p<0.05）。
我们注意到 X 需要 2 倍于我们的算力预算。

规则：

• 回应每个关切——跳过一个评审人会注意到
• 最强回应放前面
• 简洁直接——评审看几十份 rebuttal
• 若 rebuttal 期间跑了实验，附上新结果
• 绝不防御或轻蔑，即使对弱批评
• 用 latexdiff 生成带标注的改动 PDF（见专业 LaTeX 工具一节）
• 感谢具体、可操作的反馈（而非泛泛表扬）

不要做：无证据地“我们尊重地不同意”。不解释地“这超出范围”。只回应优势而忽略弱点。

步骤 6.5：论文演进跟踪

在关键里程碑存快照：

paper/
  paper.tex                    # 当前工作版
  paper_v1_first_draft.tex     # 第一份完整草稿
  paper_v2_post_review.tex     # 模拟评审后
  paper_v3_pre_submission.tex  # 投稿前终稿
  paper_v4_camera_ready.tex    # 接收后终稿

阶段 7：投稿准备

目标：最终检查、排版与提交。

步骤 7.1：会议清单

每个会议都有强制清单。仔细填——清单不完整可能导致 desk reject。

见 references/checklists.md：

• NeurIPS 16 项论文清单
• ICML 更广泛影响 + 可复现性
• ICLR LLM 披露政策
• ACL 强制局限性章节
• 通用投稿前清单

步骤 7.2：匿名化清单

双盲评审意味着评审人不能知道作者。逐项检查：

匿名化清单：
- [ ] PDF 任何地方无作者姓名或单位
- [ ] 无致谢章节（接收后再加）
- [ ] 自引用用第三人称：“Smith et al. [1] showed...” 而非 “We previously showed [1]...”
- [ ] 无指向你个人仓库的 GitHub/GitLab URL
- [ ] 代码链接用 Anonymous GitHub（https://anonymous.4open.science/）
- [ ] 图中无机构 logo 或标识
- [ ] 文件元数据无作者名（查 PDF 属性）
- [ ] 无 “our previous work” 或 “in our earlier paper” 措辞
- [ ] 数据集名不暴露机构（需要就改名）
- [ ] 补充材料不含识别信息

常见错误：补充代码里可见的 git 提交消息、机构工具生成的带水印图、上一稿残留的致谢、匿名期前就发了 arXiv 预印本。

步骤 7.3：排版验证

投稿前格式检查：
- [ ] 遵守页数限制（不含参考文献和附录）
- [ ] 所有图为矢量（PDF）或高分辨率位图（600 DPI PNG）
- [ ] 所有图灰度下可读
- [ ] 所有表用 booktabs
- [ ] 参考文献正确编译（引用无 “?”）
- [ ] 关键区域无 overfull hbox
- [ ] 附录清晰标注并分隔
- [ ] 必备章节齐全（局限性、更广泛影响等）

步骤 7.4：编译前校验

在尝试 pdflatex 之前跑这些自动检查。在这里抓错比调试编译器输出快。

# 1. 用 chktex lint（抓常见 LaTeX 错误）
# 屏蔽吵闹警告：-n2（句末）、-n24（括号）、-n13（句间）、-n1（命令终止）
chktex main.tex -q -n2 -n24 -n13 -n1

# 2. 核实所有引用在 .bib 中存在
# 从 .tex 提取 \cite{...}，逐条对照 .bib
python3 -c "
import re
tex = open('main.tex').read()
bib = open('references.bib').read()
cites = set(re.findall(r'\\\\cite[tp]?{([^}]+)}', tex))
for cite_group in cites:
    for cite in cite_group.split(','):
        cite = cite.strip()
        if cite and cite not in bib:
            print(f'WARNING: \\\\cite{{{cite}}} not found in references.bib')
"

# 3. 核实所有引用的图在磁盘上存在
python3 -c "
import re, os
tex = open('main.tex').read()
figs = re.findall(r'\\\\includegraphics(?:\[.*?\])?{([^}]+)}', tex)
for fig in figs:
    if not os.path.exists(fig):
        print(f'WARNING: Figure file not found: {fig}')
"

# 4. 检查重复 \label 定义
python3 -c "
import re
from collections import Counter
tex = open('main.tex').read()
labels = re.findall(r'\\\\label{([^}]+)}', tex)
dupes = {k: v for k, v in Counter(labels).items() if v > 1}
for label, count in dupes.items():
    print(f'WARNING: Duplicate label: {label} (appears {count} times)')
"

继续前修掉所有警告。基于 agent 的工作流：把 chktex 输出喂回 agent，指示做最小修复。

步骤 7.5：最终编译

# 干净构建
rm -f *.aux *.bbl *.blg *.log *.out *.pdf
latexmk -pdf main.tex

# 或手动（三遍 pdflatex + bibtex 处理交叉引用）
pdflatex -interaction=nonstopmode main.tex
bibtex main
pdflatex -interaction=nonstopmode main.tex
pdflatex -interaction=nonstopmode main.tex

# 验证输出存在且有内容
ls -la main.pdf

若编译失败：解析 .log 文件找第一个错误。常见修复：

• “Undefined control sequence” → 缺宏包或命令名拼写错
• “Missing $ inserted” → 数学符号在数学模式外
• “File not found” → 图路径错或缺 .sty 文件
• “Citation undefined” → 缺 .bib 条目或没跑 bibtex

步骤 7.6：会议特定要求

步骤 7.7：会议重投与格式转换

在会议间转换时，绝不把 LaTeX 导言区在模板间复制：

# 1. 用目标模板全新开始
cp -r templates/icml2026/ new_submission/

# 2. 只复制内容章节（不复制导言区）
#    —— 摘要文字、章节内容、图、表、bib 条目

# 3. 按页数限制调整
# 4. 加会议特定必备章节
# 5. 更新参考文献

砍页时：证明移附录、压缩相关工作、合并表、用子图。扩页时：加消融、扩局限性、加额外基线、加定性示例。

被拒后：在新版里解决评审关切，但不要加“changes”章节或提及前次投稿（双盲）。

步骤 7.8：Camera-Ready 准备（接收后）

接收后准备 camera-ready：

Camera-Ready 清单：
- [ ] 去匿名：加作者姓名、单位、邮箱
- [ ] 加致谢章节（资助、算力基金、有帮助的评审）
- [ ] 加公开代码/数据 URL（真实 GitHub，不是匿名）
- [ ] 处理元评审要求的任何强制修改
- [ ] 模板切到 camera-ready 模式（如适用——如 AAAI \anon → \camera）
- [ ] 如会议要求加版权声明
- [ ] 更新文中任何 “anonymous” 占位符
- [ ] 验证最终 PDF 干净编译
- [ ] 查 camera-ready 页数限制（有时与投稿不同）
- [ ] 上传补充材料（代码、数据、附录）到会议门户

步骤 7.9：arXiv 与预印本策略

发 arXiv 在 ML 是惯例，但有重要的时机与匿名考量。

时机决策树：

arXiv 分类选择（ML/AI 论文）：

列主类 + 1-2 个交叉类。 分类越多曝光越多，但只在真正相关时交叉。

版本策略：

• v1：初次投稿（与会议投稿一致）
• v2：接收后带 camera-ready 修正（摘要加 “accepted at [Venue]”）
• 评审期间不要发明显回应评审反馈的 v2

# 选标题前查你的论文标题在 arXiv 是否已被占用
pip install arxiv
python -c "
import arxiv
results = list(arxiv.Search(query='ti:\"Your Exact Title\"', max_results=5).results())
print(f'Found {len(results)} matches')
for r in results: print(f'  {r.title} ({r.published.year})')
"

步骤 7.10：研究代码打包

发布干净、可跑的代码能显著提高引用和评审信任。把代码和 camera-ready 一起打包。

仓库结构：

your-method/
  README.md              # 安装、用法、复现说明
  requirements.txt       # 或 conda 用 environment.yml
  setup.py               # pip 可装包
  LICENSE                # 研究推荐 MIT 或 Apache 2.0
  configs/               # 实验配置
  src/                   # 核心方法实现
  scripts/               # 训练、评估、分析脚本
    train.py
    evaluate.py
    reproduce_table1.sh  # 每个主结果一个脚本
  data/                  # 小数据或下载脚本
    download_data.sh
  results/               # 供验证的预期输出

研究代码 README 模板：

# [论文标题]

"[论文标题]"（会议 年份）的官方实现。

## 安装
[设置环境的确切命令]

## 复现
复现表 1：`bash scripts/reproduce_table1.sh`
复现图 2：`python scripts/make_figure2.py`

## 引用
[BibTeX 条目]

发布前清单：

- [ ] 从干净 clone 能跑（在新机器或 Docker 上测）
- [ ] 所有依赖固定到具体版本
- [ ] 无硬编码绝对路径
- [ ] 仓库无 API 密钥、凭据或个人数据
- [ ] README 覆盖安装、复现、引用
- [ ] 有 LICENSE 文件（MIT 或 Apache 2.0 最大化复用）
- [ ] 结果在预期方差内可复现
- [ ] .gitignore 排除数据文件、checkpoint、日志

投稿用匿名代码（接收前）：

# 双盲评审用 Anonymous GitHub
# https://anonymous.4open.science/
# 上传仓库 → 拿到匿名 URL → 放进论文

阶段 8：接收后交付物

目标：通过展示材料和社区参与最大化你论文的影响。

步骤 8.1：会议海报

大多数会议有海报环节。海报设计原则：

工具：LaTeX（beamerposter 宏包）、PowerPoint/Keynote、Figma、Canva。

制作：会议前 2+ 周订。布制海报旅行更轻。许多会议现在也支持虚拟/数字海报。

步骤 8.2：会议报告 / Spotlight

若获 oral 或 spotlight：

幻灯片设计规则：

• 一页一个想法
• 文字最少——细节口头讲，不要投影出来
• 关键图逐步动画，循序渐进建立理解
• 结尾放一页“takeaway”（一句话贡献）
• 为预期问题准备备份页

步骤 8.3：博客 / 社交媒体

易懂的总结显著扩大影响：

• Twitter/X 串：5-8 条。从结果而非方法开头。含图 1 和关键结果图。
• 博客：800-1500 词。写给 ML 从业者，不是评审。跳过形式化，强调直觉和实践意义。
• 项目页：含摘要、图、demo、代码链接、BibTeX 的 HTML 页。用 GitHub Pages。

时机：论文见刊或 arXiv camera-ready 后 1-2 天内发。

Workshop 与短论文

Workshop 论文和短论文（如 ACL 短论文、Findings 论文）遵循同一流水线，但约束和期望不同。

Workshop 论文

何时投 workshop：

• 早期想法，想在写完整论文前先获反馈
• 不够 8+ 页的负面结果
• 对热门话题的立场文或观点
• 复现研究或可复现性报告

ACL 短论文与 Findings

ACL 会议有不同投稿类型：

短论文策略：选一个主张并充分支撑。不要把长论文压成 4 页——写一篇不同的、更聚焦的论文。

实证 ML 之外的论文类型

上面的主流水线面向实证 ML 论文。其他论文类型需要不同结构和证据标准。各类详细指南见 references/paper-types.md。

理论论文

结构：引言 → 预备知识（定义、记号）→ 主结果（定理）→ 证明梗概 → 讨论 → 完整证明（附录）

与实证论文的关键区别：

• 贡献是定理、界或不可能性结果——不是实验数字
• 方法章节由“预备知识”和“主结果”取代
• 证明就是证据，不是实验（尽管理论的实证验证受欢迎）
• 正文放证明梗概、附录放完整证明是惯例
• 实验章节可选，但若是验证理论预测则增强论文

证明写作原则：

• 形式化陈述定理，所有假设明确
• 形式证明前给直觉（“关键洞见是……”）
• 证明梗概应在 0.5-1 页传达主想法
• 用 \begin{proof}...\end{proof} 环境
• 给假设编号并在定理中引用：“在假设 1-3 下，……”

综述 / 教程论文

结构：引言 → 分类体系 / 组织 → 详细覆盖 → 开放问题 → 结论

关键区别：

• 贡献是组织、综合和识别开放问题——不是新方法
• 必须在范围内全面（评审会查漏引）
• 需要清晰的分类体系或组织框架
• 价值来自单篇论文之间不做的连接
• 最佳发表处：TMLR（综述 track）、JMLR、Foundations and Trends in ML、ACM Computing Surveys

基准论文

结构：引言 → 任务定义 → 数据集构建 → 基线评估 → 分析 → 预期用途与局限

关键区别：

• 贡献是基准本身——必须填补真实的评估空白
• 数据集文档是强制的，不是可选（见 Datasheets，步骤 5.11）
• 必须证明基准有挑战性（基线不会饱和）
• 必须证明基准测的就是你声称的（构念效度）
• 最佳发表处：NeurIPS Datasets & Benchmarks track、ACL（资源论文）、LREC-COLING

立场论文

结构：引言 → 背景 → 论点 / 主张 → 支撑证据 → 反驳 → 启示

关键区别：

• 贡献是一个论点，不是结果
• 必须认真对待反驳
• 证据可以是实证、理论或逻辑分析
• 最佳发表处：ICML（立场 track）、workshop、TMLR

Hermes Agent 集成

本 skill 为 Hermes agent 设计。它使用 Hermes 工具、委派、调度和记忆完成完整研究生命周期。

相关 skill

把本 skill 与其他 Hermes skill 组合用于特定阶段：

本 skill 取代 ml-paper-writing——它包含 ml-paper-writing 的全部内容，外加完整实验/分析流水线和 autoreason 方法论。

Hermes 工具参考

工具使用模式

实验监控（最常见）：

terminal("ps aux | grep <pattern>")
→ terminal("tail -30 <logfile>")
→ terminal("ls results/")
→ execute_code("分析结果 JSON、算指标")
→ terminal("git add -A && git commit -m '<描述性消息>' && git push")
→（最终响应自动投递 "Experiment complete: <summary>"；无人值守运行则通过 cron 带 deliver: 目标调度）

并行章节起草（用委派）：

delegate_task("基于这些实验脚本和配置起草方法章节。
  包括：伪代码、所有超参数、足以复现的架构细节。
  用 neurips2025 模板约定写 LaTeX。")

delegate_task("起草相关工作章节。用 web_search 和 web_extract 找论文。
  通过 Semantic Scholar 验证每条引用。按方法分组。")

delegate_task("起草实验章节。读 results/ 下所有结果文件。
  说明每个实验支撑哪条主张。含误差棒和显著性。")

每个 delegate 作为全新子 agent 运行，无共享上下文——在 prompt 里提供全部必要信息。收集输出并整合。

引用验证（用 execute_code）：

# 在 execute_code 中：
from semanticscholar import SemanticScholar
import requests

sch = SemanticScholar()
results = sch.search_paper("attention mechanism transformers", limit=5)
for paper in results:
    doi = paper.externalIds.get('DOI', 'N/A')
    if doi != 'N/A':
        bibtex = requests.get(f"https://doi.org/{doi}", 
                              headers={"Accept": "application/x-bibtex"}).text
        print(bibtex)

用 memory 和 todo 管理状态

memory 工具——持久化关键决策（有界：MEMORY.md 约 2200 字符）：

memory("add", "Paper: autoreason. Venue: NeurIPS 2025 (9 pages). 
  Contribution: structured refinement works when generation-evaluation gap is wide.
  Key results: Haiku 42/42, Sonnet 3/5, S4.6 constrained 2/3.
  Status: Phase 5 — drafting Methods section.")

重大决策或阶段转换后更新 memory。这跨会话持久。

todo 工具——跟踪细粒度进度：

todo("add", "Design constrained task experiments for Sonnet 4.6")
todo("add", "Run Haiku baseline comparison")
todo("add", "Draft Methods section")
todo("update", id=3, status="in_progress")
todo("update", id=1, status="completed")

会话启动协议：

1. todo("list")                           # 查当前任务列表
2. memory("read")                         # 回忆关键决策
3. terminal("git log --oneline -10")      # 查最近提交
4. terminal("ps aux | grep python")       # 查在跑的实验
5. terminal("ls results/ | tail -20")     # 查新结果
6. 向用户报告状态，询问方向

用 cronjob 做 cron 监控

用 cronjob 工具安排周期性实验检查：

cronjob("create", {
  "schedule": "*/30 * * * *",  # 每 30 分钟
  "prompt": "Check experiment status:
    1. ps aux | grep run_experiment
    2. tail -30 logs/experiment_haiku.log
    3. ls results/haiku_baselines/
    4. If complete: read results, compute Borda scores, 
       git add -A && git commit -m 'Add Haiku results' && git push
    5. Report: table of results, key finding, next step
    6. If nothing changed: respond with [SILENT]"
})

[SILENT] 协议：自上次检查无变化时，精确回复 [SILENT]。这抑制对用户的通知。只有真正值得知道的变化才报告。

截止跟踪：

cronjob("create", {
  "schedule": "0 9 * * *",  # 每天 9am
  "prompt": "NeurIPS 2025 deadline: May 22. Today is {date}. 
    Days remaining: {compute}. 
    Check todo list — are we on track? 
    If <7 days: warn user about remaining tasks."
})

沟通模式

何时通知用户（通过你的直接/最终响应，或无人值守运行的 cron deliver: 目标）：

• 实验批次完成（带结果表）
• 需要决策的意外发现或失败
• 草稿章节可评审
• 截止临近而任务未完成

何时不通知：

• 实验在跑、无新结果 → [SILENT]
• 例行监控无变化 → [SILENT]
• 不需关注的中间步骤

报告格式——始终含结构化数据：

## 实验：<名>
状态：完成 / 运行中 / 失败

| 任务 | 方法 A | 方法 B | 方法 C |
|------|--------|--------|--------|
| 任务 1 | 85.2 | 82.1 | **89.4** |

关键发现：<一句话>
下一步：<接下来做什么>

需要人工输入的决策点

真正卡住时用 clarify 问有针对性的问题：

不要问（主动、自己选、标注）：

• 措辞、章节顺序
• 突出哪些具体结果
• 引用完整性（用你找到的起草，记下空白）

评审评估标准

理解评审看什么有助于聚焦精力：

打分（NeurIPS 6 分制）：

• 6：Strong Accept——开创性、无瑕疵
• 5：Accept——技术扎实、高影响
• 4：Borderline Accept——扎实、评估有限
• 3：Borderline Reject——弱点更大
• 2：Reject——技术缺陷
• 1：Strong Reject——已知结果或伦理问题

详细指南、常见关切和 rebuttal 策略见 references/reviewer-guidelines.md。

常见问题与解决

参考文档

LaTeX 模板

templates/ 下有 NeurIPS 2025、ICML 2026、ICLR 2026、ACL、AAAI 2026、COLM 2025 模板。

编译说明见 templates/README.md。

关键外部来源

写作哲学：

• Neel Nanda: How to Write ML Papers
• Sebastian Farquhar: How to Write ML Papers
• Gopen & Swan: Science of Scientific Writing
• Lipton: Heuristics for Scientific Writing
• Perez: Easy Paper Writing Tips

API：Semantic Scholar | CrossRef | arXiv

会议：NeurIPS | ICML | ICLR | ACL