{/* 此页面由 website/scripts/generate-skill-docs.py 从技能的 SKILL.md 自动生成。请编辑源文件 SKILL.md，而非此页面。 */}

科研论文写作

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

技能元数据


来源	内置（默认已安装）
路径	`skills/research/research-paper-writing`
版本	`1.1.0`
作者	Orchestra Research
许可证	MIT
依赖项	`semanticscholar`、`arxiv`、`habanero`、`requests`、`scipy`、`numpy`、`matplotlib`、`SciencePlots`
平台	linux, macos
标签	`Research`、`Paper Writing`、`Experiments`、`ML`、`AI`、`NeurIPS`、`ICML`、`ICLR`、`ACL`、`AAAI`、`COLM`、`LaTeX`、`Citations`、`Statistical Analysis`
相关技能	`arxiv`、`ml-paper-writing`、`subagent-driven-development`、`plan`

参考：完整 SKILL.md

:::info 以下是当此技能被触发时 Hermes 加载的完整技能定义。这是技能激活时代理所看到的指令。 :::

科研论文写作流程

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

这不是一个线性流程——它是一个迭代循环。结果触发新实验。审查触发新分析。代理必须处理这些反馈循环。

┌─────────────────────────────────────────────────────────────┐
│                    科研论文写作流程                           │
│                                                             │
│  阶段 0：项目设置 ──► 阶段 1：文献综述                      │
│       │                          │                          │
│       ▼                          ▼                          │
│  阶段 2：实验设计         阶段 5：论文草稿 ◄──┐              │
│       │                          │           │              │
│       ▼                          ▼           │              │
│  阶段 3：执行与监控         阶段 6：自我审查   │              │
│       │                      & 修订 ──────────┘              │
│       │                          │                          │
│       ▼                          ▼                          │
│  阶段 4：结果分析 ───► 阶段 7：投稿                           │
│       （反馈至阶段 2 或 5）                                  │
│                                                             │
└─────────────────────────────────────────────────────────────┘

何时使用此技能

在以下情况使用此技能：

从现有代码库或想法开始撰写新的科研论文
设计和运行实验以支持论文主张
撰写或修订科研论文的任何部分
准备投稿到特定会议或研讨会
回应审稿意见进行补充实验或修订
在不同会议格式之间转换论文
撰写非实证论文——理论、综述、基准测试或立场论文（参见实证 ML 之外的论文类型）
设计人工评估用于 NLP、HCI 或对齐研究
准备接收后的交付物——海报、演讲、代码发布

核心理念

主动出击。 交付完整的草稿，而不是提问。科学家都很忙——提供他们可以反馈的具体内容，然后迭代。
绝不捏造引用。 AI 生成的引用错误率约 40%。始终通过编程方式获取。将无法验证的引用标记为 [CITATION NEEDED]。
论文是故事，而不是实验的集合。 每篇论文需要用一个句子陈述一个清晰的贡献。如果你做不到，论文还没准备好。
实验服务于主张。 每个实验必须明确说明它支持哪个主张。永远不要运行与论文叙事无关的实验。
尽早提交，经常提交。 每完成一批实验、每次更新论文草稿——使用描述性信息提交。Git 日志就是实验历史。

主动性与协作

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

置信水平	行动
高（仓库清晰，贡献明确）	撰写完整草稿，交付，根据反馈迭代
中（有些模糊）	撰写带标记不确定性的草稿，继续
低（重大未知）	通过 `clarify` 提出 1-2 个针对性问题，然后起草

章节	自主起草？	随草稿标记
摘要	是	”将贡献框架定为 X——如有需要请调整”
引言	是	”强调了问题 Y——如果错误请纠正”
方法	是	”包含了细节 A、B、C——请补充遗漏部分”
实验	是	”突出显示了结果 1、2、3——如有需要请重新排序”
相关工作	是	”引用了论文 X、Y、Z——请补充我遗漏的”

仅在以下情况征求输入：目标会议不明确、多个矛盾的框架、结果似乎不完整、明确要求先审查。

阶段 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：确定贡献

在写任何内容之前，明确以下内容：

是什么（The What）：这篇论文贡献的单一事物是什么？
为什么（The Why）：什么证据支持它？
所以呢（The So What）：为什么读者应该关心？

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

步骤 0.5：创建待办事项列表

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

Research Paper TODO:
- [ ] 定义一句话贡献
- [ ] 文献综述（相关工作 + 基线）
- [ ] 设计核心实验
- [ ] 运行实验
- [ ] 分析结果
- [ ] 撰写初稿
- [ ] 自我审查（模拟审稿人）
- [ ] 根据审稿意见修订
- [ ] 投稿准备

在整个项目中更新此列表。它是跨会话的持久状态。

步骤 0.6：估算计算预算

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

Compute Budget Checklist:
- [ ] 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 经验
Git + LaTeX	`git` 配合 `.gitignore` 忽略辅助文件	技术团队，需要基于分支的审查
Overleaf + Git 同步	Overleaf 高级版	两全其美——实时协作与版本历史

章节所有权：为每个章节指定一位主要作者。其他人可以评论但不直接编辑。防止合并冲突和风格不一致。

作者协调清单：
- [ ] 就章节所有权达成一致（谁写什么）
- [ ] 设置共享工作区（Overleaf 或 git 仓库）
- [ ] 建立符号约定（在任何人写作之前）
- [ ] 安排内部审查轮次（而不仅仅在最后）
- [ ] 指定一人负责最终格式检查
- [ ] 在创建图表前就图表风格（颜色、字体、大小）达成一致

需要尽早商定的 LaTeX 约定：

用于一致方法命名的 \method{} 宏
引用风格：\citet{} 与 \citep{} 的使用
数学符号：向量用粗体小写，矩阵用粗体大写等
英式 vs 美式拼写

阶段 1：文献综述

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

步骤 1.1：确定种子论文

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

# 通过终端：
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 获取特定论文：

# 通过 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 轮。

对于基于代理的工作流：通过 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] 个引用为占位符，需要验证。”

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

步骤 1.4：组织相关工作

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

好：“一系列工作使用了 X 的假设 [引用]，而我们使用 Y 的假设，因为…” 差：“Smith 等人引入了 X。Jones 等人引入了 Y。我们结合了二者。“

阶段 2：实验设计

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

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

创建显式映射：

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

规则：如果一个实验不映射到某个主张，就不要运行它。

步骤 2.2：设计基线

强基线是区分被接收论文和被拒绝论文的关键。审稿人会问：“他们与 X 比较了吗？”

标准基线类别：

朴素基线（Naive baseline）：最简单可能的方法
强基线（Strong baseline）：已知最佳现有方法
消融基线（Ablation baselines）：你的方法减去一个组件
计算量匹配基线（Compute-matched baselines）：相同计算预算，不同分配

步骤 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                 # 可视化

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

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

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

何时需要人工评估：

自动化指标无法捕获你关心的内容（流畅性、有用性、安全性）
你的贡献涉及面向人类的特质（可读性、偏好、信任）
NLP 会议（ACL、EMNLP）的审稿人在生成任务中期望它

关键设计决策：

决策	选项	指导
标注者类型	专家、众包工作者、最终用户	与你主张所需内容匹配
评分方式	Likert（1-5）、成对比较、排序	对于 LLM 输出，成对比较比 Likert 更可靠
样本量	每个标注者和总项目数	效能分析或至少 100 个项目，3 名以上标注者
一致性指标	Cohen’s kappa、Krippendorff’s alpha、ICC	对于 >2 名标注者使用 Krippendorff’s alpha；同时报告原始一致性
平台	Prolific、MTurk、内部团队	Prolific 保证质量；MTurk 保证规模；内部保证领域专业知识

标注指南清单：

- [ ] 带有示例（好 AND 坏）的清晰任务描述
- [ ] 模糊情况下的决策标准
- [ ] 每个类别至少 2 个工作示例
- [ ] 注意力检查/黄金标准项目（占总数的 10-15%）
- [ ] 资格任务或筛选轮次
- [ ] 每个项目的预计时间和公平报酬（>= 当地最低工资）
- [ ] 如机构要求则进行 IRB/伦理审查

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

标注者人数及其资格
标注者间一致性指标和具体数值
报酬详情（金额、估计小时费率）
标注界面描述或截图（附录）
总标注时间

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

阶段 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 提示应遵循此模板：

监控提示模板：
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：处理失败

常见失败模式及恢复：

失败	检测	恢复
API 速率限制/信用耗尽	日志中的 402/429 错误	等待后重新运行（脚本跳过已完成的工作）
进程崩溃	PID 消失，结果不完整	从最后一个检查点重新运行
困难问题超时	进程卡住，日志无进展	终止并跳过，在结果中记录
错误模型 ID	引用模型名称的错误	修复 ID 并重新运行

关键：脚本应始终检查现有结果并跳过已完成的工作。这使得重新运行安全高效。

步骤 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": "添加范围约束将修复 exp_001 的收敛失败",
  "plan": "使用 max_tokens=2000 和固定结构模板重新运行 autoreason",
  "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": "范围约束修复了收敛问题。胜率从 0.42 跃升至 0.85。",
  "next_steps": ["在 Sonnet 上尝试相同约束", "测试无结构模板"],
  "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：聚合结果

编写分析脚本：

加载所有批次的結果文件
计算每个任务和聚合指标
生成汇总表

# 标准分析模式
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’s d 或 h 用于实际显著性

参见 references/experiment-patterns.md 获取 McNemar 检验、自助法置信区间和 Cohen’s h 的完整实现。

步骤 4.3：确定故事

分析后，明确回答：

主要发现是什么？ 用一句话陈述。
什么让你惊讶？ 意外的结果往往能成就最好的论文。
什么失败了？ 失败的实验可能最具信息量。诚实的失败报告能增强论文的可信度。
需要哪些后续实验？ 结果往往会提出新的问题。

处理负面或无效结果

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

情况	行动	适合的会议
假设错误但原因有启发性	围绕原因分析的框架撰写论文	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
方法 & 准确率 $\uparrow$ & 延迟 $\downarrow$ \\
\midrule
基线 & 85.2 & 45ms \\
\textbf{我们的方法} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

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

情况	行动
核心主张得到支持，结果显著	进入阶段 5（写作）
结果不明确，需要更多数据	回到阶段 2（设计）
意外发现提示新方向	回到阶段 2（设计）
审稿人会问的一个消融实验缺失	运行它，然后阶段 5
所有实验已完成但部分失败	记录失败，进入阶段 5

步骤 4.6：编写实验日志（连接写作的桥梁）

在进入论文写作之前，创建一个结构化的实验日志，将结果与写作连接起来。这是实验与写作之间最重要的连接组织——没有它，写作代理必须从原始结果文件中重新推导出故事。

创建 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 |
 
## 失败的实验（为诚实记录）
- [尝试了什么，为什么失败，告诉了我们什么]
 
## 未解决的问题
- [结果提出的、论文应解决的问题]

为什么这很重要：在起草时，代理（或委派的子代理）可以加载 experiment_log.md 以及 LaTeX 模板，并生成一篇基于实际结果的初稿。没有这座桥梁，写作代理必须解析原始 JSON/CSV 文件并推断故事——这是常见的虚构或误报数字的来源。

Git 纪律：将此日志与它所描述的结果一起提交。

迭代优化：策略选择

此流程中的任何输出——论文草稿、实验脚本、分析——都可以迭代优化。Autoreason 研究为每种优化策略何时有效和何时失败提供了实证证据。使用此部分选择正确的方法。

快速决策表

你的情况	策略	原因
中档模型 + 受约束任务	Autoreason	最佳选择。生成-评估差距最大。基线会主动破坏弱模型输出。
中档模型 + 开放式任务	Autoreason 并添加范围约束	添加固定事实、结构或交付物以限定改进空间。
前沿模型 + 受约束任务	Autoreason	即使在前沿模型上也能赢得 2/3 受约束任务。
前沿模型 + 无约束任务	Critique-and-revise 或单次生成	Autoreason 垫底。模型自我评估能力足够好。
具体技术任务（系统设计）	Critique-and-revise	直接的查找-修复循环更高效。
模板填充任务（一种正确结构）	单次生成或保守策略	决策空间最小。迭代无法增加价值。
带测试用例的代码	Autoreason（代码变体）	在修复前对失败原因进行结构化分析。恢复率 62% vs 43%。
非常弱的模型（Llama 8B 级别）	单次生成	模型太弱，无法生成多样化的候选。投入生成质量。

生成-评估差距

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

模型层级        │ 生成能力 │ 自我评估 │ 差距   │ Autoreason 价值
──────────────────┼────────────┼───────────┼────────┼─────────────────
弱（Llama 8B）   │ 差        │ 差       │ 小     │ 无——无法生成多样化候选
中（Haiku 3.5）   │ 尚可      │ 差       │ 大     │ 最大——42/42 完美 Borda
中（Gemini Flash）│ 尚可      │ 中等     │ 大     │ 高——赢得 2/3
强（Sonnet 4） │ 好        │ 尚可     │ 中等   │ 中等——赢得 3/5
前沿（S4.6）   │ 优秀      │ 好       │ 小     │ 仅在有约束条件下

这个差距是结构性的，而非暂时的。随着成本下降，今天的前沿模型会成为明天的中档模型。最佳选择点会移动但从未消失。

Autoreason 循环（总结）

每次迭代从全新的、隔离的代理产生三个候选：

批评者（Critic） → 发现现有方案 A 的问题（不修复）
作者 B（Author B） → 基于批评意见修改 A
综合者（Synthesizer） → 合并 A 和 B（随机标签）
评审团（Judge Panel） → 3 个盲审 CoT 评审通过 Borda 计数对 A、B、AB 排序
收敛（Convergence） → A 连续赢 k=2 次 → 完成

关键参数：

k=2 收敛（k=1 过早，k=3 太贵，无质量提升）
始终使用 CoT 评审（收敛速度提升 3 倍）
作者温度 0.8，评审温度 0.3
保守平局规则：现任者赢得平局
每个角色都是全新代理，无共享上下文

应用于论文草稿

当通过 autoreason 优化论文本身时：

向批评者提供真实依据：实际实验数据、结果 JSON、统计输出。没有这些，模型会虚构捏造的消融研究和假置信区间。
至少使用 3 个工作评审：一个损坏的评审解析器不会增加噪声——它会完全阻止达到均衡。
范围约束修订：“解决这些特定弱点”而非”改进论文”。

失败模式

失败	检测	修复
无收敛（A 从未赢）	A 在 20+ 轮中赢 <15%	为任务添加范围约束
综合漂移	字数无限增长	约束结构和交付物
退化低于单次生成	基线得分高于迭代输出	切换为单次生成；模型可能太弱
过拟合（代码）	公共测试通过率高，私有测试通过率低	使用结构化分析，而非仅测试反馈
评审损坏	解析失败导致评审团低于 3 人	在继续前修复解析器

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

阶段 5：论文草稿撰写

目标：撰写完整的、可发表的论文。

大型项目的上下文管理

一个有 50+ 个实验文件、多个结果目录和大量文献笔记的论文项目很容易超出代理的上下文窗口。主动管理这一点：

每个起草任务应加载的上下文：

起草任务	加载到上下文	不要加载
撰写引言	`experiment_log.md`、贡献陈述、5-10 篇最相关论文摘要	原始结果 JSON、完整实验脚本、所有文献笔记
撰写方法	实验配置、伪代码、架构描述	原始日志、其他实验的结果
撰写结果	`experiment_log.md`、结果汇总表、图表列表	完整分析脚本、中间数据
撰写相关工作	组织好的引用笔记（步骤 1.4 输出）、.bib 文件	实验文件、原始 PDF
修订轮次	完整论文草稿、特定审稿人关注点	其他所有内容

原则：

experiment_log.md 是主要的上下文桥梁——它汇总了写作所需的一切，无需加载原始数据文件（参见步骤 4.6）
委派时一次只加载一个章节的上下文。起草方法的子代理不需要文献综述笔记。
汇总而非包含原始文件。对于 200 行的结果 JSON，加载 10 行的汇总表。对于 50 页的相关论文，加载 5 句摘要 + 你关于其相关性的 2 行笔记。

对于非常大的项目：创建包含预压缩摘要的 context/ 目录：

context/
  contribution.md          # 1 句话
  experiment_summary.md    # 关键结果表（来自 experiment_log.md）
  literature_map.md        # 组织好的引用笔记
  figure_inventory.md      # 带有描述的图表列表

叙事原则

最关键的核心洞察：你的论文不是实验的集合——它是一个故事，有一个由证据支持的清晰贡献。

每篇成功的 ML 论文都围绕 Neel Nanda 所说的”叙事”展开：一个简短、严谨、基于证据的技术故事，带有读者关心的要点。

三大支柱（在引言结束前必须完全清晰）：

支柱	描述	测试
是什么（The What）	1-3 个具体的新主张	你能用一句话陈述它们吗？
为什么（The Why）	严谨的实证证据	实验能否区分你的假设与替代方案？
所以呢（The So What）	为什么读者应该关心	这是否与公认的社区问题相关？

如果你不能用一句话陈述你的贡献，你还没有一篇论文。

此指导的来源

此技能综合了在顶级会议上大量发表论文的研究人员的写作理念。写作理念层最初由 Orchestra Research 作为 ml-paper-writing 技能编译。

来源	关键贡献	链接
Neel Nanda（Google DeepMind）	叙事原则、是什么/为什么/所以呢框架	How to Write ML Papers
Sebastian Farquhar（DeepMind）	5 句摘要公式	How to Write ML Papers
Gopen & Swan	读者期望的 7 个原则	Science of Scientific Writing
Zachary Lipton	词汇选择、消除模糊表述	Heuristics for Scientific Writing
Jacob Steinhardt（UC Berkeley）	精确性、一致的术语	Writing Tips
Ethan Perez（Anthropic）	微观层面的清晰度技巧	Easy Paper Writing Tips
Andrej Karpathy	单一贡献聚焦	Various lectures

要深入了解以上任何内容，请参阅：

references/writing-guide.md — 带示例的完整解释
references/sources.md — 完整参考文献

时间分配

在以下各部分上花费大约相等的时间：

摘要
引言
图表
其他所有内容的总和

为什么？ 大多数审稿人在看到你的方法之前就已经形成了判断。读者接触你的论文的顺序是：标题 → 摘要 → 引言 → 图表 → 可能才到其余部分。

写作工作流

论文写作清单：
- [ ] 步骤 1：定义一句话贡献
- [ ] 步骤 2：起草图 1（核心思想或最有说服力的结果）
- [ ] 步骤 3：起草摘要（5 句公式）
- [ ] 步骤 4：起草引言（最多 1-1.5 页）
- [ ] 步骤 5：起草方法
- [ ] 步骤 6：起草实验和结果
- [ ] 步骤 7：起草相关工作
- [ ] 步骤 8：起草结论和讨论
- [ ] 步骤 9：起草局限性（所有会议均要求）
- [ ] 步骤 10：规划附录（证明、额外实验、细节）
- [ ] 步骤 11：完成论文清单
- [ ] 步骤 12：最终审查

两遍优化模式

当使用 AI 代理起草时，使用两遍方法（在 SakanaAI 的 AI-Scientist 流程中已验证有效）：

第 1 遍——逐章节编写 + 即时优化： 对于每个章节，编写完整的草稿，然后立即在同一上下文中优化。这能捕捉局部问题（清晰度、流畅度、完整性）。

第 2 遍——全局优化，结合整篇论文的上下文： 所有章节起草完成后，带着对完整论文的认知重新审视每个章节。这能捕捉跨章节问题：冗余、术语不一致、叙事流畅性，以及某个章节承诺了另一个章节未实现的断点。

第 2 遍优化提示（按章节）：
"在完整论文的上下文中审查[章节]。
- 它是否与论文的其他部分协调一致？与其他章节是否有冗余？
- 术语是否与引言和方法一致？
- 能否在不削弱信息的情况下删减任何内容？
- 叙事是否能从前一章节流畅过渡到下一章节？
进行最小限度的、有针对性的编辑。不要从头重写。"

LaTeX 错误检查清单

将此清单附加到每个优化提示中。这些是 LLM 编写 LaTeX 时最常见的错误：

LaTeX 质量检查清单（每次编辑后验证）：
- [ ] 没有未闭合的数学符号（$ 符号平衡）
- [ ] 只引用存在的图表（\\ref 匹配 \\label）
- [ ] 没有捏造的引用（\\cite 匹配 .bib 中的条目）
- [ ] 每个 \\begin{env} 有对应的 \\end{env}（尤其是 figure、table、algorithm）
- [ ] 没有 HTML 污染（</end{figure}> 而非 \\end{figure}）
- [ ] 数学模式外没有未转义的下划线（文本中使用 \\_）
- [ ] 没有重复的 \\label 定义
- [ ] 没有重复的章节标题
- [ ] 文本中的数字与实际实验结果匹配
- [ ] 所有图表都有标题和标签
- [ ] 没有导致 overfull hbox 警告的过长行

步骤 5.0：标题

标题是论文中阅读最多的元素。它决定是否有人点击进入摘要。

好的标题：

陈述贡献或发现：“Autoreason: When Iterative LLM Refinement Works and Why It Fails”
突出意外结果：“Scaling Data-Constrained Language Models”（暗示你可以做到）
命名方法 + 其功能：“DPO: Direct Preference Optimization of Language Models”

差的标题：

过于泛化：“An Approach to Improving Language Model Outputs”
过长：超过约 15 个单词
仅使用术语：“Asymptotic Convergence of Iterative Stochastic Policy Refinement”（这是给谁看的？）

规则：

如果有方法名称，请包含在内（便于引用）
包含审稿人会搜索的 1-2 个关键词
避免冒号，除非两部分都有意义
测试：审稿人仅从标题能否知道领域和贡献？

步骤 5.1：摘要（5 句公式）

来自 Sebastian Farquhar（DeepMind）：

1. 你实现了什么："我们提出了..."、"我们证明了..."、"我们展示了..."
2. 为什么这很难且重要
3. 你是如何做到的（包含专业关键词以便被发现）
4. 你有什么证据
5. 你最显著的数值/结果

删除”大型语言模型取得了显著成功…”之类的泛泛开头。

步骤 5.2：图 1

图 1 是大多数读者看的第二样东西（在摘要之后）。在写引言之前起草它——它迫使你理清核心思想。

图 1 类型	何时使用	示例
方法图	新架构或流程	显示你系统的 TikZ 流程图
结果预告	一个有说服力的结果讲述整个故事	柱状图：“我们的方法 vs 基线”有明显差距
问题说明	问题不直观	前后对比显示你修复的失败模式
概念图	抽象贡献需要视觉支撑	方法属性的 2x2 矩阵

规则：图 1 必须无需阅读任何文本就能理解。仅凭图注就应传达核心思想。有目的地使用颜色——不要仅仅装饰。

步骤 5.3：引言（最多 1-1.5 页）

必须包含：

清晰的问题陈述
方法简要概述
2-4 条项目符号贡献列表（双栏格式中每条最多 1-2 行）
方法应在第 2-3 页开始

步骤 5.4：方法

能够支持重新实现：

概念概述或伪代码
列出所有超参数
足以复现的架构细节
展示最终设计决策；消融实验放在实验结果中

步骤 5.5：实验与结果

对于每个实验，明确陈述：

它支持什么主张
它与主要贡献的关联
要观察什么：“蓝线显示 X，这证明了 Y”

要求：

带方法的误差棒（标准差 vs 标准误差）
超参数搜索范围
计算基础设施（GPU 类型、总小时数）
种子设置方法

步骤 5.6：相关工作

按方法论组织，而非逐篇罗列。慷慨引用——审稿人很可能撰写了相关论文。

步骤 5.7：局限性（必填）

所有主要会议都要求此项。诚实有帮助：

审稿人被指示不要因诚实的局限性承认而惩罚
通过首先识别弱点来抢先批评
解释为什么局限性不削弱核心主张

步骤 5.8：结论与讨论

结论（必填，0.5-1 页）：

用一句话重新陈述贡献（措辞与摘要不同）
总结关键发现（2-3 句，不是列表）
影响：这对领域意味着什么？
未来工作：2-3 个具体后续步骤（不是模糊的”我们将其留作未来工作”）

讨论（可选，有时与结论合并）：

超出即时结果的更广泛影响
与其他子领域的联系
对方法何时有效和何时无效的诚实评估
实际部署考虑

不要在结论中引入新结果或主张。

步骤 5.9：附录策略

所有主要会议的附录都不受限制，且对可复现性至关重要。结构：

附录章节	内容
证明与推导	正文中太长的完整证明。正文可陈述定理，注明”证明见附录 A”。
额外实验	消融实验、扩展曲线、每个数据集的分项结果、超参数敏感性
实现细节	完整超参数表、训练细节、硬件规格、随机种子
数据集文档	数据收集过程、标注指南、许可、预处理
提示与模板	使用的确切提示（针对基于 LLM 的方法）、评估模板
人工评估	标注界面截图、给标注者的说明、IRB 细节
额外图表	每个任务的分项、轨迹可视化、失败案例示例

规则：

主论文必须自包含——不要求审稿人阅读附录
绝不要把关键证据仅放在附录中
交叉引用：“完整结果见表 5（附录 B）“，而不仅仅”见附录”
使用 \appendix 命令，然后是 \section{A: Proofs} 等

页面预算管理

当超出页数限制时：

删减策略	节省空间	风险
将证明移到附录	0.5-2 页	低——标准做法
压缩相关工作	0.5-1 页	中——可能遗漏关键引用
用子图合并表格	0.25-0.5 页	低——通常提高可读性
适度使用 `\vspace{-Xpt}`	0.1-0.3 页	适度则低，明显则高
移除定性示例	0.5-1 页	中——审稿人喜欢示例
减小图表尺寸	0.25-0.5 页	高——图表必须保持可读

不要：缩小字号、更改边距、移除必填章节（局限性、更广泛影响），或在正文中使用 \small/\footnotesize。

步骤 5.10：伦理与更广泛影响声明

现在大多数会议要求或强烈鼓励伦理/更广泛影响声明。这不是套话——审稿人会阅读它，并可能标记导致 desk rejection 的伦理问题。

内容：

组成部分	内容	要求方
积极社会影响	你的工作如何造福社会	NeurIPS、ICML
潜在负面影响	滥用风险、双重用途问题、失败模式	NeurIPS、ICML
公平与偏见	你的方法/数据是否存在已知偏见？	所有会议（隐含）
环境影响	大规模训练的计算碳足迹	ICML、越来越多的 NeurIPS
隐私	你的工作是否使用或支持处理个人数据？	ACL、NeurIPS
LLM 披露	是否在写作或实验中使用 AI？	ICLR（强制）、ACL

撰写声明：

\section*{更广泛影响声明}
% NeurIPS/ICML：在结论后，不计入页数限制
 
% 1. 积极应用（1-2 句）
这项工作使[具体应用]成为可能，这可能使[特定群体]受益。
 
% 2. 风险和缓解措施（1-3 句，要具体）
[方法/模型]可能被滥用于[特定风险]。我们通过[具体缓解措施，例如仅发布超过 X 大小的模型权重、包含安全过滤器、记录失败模式]来缓解此风险。
 
% 3. 影响声明的局限性（1 句）
我们的评估限于[特定领域]；更广泛的部署需要[具体的额外工作]。

常见错误：

写”我们预见没有负面影响”（几乎从不是真的——审稿人不信任此说法）
模糊表述：“这可能被滥用”而不指定如何
忽略大规模工作的计算成本
在要求LLM披露的会议中忘记披露

计算碳足迹（针对训练密集型论文）：

# 使用 ML CO2 Impact 工具方法估算
gpu_hours = 1000  # 总 GPU 小时数
gpu_tdp_watts = 400  # 例如 A100 = 400W
pue = 1.1  # 能源使用效率（数据中心开销）
carbon_intensity = 0.429  # kg CO2/kWh（美国平均值；因地区而异）
 
energy_kwh = (gpu_hours * gpu_tdp_watts * pue) / 1000
carbon_kg = energy_kwh * carbon_intensity
print(f"能耗：{energy_kwh:.0f} kWh，碳排放：{carbon_kg:.0f} kg CO2eq")

步骤 5.11：数据表和模型卡（如适用）

如果你的论文引入了新数据集或发布模型，请包含结构化文档。审稿人越来越多地期望这一点，NeurIPS Datasets & Benchmarks 通道要求它。

数据集的数据表（Gebru 等人，2021）——包含在附录中：

数据集文档（附录）：
- 动机：为什么创建此数据集？它支持什么任务？
- 组成：实例是什么？有多少？什么数据类型？
- 收集：数据是如何收集的？来源是什么？
- 预处理：应用了什么清洗/过滤？
- 分发：数据集如何分发？在什么许可下？
- 维护：谁维护它？如何报告问题？
- 伦理考虑：包含个人数据？获得同意？
  潜在危害？已知偏见？

模型卡（Mitchell 等人，2019）——对于模型发布，包含在附录中：

模型卡（附录）：
- 模型详细信息：架构、训练数据、训练过程
- 预期用途：主要用例、范围外用途
- 指标：评估指标和基准测试结果
- 伦理考虑：已知偏见、公平性评估
- 局限性：已知失败模式、模型表现不佳的领域

写作风格

句子级清晰度（Gopen & Swan 的 7 个原则）：

原则	规则
主语-谓语接近	保持主语和谓语靠近
强调位置	将重点放在句末
主题位置	把上下文放在前面，新信息放在后面
旧信息在前	熟悉信息 → 不熟悉信息
一个单位，一个功能	每个段落表达一个观点
动作在动词中	使用动词，而非名词化
先上下文后新内容	在呈现之前设置场景

词汇选择（Lipton、Steinhardt）：

具体：“accuracy”而非”performance”
消除模糊表述：除非确实不确定，否则删除”may”
全文使用一致的术语
避免增量词汇：“develop”而非”combine”

带示例的完整写作指南：参见 references/writing-guide.md

使用 LaTeX 模板

始终先复制整个模板目录，然后在其内部编写。

模板设置清单：
- [ ] 步骤 1：将整个模板目录复制到新项目
- [ ] 步骤 2：验证模板按原样编译（在任何更改之前）
- [ ] 步骤 3：阅读模板的示例内容以理解结构
- [ ] 步骤 4：逐节替换示例内容
- [ ] 步骤 5：使用模板宏（检查前导文中的 \newcommand 定义）
- [ ] 步骤 6：只在最后清理模板产物

步骤 1：复制完整模板

cp -r templates/neurips2025/ ~/papers/my-paper/
cd ~/papers/my-paper/
ls -la  # 应看到：main.tex、neurips.sty、Makefile 等

复制整个目录，而不仅仅是 .tex 文件。模板包含样式文件（.sty）、参考文献风格（.bst）、示例内容和 Makefile。

步骤 2：首先验证模板可编译

在进行任何更改之前：

latexmk -pdf main.tex
# 或手动：pdflatex main.tex && bibtex main && pdflatex main.tex && pdflatex main.tex

如果未修改的模板无法编译，先解决此问题（通常是缺少 TeX 包——通过 tlmgr install <package> 安装）。

步骤 3：保留模板内容作为参考

不要立即删除示例内容。注释掉并用作格式参考：

% 模板示例（保留供参考）：
% \begin{figure}[t]
%   \centering
%   \includegraphics[width=0.8\linewidth]{example-image}
%   \caption{模板显示标题样式}
% \end{figure}
 
% 你的实际图表：
\begin{figure}[t]
  \centering
  \includegraphics[width=0.8\linewidth]{your-figure.pdf}
  \caption{您的标题遵循相同样式。}
\end{figure}

步骤 4：逐节替换内容

按顺序系统地工作：标题/作者 → 摘要 → 引言 → 方法 → 实验 → 相关工作 → 结论 → 参考文献 → 附录。每个章节后编译。

步骤 5：使用模板宏

\newcommand{\method}{YourMethodName}  % 一致的方法命名
\newcommand{\eg}{e.g.,\xspace}        % 正确缩写
\newcommand{\ie}{i.e.,\xspace}

模板陷阱

陷阱	问题	解决方案
仅复制 `.tex` 文件	缺少 `.sty`，无法编译	复制整个目录
修改 `.sty` 文件	破坏会议格式	永远不要编辑样式文件
添加随机包	冲突，破坏模板	仅在必要时添加
过早删除模板内容	失去格式参考	在完成前保留为注释
不经常编译	错误累积	每个章节后编译
使用光栅 PNG 格式的图表	论文中模糊	始终通过 `savefig('fig.pdf')` 使用矢量 PDF

快速模板参考

会议	主文件	样式文件	页数限制
NeurIPS 2025	`main.tex`	`neurips.sty`	9 页
ICML 2026	`example_paper.tex`	`icml2026.sty`	8 页
ICLR 2026	`iclr2026_conference.tex`	`iclr2026_conference.sty`	9 页
ACL 2025	`acl_latex.tex`	`acl.sty`	8 页（长论文）
AAAI 2026	`aaai2026-unified-template.tex`	`aaai2026.sty`	7 页
COLM 2025	`colm2025_conference.tex`	`colm2025_conference.sty`	9 页

通用：双盲、参考文献不计入、附录无限制、必须使用 LaTeX。

模板位于 templates/ 目录。参见 templates/README.md 获取编译设置指南（VS Code、CLI、Overleaf、其他 IDE）。

表格和图表

表格——使用 booktabs 实现专业格式：

\usepackage{booktabs}
\begin{tabular}{lcc}
\toprule
方法 & 准确率 $\uparrow$ & 延迟 $\downarrow$ \\
\midrule
基线 & 85.2 & 45ms \\
\textbf{我们的方法} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

规则：

每个指标加粗最佳值
包含方向符号（ $↑$ 越高越好， $↓$ 越低越好）
数字列右对齐
一致的小数精度

图表：

矢量图形（PDF、EPS）用于所有绘图和图表——plt.savefig('fig.pdf')
光栅（PNG 600 DPI）仅用于照片
色盲安全调色板（Okabe-Ito 或 Paul Tol）
验证灰度可读性（8% 的男性有颜色视觉缺陷）
图表内无标题——图注应承担此功能
自包含图注——读者无需正文即可理解

会议重新投稿

对于在不同会议之间转换，参见阶段 7（投稿准备）——它涵盖完整的转换工作流、页数变化表和被拒后的指导。

专业 LaTeX 前导文

为达到专业质量，向任何论文添加以下包。它们与所有主要会议样式文件兼容：

% --- 专业包（在会议样式文件后添加）---
 
% 排版
\usepackage{microtype}              % 微排版改进（突出、扩展）
                                     % 使文本明显更精致——始终包含
 
% 表格
\usepackage{booktabs}               % 专业表格规则（\toprule、\midrule、\bottomrule）
\usepackage{siunitx}                % 一致的数字格式、小数点对齐
                                     % 用法：\num{12345} → 12,345；\SI{3.5}{GHz} → 3.5 GHz
                                     % 表格对齐：S 列类型用于小数点对齐数字
 
% 图表
\usepackage{graphicx}               % 包含图形（\includegraphics）
\usepackage{subcaption}             % 子图，带 (a), (b), (c) 标签
                                     % 用法：\begin{subfigure}{0.48\textwidth} ... \end{subfigure}
 
% 图表和算法
\usepackage{tikz}                   % 可编程矢量图表
\usetikzlibrary{arrows.meta, positioning, shapes.geometric, calc, fit, backgrounds}
\usepackage[ruled,vlined]{algorithm2e}  % 专业伪代码
                                     % 替代方案：如果模板捆绑了，使用 \usepackage{algorithmicx}
 
% 交叉引用
\usepackage{cleveref}               % 智能引用：\cref{fig:x} → "Figure 1"
                                     % 必须在 hyperref 之后加载
                                     % 处理：图表、表格、章节、公式、算法
 
% 数学（通常包含在会议的 .sty 中，但需验证）
\usepackage{amsmath,amssymb}        % AMS 数学环境和符号
\usepackage{mathtools}              % 扩展 amsmath（dcases、coloneqq 等）
 
% 颜色（用于图表）
\usepackage{xcolor}                 % 颜色管理
% Okabe-Ito 色盲安全调色板：
\definecolor{okblue}{HTML}{0072B2}
\definecolor{okorange}{HTML}{E69F00}
\definecolor{okgreen}{HTML}{009E73}
\definecolor{okred}{HTML}{D55E00}
\definecolor{okpurple}{HTML}{CC79A7}
\definecolor{okcyan}{HTML}{56B4E9}
\definecolor{okyellow}{HTML}{F0E442}

注意事项：

microtype 是对视觉质量影响最大的单个包。它会在亚像素级别调整字符间距。始终包含它。
siunitx 通过 S 列类型处理表格中的小数点对齐——无需手动间距。
cleveref 必须在 hyperref 之后加载。大多数会议的 .sty 文件会加载 hyperref，因此将 cleveref 放在最后。
检查会议模板是否已加载其中任何包（尤其是 algorithm、amsmath、graphicx）。不要重复加载。

siunitx 表格对齐

siunitx 使数字密集型表格更具可读性：

\begin{tabular}{l S[table-format=2.1] S[table-format=2.1] S[table-format=2.1]}
\toprule
方法 & {准确率 $\uparrow$} & {F1 $\uparrow$} & {延迟 (ms) $\downarrow$} \\
\midrule
基线         & 85.2  & 83.7  & 45.3 \\
消融（无 X）  & 87.1  & 85.4  & 42.1 \\
\textbf{我们的方法}    & \textbf{92.1} & \textbf{90.8} & \textbf{38.7} \\
\bottomrule
\end{tabular}

S 列类型自动在小数点处对齐。{} 中的标题会避免对齐。

子图

并排图的标准模式：

\begin{figure}[t]
  \centering
  \begin{subfigure}[b]{0.48\textwidth}
    \centering
    \includegraphics[width=\textwidth]{fig_results_a.pdf}
    \caption{数据集 A 上的结果。}
    \label{fig:results-a}
  \end{subfigure}
  \hfill
  \begin{subfigure}[b]{0.48\textwidth}
    \centering
    \includegraphics[width=\textwidth]{fig_results_b.pdf}
    \caption{数据集 B 上的结果。}
    \label{fig:results-b}
  \end{subfigure}
  \caption{我们的方法在两个数据集上的比较。(a) 显示了缩放行为，(b) 显示了消融结果。两者均使用 5 个随机种子。}
  \label{fig:results}
\end{figure}

使用 \cref{fig:results} → “Figure 1”，\cref{fig:results-a} → “Figure 1a”。

使用 algorithm2e 的伪代码

\begin{algorithm}[t]
\caption{带评审团的迭代优化}
\label{alg:method}
\KwIn{任务 $T$、模型 $M$、评审 $J_1 \ldots J_n$、收敛阈值 $k$}
\KwOut{最终输出 $A^*$}
$A \gets M(T)$ \tcp*{初始生成}
$\text{streak} \gets 0$\;
\While{$\text{streak} < k$}{
  $C \gets \text{Critic}(A, T)$ \tcp*{识别弱点}
  $B \gets M(T, C)$ \tcp*{解决批评意见的修订版本}
  $AB \gets \text{Synthesize}(A, B)$ \tcp*{合并最佳元素}
  \ForEach{评审 $J_i$}{
    $\text{rank}_i \gets J_i(\text{shuffle}(A, B, AB))$ \tcp*{盲审排序}
  }
  $\text{winner} \gets \text{BordaCount}(\text{ranks})$\;
  \eIf{$\text{winner} = A$}{
    $\text{streak} \gets \text{streak} + 1$\;
  }{
    $A \gets \text{winner}$; $\text{streak} \gets 0$\;
  }
}
\Return{$A$}\;
\end{algorithm}

TikZ 图表模式

TikZ 是 ML 论文中方法图的标准。常见模式：

流程/流水线图（ML 论文中最常见）：

\begin{figure}[t]
\centering
\begin{tikzpicture}[
  node distance=1.8cm,
  box/.style={rectangle, draw, rounded corners, minimum height=1cm, 
              minimum width=2cm, align=center, font=\small},
  arrow/.style={-{Stealth[length=3mm]}, thick},
]
  \node[box, fill=okcyan!20] (input) {输入\\$x$};
  \node[box, fill=okblue!20, right of=input] (encoder) {编码器\\$f_\theta$};
  \node[box, fill=okgreen!20, right of=encoder] (latent) {潜变量\\$z$};
  \node[box, fill=okorange!20, right of=latent] (decoder) {解码器\\$g_\phi$};
  \node[box, fill=okred!20, right of=decoder] (output) {输出\\$\hat{x}$};
  
  \draw[arrow] (input) -- (encoder);
  \draw[arrow] (encoder) -- (latent);
  \draw[arrow] (latent) -- (decoder);
  \draw[arrow] (decoder) -- (output);
\end{tikzpicture}
\caption{架构概览。编码器将输入 $x$ 映射到潜表示 $z$，解码器将其重建。}
\label{fig:architecture}
\end{figure}

比较/矩阵图（用于展示方法变体）：

\begin{tikzpicture}[
  cell/.style={rectangle, draw, minimum width=2.5cm, minimum height=1cm, 
               align=center, font=\small},
  header/.style={cell, fill=gray!20, font=\small\bfseries},
]
  % 表头
  \node[header] at (0, 0) {方法};
  \node[header] at (3, 0) {收敛？};
  \node[header] at (6, 0) {质量？};
  % 行
  \node[cell] at (0, -1) {单次生成};
  \node[cell, fill=okgreen!15] at (3, -1) {N/A};
  \node[cell, fill=okorange!15] at (6, -1) {基线};
  \node[cell] at (0, -2) {Critique+Revise};
  \node[cell, fill=okred!15] at (3, -2) {否};
  \node[cell, fill=okred!15] at (6, -2) {退化};
  \node[cell] at (0, -3) {我们的方法};
  \node[cell, fill=okgreen!15] at (3, -3) {是（$k$=2）};
  \node[cell, fill=okgreen!15] at (6, -3) {改进};
\end{tikzpicture}

迭代循环图（用于带反馈的方法）：

\begin{tikzpicture}[
  node distance=2cm,
  box/.style={rectangle, draw, rounded corners, minimum height=0.8cm, 
              minimum width=1.8cm, align=center, font=\small},
  arrow/.style={-{Stealth[length=3mm]}, thick},
  label/.style={font=\scriptsize, midway, above},
]
  \node[box, fill=okblue!20] (gen) {生成器};
  \node[box, fill=okred!20, right=2.5cm of gen] (critic) {批评者};
  \node[box, fill=okgreen!20, below=1.5cm of $(gen)!0.5!(critic)$] (judge) {评审团};
  
  \draw[arrow] (gen) -- node[label] {输出 $A$} (critic);
  \draw[arrow] (critic) -- node[label, right] {批评 $C$} (judge);
  \draw[arrow] (judge) -| node[label, left, pos=0.3] {胜出者} (gen);
\end{tikzpicture}

用于修订跟踪的 latexdiff

对质询回复至关重要——生成标记修订的 PDF，显示版本间的更改：

# 安装
# macOS：brew install latexdiff（或随 TeX Live 提供）
# Linux：sudo apt install latexdiff
 
# 生成差异
latexdiff paper_v1.tex paper_v2.tex > paper_diff.tex
pdflatex paper_diff.tex
 
# 对于多文件项目（使用 \input{} 或 \include{}）
latexdiff --flatten paper_v1.tex paper_v2.tex > paper_diff.tex

这会生成一个 PDF，其中删除内容为红色删除线，新增内容为蓝色——这是质询补充材料的标准格式。

用于 matplotlib 的 SciencePlots

安装并用于可发表质量的绘图：

pip install SciencePlots

import matplotlib.pyplot as plt
import scienceplots  # 注册样式
 
# 使用科学样式（类似 IEEE，简洁）
with plt.style.context(['science', 'no-latex']):
    fig, ax = plt.subplots(figsize=(3.5, 2.5))  # 单栏宽度
    ax.plot(x, y, label='Ours', color='#0072B2')
    ax.plot(x, y2, label='Baseline', color='#D55E00', linestyle='--')
    ax.set_xlabel('Training Steps')
    ax.set_ylabel('Accuracy')
    ax.legend()
    fig.savefig('paper/fig_results.pdf', bbox_inches='tight')
 
# 可用样式：'science'、'ieee'、'nature'、'science+ieee'
# 如果生成绘图的机器上未安装 LaTeX，添加 'no-latex'

标准图表尺寸（双栏格式）：

单栏：figsize=(3.5, 2.5) — 适合一栏
双栏：figsize=(7.0, 3.0) — 跨两栏
正方形：figsize=(3.5, 3.5) — 用于热力图、混淆矩阵

阶段 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. 使用所有审稿的 AVERAGED 数值评分

保守行事：如果审稿人对某个弱点是否严重存在分歧，
在作者解决它之前视为严重。

审稿意见：
[review_1]
[review_2]
...

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

每份审稿可以在看到元审稿后优化自己的审稿意见。使用早期终止哨兵：如果审稿人回复”I am done”（无更改），停止迭代。

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

少样本校准：如果可用，包含 1-2 篇目标会议上实际发表的审稿作为示例。这能显著改进评分校准。参见 references/reviewer-guidelines.md 获取审稿示例。

步骤 6.1b：视觉审稿轮次（VLM）

纯文本审稿会漏掉一整类问题：图表质量、排版问题、视觉一致性。如果你能访问视觉模型，对编译后的 PDF 运行单独的视觉审稿：

你正在审阅此科研论文 PDF 的视觉呈现。
检查：
1. 图表质量：绘图是否可读？标签是否清晰？颜色是否可区分？
2. 图表标题对应：每个标题是否准确描述其图表？
3. 排版问题：孤立的章节标题、尴尬的分页、图表远离其引用位置
4. 表格格式：列对齐、一致的小数精度、加粗最佳结果
5. 视觉一致性：所有图表使用相同配色方案、一致的字号
6. 灰度可读性：如果以黑白打印，图表是否仍可理解？

对每个问题，指定页码和精确位置。

这能捕获纯文本审稿无法发现的问题：带有难以辨认的轴标签的绘图、离首次引用位置 3 页远的图、图 2 和图 5 之间不一致的调色板，或明显宽于栏宽的表格。

步骤 6.1c：主张验证轮次

在模拟审稿之后，运行单独的验证轮次。这能捕获审稿人可能遗漏的事实错误：

主张验证协议：
1. 从论文中提取每个事实主张（数字、比较、趋势）
2. 对于每个主张，追溯到支持它的具体实验/结果
3. 验证论文中的数字与实际结果文件匹配
4. 标记任何无法追踪来源的主张为 [VERIFY]

对于基于代理的工作流：将验证委托给仅接收论文文本和原始结果文件的全新子代理。新上下文防止确认偏见——验证者不”记得”结果应该是怎样的。

步骤 6.2：确定反馈优先级

收集审稿意见后，进行分类：

优先级	行动
关键（技术缺陷、缺失基线）	必须修复。可能需要新实验 → 回到阶段 2
高（清晰度问题、缺失消融）	应在此次修订中修复
中（次要写作问题、额外实验）	如果时间允许则修复
低（风格偏好、边缘建议）	记录为未来工作

步骤 6.3：修订循环

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

确定受影响的具体章节
起草修复方案
验证修复不会破坏其他主张
更新论文
重新对照审稿人的关切检查

步骤 6.4：质询回复撰写

当回应实际审稿意见时（投稿后），质询回复是与修订不同的技能：

格式：逐点回应。对于每个审稿人关切：

> R1-W1："论文缺乏与方法 X 的比较。"

我们感谢审稿人的建议。我们在表 3（修订版）中添加了与方法 X 的比较。
我们的方法在[指标]上以 3.2pp 的优势优于 X（p<0.05）。我们注意到 X 需要的计算预算是我们方法的 2 倍。

规则：

回应每个关切——审稿人注意你是否跳过了一个
以最强有力的回应用开头
简洁直接——审稿人阅读大量质询回复
如果你在质询期间运行了实验，包含新结果
即使对薄弱的批评，也绝不要防御性或轻蔑
使用 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 rejection。

参见 references/checklists.md 获取：

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

步骤 7.2：匿名化清单

双盲审稿意味着审稿人不能知道是谁写了论文。检查所有以下内容：

匿名化清单：
- [ ] PDF 中没有任何作者姓名或所属机构
- [ ] 没有致谢章节（接收后添加）
- [ ] 自引用以第三人称书写："Smith 等人 [1] 展示了..."而非"我们之前展示了 [1]..."
- [ ] 没有指向你个人仓库的 GitHub/GitLab URL
- [ ] 对于代码链接，使用 Anonymous GitHub (https://anonymous.4open.science/)
- [ ] 图表中没有机构标志或标识符
- [ ] 没有包含作者姓名的文件元数据（检查 PDF 属性）
- [ ] 没有"我们之前的工作"或"在我们早期的论文中"的表述
- [ ] 数据集名称不透露机构（如果需要，重命名）
- [ ] 补充材料不包含识别信息

常见错误：补充代码中可见的 Git 提交信息、来自机构工具的水印图表、来自早期草稿遗留的致谢、在匿名期之前发布的 arXiv 预印本。

步骤 7.3：格式验证

投稿前格式检查：
- [ ] 页数限制得到遵守（参考文献和附录除外）
- [ ] 所有图表为矢量（PDF）或高分辨率光栅（600 DPI PNG）
- [ ] 所有图表在灰度下可读
- [ ] 所有表格使用 booktabs
- [ ] 参考文献正确编译（引用中没有"?"）
- [ ] 关键区域没有 overfull hbox
- [ ] 附录清晰标记并分隔
- [ ] 必填章节存在（局限性、更广泛影响等）

步骤 7.4：预编译验证

在尝试 pdflatex之前运行这些自动化检查。在此处捕获错误比调试编译器输出更快。

# 1. 使用 chktex 进行代码检查（捕获常见 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)')
"

在继续前修复所有警告。对于基于代理的工作流：将 chktex 输出反馈给代理，并指示进行最小修复。

步骤 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：会议特定要求

会议	特殊要求
NeurIPS	附录中的论文清单，接收后需提交通俗摘要
ICML	更广泛影响声明（结论后，不计入页数限制）
ICLR	需要 LLM 披露、互惠审稿协议
ACL	强制性局限性章节、负责任的 NLP 清单
AAAI	严格的样式文件——不得有任何修改
COLM	为语言模型社区框架贡献

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

在不同会议之间转换时，永远不要在模板之间复制 LaTeX 前导文：

# 1. 使用目标模板全新开始
cp -r templates/icml2026/ new_submission/
 
# 2. 仅复制内容章节（非前导文）
#    - 摘要文本、章节内容、图表、表格、bib 条目
 
# 3. 针对页数限制进行调整
# 4. 添加会议特定的必填章节
# 5. 更新参考文献

从 → 到	页数变化	关键调整
NeurIPS → ICML	9 → 8	缩减 1 页，添加更广泛影响
ICML → ICLR	8 → 9	扩展实验，添加 LLM 披露
NeurIPS → ACL	9 → 8	为 NLP 惯例重构，添加局限性
ICLR → AAAI	9 → 7	大幅缩减，严格遵循样式
任何 → COLM	可变 → 9	为语言模型焦点重新框架

缩减时：将证明移到附录、压缩相关工作、合并表格、使用子图。扩展时：添加消融实验、扩展局限性、包含额外基线、添加定性示例。

被拒后：在新版本中解决审稿人关切，但不要包含”更改”章节或引用先前投稿（盲审）。

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

接收后，准备 camera-ready 版本：

Camera-Ready 清单：
- [ ] 去匿名化：添加作者姓名、所属机构、邮箱地址
- [ ] 添加致谢章节（资助、计算赠予、有帮助的审稿人）
- [ ] 添加公开代码/数据 URL（真实 GitHub，非匿名）
- [ ] 解决元审稿人的任何强制修订
- [ ] 切换模板到 camera-ready 模式（如适用——例如 AAAI 的 \anon → \camera）
- [ ] 如果会议要求，添加版权声明
- [ ] 更新文本中的任何"匿名"占位符
- [ ] 验证最终 PDF 干净编译
- [ ] 检查 camera-ready 的页数限制（有时与投稿不同）
- [ ] 将补充材料（代码、数据、附录）上传到会议门户

步骤 7.9：arXiv 与预印本策略

在 ML 领域，发布到 arXiv 是标准做法，但存在重要的时机和匿名性考虑。

时机决策树：

情况	建议
投稿到双盲会议（NeurIPS、ICML、ACL）	在投稿截止日期后发布到 arXiv，而非之前。之前发布可能在技术上违反匿名性政策，尽管执行力度不同。
投稿到 ICLR	ICLR 明确允许在投稿前发布到 arXiv。但不要在投稿本身中包含作者姓名。
论文已在 arXiv 上，投稿到新会议	大多数会议接受。不要在审稿期间更新 arXiv 版本以包含引用审稿意见的更改。
研讨会论文	任何时间都可以发布到 arXiv——研讨会通常不是双盲的。
想要确立优先权	如果担心被抢先，立即发布——但接受匿名性折衷。

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

类别	代码	最适合
Machine Learning	`cs.LG`	通用 ML 方法
Computation and Language	`cs.CL`	NLP、语言模型
Artificial Intelligence	`cs.AI`	推理、规划、智能体
Computer Vision	`cs.CV`	视觉模型
Information Retrieval	`cs.IR`	搜索、推荐

列出主要类别 + 1-2 个交叉列出的类别。 更多类别 = 更多可见性，但只在确实相关的类别中交叉列出。

版本策略：

v1：初始投稿（与会议投稿匹配）
v2：接收后更改的 camera-ready 修正版（在摘要中添加”accepted at [会议]”）
不要在审稿期间发布明显回应审稿人反馈的更改的 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 条目]

预发布清单：

- [ ] 代码在干净的克隆上运行（在全新机器或 Docker 上测试）
- [ ] 所有依赖项固定到特定版本
- [ ] 没有硬编码的绝对路径
- [ ] 仓库中没有 API 密钥、凭据或个人数据
- [ ] README 涵盖设置、复现和引用
- [ ] LICENSE 文件存在（MIT 或 Apache 2.0 以实现最大复用）
- [ ] 结果在预期方差内可复现
- [ ] .gitignore 排除数据文件、检查点、日志

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

# 使用 Anonymous GitHub 进行双盲审稿
# https://anonymous.4open.science/
# 上传你的仓库 → 获取匿名 URL → 放入论文

阶段 8：接收后交付物

目标：通过演示材料和社区参与最大化已接收论文的影响力。

步骤 8.1：会议海报

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

元素	指南
尺寸	查看会议要求（通常为 24”x36” 或 A0 纵向/横向）
内容	标题、作者、一句话贡献、方法图、2-3 个关键结果、结论
流	左上到右下（Z 型）或列式
文字	标题在 3 米处可读，正文在 1 米处可读。无完整段落——仅使用要点。
图表	以更高分辨率复用论文图表。放大关键结果。

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

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

步骤 8.2：会议演讲 / Spotlight

如果被授予口头或 spotlight 演示：

演讲类型	时长	内容
Spotlight	5 分钟	问题、方法、一个关键结果。排练到恰好 5 分钟。
口头演讲	15-20 分钟	完整故事：问题、方法、关键结果、消融、局限性。
研讨会演讲	10-15 分钟	根据研讨会受众调整——可能需要更多背景。

幻灯片设计规则：

每张幻灯片一个想法
最小化文字——说出细节，而非投射
动画关键图表以逐步构建理解
在结尾包含”要点”幻灯片（一句话贡献）
准备应对预期问题的备用幻灯片

步骤 8.3：博客 / 社交媒体

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

Twitter/X 串：5-8 条推文。以结果开头，而非方法。包含图 1 和关键结果图。
博客文章：800-1500 字。面向 ML 从业者，而非审稿人。跳过形式化，强调直觉和实际影响。
项目页面：包含摘要、图表、演示、代码链接、BibTeX 的 HTML 页面。使用 GitHub Pages。

时机：在论文出现在会议论文集或 arXiv camera-ready 后的 1-2 天内发布。

研讨会与短篇论文

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

研讨会论文

属性	研讨会	主会议
页数限制	4-6 页（通常）	7-9 页
审稿标准	完整性门槛较低	必须完整、彻底
审稿流程	通常单盲或轻松审稿	双盲、严格
重视什么	有趣的想法、初步结果、立场文章	有强基线的完整实证故事
arXiv	随时发布	时机重要（参见 arXiv 策略）
贡献门槛	新颖方向、有趣的负面结果、进行中的工作	有强力证据的重大进展

何时瞄准研讨会：

在完整论文之前想要反馈的早期想法
不值得 8+ 页的负面结果
关于及时话题的立场或观点文章
复现研究或可复现性报告

ACL 短篇论文与 Findings

ACL 会议有不同投稿类型：

类型	页数	预期内容
长论文	8	完整研究、强基线、消融
短论文	4	聚焦贡献：一个有证据的清晰观点
Findings	8	接近主会议但差一点的扎实工作

短论文策略：选择一个主张并彻底支持它。不要试图将长论文压缩到 4 页——写一篇不同的、更聚焦的论文。

实证 ML 之外的论文类型

上述主要流程针对实证 ML 论文。其他论文类型需要不同的结构和证据标准。参见 references/paper-types.md 获取各种类型的详细指导。

理论论文

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

与实证论文的关键区别：

贡献是定理、界限或不可能性结果——而非实验数字
方法部分替换为”预备知识”和”主要结果”
证明是证据，而非实验（尽管理论的实证验证也受欢迎）
正文中的证明草图和附录中的完整证明是标准做法
实验部分可选，但如果验证了理论预测则能增强论文

证明写作原则：

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

综述/教程论文

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

关键区别：

贡献是组织、综合和开放问题的识别——而非新方法
必须在范围内全面（审稿人会检查遗漏的参考文献）
需要清晰的分类或组织框架
价值来自单篇论文未做出的作品间联系
最佳会议：TMLR（综述通道）、JMLR、Foundations and Trends in ML、ACM Computing Surveys

基准测试论文

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

关键区别：

贡献是基准测试本身——它必须填补真正的评估空白
数据集文档是强制性的，而非可选的（参见数据表，步骤 5.11）
必须证明基准测试具有挑战性（基线未使其饱和）
必须证明基准测试测量了你声称的内容（构念效度）
最佳会议：NeurIPS Datasets & Benchmarks 通道、ACL（资源论文）、LREC-COLING

立场论文

结构：引言 → 背景 → 论文/论点 → 支持证据 → 反方论点 → 影响

关键区别：

贡献是论点，而非结果
必须认真对待反方论点
证据可以是实证、理论或逻辑分析
最佳会议：ICML（立场通道）、研讨会、TMLR

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")`

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`	并行章节起草——为每个章节生成隔离的子代理。也用于并发引用验证。
`todo`	跨会话的主要状态跟踪器。每个阶段转换后更新。
`memory`	跨会话持久化关键决策：贡献框架、会议选择、审稿人反馈。
`cronjob`	调度实验监控、截止日期倒计时、自动化 arXiv 检查。
`clarify`	当被阻塞时向用户提出有针对性的问题（会议选择、贡献框架）。
`send_message`	实验完成或草稿就绪时通知用户，即使用户不在聊天中。

工具使用模式

实验监控（最常见）：

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 '<描述性信息>' && git push")
→ send_message("Experiment complete: <summary>")

并行章节起草（使用委托）：

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

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

delegate_task("起草实验部分。读取 results/ 中的所有结果文件。
  说明每个实验支持哪个主张。包含误差棒和显著性。")

每个委托作为全新子代理运行，无共享上下文——在提示中提供所有必要信息。收集输出并整合。

引用验证（使用 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": "检查实验状态：
    1. ps aux | grep run_experiment
    2. tail -30 logs/experiment_haiku.log
    3. ls results/haiku_baselines/
    4. 如果完成：读取结果，计算 Borda 分数，
       git add -A && git commit -m 'Add Haiku results' && git push
    5. 报告：结果表、关键发现、下一步
    6. 如果无变化：用 [SILENT] 响应"
})

[SILENT] 协议：当自上次检查以来没有变化时，完全以 [SILENT] 响应。这会抑制向用户发送通知。仅在有值得了解的真实变化时才报告。

截止日期跟踪：

cronjob("create", {
  "schedule": "0 9 * * *",  # 每天上午 9 点
  "prompt": "NeurIPS 2025 截止日期：5 月 22 日。今天是 {date}。
    剩余天数：{compute}。
    检查 todo 列表——我们是否按计划进行？
    如果 <7 天：警告用户剩余任务。"
})

沟通模式

何时通知用户（通过 send_message 或直接响应）：

实验批次完成（附结果表）
需要决策的意外发现或失败
章节草稿准备好审查
截止日期临近且有未完成任务

何时不通知：

实验仍在运行，无新结果 → [SILENT]
例行监控无变化 → [SILENT]
不需要关注的中间步骤

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

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

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

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

需要人工输入的决策点

使用 clarify 在真正被阻塞时提出有针对性的问题：

决策	何时询问
目标会议	在开始论文前（影响页数限制、框架）
贡献框架	当存在多个有效的框架时
实验优先级	当待办列表中的实验超出时间允许的范围时
投稿就绪状态	在最终投稿前

不要询问（主动、做出选择、标记它）：

词汇选择、章节排序
要突出显示哪些具体结果
引用完整性（用你找到的起草，记录空白）

审稿人评估标准

理解审稿人关注什么有助于集中精力：

标准	他们检查什么
质量	技术严谨性、有充分支持的主张、公平的基线
清晰度	清晰写作、专家可复现、一致的符号
重要性	社区影响、推进理解
原创性	新洞察（不要求新方法）

评分（NeurIPS 6 分制）：

6：强烈接收——开创性、无懈可击
5：接收——技术上扎实、高影响力
4：边缘接收——扎实、评估有限
3：边缘拒绝——弱点多于优点
2：拒绝——技术缺陷
1：强烈拒绝——已知结果或伦理问题

参见 references/reviewer-guidelines.md 获取详细指南、常见关切和质询策略。

常见问题与解决方案

问题	解决方案
摘要过于泛化	删除第一句话（如果它可以前置任何 ML 论文）。从你的具体贡献开始。
引言超过 1.5 页	将背景拆分为相关工作。将贡献要点前置。
实验缺少明确主张	在每个实验前添加：“此实验测试是否[具体主张]…”
审稿人认为论文难理解	添加路标、使用一致的术语、使图注自包含。
缺少统计显著性	添加误差棒、运行次数、统计检验、置信区间。
实验范围蔓延	每个实验必须映射到特定主张。裁剪不匹配的实验。
论文被拒，需要重新投稿	参见阶段 7 中的会议重新投稿部分。解决审稿人关切而不引用审稿。
缺少更广泛影响声明	参见步骤 5.10。大多数会议要求。“无负面影响”几乎从不可信。
人工评估被批评为薄弱	参见步骤 2.5 和 references/human-evaluation.md。报告一致性指标、标注者详情、报酬。
审稿人质疑可复现性	发布代码（步骤 7.9）、记录所有超参数、包含种子和计算细节。
理论论文缺乏直觉	在形式证明前添加带有通俗语言解释的证明草图。参见 references/paper-types.md。
结果是负面/无效	参见阶段 4.3 关于处理负面结果的内容。考虑研讨会、TMLR，或重新框架为分析。

参考文档

文档	内容
references/writing-guide.md	Gopen & Swan 7 原则、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 获取编译说明。

关键外部来源

写作理念：

API： Semantic Scholar | CrossRef | arXiv

会议： NeurIPS | ICML | ICLR | ACL

好奇心花园🪴

探索

最近的笔记

note-template

getMoon.js

getWeather.js

科研论文写作 — 为 NeurIPS/ICML/ICLR 撰写 ML 论文：从设计到投稿

科研论文写作

技能元数据

参考：完整 SKILL.md

科研论文写作流程

何时使用此技能

核心理念

主动性与协作

阶段 0：项目设置

步骤 0.1：探索仓库

步骤 0.2：组织工作区

步骤 0.3：设置版本控制

步骤 0.4：确定贡献

步骤 0.5：创建待办事项列表

步骤 0.6：估算计算预算

步骤 0.7：多作者协作

阶段 1：文献综述

步骤 1.1：确定种子论文

步骤 1.2：搜索相关工作

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

步骤 1.3：验证每个引用

步骤 1.4：组织相关工作

阶段 2：实验设计

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

步骤 2.2：设计基线

步骤 2.3：定义评估协议

步骤 2.4：编写实验脚本

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

阶段 3：实验执行与监控

步骤 3.1：启动实验

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

步骤 3.3：处理失败

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

步骤 3.5：维护实验日志

阶段 4：结果分析

步骤 4.1：聚合结果

步骤 4.2：统计显著性

步骤 4.3：确定故事

处理负面或无效结果

步骤 4.4：创建图表和表格

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

步骤 4.6：编写实验日志（连接写作的桥梁）

迭代优化：策略选择

快速决策表

生成-评估差距

Autoreason 循环（总结）

应用于论文草稿

失败模式

阶段 5：论文草稿撰写

大型项目的上下文管理

叙事原则

此指导的来源

时间分配

写作工作流

两遍优化模式

LaTeX 错误检查清单

步骤 5.0：标题

步骤 5.1：摘要（5 句公式）

步骤 5.2：图 1

步骤 5.3：引言（最多 1-1.5 页）

步骤 5.4：方法

步骤 5.5：实验与结果

步骤 5.6：相关工作

步骤 5.7：局限性（必填）

步骤 5.8：结论与讨论

步骤 5.9：附录策略

页面预算管理

步骤 5.10：伦理与更广泛影响声明

步骤 5.11：数据表和模型卡（如适用）

写作风格

使用 LaTeX 模板

模板陷阱

快速模板参考

表格和图表

使用 `memory` 和 `todo` 的状态管理

使用 `cronjob` 的 Cron 监控