研究論文寫作

用於撰寫機器學習/人工智能研究論文的端到端流水線——涵蓋從實驗設計到分析、起草、修訂和提交的整個過程。涵蓋 NeurIPS、ICML、ICLR、ACL、AAAI、COLM 等會議。集成自動化實驗監控、統計分析、迭代式寫作和引文驗證功能。

技能元數據


來源	捆綁（默認安裝）
路徑	`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

信息

以下是 Hermes 在觸發此技能時加載的完整技能定義。這是技能激活時代理看到的指令。

研究論文寫作流水線

用於生成面向 NeurIPS、ICML、ICLR、ACL、AAAI 和 COLM 的可供出版的機器學習/人工智能研究論文的端到端流水線。此技能涵蓋完整的研究生命週期：實驗設計、執行、監控、分析、論文寫作、評審、修訂和提交。

這不是一個線性流水線——而是一個迭代循環。結果會觸發新的實驗。評審意見會觸發新的分析。代理必須處理這些反饋循環。

┌─────────────────────────────────────────────────────────────┐
│                    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)     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

何時使用此技能

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

從頭開始撰寫新的研究論文，基於現有代碼庫或想法
設計和運行實驗以支持論文主張
撰寫或修訂研究論文的任何部分
準備向特定會議或研討會投稿
通過額外實驗或修訂回應評審意見
在不同會議格式之間轉換論文
撰寫非實證論文——理論、綜述、基準測試或立場論文（參見超越實證機器學習的論文類型）
為自然語言處理、人機交互或對齊研究設計人工評估
準備錄用後的交付物——海報、演講、代碼發佈

核心理念

積極主動。 提供完整的草稿，而不是提出問題。科學家都很忙——提供一些具體的內容供他們反應，然後進行迭代。
絕不虛構引文。 AI 生成的引文錯誤率約為 40%。務必以編程方式獲取。將無法驗證的引文標記為 [CITATION NEEDED]。
論文是一個故事，而不是實驗的集合。 每篇論文都需要用一句話陳述一個清晰的貢獻。如果你做不到這一點，說明論文尚未準備好。
實驗服務於主張。 每個實驗都必須明確說明它支持哪個主張。切勿運行與論文敘事無關的實驗。
儘早提交，頻繁提交。 每完成一批實驗，每次更新論文草稿——都要附帶描述性信息進行提交。Git 日誌就是實驗歷史。

主動性與協作

默認行為：積極主動。先起草，帶著草稿提問。

置信度級別	操作
高（清晰的倉庫，明顯的貢獻）	撰寫完整草稿，交付，根據反饋迭代
中（存在一些歧義）	撰寫草稿並標記不確定之處，繼續推進
低（存在重大未知因素）	通過 `clarify` 提出 1-2 個針對性問題，然後起草

章節	自主起草？	隨草稿標記
摘要	是	“將貢獻框架化為 X——如有需要請調整”
引言	是	“強調了問題 Y——如有錯誤請糾正”
方法	是	“包含了細節 A、B、C——補充缺失部分”
實驗	是	“突出了結果 1、2、3——如有需要請重新排序”
相關工作	是	“引用了論文 X、Y、Z——補充我遺漏的內容”

僅在以下情況下阻止並等待輸入：目標 venue 不明確、存在多種相互矛盾的框架、結果似乎不完整、明確要求先審查。

階段 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：明確貢獻點

在開始寫作之前，請闡明：

是什麼 (The What)：這篇論文的唯一核心貢獻是什麼？
為什麼 (The Why)：有哪些證據支持這一貢獻？
那又怎樣 (The So What)：讀者為什麼要關心這一點？

向科學家提議：“根據我的理解，主要貢獻是：[一句話]。關鍵結果顯示 [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 同步	Overleaf 高級版	兼具兩者優勢——實時協作與版本歷史

章節歸屬：將每個章節分配給一位主要作者。其他人可以評論，但不要直接編輯。這可以防止合併衝突和風格不一致。

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：確定種子論文

從代碼庫中已引用的論文開始：

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

加載 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 輪。

對於基於代理的工作流：通過 delegate_task 並行委託每輪的查詢。收集結果，去重，然後根據綜合學到的知識生成下一輪的查詢。

步驟 1.3：驗證每條引用

絕不要憑記憶生成 BibTeX。務必以編程方式獲取。

對於每條引用，遵循強制性的 5 步流程：

Citation Verification (MANDATORY per citation):
SEARCH → Query Semantic Scholar or Exa MCP with specific keywords
VERIFY → Confirm paper exists in 2+ sources (Semantic Scholar + arXiv/CrossRef)
RETRIEVE → Get BibTeX via DOI content negotiation (programmatically, not from memory)
VALIDATE → Confirm the claim you're citing actually appears in the paper
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] 條引用標記為需要驗證的佔位符。”

請參閱 references/citation-workflow.md 以獲取完整的 API 文檔和完整的 CitationManager 類。

按方法論對論文進行分組，而不是逐篇羅列：

好：“有一系列工作使用了 X 的假設 [refs]，而我們使用 Y 的假設，因為...” 壞：“Smith 等人引入了 X。Jones 等人引入了 Y。我們將兩者結合。”

第二階段：實驗設計

目標：設計直接支持論文主張的實驗。每個實驗必須回答一個具體問題。

步驟 2.1：將主張映射到實驗

創建顯式映射：

主張	實驗	預期證據
“我們的方法優於基線”	主要對比（表 1）	勝率，統計顯著性
“較弱模型的效果更明顯”	模型縮放研究	單調改進曲線
“收斂需要範圍約束”	有約束 vs 無約束	收斂速率對比

規則：如果實驗不對應任何主張，則不要運行它。

步驟 2.2：設計基線

強大的基線是區分錄用論文與被拒論文的關鍵。審稿人會問：“他們是否與 X 進行了對比？”

標準基線類別：

樸素基線 (Naive baseline)：儘可能簡單的方法
強基線 (Strong baseline)：已知的最佳現有方法
消融基線 (Ablation baselines)：你的方法減去一個組件
計算量匹配基線 (Compute-matched baselines)：相同的計算預算，不同的分配方式

步驟 2.3：定義評估協議

在運行任何實驗之前，請指定：

指標 (Metrics)：你要測量的內容，方向符號（越高越好/越低越好）
聚合 (Aggregation)：如何跨運行/任務組合結果
統計檢驗 (Statistical tests)：使用哪些檢驗來確定顯著性
樣本量 (Sample sizes)：運行次數/問題數量/任務數量

步驟 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)

** artifacts 保留** — 保存所有中間輸出：

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

請參閱 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 保證規模；內部團隊提供領域專業知識

標註指南檢查清單：

- [ ] 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

報告要求（審稿人會檢查所有這些內容）：

標註者人數及其資質
標註者間一致性，包括具體指標和數值
薪酬詳情（金額、預估時薪）
標註界面描述或截圖（附錄）
總標註時間

請參閱 references/human-evaluation.md 以獲取完整指南，包括人工評估數據的統計檢驗、眾包質量控制模式和 IRB 指導。

階段 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:
Check if process is still running: ps aux | grep <pattern>
Read last 30 lines of log: tail -30 <logfile>
Check for completed results: ls <result_dir>
If results exist, read and report: cat <result_file>
If all done, commit: git add -A && git commit -m "<descriptive message>" && git push
Report in structured format (tables with key metrics)
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 提交跟蹤發生了什麼，但不跟蹤 探索樹 (exploration tree) —— 即基於所學內容決定接下來嘗試什麼的決策過程。維護一個結構化的實驗日誌來捕捉這棵樹：

// 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：彙總結果

編寫執行以下操作的分析腳本：

從批次中加載所有結果文件
計算每個任務和聚合指標
生成摘要表格

# 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，用於衡量實際顯著性

請參閱 references/experiment-patterns.md 以獲取 McNemar 檢驗、bootstrap 置信區間和 Cohen's h 的完整實現。

步驟 4.3：確定故事線

分析後，明確回答以下問題：

主要發現是什麼？ 用一句話陳述。
什麼讓你感到驚訝？ 意想不到的結果往往能成就最好的論文。
什麼失敗了？ 失敗的實驗可能最具信息量。誠實地報告失敗會增強論文的說服力。
需要哪些後續實驗？ 結果往往會引發新的問題。

處理負面或無效結果

當你的假設錯誤或結果不確定時，你有三個選項：

情況	行動	適合的發表場所
假設錯誤，但原因具有信息量	圍繞對原因的分析構建論文	NeurIPS, ICML（如果分析嚴謹）
方法未超越基線，但揭示了新內容	將貢獻重新框架為理解/分析	ICLR（重視理解），研討會論文
針對流行主張的清晰負面結果	撰寫出來——領域內需要知曉	NeurIPS Datasets & Benchmarks, TMLR, 研討會
結果不確定，沒有清晰的故事線	轉向——運行不同的實驗或重新框架	不要強行拼湊一篇不存在的論文

如何撰寫負面結果論文：

開篇介紹社區普遍相信的觀點以及測試它的重要性
描述你嚴謹的方法論（必須無懈可擊——審稿人會更嚴格地審查）
清晰地呈現帶有統計證據的無效結果
分析為什麼預期的結果沒有出現
討論對該領域的影響

明確歡迎負面結果的發表場所：NeurIPS（Datasets & Benchmarks 軌道）、TMLR、ML 可復現性挑戰、主要會議的研討會。一些研討會特別徵集負面結果。

步驟 4.4：創建圖表和表格

圖形 (Figures)：

所有繪圖使用矢量圖形 (PDF)：plt.savefig('fig.pdf')
使用色盲友好調色板（Okabe-Ito 或 Paul Tol）
自包含的標題——讀者無需閱讀正文即可理解
圖形內部無標題——標題由圖注承擔此功能

表格 (Tables)：

使用 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：撰寫實驗日誌（通往寫作的橋樑）

在開始撰寫論文之前，創建一個結構化的實驗日誌，將結果與散文連接起來。這是實驗與寫作之間最重要的連接紐帶——如果沒有它，寫作代理必須從原始結果文件中重新推導故事線。

創建 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]

為何這很重要：在起草時，代理（或委託的子代理）可以加載 experiment_log.md 以及 LaTeX 模板，並生成基於實際結果的初稿。如果沒有這個橋樑，寫作代理必須解析原始 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 循環（摘要）

每一輪由全新的、隔離的代理產生三個候選項：

Critic → 找出當前 incumbent A 中的問題（不進行修復）
Author B → 根據批評意見修訂 A
Synthesizer → 合併 A 和 B（標籤隨機化）
Judge Panel → 3 位盲測思維鏈（CoT）評委通過博達計數法對 A、B、AB 進行排名
Convergence → A 連續贏得 k=2 輪 → 完成

關鍵參數：

k=2 收斂（k=1 過早，k=3 成本過高且無質量提升）
始終使用 CoT 評委（收斂速度快 3 倍）
作者溫度設為 0.8，評委溫度設為 0.3
保守平局打破規則：平局時 incumbent 勝出
每個角色都是擁有獨立上下文的全新代理

應用於論文草稿

當通過 autoreason 優化論文本身時：

向 Critic 提供真實數據：實際的實驗數據、結果 JSON、統計輸出。如果沒有這些，模型會產生捏造的消融實驗和虛假的置信區間。
至少使用 3 位有效的評委：損壞的評委解析器不僅會增加噪聲，還會完全阻止均衡狀態的達成。
限制修訂範圍：“解決這些具體弱點”，而不是“改進論文”。

失敗模式

失敗類型	檢測方法	修復方法
未收斂（A 從未獲勝）	在 20+ 輪中 A 勝率 <15%	為任務添加範圍約束
合成漂移	字數無限增長	約束結構和交付物
效果低於單次傳遞	基線得分高於迭代輸出	切換到 single pass；模型可能太弱
過擬合（代碼）	公共測試通過率高，私有測試通過率低	使用結構化分析，而不僅僅是測試反饋
評委失效	解析失敗導致評委小組少於 3 人	在繼續之前修復解析器

完整提示詞、博達評分細節、模型選擇指南、範圍約束設計模式和計算預算參考，請參閱 references/autoreason-methodology.md。

第 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 sentence
    experiment_summary.md    # Key results table (from experiment_log.md)
    literature_map.md        # Organized citation notes
    figure_inventory.md      # List of figures with descriptions

敘事原則

最關鍵的見解：你的論文不是實驗的集合——它是一個由證據支持的、具有單一清晰貢獻的故事。

每一篇成功的機器學習論文都圍繞著 Neel Nanda 所稱的“敘事”：一個簡短、嚴謹、基於證據的技術故事，並帶有讀者關心的核心觀點。

三大支柱（在引言結束時必須清晰明確）：

支柱	描述	測試
是什麼 (The What)	1-3 個具體的新穎主張	你能用一句話陳述它們嗎？
為什麼 (The Why)	嚴謹的經驗證據	實驗能否將你的假設與替代方案區分開來？
那又怎樣 (The So What)	讀者為何要關心	這是否與公認社區問題相關聯？

如果你不能用一句話陳述你的貢獻，那麼你還沒有形成一篇論文。

本指南的來源

這項技能綜合了曾在頂級會議發表大量論文的研究人員的寫作哲學。寫作哲學層最初由 Orchestra Research 編譯為 ml-paper-writing 技能。

來源	關鍵貢獻	鏈接
Neel Nanda (Google DeepMind)	敘事原則，是什麼/為什麼/那又怎樣框架	如何撰寫機器學習論文
Sebastian Farquhar (DeepMind)	5 句話摘要公式	如何撰寫機器學習論文
Gopen & Swan	讀者期望的 7 項原則	科學寫作的科學
Zachary Lipton	措辭選擇，消除模糊用語	科學寫作的啟發式方法
Jacob Steinhardt (UC Berkeley)	精確性，術語一致性	寫作建議
Ethan Perez (Anthropic)	微觀層面的清晰度技巧	簡單的論文寫作技巧
Andrej Karpathy	聚焦單一貢獻	各類講座

如需深入瞭解上述任何內容，請參閱：

references/writing-guide.md — 帶有示例的完整解釋
references/sources.md — 完整參考文獻列表

時間分配

在以下各項上花費大致相等的時間：

摘要
引言
圖表
其餘所有部分合計

為什麼？ 大多數審稿人在讀到你的方法之前就已經形成了判斷。讀者接觸你論文的順序是：標題 → 摘要 → 引言 → 圖表 → 也許還有其餘部分。

寫作工作流

Paper Writing Checklist:
- [ ] Step 1: Define the one-sentence contribution
- [ ] Step 2: Draft Figure 1 (core idea or most compelling result)
- [ ] Step 3: Draft abstract (5-sentence formula)
- [ ] Step 4: Draft introduction (1-1.5 pages max)
- [ ] Step 5: Draft methods
- [ ] Step 6: Draft experiments & results
- [ ] Step 7: Draft related work
- [ ] Step 8: Draft conclusion & discussion
- [ ] Step 9: Draft limitations (REQUIRED by all venues)
- [ ] Step 10: Plan appendix (proofs, extra experiments, details)
- [ ] Step 11: Complete paper checklist
- [ ] Step 12: Final review

當使用 AI 代理進行起草時，採用兩輪方法（在 SakanaAI 的 AI-Scientist 管道中被證明有效）：

第一輪 — 寫作 + 立即針對每個部分進行優化： 對於每個部分，撰寫完整的初稿，然後在同一上下文中立即對其進行優化。這能在該部分內容尚新鮮時捕捉局部問題（清晰度、流暢性、完整性）。

第二輪 — 基於全文上下文的全局優化： 在所有部分起草完成後，帶著對整篇論文的瞭解重新審視每個部分。這能捕捉跨部分的問題：冗餘、術語不一致、敘事流暢性，以及某個部分承諾了但另一個部分未交付的缺口。

Second-pass refinement prompt (per section):
"Review the [SECTION] in the context of the complete paper.
- Does it fit with the rest of the paper? Are there redundancies with other sections?
- Is terminology consistent with Introduction and Methods?
- Can anything be cut without weakening the message?
- Does the narrative flow from the previous section and into the next?
Make minimal, targeted edits. Do not rewrite from scratch."

LaTeX 錯誤檢查清單

將此檢查清單附加到每個優化提示中。這些是大語言模型編寫 LaTeX 時最常見的錯誤：

LaTeX Quality Checklist (verify after every edit):
- [ ] No unenclosed math symbols ($ signs balanced)
- [ ] Only reference figures/tables that exist (\ref matches \label)
- [ ] No fabricated citations (\cite matches entries in .bib)
- [ ] Every \begin{env} has matching \end{env} (especially figure, table, algorithm)
- [ ] No HTML contamination (</end{figure}> instead of \end{figure})
- [ ] No unescaped underscores outside math mode (use \_ in text)
- [ ] No duplicate \label definitions
- [ ] No duplicate section headers
- [ ] Numbers in text match actual experimental results
- [ ] All figures have captions and labels
- [ ] No overly long lines that cause overfull hbox warnings

步驟 5.0：標題

標題是論文中被閱讀次數最多的元素。它決定了是否有人會點擊進入摘要。

好的標題：

陳述貢獻或發現：“Autoreason：迭代大語言模型優化何時有效及其失敗原因”
強調令人驚訝的結果：“擴展數據受限的語言模型”（暗示你可以做到）
命名方法 + 其功能：“DPO：語言模型的直接偏好優化”

糟糕的標題：

過於泛泛：“一種改進語言模型輸出的方法”
過長：超過約 15 個詞的任何內容
僅含術語：“迭代隨機策略細化的漸近收斂性”（這是寫給誰看的？）

規則：

如果有方法名稱，請包含在內（以便引用）
包含 1-2 個審稿人會搜索的關鍵詞
避免使用冒號，除非前後兩部分都承載實質意義
測試：審稿人能否僅從標題中得知研究領域和貢獻？

步驟 5.1：摘要（5 句話公式）

來自 Sebastian Farquhar (DeepMind)：

What you achieved: "We introduce...", "We prove...", "We demonstrate..."
Why this is hard and important
How you do it (with specialist keywords for discoverability)
What evidence you have
Your most remarkable number/result

刪除諸如“大型語言模型取得了顯著成功……”之類的通用開場白。

步驟 5.2：圖 1

圖 1 是大多數讀者繼摘要之後查看的第二部分內容。在撰寫引言之前先起草它——這迫使你釐清核心思想。

圖 1 類型	何時使用	示例
方法示意圖	新架構或流程	展示你係統的 TikZ 流程圖
結果預覽	一個引人注目的結果就能說明全部故事	柱狀圖：“ ours vs baselines”，差距清晰
問題圖示	問題不直觀	展示你所修復的失敗模式的前後對比
概念圖	抽象貢獻需要視覺化支撐	方法屬性的 2x2 矩陣

規則：圖 1 必須在不閱讀任何文本的情況下也能被理解。僅憑圖注就應能傳達核心思想。有目的地使用顏色——不要僅僅為了裝飾。

步驟 5.3：引言（最多 1-1.5 頁）

必須包含：

清晰的問題陳述
簡要的方法概述
2-4 條貢獻列表（在雙欄格式中每條最多 1-2 行）
方法部分應從第 2-3 頁開始

步驟 5.4：方法

確保可復現：

概念大綱或偽代碼
列出所有超參數
提供足以復現的架構細節
展示最終的設計決策；消融實驗放在實驗部分

步驟 5.5：實驗與結果

對於每個實驗，明確陳述：

它支持什麼主張
它如何與主要貢獻相關聯
觀察要點：“藍線顯示 X，這證明了 Y”

要求：

帶有方法論說明的誤差棒（標準差 vs 標準誤）
超參數搜索範圍
計算基礎設施（GPU 類型、總小時數）
隨機種子設置方法

按方法論組織，而不是逐篇論文羅列。廣泛引用——審稿人很可能撰寫過相關論文。

步驟 5.7：侷限性（必需）

所有主要會議都要求此部分。誠實有益：

審稿人被指示不因誠實地承認侷限性而懲罰作者
通過首先識別弱點來先發制人地應對批評
解釋為何這些侷限性不會削弱核心主張

步驟 5.8：結論與討論

結論（必需，0.5-1 頁）：

用一句話重述貢獻（措辭應與摘要不同）
總結關鍵發現（2-3 句話，而非列表形式）
影響：這對該領域意味著什麼？
未來工作：2-3 個具體的下一步計劃（而非模糊的“我們將 X 留待未來研究”）

討論（可選，有時與結論合併）：

超出直接結果的更廣泛影響
與其他子領域的聯繫
誠實地評估該方法有效和無效的情況
實際部署考量

切勿在結論中引入新的結果或主張。

步驟 5.9：附錄策略

在所有主要 venues 中，附錄篇幅不限，且對於可復現性至關重要。結構如下：

附錄部分	內容
證明與推導	正文中篇幅過長的完整證明。正文可以陳述定理並註明“證明見附錄 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：倫理與更廣泛影響聲明

大多數會議現在要求或強烈建議提供倫理/更廣泛影響聲明。這不是套話 — 審稿人會閱讀它，並可能標記出導致直接拒稿的倫理問題。

包含內容：

組成部分	內容	要求方
積極的社會影響	你的工作如何造福社會	NeurIPS, ICML
潛在的負面影響	濫用風險、雙重用途擔憂、失效模式	NeurIPS, ICML
公平性與偏見	你的方法/數據是否存在已知偏見？	所有會議（隱含要求）
環境影響	大規模訓練的算力碳足跡	ICML，NeurIPS 日益增加此要求
隱私	你的工作是否使用或啟用個人數據處理？	ACL, NeurIPS
LLM 披露	寫作或實驗中是否使用了 AI？	ICLR（強制）, ACL

撰寫聲明：

\section*{Broader Impact Statement}
% NeurIPS/ICML: after conclusion, does not count toward page limit

% 1. Positive applications (1-2 sentences)
This work enables [specific application] which may benefit [specific group].

% 2. Risks and mitigations (1-3 sentences, be specific)
[Method/model] could potentially be misused for [specific risk]. We mitigate
this by [specific mitigation, e.g., releasing only model weights above size X,
including safety filters, documenting failure modes].

% 3. Limitations of impact claims (1 sentence)
Our evaluation is limited to [specific domain]; broader deployment would
require [specific additional work].

常見錯誤：

寫道“我們預見不到任何負面影響”（幾乎從不屬實 — 審稿人不信任這種說法）
表述模糊：“這可能會被濫用”，但未具體說明如何被濫用
忽略大規模工作的算力成本
忘記在要求披露的會議上聲明 LLM 的使用情況

算力碳足跡（針對訓練密集型論文）：

# Estimate using ML CO2 Impact tool methodology
gpu_hours = 1000  # total GPU hours
gpu_tdp_watts = 400  # e.g., A100 = 400W
pue = 1.1  # Power Usage Effectiveness (data center overhead)
carbon_intensity = 0.429  # kg CO2/kWh (US average; varies by region)

energy_kwh = (gpu_hours * gpu_tdp_watts * pue) / 1000
carbon_kg = energy_kwh * carbon_intensity
print(f"Energy: {energy_kwh:.0f} kWh, Carbon: {carbon_kg:.0f} kg CO2eq")

步驟 5.11：數據說明書與模型卡片（如適用）

如果你的論文引入了新數據集或發佈了模型，請包含結構化文檔。審稿人越來越期望看到這一點，且 NeurIPS Datasets & Benchmarks 軌道強制要求提供。

數據集說明書 (Datasheets for Datasets) (Gebru et al., 2021) — 包含在附錄中：

Dataset Documentation (Appendix):
- Motivation: Why was this dataset created? What task does it support?
- Composition: What are the instances? How many? What data types?
- Collection: How was data collected? What was the source?
- Preprocessing: What cleaning/filtering was applied?
- Distribution: How is the dataset distributed? Under what license?
- Maintenance: Who maintains it? How to report issues?
- Ethical considerations: Contains personal data? Consent obtained?
  Potential for harm? Known biases?

模型卡片 (Model Cards) (Mitchell et al., 2019) — 發佈模型時包含在附錄中：

Model Card (Appendix):
- Model details: Architecture, training data, training procedure
- Intended use: Primary use cases, out-of-scope uses
- Metrics: Evaluation metrics and results on benchmarks
- Ethical considerations: Known biases, fairness evaluations
- Limitations: Known failure modes, domains where model underperforms

寫作風格

句子層面的清晰度（Gopen & Swan 的 7 項原則）：

原則	規則
主謂鄰近	保持主語和謂語靠近
強調位置	將重點放在句尾
主題位置	先放背景信息，後放新信息
舊信息在前	熟悉的信息 → 不熟悉的信息
一個單元，一個功能	每個段落闡述一個觀點
動詞體現動作	使用動詞，而非名詞化結構
背景在新信息之前	在呈現內容前先鋪墊背景

用詞選擇（Lipton, Steinhardt）：

具體明確：使用“準確率 (accuracy)”而非“性能 (performance)”
消除含糊其辭：除非真正不確定，否則去掉“可能 (may)”
全文術語保持一致
避免增量式詞彙：使用“開發 (develop)”，而非“結合 (combine)”

包含示例的完整寫作指南：參見 references/writing-guide.md

使用 LaTeX 模板

務必先複製整個模板目錄，然後在其中進行寫作。

Template Setup Checklist:
- [ ] Step 1: Copy entire template directory to new project
- [ ] Step 2: Verify template compiles as-is (before any changes)
- [ ] Step 3: Read the template's example content to understand structure
- [ ] Step 4: Replace example content section by section
- [ ] Step 5: Use template macros (check preamble for \newcommand definitions)
- [ ] Step 6: Clean up template artifacts only at the end

步驟 1：複製完整模板

cp -r templates/neurips2025/ ~/papers/my-paper/
cd ~/papers/my-paper/
ls -la  # Should see: main.tex, neurips.sty, Makefile, etc.

複製整個目錄，而不僅僅是 .tex 文件。模板包括樣式文件 (.sty)、參考文獻樣式 (.bst)、示例內容和 Makefiles。

步驟 2：首先驗證模板能否編譯

在進行任何更改之前：

latexmk -pdf main.tex
# Or manual: pdflatex main.tex && bibtex main && pdflatex main.tex && pdflatex main.tex

如果未修改的模板無法編譯，請先修復該問題（通常是缺少 TeX 包 — 通過 tlmgr install <package> 安裝）。

步驟 3：保留模板內容作為參考

不要立即刪除示例內容。將其註釋掉，並用作格式參考：

% Template example (keep for reference):
% \begin{figure}[t]
%   \centering
%   \includegraphics[width=0.8\linewidth]{example-image}
%   \caption{Template shows caption style}
% \end{figure}

% Your actual figure:
\begin{figure}[t]
  \centering
  \includegraphics[width=0.8\linewidth]{your-figure.pdf}
  \caption{Your caption following the same style.}
\end{figure}

步驟 4：逐節替換內容

系統性地處理：標題/作者 → 摘要 → 引言 → 方法 → 實驗 → 相關工作 → 結論 → 參考文獻 → 附錄。每完成一節就編譯一次。

步驟 5：使用模板宏

\newcommand{\method}{YourMethodName}  % Consistent method naming
\newcommand{\eg}{e.g.,\xspace}        % Proper abbreviations
\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
Method & Accuracy $\uparrow$ & Latency $\downarrow$ \\
\midrule
Baseline & 85.2 & 45ms \\
\textbf{Ours} & \textbf{92.1} & 38ms \\
\bottomrule
\end{tabular}

規則：

每個指標的最佳值加粗
包含方向符號（$\uparrow$ 表示越高越好，$\downarrow$ 表示越低越好）
數值列右對齊
保持小數精度一致

圖形：

所有繪圖和圖表使用矢量圖形（PDF、EPS）— plt.savefig('fig.pdf')
僅照片使用柵格圖像（PNG 600 DPI）
使用色盲友好調色板（Okabe-Ito 或 Paul Tol）
驗證灰度可讀性（8% 的男性患有色覺缺陷）
圖形內部無標題 — 標題由圖注承擔此功能
自包含圖注 — 讀者無需閱讀正文即可理解

會議重投

若需在不同會議間轉換稿件，請參閱第 7 階段（投稿準備）— 其中涵蓋了完整的轉換工作流程、頁數變化表以及被拒後的指導建議。

專業 LaTeX 導言區

將以下宏包添加到任何論文中以提升專業質量。它們與所有主要會議的樣式文件兼容：

% --- Professional Packages (add after conference style file) ---

% Typography
\usepackage{microtype}              % Microtypographic improvements (protrusion, expansion)
                                     % Makes text noticeably more polished — always include

% Tables
\usepackage{booktabs}               % Professional table rules (\toprule, \midrule, \bottomrule)
\usepackage{siunitx}                % Consistent number formatting, decimal alignment
                                     % Usage: \num{12345} → 12,345; \SI{3.5}{GHz} → 3.5 GHz
                                     % Table alignment: S column type for decimal-aligned numbers

% Figures
\usepackage{graphicx}               % Include graphics (\includegraphics)
\usepackage{subcaption}             % Subfigures with (a), (b), (c) labels
                                     % Usage: \begin{subfigure}{0.48\textwidth} ... \end{subfigure}

% Diagrams and Algorithms
\usepackage{tikz}                   % Programmable vector diagrams
\usetikzlibrary{arrows.meta, positioning, shapes.geometric, calc, fit, backgrounds}
\usepackage[ruled,vlined]{algorithm2e}  % Professional pseudocode
                                     % Alternative: \usepackage{algorithmicx} if template bundles it

% Cross-references
\usepackage{cleveref}               % Smart references: \cref{fig:x} → "Figure 1"
                                     % MUST be loaded AFTER hyperref
                                     % Handles: figures, tables, sections, equations, algorithms

% Math (usually included by conference .sty, but verify)
\usepackage{amsmath,amssymb}        % AMS math environments and symbols
\usepackage{mathtools}              % Extends amsmath (dcases, coloneqq, etc.)

% Colors (for figures and diagrams)
\usepackage{xcolor}                 % Color management
% Okabe-Ito colorblind-safe palette:
\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
Method & {Accuracy $\uparrow$} & {F1 $\uparrow$} & {Latency (ms) $\downarrow$} \\
\midrule
Baseline         & 85.2  & 83.7  & 45.3 \\
Ablation (no X)  & 87.1  & 85.4  & 42.1 \\
\textbf{Ours}    & \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{Results on Dataset A.}
    \label{fig:results-a}
  \end{subfigure}
  \hfill
  \begin{subfigure}[b]{0.48\textwidth}
    \centering
    \includegraphics[width=\textwidth]{fig_results_b.pdf}
    \caption{Results on Dataset B.}
    \label{fig:results-b}
  \end{subfigure}
  \caption{Comparison of our method across two datasets. (a) shows the scaling
  behavior and (b) shows the ablation results. Both use 5 random seeds.}
  \label{fig:results}
\end{figure}

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

使用 algorithm2e 編寫偽代碼

\begin{algorithm}[t]
\caption{Iterative Refinement with Judge Panel}
\label{alg:method}
\KwIn{Task $T$, model $M$, judges $J_1 \ldots J_n$, convergence threshold $k$}
\KwOut{Final output $A^*$}
$A \gets M(T)$ \tcp*{Initial generation}
$\text{streak} \gets 0$\;
\While{$\text{streak} < k$}{
  $C \gets \text{Critic}(A, T)$ \tcp*{Identify weaknesses}
  $B \gets M(T, C)$ \tcp*{Revised version addressing critique}
  $AB \gets \text{Synthesize}(A, B)$ \tcp*{Merge best elements}
  \ForEach{judge $J_i$}{
    $\text{rank}_i \gets J_i(\text{shuffle}(A, B, AB))$ \tcp*{Blind ranking}
  }
  $\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 是機器學習論文中方法圖表的標準工具。常見模式：

管道/流程圖（機器學習論文中最常見）：

\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) {Input\\$x$};
  \node[box, fill=okblue!20, right of=input] (encoder) {Encoder\\$f_\theta$};
  \node[box, fill=okgreen!20, right of=encoder] (latent) {Latent\\$z$};
  \node[box, fill=okorange!20, right of=latent] (decoder) {Decoder\\$g_\phi$};
  \node[box, fill=okred!20, right of=decoder] (output) {Output\\$\hat{x}$};
  
  \draw[arrow] (input) -- (encoder);
  \draw[arrow] (encoder) -- (latent);
  \draw[arrow] (latent) -- (decoder);
  \draw[arrow] (decoder) -- (output);
\end{tikzpicture}
\caption{Architecture overview. The encoder maps input $x$ to latent 
representation $z$, which the decoder reconstructs.}
\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},
]
  % Headers
  \node[header] at (0, 0) {Method};
  \node[header] at (3, 0) {Converges?};
  \node[header] at (6, 0) {Quality?};
  % Rows
  \node[cell] at (0, -1) {Single Pass};
  \node[cell, fill=okgreen!15] at (3, -1) {N/A};
  \node[cell, fill=okorange!15] at (6, -1) {Baseline};
  \node[cell] at (0, -2) {Critique+Revise};
  \node[cell, fill=okred!15] at (3, -2) {No};
  \node[cell, fill=okred!15] at (6, -2) {Degrades};
  \node[cell] at (0, -3) {Ours};
  \node[cell, fill=okgreen!15] at (3, -3) {Yes ($k$=2)};
  \node[cell, fill=okgreen!15] at (6, -3) {Improves};
\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) {Generator};
  \node[box, fill=okred!20, right=2.5cm of gen] (critic) {Critic};
  \node[box, fill=okgreen!20, below=1.5cm of $(gen)!0.5!(critic)$] (judge) {Judge Panel};
  
  \draw[arrow] (gen) -- node[label] {output $A$} (critic);
  \draw[arrow] (critic) -- node[label, right] {critique $C$} (judge);
  \draw[arrow] (judge) -| node[label, left, pos=0.3] {winner} (gen);
\end{tikzpicture}

使用 latexdiff 跟蹤修訂

對於反駁至關重要 — 生成標記版的 PDF，顯示版本間的更改：

# Install
# macOS: brew install latexdiff (or comes with TeX Live)
# Linux: sudo apt install latexdiff

# Generate diff
latexdiff paper_v1.tex paper_v2.tex > paper_diff.tex
pdflatex paper_diff.tex

# For multi-file projects (with \input{} or \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  # registers styles

# Use science style (IEEE-like, clean)
with plt.style.context(['science', 'no-latex']):
    fig, ax = plt.subplots(figsize=(3.5, 2.5))  # Single-column width
    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')

# Available styles: 'science', 'ieee', 'nature', 'science+ieee'
# Add 'no-latex' if LaTeX is not installed on the machine generating plots

標準圖形尺寸（雙欄格式）：

單欄：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 在評估中存在記錄良好的正面偏差。

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 篇來自目標 venues 的真實已發表評審作為示例。這能顯著改善評分校準。參見 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:
Extract every factual claim from the paper (numbers, comparisons, trends)
For each claim, trace it to the specific experiment/result that supports it
Verify the number in the paper matches the actual result file
Flag any claim without a traceable source as [VERIFY]

對於基於代理的工作流：將驗證任務委託給一個全新的子代理，該代理僅接收論文文本和原始結果文件。全新的上下文可防止確認偏誤——驗證者不會“記得”結果原本應該是什麼。

步驟 6.2：優先處理反饋

收集評審意見後，進行分類：

優先級	行動
關鍵（技術缺陷、缺少基線）	必須修復。可能需要新實驗 → 返回階段 2
高（清晰度問題、缺少消融實驗）	應在本次修訂中修復
中（次要寫作問題、額外實驗）	如有時間則修復
低（風格偏好、邊緣建議）	記錄以備將來工作

步驟 6.3：修訂週期

針對每個關鍵/高優先級問題：

確定受影響的具體章節
起草修復方案
驗證修復不會破壞其他主張
更新論文
對照評審員的關切重新檢查

步驟 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：會議檢查清單

每個 venue 都有強制性的檢查清單。仔細完成它們——不完整的檢查清單可能導致直接拒稿。

參見 references/checklists.md 獲取：

NeurIPS 16 項論文檢查清單
ICML 更廣泛影響 + 可復現性
ICLR LLM 披露政策
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)')
"

在繼續之前修復任何警告。對於基於代理的工作流：將 chktex 輸出反饋給代理，並指示其進行最小限度的修復。

步驟 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 文件以查找第一個錯誤。常見修復方法：

“Undefined control sequence” → 缺少包或命令名稱拼寫錯誤
“Missing $ inserted” → 數學模式外的數學符號
“File not found” → 圖片路徑錯誤或缺少 .sty 文件
“Citation undefined” → 缺少 .bib 條目或未運行 bibtex

步驟 7.6：特定會議要求

會議	特殊要求
NeurIPS	附錄中需包含論文檢查清單，若被錄用需提供通俗摘要
ICML	更廣泛影響聲明（置於結論之後，不計入頁數限制）
ICLR	必須披露大語言模型（LLM）使用情況，簽署互惠審稿協議
ACL	必須包含侷限性（Limitations）章節，提供負責任的 NLP 檢查清單
AAAI	嚴格的樣式文件——嚴禁任何修改
COLM	針對語言模型社區重構貢獻陳述

步驟 7.7：會議重投與格式轉換

在不同會議間轉換時，切勿在不同模板間複製 LaTeX 導言區（preambles）：

# 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	擴展實驗部分，添加 LLM 披露
NeurIPS → ACL	9 → 8	按照 NLP 慣例重構結構，添加侷限性章節
ICLR → AAAI	9 → 7	大幅刪減，嚴格遵守樣式規範
任意 → COLM	可變 → 9	重新構建以聚焦語言模型

刪減頁數時：將證明移至附錄，精簡相關工作，合併表格，使用子圖。擴展內容時：添加消融實驗，擴展侷限性討論，包含額外的基線方法，添加定性示例。

被拒稿後：在新版本中解決審稿人的關切，但不要包含“變更”章節或提及之前的投稿（盲審要求）。

步驟 7.8：終稿準備（錄用後）

錄用後，準備終稿（camera-ready version）：

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 上發佈是機器學習領域的常規做法，但需要注意時機和匿名性考量。

時機決策樹：

情況	建議
投稿至雙盲會議（NeurIPS, ICML, ACL）	在投稿截止日期之後發佈至 arXiv，而非之前。提前發佈可能在技術上違反匿名政策，儘管執行力度各異。
投稿至 ICLR	ICLR 明確允許在投稿前發佈至 arXiv。但不要在投稿文件本身中包含作者姓名。
論文已在 arXiv 上，投稿至新會議	大多數會議均接受。切勿在審稿期間更新 arXiv 版本以包含引用審稿意見的更改。
研討會（Workshop）論文	隨時可發佈至 arXiv——研討會通常不採用雙盲評審。
希望確立優先權	如果擔心被搶發（scooping），請立即發佈——但需接受犧牲匿名性的代價。

arXiv 類別選擇（ML/AI 論文）：

類別	代碼	適用領域
Machine Learning	`cs.LG`	通用機器學習方法
Computation and Language	`cs.CL`	自然語言處理，語言模型
Artificial Intelligence	`cs.AI`	推理，規劃，智能體
Computer Vision	`cs.CV`	視覺模型
Information Retrieval	`cs.IR`	搜索，推薦系統

列出主要類別 + 1-2 個交叉列表類別。 類別越多 = 曝光率越高，但僅在與內容真正相關時才進行交叉列表。

版本控制策略：

v1：初始提交（與會議投稿版本一致）
v2：錄用後包含終稿修正的版本（在摘要中添加“accepted at [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：會議演講 / 焦點報告

如果獲得口頭報告或焦點報告（spotlight presentation機會：

演講類型	時長	內容
Spotlight（焦點演講）	5 分鐘	問題、方法、一個關鍵結果。排練至精確的 5 分鐘。
Oral（口頭報告）	15-20 分鐘	完整故事：問題、方法、關鍵結果、消融實驗、侷限性。
Workshop talk（研討會演講）	10-15 分鐘	根據研討會受眾進行調整——可能需要更多背景介紹。

幻燈片設計規則：

每頁幻燈片只表達一個觀點
最小化文本——口述細節，不要投影出來
對關鍵圖表進行動畫處理，逐步構建理解
在末尾包含一張“要點”幻燈片（用一句話概括貢獻）
為預期問題準備備用幻燈片

易於理解的摘要能顯著增加影響力：

Twitter/X 線程：5-8 條推文。以結果而非方法作為開頭。包含圖 1 和關鍵結果圖。
博客文章：800-1500 字。面向機器學習從業者撰寫，而非審稿人。跳過形式化描述，強調直覺和實際意義。
項目頁面：包含摘要、圖表、演示、代碼鏈接、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	紮實的工作，但略微未達到主會議標準

短論文策略：選擇一個主張並 thoroughly 支持它。不要試圖將長論文壓縮到 4 頁——寫一篇不同且更聚焦的論文。

實證機器學習之外的論文類型

上述主要流程針對實證機器學習論文。其他類型的論文需要不同的結構和證據標準。請參閱 references/paper-types.md 獲取每種類型的詳細指南。

理論論文

結構：引言 → 預備知識（定義、符號） → 主要結果（定理） → 證明概要 → 討論 → 完整證明（附錄）

與實證論文的關鍵區別：

貢獻是定理、界或不可能性結果——而非實驗數據
“方法”部分被“預備知識”和“主要結果”取代
證明是證據，而非實驗（儘管對理論的實證驗證是受歡迎的）
正文中包含證明概要，附錄中包含完整證明是標準做法
實驗部分是可選的，但如果能驗證理論預測，則會增強論文說服力

證明寫作原則：

正式陳述定理，明確所有假設
在形式化證明之前提供直覺解釋（“關鍵洞察是……”）
證明概要用 0.5-1 頁傳達主要思想
使用 \begin{proof}...\end{proof} 環境
對假設進行編號並在定理中引用：“在假設 1-3 下，……”

綜述 / 教程論文

結構：引言 → 分類法 / 組織結構 → 詳細覆蓋 → 開放問題 → 結論

關鍵區別：

貢獻是組織、綜合以及識別開放問題——而非新方法
必須在範圍內全面（審稿人會檢查是否遺漏參考文獻）
需要清晰的分類法或組織框架
價值來自於建立單個論文未建立的各項工作之間的聯繫
最佳投稿 venue：TMLR（綜述軌道）、JMLR、Foundations and Trends in ML、ACM Computing Surveys

基準測試論文

結構：引言 → 任務定義 → 數據集構建 → 基線評估 → 分析 → 預期用途與侷限性

關鍵區別：

貢獻本身就是基準——它必須填補真正的評估空白
數據集文檔是強制性的，而非可選的（參見 Datasheets，步驟 5.11）
必須證明該基準具有挑戰性（基線模型無法在其上達到飽和性能）
必須證明該基準測量了你所聲稱的內容（構念效度）
最佳投稿 venue：NeurIPS Datasets & Benchmarks track、ACL（資源論文）、LREC-COLING

立場論文 (Position Papers)

結構：引言 → 背景 → 論點 / 論證 → 支持證據 → 反駁論點 → 啟示

關鍵區別：

貢獻是一個論點，而非結果
必須認真回應反駁論點
證據可以是實證的、理論的或邏輯分析
最佳投稿 venue：ICML（position track）、研討會、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`	並行章節起草 —— 為每個章節 spawn 隔離的子 agent。也用於併發引用驗證。
`todo`	跨會話的主要狀態跟蹤器。在每個階段轉換後更新。
`memory`	跨會話持久化關鍵決策：貢獻框架、venue 選擇、審稿人反饋。
`cronjob`	調度實驗監控、截止日期倒計時、自動 arXiv 檢查。
`clarify`	當受阻時向用戶提出針對性問題（venue 選擇、貢獻框架）。
`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 '<descriptive message>' && git push")
→ send_message("Experiment complete: <summary>")

並行章節起草（使用委託）：

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

每個 delegate 作為全新的子 agent 運行，沒有共享上下文——在 prompt 中提供所有必要信息。收集輸出並整合。

引用驗證（使用 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")

會話啟動協議：

todo("list")                           # Check current task list
memory("read")                         # Recall key decisions
terminal("git log --oneline -10")      # Check recent commits
terminal("ps aux | grep python")       # Check running experiments
terminal("ls results/ | tail -20")     # Check for new results
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."
})

溝通模式

何時通知用戶（通過 send_message 或直接響應）：

實驗批次完成（附帶結果表）
出現需要決策的意外發現或失敗
章節草稿準備好供審查
截止日期臨近且任務未完成

何時不通知：

實驗仍在運行，無新結果 → [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: Strong Accept（強烈接收）— 突破性，完美無瑕
5: Accept（接收）— 技術紮實，高影響力
4: Borderline Accept（邊緣接收）— 紮實，但評估有限
3: Borderline Reject（邊緣拒絕）— 缺點大於優點
2: Reject（拒絕）— 技術缺陷
1: Strong Reject（強烈拒絕）— 已知結果或倫理問題

詳見 references/reviewer-guidelines.md 以獲取詳細指南、常見擔憂及反駁策略。

常見問題及解決方案

問題	解決方案
摘要過於泛泛	刪除首句（如果它可以放在任何機器學習論文開頭）。以你的具體貢獻開篇。
引言超過 1.5 頁	將背景部分拆分到相關工作（Related Work）中。前置貢獻要點。
實驗缺乏明確的主張	在每個實驗前添加：“本實驗測試是否[具體主張]...”
審稿人認為論文難以跟進	添加路標指引，使用一致的術語，使圖片標題自包含（self-contained）。
缺少統計顯著性	添加誤差線、運行次數、統計檢驗、置信區間。
實驗範圍蔓延	每個實驗必須對應一個具體主張。刪除不對應的實驗。
論文被拒，需要重新提交	參見第 7 階段的會議重新提交（Conference Resubmission）。解決審稿人的擔憂，但不要引用審稿意見。
缺少更廣泛的影響陳述	參見步驟 5.10。大多數 venue 都需要它。“無負面影響”幾乎不可信。
人工評估被批評為薄弱	參見步驟 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 獲取編譯說明。

關鍵外部來源

寫作哲學：

API： Semantic Scholar | CrossRef | arXiv

會議/期刊： NeurIPS | ICML | ICLR | ACL

技能元數據​

參考：完整 SKILL.md​

研究論文寫作流水線

何時使用此技能​

核心理念​

主動性與協作​

階段 0：項目設置​

步驟 0.1：探索倉庫​

步驟 0.2：組織工作空間​

步驟 0.3：設置版本控制​

步驟 0.4：明確貢獻點​

步驟 0.5：創建待辦事項列表​

步驟 0.6：估算計算預算​

步驟 0.7：多作者協調​

第一階段：文獻綜述​

步驟 1.1：確定種子論文​

步驟 1.2：搜索相關工作​

步驟 1.2b：深化搜索（先廣度後深度）​

步驟 1.3：驗證每條引用​

步驟 1.4：組織相關工作​

第二階段：實驗設計​

步驟 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 模板​

模板陷阱​

快速模板參考​

表格與圖形​

會議重投​

專業 LaTeX 導言區​

siunitx 表格對齊​

子圖​

使用 algorithm2e 編寫偽代碼​

TikZ 圖表模式​

使用 latexdiff 跟蹤修訂​

用於 matplotlib 的 SciencePlots​

技能元數據

參考：完整 SKILL.md

何時使用此技能

核心理念

主動性與協作

階段 0：項目設置

步驟 0.1：探索倉庫

步驟 0.2：組織工作空間

步驟 0.3：設置版本控制

步驟 0.4：明確貢獻點

步驟 0.5：創建待辦事項列表

步驟 0.6：估算計算預算

步驟 0.7：多作者協調

第一階段：文獻綜述

步驟 1.1：確定種子論文

步驟 1.2：搜索相關工作

步驟 1.2b：深化搜索（先廣度後深度）

步驟 1.3：驗證每條引用

步驟 1.4：組織相關工作

第二階段：實驗設計

步驟 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 模板

模板陷阱

快速模板參考

表格與圖形

會議重投

專業 LaTeX 導言區

siunitx 表格對齊

子圖

使用 algorithm2e 編寫偽代碼

TikZ 圖表模式

使用 latexdiff 跟蹤修訂

用於 matplotlib 的 SciencePlots

第 6 階段：自我審查與修訂