experiment-plan

实验计划：以论点为导向、面向论文的验证

细化并具体化：$ARGUMENTS

概览

当方法已经足够稳定，接下来的问题变成：我们究竟该按什么顺序开展哪些实验，才能支撑论文？ 此时使用此技能。如果用户希望一次请求涵盖完整流程，优先使用 /research-refine-pipeline。

目标不是生成一份庞大的基准测试愿望清单，而是将提案转化为一份 论点 -> 证据 -> 实验顺序 路线图，以支撑以下四点：

1. 该方法确实解决了所锚定的问题
2. 核心贡献真实且聚焦
3. 该方法足够简洁，无需额外复杂性
4. 任何前沿大模型时代的组件都确实有用，而非徒具装饰性

常量

• OUTPUT_DIR = refine-logs/ — 实验规划产物的默认目标目录。
• MAX_PRIMARY_CLAIMS = 2 — 优先采用一个核心论点和一个支撑论点。
• MAX_CORE_BLOCKS = 5 — 让必须开展的实验内容保持精简。
• MAX_BASELINE_FAMILIES = 3 — 优先选择少数强基线，而非许多弱基线。
• DEFAULT_SEEDS = 3 — 当随机性方差不可忽略且预算允许时，使用 3 个随机种子。

工作流程

阶段 0：加载提案背景

如果以下相关文件存在，请优先阅读：

• refine-logs/FINAL_PROPOSAL.md
• refine-logs/REVIEW_SUMMARY.md
• refine-logs/REFINEMENT_REPORT.md

提取：

• 问题锚点
• 核心贡献
• 可选的支撑性贡献
• 关键审稿人疑虑
• 数据 / 算力 / 时间安排约束
• 核心前沿技术组件（如有）

如果这些文件不存在，则根据用户的提示推导相同信息。

阶段 1：明确论文论点

在提出实验前，先写下必须支撑的论点。

采用以下结构：

• 主要论点：机制层面的核心贡献
• 支撑论点：可选，仅在其能直接强化论文主线时加入
• 需排除的反论点：例如“增益仅来自参数更多”“增益仅来自搜索空间更大”或“现代组件只是装饰”
• 最低限度的有说服力证据：哪些证据足以让严格的审稿人相信每项论点？

除非论文确实包含多个不可分割的论点，否则不要超过 MAX_PRIMARY_CLAIMS。

阶段 2：构建实验主线

围绕一组精简的实验模块设计论文。默认采用以下模块，并删除所有不必要的模块：

1. 核心锚定结果 — 该方法是否解决了实际瓶颈？
2. 创新点隔离 — 核心贡献本身是否发挥作用？
3. 简洁性 / 优雅性检验 — 是否可以避免采用更大或更零散的版本？
4. 前沿技术必要性检验 — 如果大模型 / VLM / Diffusion / RL 时代的组件至关重要，它是否确实是合适的工具？
5. 失败分析或定性诊断 — 该方法仍有哪些不足？

对每个模块，决定将其归入：

• 论文正文 — 支撑核心论点不可或缺
• 附录 — 有帮助，但非关键
• 删去 — 虽然有趣，但不值得占用论文篇幅

优先选择一个强基线系列，而非许多弱基线。如果存在更强的现代基线，就使用它，而不是为了凑数而扩充列表。

阶段 3：明确每个实验模块

对于每个保留的模块，请完整说明：

• 待检验的主张
• 此模块存在的原因
• 数据集 / 划分 / 任务
• 对比系统：仅包括最强基线、消融项和变体
• 指标：先列出决定性指标，再列出次要指标
• 设置详情：主干网络、冻结与可训练部分、关键超参数、训练预算、随机种子
• 成功标准：什么结果才算令人信服的证据？
• 失败解读：如果结果为负面，意味着什么？
• 表格 / 图示位置：此结果应出现在论文的什么位置

特别规则：

• 简洁性检查通常应将最终方法与过度复杂的变体，或论文有意舍弃的一个看似诱人的额外组件进行比较。
• 前沿技术必要性检查通常应将选用的现代基础技术与最有力、合理的简化或旧方案进行比较。
• 如果方案本就不打算采用前沿技术，请明确说明，并跳过前沿技术检查，不要勉强加入。

阶段 4：将计划转化为执行顺序

制定切实可行的运行顺序，让用户知道该从哪里开始。

使用以下里程碑结构：

1. 健全性阶段——数据管道、指标正确性、一次快速过拟合测试或玩具数据划分测试
2. 基线阶段——复现最强基线
3. 主要方法阶段——在主要设置下运行最终方法
4. 决策阶段——运行用于验证创新性、简洁性和前沿技术必要性的决定性消融
5. 完善阶段——稳健性、定性图示、附录补充内容

对于每个里程碑，估算：

• 计算成本
• 预计周转时间
• 停止 / 继续决策关卡
• 风险及缓解措施

将必须运行与锦上添花的实验分开。

阶段 5：编写输出

步骤 5.1：编写 refine-logs/EXPERIMENT_PLAN.md

使用以下结构：

# Experiment Plan

**Problem**: [problem]
**Method Thesis**: [one-sentence thesis]
**Date**: [today]

## Claim Map
| Claim | Why It Matters | Minimum Convincing Evidence | Linked Blocks |
|-------|-----------------|-----------------------------|---------------|
| C1    | ...             | ...                         | B1, B2        |

## Paper Storyline
- Main paper must prove:
- Appendix can support:
- Experiments intentionally cut:

## Experiment Blocks

### Block 1: [Name]
- Claim tested:
- Why this block exists:
- Dataset / split / task:
- Compared systems:
- Metrics:
- Setup details:
- Success criterion:
- Failure interpretation:
- Table / figure target:
- Priority: MUST-RUN / NICE-TO-HAVE

### Block 2: [Name]
...

## Run Order and Milestones
| Milestone | Goal | Runs | Decision Gate | Cost | Risk |
|-----------|------|------|---------------|------|------|
| M0        | ...  | ...  | ...           | ...  | ...  |

## Compute and Data Budget
- Total estimated GPU-hours:
- Data preparation needs:
- Human evaluation needs:
- Biggest bottleneck:

## Risks and Mitigations
- [Risk]:
- [Mitigation]:

## Final Checklist
- [ ] Main paper tables are covered
- [ ] Novelty is isolated
- [ ] Simplicity is defended
- [ ] Frontier contribution is justified or explicitly not claimed
- [ ] Nice-to-have runs are separated from must-run runs

步骤 5.2：编写 refine-logs/EXPERIMENT_TRACKER.md

使用以下结构：

# Experiment Tracker

| Run ID | Milestone | Purpose | System / Variant | Split | Metrics | Priority | Status | Notes |
|--------|-----------|---------|------------------|-------|---------|----------|--------|-------|
| R001   | M0        | sanity  | ...              | ...   | ...     | MUST     | TODO   | ...   |

保持跟踪表简洁，并以执行为导向。

步骤 5.3：向用户提供简要摘要

Experiment plan ready.

Must-run blocks:
- [Block 1]
- [Block 2]

Highest-risk assumption:
- [risk]

First three runs to launch:
1. [run]
2. [run]
3. [run]

Plan file: refine-logs/EXPERIMENT_PLAN.md
Tracker file: refine-logs/EXPERIMENT_TRACKER.md

输出协议

所有输出文件均须遵循以下通用协议：

• 输出版本控制协议——先写入带时间戳的文件，再复制到固定名称的文件
• 输出清单协议——将每个输出记录到 MANIFEST.md
• 输出语言协议——遵循项目的语言设置

关键规则

• 处理大文件：如果 Write 工具因文件过大而失败，立即改用 Bash（cat << 'EOF' > file）分块写入。不要征求用户许可——直接静默处理。

• 每个实验都必须支撑一项主张。 如果它不会改变评审者的看法，就删掉。

• 优先采用紧凑的论文叙事。 先设计主表格，再只添加能够支撑该表格的消融实验。

• 明确论证简洁性。 如果复杂度存在疑虑，请加入组件删除研究，或与更强但臃肿的变体进行比较。

• 明确论证前沿技术选择。 如果现代基础技术是核心，就证明它为何优于最有力的简化替代方案。

• 优先选择强基线，而非冗长的基线列表。 简短、可信的对比集胜过凑数的长列表。

• 区分必须运行与锦上添花的实验。 不要让附录想法拖延论文核心证据。

• 沿用方案中的约束。 不要臆造不切实际的预算或数据假设。

• 不要捏造结果。 规划证据，不要声称已有证据。

与其他技能协作

/research-refine-pipeline -> one-shot method + experiment planning
/research-refine   -> method and claim refinement
/experiment-plan   -> detailed experiment roadmap
/run-experiment    -> execute the runs
/auto-review-loop  -> react to results and iterate on the paper