research-paper-writing

研究论文写作工作流

一套端到端工作流，用于产出面向 NeurIPS、ICML、ICLR、ACL、AAAI 和 COLM 的可发表 ML/AI 研究论文。本技能涵盖完整的研究生命周期：实验设计、执行、监控、分析、论文写作、评审、修订和投稿。

这不是线性工作流——而是一个迭代循环。实验结果会触发新实验，评审意见会触发新分析。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)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

---

何时使用此技能

在以下情况下使用此技能：

• 基于现有代码库或想法，开始新的研究论文
• 设计并运行实验，以支撑论文论点
• 撰写或修改研究论文的任何章节
• 准备投稿至特定会议或研讨会
• 回应评审意见，通过补充实验或修订来处理
• 在不同会议格式之间转换论文
• 撰写非实证论文——理论、综述、基准或立场论文（请参阅实证 ML 之外的论文类型）
• 为 NLP、HCI 或对齐研究设计人工评估
• 准备录用后的交付物——海报、演讲和代码发布

核心理念

1. **保持主动。**交付完整草稿，而不是提问。科学家都很忙——先产出具体内容供他们反馈，然后迭代。
2. **绝不臆造引用。**AI 生成的引用错误率约为 40%。始终以程序化方式获取引用。将无法验证的引用标记为 [CITATION NEEDED]。
3. **论文是一个故事，而不是实验的集合。**每篇论文都需要有一项明确贡献，并用一句话表述。如果做不到，论文就还没准备好。
4. **实验服务于论点。**每项实验都必须明确说明它支持哪项论点。绝不运行与论文叙事无关的实验。
5. **尽早提交、经常提交。**每完成一批实验、每次更新论文草稿，都要使用描述性消息提交。Git 日志就是实验历史。

主动性与协作

默认：保持主动。先起草，再基于草稿提问。

置信度等级	操作
高（代码库清晰，贡献明确）	撰写完整草稿，交付后根据反馈迭代
中（存在一些歧义）	撰写草稿，标出不确定之处并继续
低（存在重大未知因素）	通过 clarify 提出 1-2 个有针对性的问题，然后起草

章节	是否自主起草？	在草稿中标注
摘要	是	将贡献定位为 X——如有需要请调整
引言	是	强调了问题 Y——若有误请更正
方法	是	纳入了细节 A、B、C——补充缺失内容
实验	是	突出了结果 1、2、3——如有需要可重新排序
相关工作	是	引用了论文 X、Y、Z——补充我遗漏的任何论文

仅在以下情况下暂停并等待输入：目标投稿会议不明确、存在多种相互矛盾的表述框架、结果似乎不完整，或明确要求先行审阅。

---

阶段 0：项目设置

目标：建立工作区，了解现有工作并确定贡献。

第 0.1 步：探索代码库

# Understand project structure
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 source, figures, compiled PDFs
  experiments/         # Experiment runner scripts
  code/                # Core method implementation
  results/             # Raw experiment results (auto-generated)
  tasks/               # Task/benchmark definitions
  human_eval/          # Human evaluation materials (if needed)

第 0.3 步：设置版本控制

git init  # if not already
git remote add origin <repo-url>
git checkout -b paper-draft  # or 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 工具创建结构化的项目计划：

Research Paper TODO:
- [ ] Define one-sentence contribution
- [ ] Literature review (related work + baselines)
- [ ] Design core experiments
- [ ] Run experiments
- [ ] Analyze results
- [ ] Write first draft
- [ ] Self-review (simulate reviewers)
- [ ] Revise based on review
- [ ] Submission prep

在项目过程中持续更新该计划。它是跨会话保存状态的依据。

步骤 0.6：估算计算预算

运行实验之前，估算总成本和时间：

Compute Budget Checklist:
- [ ] API costs: (model price per token) × (estimated tokens per run) × (number of runs)
- [ ] GPU hours: (time per experiment) × (number of experiments) × (number of seeds)
- [ ] Human evaluation costs: (annotators) × (hours) × (hourly rate)
- [ ] Total budget ceiling and contingency (add 30-50% for reruns)

实验运行期间，跟踪实际支出：

# Simple cost tracker pattern
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 使用经验
Git + LaTeX	使用 .gitignore 排除辅助文件的 git	技术团队，需要基于分支进行审阅
Overleaf + Git sync	Overleaf premium	两全其美——实时协作并保留版本历史

章节分工：每个章节指定一位主要作者。其他作者可以评论，但不要直接编辑。这样可以避免合并冲突和风格不一致。

Author Coordination Checklist:
- [ ] Agree on section ownership (who writes what)
- [ ] Set up shared workspace (Overleaf or git repo)
- [ ] Establish notation conventions (before anyone writes)
- [ ] Schedule internal review rounds (not just at the end)
- [ ] Designate one person for final formatting pass
- [ ] Agree on figure style (colors, fonts, sizes) before creating figures

尽早商定 LaTeX 约定：

• 使用 \method{} 宏统一方法名称
• 引用样式：\citet{} 与 \citep{} 的用法
• 数学记法：向量使用小写粗体，矩阵使用大写粗体等
• 英式拼写还是美式拼写

---

阶段 1：文献综述

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

步骤 1.1：确定种子论文

从代码库中已经引用的论文入手：

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

步骤 1.2：搜索相关工作

加载 arxiv 技能，以便系统地发现论文：skill_view("arxiv")。它提供 arXiv REST API 搜索、Semantic Scholar 引用图、作者档案和 BibTeX 生成。

使用 web_search 广泛查找，使用 web_extract 获取特定论文：

# Via web_search:
web_search("[main technique] + [application domain] site:arxiv.org")
web_search("[baseline method] comparison ICML NeurIPS 2024")

# Via web_extract (for specific papers):
web_extract("https://arxiv.org/abs/2303.17651")

可尝试的其他搜索查询：

Search queries:
- "[main technique] + [application domain]"
- "[baseline method] comparison"
- "[problem name] state-of-the-art"
- Author names from existing citations

建议：安装 Exa MCP，进行实时学术搜索：

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

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

仅进行一轮查询的浅层搜索通常会遗漏重要的相关工作。采用迭代式的先广后深模式，借鉴深度研究流程：

Iterative Literature Search:

Round 1 (Breadth): 4-6 parallel queries covering different angles
  - "[method] + [domain]"
  - "[problem name] state-of-the-art 2024 2025"
  - "[baseline method] comparison"
  - "[alternative approach] vs [your approach]"
  → Collect papers, extract key concepts and terminology

Round 2 (Depth): Generate follow-up queries from Round 1 learnings
  - New terminology discovered in Round 1 papers
  - Papers cited by the most relevant Round 1 results
  - Contradictory findings that need investigation
  → Collect papers, identify remaining gaps

Round 3 (Targeted): Fill specific gaps
  - Missing baselines identified in Rounds 1-2
  - Concurrent work (last 6 months, same problem)
  - Key negative results or failed approaches
  → Stop when new queries return mostly papers you've already seen

何时停止：如果一轮搜索返回的论文中，超过 80% 已在你的收藏中，则说明搜索已趋于饱和。通常 2-3 轮即可。综述论文则预计需要 4-5 轮。

对于基于 Agent 的工作流：通过 delegate_task 并行分派每一轮的查询。收集结果并去重，然后根据汇总所得的信息生成下一轮查询。

步骤 1.3：核实每条引用

绝不根据记忆生成 BibTeX。务必通过程序获取。

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

Citation Verification (MANDATORY per citation):
1. SEARCH → Query Semantic Scholar or Exa MCP with specific keywords
2. VERIFY → Confirm paper exists in 2+ sources (Semantic Scholar + arXiv/CrossRef)
3. RETRIEVE → Get BibTeX via DOI content negotiation (programmatically, not from memory)
4. VALIDATE → Confirm the claim you're citing actually appears in the paper
5. ADD → Add verified BibTeX to bibliography
If ANY step fails → mark as [CITATION NEEDED], inform scientist

# Fetch BibTeX via DOI
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: Verify this citation exists

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

完整的 API 文档和 CitationManager 类请参阅 references/citation-workflow.md。

步骤 1.4：整理相关工作

按方法归类论文，而不是逐篇介绍：

较好：“一种研究方向采用 X 假设 [refs]，而我们采用 Y 假设，因为……” 较差：“Smith 等人提出了 X。Jones 等人提出了 Y。我们将两者结合起来。”

---

阶段 2：实验设计

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

第 2.1 步：将主张映射到实验

建立明确的映射：

主张	实验	预期证据
“我们的方法优于基线”	主对比实验（表 1）	胜率、统计显著性
“对较弱模型的效果更大”	模型缩放研究	单调改进曲线
“收敛需要范围约束”	有约束与无约束对比	收敛速率对比

规则：如果某项实验未映射到任何主张，就不要运行。

第 2.2 步：设计基线

强有力的基线是论文被接收与被拒稿的关键区别。审稿人会问：“他们是否与 X 进行了比较？”

标准基线类别：

• 朴素基线：尽可能简单的方法
• 强基线：已知最佳的现有方法
• 消融基线：从你的方法中移除一个组件
• 计算量匹配基线：计算预算相同，但分配方式不同

第 2.3 步：定义评估协议

在运行任何内容前，明确以下内容：

• 指标：测量内容、方向符号（数值越高或越低越好）
• 汇总方式：如何跨多次运行和任务合并结果
• 统计检验：用于确定显著性的检验
• 样本量：运行次数、问题数量和任务数量

第 2.4 步：编写实验脚本

遵循成功研究流水线中的以下模式：

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

# Save after each problem/task
result_path = f"results/{task}/{strategy}/result.json"
if os.path.exists(result_path):
    continue  # Skip already-completed work
# ... run experiment ...
with open(result_path, 'w') as f:
    json.dump(result, f, indent=2)

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

results/<experiment>/
  <task>/
    <strategy>/
      final_output.md          # Final result
      history.json             # Full trajectory
      pass_01/                 # Per-iteration artifacts
        version_a.md
        version_b.md
        critic.md

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

run_experiment.py              # Core experiment runner
run_baselines.py               # Baseline comparison
run_comparison_judge.py        # Blind evaluation
analyze_results.py             # Statistical analysis
make_charts.py                 # Visualization

有关完整的设计模式、cron 监控和错误恢复，请参阅 references/experiment-patterns.md。

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

许多 NLP、HCI 和对齐论文需要将人工评估作为主要或补充证据。在运行自动实验前完成设计，因为人工评估的准备周期通常更长（IRB 审批、标注者招募）。

需要人工评估的情况：

• 自动指标无法反映你关注的内容（流畅性、有用性、安全性）
• 你的贡献涉及面向人的特性（可读性、偏好、信任度）
• NLP 会议（ACL、EMNLP）的审稿人对于生成任务会要求提供人工评估

关键设计决策：

决策	选项	指导
标注者类型	专家、众包工作者、终端用户	与主张的要求相匹配
规模	Likert（1-5）、成对比较、排名	对于大模型输出，成对比较比 Likert 更可靠
样本量	每位标注者和总条目数	进行功效分析，或至少设置 100 个条目、3 名以上标注者
一致性指标	Cohen's kappa、Krippendorff's alpha、ICC	超过 2 名标注者时使用 Krippendorff's alpha；也要报告原始一致率
平台	Prolific、MTurk、内部团队	对质量要求高时用 Prolific；需要规模时用 MTurk；需要领域专业知识时用内部团队

标注指南检查清单：

- [ ] Clear task description with examples (good AND bad)
- [ ] Decision criteria for ambiguous cases
- [ ] At least 2 worked examples per category
- [ ] Attention checks / gold standard items (10-15% of total)
- [ ] Qualification task or screening round
- [ ] Estimated time per item and fair compensation (>= local minimum wage)
- [ ] IRB/ethics review if required by your institution

报告要求（审稿人会检查以下所有内容）：

• 标注者人数及其资质
• 标注者间一致性及其具体指标和数值
• 报酬细节（金额、预计时薪）
• 标注界面说明或屏幕截图（附录）
• 总标注时间

有关包括人工评估数据统计检验、众包质量控制模式和 IRB 指导在内的完整指南，请参阅 references/human-evaluation.md。

---

阶段 3：实验执行与监控

目标：可靠地运行实验、监控进度并从故障中恢复。

第 3.1 步：启动实验

长时间运行的实验应使用 nohup：

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

并行执行：同时运行相互独立的实验，但要注意 API 速率限制。在同一 API 上并发运行 4 个以上实验会彼此拖慢。

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

对于长时间运行的实验，应设置定期状态检查。cron 提示词应采用以下模板：

Monitor Prompt Template:
1. Check if process is still running: ps aux | grep <pattern>
2. Read last 30 lines of log: tail -30 <logfile>
3. Check for completed results: ls <result_dir>
4. If results exist, read and report: cat <result_file>
5. If all done, commit: git add -A && git commit -m "<descriptive message>" && git push
6. Report in structured format (tables with key metrics)
7. Answer the key analytical question for this experiment

静默模式：如果自上次检查以来没有任何变化，请回复 [SILENT]，以避免向用户发送通知。仅在有新情况时报告。

步骤 3.3：处理失败

常见失败模式及恢复方式：

失败	检测	恢复
API 速率限制或额度耗尽	日志中出现 402/429 错误	等待后重新运行（脚本会跳过已完成的工作）
进程崩溃	PID 已消失，结果不完整	从上次检查点重新运行
难题超时	进程卡住，日志无进展	终止进程并跳过，在结果中注明
模型 ID 错误	出现引用模型名称的错误	修正 ID 后重新运行

关键点：脚本应始终检查现有结果，并跳过已完成的工作。这样可以安全、高效地重新运行。

步骤 3.4：提交已完成的结果

每批实验完成后：

git add -A
git commit -m "Add <experiment name>: <key finding in 1 line>"
git push

步骤 3.5：维护实验日志

Git 提交记录发生了什么，但不会记录 探索树——即根据所学内容决定下一步尝试什么的决策过程。维护结构化实验日志以记录这棵树：

// experiment_journal.jsonl — append one entry per experiment attempt
{
  "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. 生成汇总表格

# Standard analysis pattern
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

# Compute aggregate metrics
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's d 或 h，用于衡量实际显著性

有关 McNemar 检验、自助法置信区间和 Cohen's h 的完整实现，请参阅 references/experiment-patterns.md。

步骤 4.3：识别核心故事

分析后，明确回答以下问题：

1. 主要发现是什么？ 用一句话陈述。
2. 什么让你感到意外？ 出乎意料的结果往往能成就最出色的论文。
3. 什么失败了？ 失败实验往往能提供最多信息。如实报告失败能增强论文的说服力。
4. 需要开展哪些后续实验？ 结果往往会引出新的问题。

处理负面或空结果

当你的假设有误或结果无法得出结论时，有三种选择：

情况	做法	适合的发表场合
假设有误，但原因具有启发性	围绕对原因的分析来构思论文	NeurIPS、ICML（前提是分析严谨）
方法未胜过基线，但揭示了新发现	将贡献重新定位为理解或分析	ICLR（重视理解）、研讨会论文
对热门观点得出明确的负面结果	将其写成论文——该领域需要了解这一结果	NeurIPS Datasets & Benchmarks、TMLR、研讨会
结果无法得出结论，也没有明确的故事	转向其他方向——进行不同的实验或重新构思	不要硬凑一篇并不存在的论文

如何撰写负面结果论文：

• 从学界普遍相信的观点及其为何值得检验入手
• 描述严谨的方法（必须经得起推敲——审稿人会更加仔细地审查）
• 结合统计证据，清晰地呈现空结果
• 分析预期结果为何未能出现
• 讨论对该领域的影响

明确欢迎负面结果的发表场合：NeurIPS（Datasets & Benchmarks 赛道）、TMLR、ML Reproducibility Challenge、各大会议的研讨会。一些研讨会会专门征集负面结果。

第 4.4 步：创建图表和表格

图表：

• 所有绘图均使用矢量图形（PDF）：plt.savefig('fig.pdf')
• 使用色觉障碍友好型配色方案（Okabe-Ito 或 Paul Tol）
• 使用自包含的图注——读者无需阅读正文也应能理解
• 图内不加标题——图注承担这一作用

表格：

• 使用 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 步：决定是继续实验还是开始写作

情况	做法
核心论点得到支持，结果显著	进入第 5 阶段（写作）
结果无法得出结论，需要更多数据	返回第 2 阶段（设计）
意外发现提示了新的方向	返回第 2 阶段（设计）
缺少一项审稿人会要求的消融实验	完成后进入第 5 阶段
所有实验均已完成，但有些实验失败	记录失败情况，进入第 5 阶段

第 4.6 步：撰写实验日志（衔接论文写作）

开始撰写论文前，应创建一份结构化的实验日志，将实验结果与文字表述衔接起来。这是实验与论文写作之间最重要的纽带——没有它，写作 Agent 就必须从原始结果文件中重新推导论文故事。

创建 experiment_log.md，并采用以下结构：

# Experiment Log

## Contribution (one sentence)
[The paper's main claim]

## Experiments Run

### Experiment 1: [Name]
- **Claim tested**: [Which paper claim this supports]
- **Setup**: [Model, dataset, config, number of runs]
- **Key result**: [One sentence with the number]
- **Result files**: results/exp1/final_info.json
- **Figures generated**: figures/exp1_comparison.pdf
- **Surprising findings**: [Anything unexpected]

### Experiment 2: [Name]
...

## Figures
| Filename | Description | Which section it belongs in |
|----------|-------------|---------------------------|
| figures/main_comparison.pdf | Bar chart comparing all methods on benchmark X | Results, Figure 2 |
| figures/ablation.pdf | Ablation removing components A, B, C | Results, Figure 3 |
...

## Failed Experiments (document for honesty)
- [What was tried, why it failed, what it tells us]

## Open Questions
- [Anything the results raised that the paper should address]

为何重要：起草论文时，Agent（或受委派的子 Agent）可以结合 LaTeX 模板加载 experiment_log.md，并据实际结果完成初稿。缺少这一衔接，写作 Agent 就必须解析原始 JSON/CSV 文件并推断论文故事——这很容易导致幻觉或错误报告数据。

Git 规范：将此日志与其所描述的结果一同提交。

---

迭代优化：策略选择

此流程中的任何输出——论文草稿、实验脚本、分析结果——都可以通过迭代加以优化。autoreason 研究为各种优化策略何时有效、何时失效提供了实证依据。请阅读本节，选择合适的方法。

快速决策表

你的情况	策略	原因
中档模型 + 受限任务	Autoreason	最佳选择。生成与评估之间的差距最大。基线方法会主动破坏较弱模型的输出。
中档模型 + 开放任务	Autoreason，并添加范围约束	添加固定事实、结构或交付物，以限定改进空间。
前沿模型 + 受限任务	Autoreason	即使使用前沿模型，在 2/3 的受限任务上也能胜出。
前沿模型 + 不受限任务	Critique-and-revise 或 single pass	Autoreason 表现最差。模型的自我评估能力已足够强。
具体技术任务（系统设计）	Critique-and-revise	直接的发现问题并修复循环效率更高。
模板填充任务（只有一种正确结构）	Single pass 或 conservative	决策空间最小。迭代没有价值。
带测试用例的代码	Autoreason（代码变体）	修复前先对失败原因进行结构化分析。恢复率为 62%，而非 43%。
非常弱的模型（Llama 8B 级别）	Single pass	模型太弱，无法生成多样化的候选结果。应投入精力提升生成质量。

生成与评估之间的差距

核心洞见：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. 评论者 → 找出当前版本 A 中的问题（不提供修复方案）
2. 作者 B → 根据评论修改 A
3. 综合者 → 合并 A 和 B（标签随机化）
4. 评审小组 → 3 位盲测 CoT 评审通过 Borda 计数对 A、B、AB 排序
5. 收敛 → A 连续 k=2 轮获胜 → 完成

关键参数：

• k=2 收敛（k=1 过早，k=3 成本过高，且质量没有提升）
• 始终使用 CoT 评审（收敛速度提高 3 倍）
• 作者温度为 0.8，评审温度为 0.3
• 保守的平局规则：平局时由当前版本胜出
• 每个角色都由全新的 Agent 担任，且不共享上下文

将其应用于论文草稿

通过 autoreason 润色论文时：

• 向评论者提供真实数据：实际实验数据、结果 JSON 和统计输出。缺少这些信息时，模型会编造消融研究和虚假的置信区间。
• 至少使用 3 位正常工作的评审：评审解析器故障不会增加噪声，而是会彻底阻止系统达到均衡。
• 限制修改范围：使用“解决这些具体弱点”，而不是“改进论文”。

失败模式

失败	检测方法	修复方法
未能收敛（A 从未获胜）	20 轮以上时 A 的胜率低于 15%	为任务添加范围约束
综合结果漂移	字数持续无界增长	限定结构和交付物
结果不如单轮处理	基线得分高于迭代输出	切换到单轮处理；模型可能太弱
过拟合（代码）	公开测试集通过率高，私有测试集通过率低	使用结构化分析，而不只是测试反馈
评审故障	解析失败导致评审小组人数少于 3 人	继续之前先修复解析器

完整提示词、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）

使用不同的模型或温度设置。每位评审者只能看到论文，而看不到其他评审。默认采用负面倾向——已有充分记录表明，大模型在评估中存在正面偏差。

You are an expert reviewer for [VENUE]. You are critical and thorough.
If a paper has weaknesses or you are unsure about a claim, flag it clearly
and reflect that in your scores. Do not give the benefit of the doubt.

Review this paper according to the official reviewer guidelines. Evaluate:

1. Soundness (are claims well-supported? are baselines fair and strong?)
2. Clarity (is the paper well-written? could an expert reproduce it?)
3. Significance (does this matter to the community?)
4. Originality (new insights, not just incremental combination?)

Provide your review as structured JSON:
{
  "summary": "2-3 sentence summary",
  "strengths": ["strength 1", "strength 2", ...],
  "weaknesses": ["weakness 1 (most critical)", "weakness 2", ...],
  "questions": ["question for authors 1", ...],
  "missing_references": ["paper that should be cited", ...],
  "soundness": 1-4,
  "presentation": 1-4,
  "contribution": 1-4,
  "overall": 1-10,
  "confidence": 1-5
}

第 2 步：元评审（领域主席汇总）

将全部 N 份评审意见提供给元评审者：

You are an Area Chair at [VENUE]. You have received [N] independent reviews
of a paper. Your job is to:

1. Identify consensus strengths and weaknesses across reviewers
2. Resolve disagreements by examining the paper directly
3. Produce a meta-review that represents the aggregate judgment
4. Use AVERAGED numerical scores across all reviews

Be conservative: if reviewers disagree on whether a weakness is serious,
treat it as serious until the authors address it.

Reviews:
[review_1]
[review_2]
...

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

每位评审者在看到元评审后，都可以完善自己的评审。使用提前终止哨兵：如果评审者回复“我已完成”（无修改），则停止迭代。

评审的模型选择：评审最好使用可用的最强模型完成，即使你撰写论文时使用的是成本较低的模型。评审模型应独立于写作模型进行选择。

少样本校准：如有可用材料，请包含目标会议或期刊发表的 1-2 份真实评审意见作为示例。这能显著提高评分校准度。示例评审意见见 references/reviewer-guidelines.md。

第 6.1b 步：视觉评审环节（VLM）

纯文本评审会遗漏整整一类问题：图形质量、布局问题和视觉一致性。如果可以访问具备视觉能力的模型，请对编译后的 PDF 另行执行一次视觉评审：

You are reviewing the visual presentation of this research paper PDF.
Check for:
1. Figure quality: Are plots readable? Labels legible? Colors distinguishable?
2. Figure-caption alignment: Does each caption accurately describe its figure?
3. Layout issues: Orphaned section headers, awkward page breaks, figures far from their references
4. Table formatting: Aligned columns, consistent decimal precision, bold for best results
5. Visual consistency: Same color scheme across all figures, consistent font sizes
6. Grayscale readability: Would the figures be understandable if printed in B&W?

For each issue, specify the page number and exact location.

这可以发现基于文本的评审无法发现的问题：坐标轴标签难以辨认的图、某幅图与首次引用位置相隔 3 页、图 2 与图 5 的配色不一致，或明显宽于栏宽的表格。

第 6.1c 步：主张验证环节

模拟评审后，运行一个单独的验证环节。这可以发现评审者可能遗漏的事实错误：

Claim Verification Protocol:
1. Extract every factual claim from the paper (numbers, comparisons, trends)
2. For each claim, trace it to the specific experiment/result that supports it
3. Verify the number in the paper matches the actual result file
4. Flag any claim without a traceable source as [VERIFY]

对于基于 Agent 的工作流：将验证工作委派给一个全新的子 Agent，它只接收论文文本和原始结果文件。全新上下文可防止确认偏差——验证者不会“记得”结果本应是什么样。

第 6.2 步：确定反馈优先级

收集评审意见后，对其分类：

优先级	操作
关键（技术缺陷、缺少基线）	必须修复。可能需要新增实验 → 返回第 2 阶段
高（表达不清、缺少消融实验）	应在本次修订中修复
中（轻微写作问题、额外实验）	如果时间允许，请修复
低（风格偏好、旁支建议）	记录，供未来工作参考

第 6.3 步：修订循环

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

1. 确定受影响的具体部分
2. 拟定修复方案
3. 验证修复不会破坏其他主张
4. 更新论文
5. 对照评审者提出的问题重新检查

第 6.4 步：审稿回复

在回复实际评审意见时（投稿后），审稿回复是一项不同于论文修订的技能：

格式：逐点回复。针对每位评审者提出的每个问题：

> R1-W1: "The paper lacks comparison with Method X."

We thank the reviewer for this suggestion. We have added a comparison with 
Method X in Table 3 (revised). Our method outperforms X by 3.2pp on [metric] 
(p<0.05). We note that X requires 2x our compute budget.

规则：

• 回应每一个问题——评审者会注意到你漏掉了任何一个
• 先给出最有力的回应
• 简洁直接——评审者会阅读数十份审稿回复
• 如果在审稿回复期间进行了实验，请附上新增结果
• 即使批评依据不足，也绝不要为自己辩护或加以轻视
• 使用 latexdiff 生成带修订标记的 PDF，以展示更改（请参阅专业 LaTeX 工具一节）
• 针对具体、可操作的反馈向评审者致谢（不要泛泛赞扬）

不要做什么：没有证据就称“我们礼貌地表示异议”。没有解释就称“这不在范围内”。只回应优点，从而忽视弱点。

第 6.5 步：论文演进跟踪

在关键里程碑处保存快照：

paper/
  paper.tex                    # Current working version
  paper_v1_first_draft.tex     # First complete draft
  paper_v2_post_review.tex     # After simulated review
  paper_v3_pre_submission.tex  # Final before submission
  paper_v4_camera_ready.tex    # Post-acceptance final

---

第 7 阶段：投稿准备

目标：完成最终检查、格式整理和投稿。

第 7.1 步：会议检查清单

每个会议都有强制检查清单。请仔细完成——检查清单不完整可能导致直接拒稿。

有关以下内容，请参阅 references/checklists.md：

• NeurIPS 16 项论文检查清单
• ICML 广泛影响与可复现性
• ICLR 大模型披露政策
• ACL 强制局限性章节
• 通用投稿前检查清单

第 7.2 步：匿名化检查清单

双盲评审意味着评审人员不能知道论文作者是谁。请检查以下所有内容：

Anonymization Checklist:
- [ ] No author names or affiliations anywhere in the PDF
- [ ] No acknowledgments section (add after acceptance)
- [ ] Self-citations written in third person: "Smith et al. [1] showed..." not "We previously showed [1]..."
- [ ] No GitHub/GitLab URLs pointing to your personal repos
- [ ] Use Anonymous GitHub (https://anonymous.4open.science/) for code links
- [ ] No institutional logos or identifiers in figures
- [ ] No file metadata containing author names (check PDF properties)
- [ ] No "our previous work" or "in our earlier paper" phrasing
- [ ] Dataset names don't reveal institution (rename if needed)
- [ ] Supplementary materials don't contain identifying information

常见错误：补充代码中可见的 Git 提交消息、机构工具生成且带水印的图片、上一版草稿中未删除的致谢、匿名期结束前发布的 arXiv 预印本。

第 7.3 步：格式验证

Pre-Submission Format Check:
- [ ] Page limit respected (excluding references and appendix)
- [ ] All figures are vector (PDF) or high-res raster (600 DPI PNG)
- [ ] All figures readable in grayscale
- [ ] All tables use booktabs
- [ ] References compile correctly (no "?" in citations)
- [ ] No overfull hboxes in critical areas
- [ ] Appendix clearly labeled and separated
- [ ] Required sections present (limitations, broader impact, etc.)

第 7.4 步：编译前验证

在尝试运行 pdflatex 之前，执行以下自动化检查。在这里发现错误比调试编译器输出更快。

# 1. Lint with chktex (catches common LaTeX mistakes)
# Suppress noisy warnings: -n2 (sentence end), -n24 (parens), -n13 (intersentence), -n1 (command terminated)
chktex main.tex -q -n2 -n24 -n13 -n1

# 2. Verify all citations exist in .bib
# Extract \cite{...} from .tex, check each against .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. Verify all referenced figures exist on disk
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. Check for duplicate \label definitions
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 步：最终编译

# Clean build
rm -f *.aux *.bbl *.blg *.log *.out *.pdf
latexmk -pdf main.tex

# Or manual (triple pdflatex + bibtex for cross-references)
pdflatex -interaction=nonstopmode main.tex
bibtex main
pdflatex -interaction=nonstopmode main.tex
pdflatex -interaction=nonstopmode main.tex

# Verify output exists and has content
ls -la main.pdf

如果编译失败：解析 .log 文件并找到第一个错误。常见修复方法：

• “未定义的控制序列” → 缺少软件包或命令名称拼写错误
• “缺少 $，已插入” → 数学符号位于数学模式之外
• “找不到文件” → 图片路径错误或缺少 .sty 文件
• “引文未定义” → 缺少 .bib 条目或未运行 bibtex

第 7.6 步：会议特定要求

会议	特殊要求
NeurIPS	论文检查清单置于附录中；录用后提供通俗摘要
ICML	广泛影响声明（结论之后，不计入篇幅限制）
ICLR	必须提供大模型披露，并签署互惠评审协议
ACL	强制局限性章节、负责任的 NLP 检查清单
AAAI	严格的样式文件——不得做任何修改
COLM	面向语言模型社区阐述贡献

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

在不同会议的模板之间转换时，绝不要在模板之间复制 LaTeX 导言区：

# 1. Start fresh with target template
cp -r templates/icml2026/ new_submission/

# 2. Copy ONLY content sections (not preamble)
#    - Abstract text, section content, figures, tables, bib entries

# 3. Adjust for page limits
# 4. Add venue-specific required sections
# 5. Update references

来源 → 目标	页数变化	关键调整
NeurIPS → ICML	9 → 8	删减 1 页，添加广泛影响声明
ICML → ICLR	8 → 9	扩展实验，添加大模型披露
NeurIPS → ACL	9 → 8	按 NLP 惯例重构，添加局限性章节
ICLR → AAAI	9 → 7	大幅删减，严格遵循样式
任意 → COLM	因会议而异 → 9	围绕语言模型重新定位内容

删减页数时：将证明移至附录，压缩相关工作，合并表格，使用子图。 扩展篇幅时：添加消融实验，扩展局限性部分，纳入更多基线，添加定性示例。

拒稿后：在新版本中回应评审意见，但不要添加“变更”章节，也不要提及之前的投稿（盲审）。

第 7.8 步：终稿准备（录用后）

录用后，准备终稿：

Camera-Ready Checklist:
- [ ] De-anonymize: add author names, affiliations, email addresses
- [ ] Add Acknowledgments section (funding, compute grants, helpful reviewers)
- [ ] Add public code/data URL (real GitHub, not anonymous)
- [ ] Address any mandatory revisions from meta-reviewer
- [ ] Switch template to camera-ready mode (if applicable — e.g., AAAI \anon → \camera)
- [ ] Add copyright notice if required by venue
- [ ] Update any "anonymous" placeholders in text
- [ ] Verify final PDF compiles cleanly
- [ ] Check page limit for camera-ready (sometimes differs from submission)
- [ ] Upload supplementary materials (code, data, appendix) to venue portal

步骤 7.9：arXiv 与预印本策略

将论文发布到 arXiv 是 ML 领域的标准做法，但在时机和匿名性方面需要慎重考虑。

时机决策树：

情况	建议
向双盲会议（NeurIPS、ICML、ACL）投稿	在投稿截止之后发布到 arXiv，而不要在之前发布。提前发布在技术上可能违反匿名性政策，尽管具体执行情况有所不同。
投稿 ICLR	ICLR 明确允许在投稿前发布到 arXiv。但不要在投稿内容中填写作者姓名。
论文已发布到 arXiv，准备投稿至新会议	大多数会议都允许。不要在评审期间更新 arXiv 版本，加入引用评审意见的修改。
研讨会论文	任何时候发布到 arXiv 都可以——研讨会通常不采用双盲审稿。
想确立优先权	如果担心被抢先发表，请立即发布——但要接受匿名性方面的权衡。

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

类别	代码	最适合
机器学习	cs.LG	通用 ML 方法
计算与语言	cs.CL	NLP、语言模型
人工智能	cs.AI	推理、规划、Agent
计算机视觉	cs.CV	视觉模型
信息检索	cs.IR	搜索、推荐

选择主分类，并交叉列出 1-2 个分类。 分类越多，曝光度越高，但只有在确实相关时才应进行交叉列出。

版本策略：

• v1：初始投稿（与会议投稿一致）
• v2：录用后发布终稿修正版（将“已获 [Venue] 接收”添加到摘要中）
• 评审期间不要发布 v2，不要加入明显回应审稿人反馈的修改

# Check if your paper's title is already taken on arXiv
# (before choosing a title)
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：研究代码打包

发布干净、可运行的代码会显著增加引用量和审稿人的信任度。将代码与终稿一同打包提交。

代码仓库结构：

your-method/
  README.md              # Setup, usage, reproduction instructions
  requirements.txt       # Or environment.yml for conda
  setup.py               # For pip-installable packages
  LICENSE                # MIT or Apache 2.0 recommended for research
  configs/               # Experiment configurations
  src/                   # Core method implementation
  scripts/               # Training, evaluation, analysis scripts
    train.py
    evaluate.py
    reproduce_table1.sh  # One script per main result
  data/                  # Small data or download scripts
    download_data.sh
  results/               # Expected outputs for verification

研究代码的 README 模板：

# [Paper Title]

Official implementation of "[Paper Title]" (Venue Year).

## Setup
[Exact commands to set up environment]

## Reproduction
To reproduce Table 1: `bash scripts/reproduce_table1.sh`
To reproduce Figure 2: `python scripts/make_figure2.py`

## Citation
[BibTeX entry]

发布前检查清单：

- [ ] Code runs from a clean clone (test on fresh machine or Docker)
- [ ] All dependencies pinned to specific versions
- [ ] No hardcoded absolute paths
- [ ] No API keys, credentials, or personal data in repo
- [ ] README covers setup, reproduction, and citation
- [ ] LICENSE file present (MIT or Apache 2.0 for max reuse)
- [ ] Results are reproducible within expected variance
- [ ] .gitignore excludes data files, checkpoints, logs

投稿用的匿名代码（录用前）：

# Use Anonymous GitHub for double-blind review
# https://anonymous.4open.science/
# Upload your repo → get an anonymous URL → put in paper

---

阶段 8：录用后的交付内容

目标：通过报告材料和社区参与，最大化录用论文的影响力。

步骤 8.1：会议海报

大多数会议都要求进行海报展示。海报设计原则：

元素	指南
尺寸	查看会议要求（通常为 24"x36" 或 A0 纵向/横向）
内容	标题、作者、一句话概括的贡献、方法图、2-3 个关键结果、结论
视觉动线	从左上到右下（Z 形模式），或采用分栏布局
文字	标题在 3 米处应清晰可读，正文在 1 米处应清晰可读。不要使用完整段落——只能使用项目符号。
插图	以更高分辨率复用论文中的插图。放大关键结果。

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

制作：在会议前 2 周以上下单。布质海报更便于携带。如今许多会议也支持虚拟/数字海报。

步骤 8.2：会议报告 / 重点报告

如果获得口头报告或重点报告机会：

报告类型	时长	内容
重点报告	5 分钟	问题、方法、一个关键结果。排练时要严格控制在 5 分钟。
口头报告	15-20 分钟	完整讲解：问题、方法、关键结果、消融实验、局限性。
研讨会报告	10-15 分钟	根据研讨会听众调整——可能需要补充更多背景介绍。

幻灯片设计规则：

• 每张幻灯片只表达一个观点
• 尽量减少文字——口头讲出细节，不要将其投影出来
• 为关键插图添加动画，逐步帮助理解
• 在末尾加入一张“要点”幻灯片（用一句话概括贡献）
• 为可能提出的问题准备备用幻灯片

步骤 8.3：博客文章／社交媒体

一份通俗易懂的摘要能显著扩大影响力：

• Twitter/X 推文串：5-8 条推文。以结果开篇，而非方法。包含图 1 和关键结果图。
• 博客文章：800-1500 词。面向机器学习实践者，而非审稿人。略去形式化推导，强调直觉和实际意义。
• 项目页面：HTML 页面，包含摘要、插图、演示、代码链接和 BibTeX。使用 GitHub Pages。

时间安排：论文在会议论文集或 arXiv 上的定稿上线后 1-2 天内发布。

---

研讨会与短论文

研讨会论文和短论文（例如 ACL 短论文、Findings 论文）遵循相同的流程，但约束和期望有所不同。

研讨会论文

属性	研讨会	主会
页数限制	4-6 页（通常）	7-9 页
评审标准	对完整性的要求较低	必须完整、详尽
评审流程	通常采用单盲或轻量评审	双盲、严格
看重的方面	有趣的想法、初步结果、立场论文	具有强基线的完整实证研究
arXiv	随时发布	时间很重要（参见 arXiv 策略）
贡献要求	新颖方向、有趣的负面结果、进行中的工作	有力证据支持的显著进展

何时以研讨会为目标：

• 希望在写成完整论文前获得反馈的早期想法
• 不足以支撑 8+ 页的负面结果
• 针对时效性主题的立场论文或观点文章
• 复现研究或可复现性报告

ACL 短论文与 Findings

ACL 有不同的投稿类型：

类型	页数	预期要求
长论文	8	完整研究、强基线、消融实验
短论文	4	聚焦的贡献：围绕一个明确且有证据支撑的观点
Findings	8	质量扎实但与主会擦肩而过的工作

短论文策略：只选定一个主张，并充分论证。不要试图把一篇长论文压缩到 4 页——而应重新写一篇内容不同、重点更集中的论文。

---

实证机器学习之外的论文类型

上述主要流程适用于实证机器学习论文。其他论文类型需要不同的结构和证据标准。每种类型的详细指南见 references/paper-types.md。

理论论文

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

与实证论文的主要区别：

• 贡献是定理、界或不可能性结论——而非实验数值
• 方法部分由“预备知识”和“主要结果”取代
• 证明（而非实验）是依据（但也欢迎对理论进行实证验证）
• 标准做法是在正文中给出证明概要，在附录中给出完整证明
• 实验部分为可选项，但如果能验证理论预测，就能增强论文

证明撰写原则：

• 以正式形式陈述定理，并明确说明所有假设
• 在形式化证明之前提供直觉（“关键洞见是……”）
• 证明概要应在 0.5-1 页内传达主要思路
• 使用 \begin{proof}...\end{proof} 环境
• 对假设进行编号，并在定理中加以引用：“在假设 1-3 下，……”

综述／教程论文

结构：引言 → 分类／组织 → 详细介绍 → 开放问题 → 结论

主要区别：

• 贡献在于组织、综合和识别开放问题——而非提出新方法
• 必须在既定范围内做到全面（审稿人会检查是否遗漏参考文献）
• 需要清晰的分类体系或组织框架
• 价值来自各项工作之间的联系，而单篇论文无法呈现这些联系
• 最佳投稿目标：TMLR（综述方向）、JMLR、Foundations and Trends in ML、ACM Computing Surveys

基准论文

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

主要区别：

• 贡献在于基准本身——它必须填补真正的评估空白
• 数据集文档编制是必需的，而非可选项（参见 Datasheets，第 5.11 步）
• 必须证明基准具有挑战性（基线模型无法轻易达到饱和表现）
• 必须证明基准衡量的是你声称要衡量的内容（构念效度）
• 最适合的会议和期刊：NeurIPS Datasets & Benchmarks track、ACL（资源论文）、LREC-COLING

立场论文

结构：引言 → 背景 → 论点／主张 → 支持证据 → 反驳观点 → 影响

主要区别：

• 贡献是论点，而非结果
• 必须认真探讨反驳观点
• 证据可以来自实证、理论或逻辑分析
• 最适合的会议和期刊：ICML（立场 track）、workshops、TMLR

---

Hermes Agent 集成

此技能专为 Hermes Agent 设计。在整个研究生命周期中，它会使用 Hermes 工具、委派、调度和记忆功能。

相关技能

针对特定阶段，将此技能与其他 Hermes 技能组合使用：

技能	使用时机	加载方式
arxiv	阶段 1（文献综述）：搜索 arXiv、生成 BibTeX、通过 Semantic Scholar 查找相关论文	skill_view("arxiv")
subagent-driven-development	阶段 5（撰写）：并行撰写各章节，并进行两阶段审查（先检查规范合规性，再检查质量）	skill_view("subagent-driven-development")
plan	阶段 0（准备）：执行前创建结构化计划。将内容写入 .hermes/plans/	skill_view("plan")
qmd	阶段 1（文献）：通过 BM25+向量混合搜索，检索本地知识库（笔记、转录文本、文档）	安装：skill_manage("install", "qmd")
diagramming	阶段 4–5：创建基于 Excalidraw 的图示和架构图	skill_view("diagramming")
data-science	阶段 4（分析）：使用 Jupyter 实时内核进行交互式分析与可视化	skill_view("data-science")

此技能取代 ml-paper-writing——它包含 ml-paper-writing 的全部内容，以及完整的实验／分析流程和 autoreason 方法论。

Hermes 工具参考

工具	在此工作流中的用途
terminal	编译 LaTeX（latexmk -pdf）、git 操作、启动实验（nohup python run.py &）、检查进程
process	管理后台实验：process("start", ...)、process("poll", pid)、process("log", pid)、process("kill", pid)
execute_code	运行 Python 进行引用验证、统计分析和数据聚合。可通过 RPC 访问工具。
read_file / write_file / patch	编辑论文、实验脚本和结果文件。对于大型 .tex 文件的定向编辑，请使用 patch。
web_search	查找文献：web_search("transformer attention mechanism 2024")
web_extract	获取论文内容、验证引用：web_extract("https://arxiv.org/abs/2303.17651")
delegate_task	并行撰写各章节——为每个章节启动独立的子 Agent。也可用于并行验证引用。
todo	跨会话的主要状态跟踪器。每次阶段转换后都要更新。
memory	持久保存关键决策：贡献定位、投稿目标、审稿人反馈。
cronjob	安排实验监控、截止日期倒计时和自动检查 arXiv。
clarify	遇到阻碍时向用户提出针对性问题（投稿目标、贡献定位）。
cron deliver:	即使用户不在聊天中，也能在实验完成或草稿就绪时通知用户——将检查安排为以消息 deliver: 为目标的 cron 任务（Agent 不再拥有 send_message 工具；出站消息由 cron/hermes send 处理）。

工具使用模式

实验监控（最常见）：

terminal("ps aux | grep <pattern>")
→ terminal("tail -30 <logfile>")
→ terminal("ls results/")
→ execute_code("analyze results JSON, compute metrics")
→ terminal("git add -A && git commit -m '<descriptive message>' && git push")
→ (final response auto-delivers "Experiment complete: <summary>"; for unattended runs, schedule via cron with a deliver: target)

并行撰写各章节（使用委派）：

delegate_task("Draft the Methods section based on these experiment scripts and configs. 
  Include: pseudocode, all hyperparameters, architectural details sufficient for 
  reproduction. Write in LaTeX using the neurips2025 template conventions.")

delegate_task("Draft the Related Work section. Use web_search and web_extract to 
  find papers. Verify every citation via Semantic Scholar. Group by methodology.")

delegate_task("Draft the Experiments section. Read all result files in results/. 
  State which claim each experiment supports. Include error bars and significance.")

每个委派任务都作为全新的子 Agent运行，且不共享上下文——请在提示词中提供所有必要信息。收集输出并进行整合。

引用验证（使用 execute_code）：

# In 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")                           # Check current task list
2. memory("read")                         # Recall key decisions
3. terminal("git log --oneline -10")      # Check recent commits
4. terminal("ps aux | grep python")       # Check running experiments
5. terminal("ls results/ | tail -20")     # Check for new results
6. Report status to user, ask for direction

使用 cronjob 进行 Cron 监控

使用 cronjob 工具安排定期实验检查：

cronjob("create", {
  "schedule": "*/30 * * * *",  # Every 30 minutes
  "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 * * *",  # Daily at 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]
• 无需关注的中间步骤

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

## Experiment: <name>
Status: Complete / Running / Failed

| Task | Method A | Method B | Method C |
|------|---------|---------|---------|
| Task 1 | 85.2 | 82.1 | **89.4** |

Key finding: <one sentence>
Next step: <what happens next>

需要人工输入的决策点

真正遇到阻碍时，使用 clarify 提出针对性问题：

决策	何时询问
目标投稿 venue	开始撰写论文前（会影响页数限制和内容定位）
贡献定位	存在多种合理定位方式时
实验优先级	TODO 列表中的实验数量超出可用时间时
是否可以投稿	最终提交前

不要询问以下事项（应主动选择并标明）：

• 用词、章节顺序
• 重点展示哪些具体结果
• 引用完整性（根据找到的内容起草，并注明缺失项）

---

审稿人评价标准

了解审稿人的评判重点有助于集中精力：

评判标准	评判内容
质量	技术可靠、论据充分、基线公平
清晰度	表述清晰、专家可复现、符号一致
重要性	对社区的影响、推进理解
原创性	新见解（不要求提出新方法）

评分（NeurIPS 6 分制）：

• 6：强接收——开创性、无瑕疵
• 5：接收——技术扎实、影响重大
• 4：临界接收——内容扎实、评测有限
• 3：临界拒稿——劣势大于优势
• 2：拒稿——存在技术缺陷
• 1：强拒稿——已有已知结果或存在伦理问题

有关详细指南、常见疑问和回复策略，请参阅 references/reviewer-guidelines.md。

---

常见问题与解决方案

问题	解决方案
摘要过于笼统	如果第一句话可以放在任何一篇 ML 论文的开头，就将其删除。从你的具体贡献开始。
引言超过 1.5 页	将背景拆分为“相关工作”。将贡献要点前置。
实验缺少明确主张	在每项实验前添加：“此实验检验 [specific claim] 是否成立……”
审稿人认为论文难以理解	添加路标式引导语，使用统一术语，让图注自成体系。
缺少统计显著性	添加误差条、运行次数、统计检验和置信区间。
实验范围膨胀	每项实验都必须对应一项具体主张。删除无法对应的实验。
论文被拒，需要重新投稿	参阅阶段 7 中的“会议重新投稿”。解决审稿人提出的问题，但不要提及审稿意见。
缺少广泛影响声明	参阅步骤 5.10。大多数会议都要求提供该声明。“没有负面影响”几乎从来不可信。
人工评估被批评不够充分	参阅步骤 2.5 和 references/human-evaluation.md。报告一致性指标、标注者详情和报酬。
审稿人质疑可复现性	发布代码（步骤 7.9），记录所有超参数，并列出随机种子和计算配置细节。
理论论文缺乏直观解释	在形式化证明前添加带有通俗语言解释的证明概要。参阅 references/paper-types.md。
结果为负面或零结果	参阅阶段 4.3 中关于处理负面结果的内容。考虑研讨会、TMLR，或将研究重新定位为分析。

---

参考文档

文档	内容
references/writing-guide.md	Gopen 与 Swan 的七项原则、Perez 的微技巧、Lipton 的措辞建议、Steinhardt 的精确性原则、图表设计
references/citation-workflow.md	引用 API、Python 代码、CitationManager 类、BibTeX 管理
references/checklists.md	NeurIPS 16 项要求、ICML、ICLR、ACL 要求、通用投稿前检查清单
references/reviewer-guidelines.md	评价标准、评分、常见问题、回复审稿意见模板
references/sources.md	所有写作指南、会议指南和 API 的完整参考文献列表
references/experiment-patterns.md	实验设计模式、评估协议、监控、错误恢复
references/autoreason-methodology.md	Autoreason 循环、策略选择、模型指南、提示词、范围约束、Borda 评分
references/human-evaluation.md	人工评估设计、标注指南、一致性指标、众包质量控制、IRB 指南
references/paper-types.md	理论论文（证明写作、定理结构）、综述论文、基准论文、立场论文

LaTeX 模板

templates/ 中的模板适用于：NeurIPS 2025、ICML 2026、ICLR 2026、ACL、AAAI 2026、COLM 2025。

有关编译说明，请参阅 templates/README.md。

主要外部来源

写作理念：

• Neel Nanda：如何撰写 ML 论文
• Sebastian Farquhar：如何撰写 ML 论文
• Gopen 与 Swan：科学写作的科学
• Lipton：科学写作的启发式方法
• Perez：轻松撰写论文的技巧

API： Semantic Scholar | CrossRef | arXiv

会议： NeurIPS | ICML | ICLR | ACL