Stage 2: 实验设计 (Design)

进入时手里有什么

• 用户选定的 idea 卡片（含 base paper 和资源估算）
• Scout 的 文献调研报告
• 全局 GPU 预算约束

阶段目标

把选定的 idea 转化为可执行的实验计划，并定义 Research Contract — 明确要证明什么、用什么 evidence 证明。

具体步骤

graph TD
    A[选定的 Idea] --> B[Planner: 制定 Research Contract]
    B --> C[Planner: 设计实验计划]
    C --> D[Judge: 评审可行性]
    D --> E{Judge 判定}
    E -->|go| F[写入状态文件]
    E -->|revise| G[Planner 修改]
    G --> D
    E -->|no-go| H[回退到 Ideation]
    F --> I[进入 Implementation 阶段]

Step 1: 定义 Research Contract

执行者: Planner (Claude Opus)

Research Contract 是整个研究的"合同"。后续所有工作都围绕它展开：

# Research Contract

## Claim
我们的方法通过对比学习解耦细粒度特征，在不增加推理开销的
前提下提升细粒度识别精度。

## Evidence Required
| # | Evidence | 实验 | 成功标准 |
|---|---------|------|---------|
| E1 | 精度提升 | 主实验 on CUB-200 | top-1 acc > 86.8% (base paper) |
| E2 | 无额外推理开销 | FLOPs 测量 | FLOPs ≤ base paper × 1.1 |
| E3 | 解耦有效 | 消融实验 | 去掉解耦模块后精度下降 |

## Base Paper
- 论文: xxx (CVPR 2024)
- 代码: github.com/xxx
- Setting: ResNet-50, CUB-200, 100 epochs, lr=0.01

## Non-Goals
- 不追求 SOTA
- 不做多数据集泛化（除非审稿人要求）
- 不做大模型实验（ViT-Large 等）

Claim-Evidence 绑定

每个 Claim 都必须绑定具体的 Evidence。如果一个 Claim 没有对应的实验来验证，这个 Claim 就不应该出现。

Step 2: 设计实验计划

执行者: Planner (Claude Opus)

实验计划包含所有要跑的实验，按优先级排序：

# Experiment Plan

## 实验 1: Baseline 复现（最高优先级）
- 目的: 确认 base paper 结果可复现
- 配置: 完全使用 base paper 代码和超参
- 预期: CUB-200 acc ≈ 86.8%
- 服务器: ic2, GPU 0-1
- 预估时间: 6h

## 实验 2: 主实验
- 目的: 验证 E1（精度提升）
- 配置: 在 baseline 基础上加入对比解耦模块
- 预期: acc > 86.8%
- 服务器: ic2, GPU 0-2
- 预估时间: 8h

## 实验 3: FLOPs 测量
- 目的: 验证 E2（无额外推理开销）
- 配置: 推理模式下测量 FLOPs
- 预估时间: 30min

## 实验 4: 消融实验
- 目的: 验证 E3（解耦贡献）
- 配置: 去掉对比损失只保留分类损失
- 预估时间: 8h

## 执行顺序
1 → 2 → 3 → 4（实验 1 必须先通过）

## 回退方案
- 实验 1 失败（acc < 85%）→ 检查代码环境
- 实验 2 失败（acc ≤ 86.8%）→ 调整超参数，最多尝试 3 组
- 连续失败 → 回退到 Ideation 换 idea

Step 3: Judge 评审

执行者: Judge (Codex)

Judge 评审实验计划的可行性，不参与计划的制定过程：

plan: exp-plan-v1
verdict: revise
issues:
  - severity: high
    issue: "缺少 baseline 复现步骤的验证标准"
    detail: "只说'≈ 86.8%'太模糊，应该定义容忍范围"
    suggestion: "建议 85.5-88.0% 视为成功复现"

  - severity: medium
    issue: "GPU 预算估算未考虑消融实验"
    detail: "实验 2 + 实验 4 共 16h，接近 24h 上限"
    suggestion: "考虑实验 2 和 4 用相同 epoch 数减少总时间"

  - severity: low
    issue: "缺少学习率搜索策略"
    detail: "对比损失的温度参数可能需要调"

各 Agent 职责

Agent	做什么	不做什么
Planner	定义 Contract、设计实验计划	不评审自己的计划
Judge	评审可行性和完整性	不修改计划
编排器	协调 Planner-Judge 循环	不自行设计实验

Gate 信息

属性	值
默认 Gate	auto-judge
最多修改轮数	3
升级条件	Judge 连续 3 轮 revise → 升级为 human
通过条件	Judge 判定 go

错误处理 / 回退

情况	处理方式
Judge 判 no-go	回退到 Ideation，原因写入 findings.md
GPU 预算超标	Planner 精简实验计划（减少 epoch、换小模型）
精简后仍超标	回退到 Ideation 换 idea
Base paper 代码无法运行	Scout 重新搜索替代 base paper
3 轮 revise 未通过	升级为 human gate，让用户决定

设计阶段是性价比最高的投入

在 Design 阶段发现问题的代价远低于在 Training 阶段。花 2 小时在实验设计上，可能省下 20 小时的无效训练。这就是为什么 Judge 评审在这个阶段特别重要。

产出物

文件	内容
contract.md	Research Contract
experiments/exp-plan.md	实验计划
experiments/baselines.yaml	Baseline 配置
status.yaml 更新	stage → design, contract → contract.md

进入下一阶段的条件

• Research Contract 已定义
• 实验计划通过 Judge 评审（或用户确认）
• GPU 预算估算在限制内
• Base paper 代码确认可用