ablation-planner

消融实验规划器

系统地设计消融实验，回答审稿人会提出的问题。由 Codex 主导设计（从审稿人视角出发），CC 负责审查可行性并实施。

上下文：$ARGUMENTS

使用时机

• 主结果通过 /result-to-claim 检查，且 claim_supported = yes 或 partial
• 用户明确要求规划消融实验
• /auto-review-loop 的审稿人指出缺少消融实验

工作流

第 1 步：准备上下文

CC 读取可用的项目文件，全面了解项目：

• 方法描述和各组件（来自 idea-stage/docs/research_contract.md、旧版 docs/research_contract.md 或项目 CLAUDE.md）
• 当前实验结果（来自 EXPERIMENT_LOG.md、EXPERIMENT_TRACKER.md 或 W&B）
• 已确认和计划提出的主张（来自 result-to-claim 输出或项目笔记）
• 可用计算资源（如果存在，则来自 CLAUDE.md 中的服务器配置）

第 2 步：Codex 设计消融实验

mcp__codex__codex:
  model: gpt-6-astra
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are a rigorous ML reviewer planning ablation studies.
    Given this method and results, design ablations that:

    1. Isolate the contribution of each novel component
    2. Answer questions reviewers will definitely ask
    3. Test sensitivity to key hyperparameters
    4. Compare against natural alternative design choices

    Method: [description from project files]
    Components: [list of removable/replaceable components]
    Current results: [key metrics from experiments]
    Claims: [what we claim and current evidence]

    For each ablation, specify:
    - name: what to change (e.g., "remove module X", "replace Y with Z")
    - what_it_tests: the specific question this answers
    - expected_if_component_matters: what we predict if the component is important
    - priority: 1 (must-run) to 5 (nice-to-have)

    Also provide:
    - coverage_assessment: what reviewer questions these ablations answer
    - unnecessary_ablations: experiments that seem useful but won't add insight
    - suggested_order: run order optimized for maximum early information
    - estimated_compute: total GPU-hours estimate

第 3 步：解析消融计划

将 Codex 的回复规范化为结构化格式：

## Ablation Plan

### Component Ablations (highest priority)
| # | Name | What It Tests | Expected If Matters | Priority |
|---|------|---------------|---------------------|----------|
| 1 | remove module X | contribution of X | performance drops on metric Y | 1 |
| 2 | replace X with simpler Z | value of learned vs fixed | drops, especially on dataset A | 2 |

### Hyperparameter Sensitivity
| # | Parameter | Values to Test | What It Tests | Priority |
|---|-----------|---------------|---------------|----------|
| 3 | lambda | [0.01, 0.1, 1.0] | sensitivity to regularization | 3 |

### Design Choice Comparisons
| # | Name | What It Tests | Priority |
|---|------|---------------|----------|
| 4 | joint vs separate matching | whether joint adds value | 4 |

### Coverage Assessment
[What reviewer questions these ablations answer]

### Unnecessary Ablations
[Experiments that seem useful but won't add insight — skip these]

### Run Order
[Optimized for maximum early information]

### Estimated Compute
[Total GPU-hours]

第 4 步：CC 审查可行性

运行任何实验前，CC 需检查：

• 计算预算：现有 GPU 能否承担所有消融实验？
• 代码改动：哪些消融实验需要修改代码，哪些只需修改配置？
• 依赖关系：哪些消融实验可以并行运行？
• 精简方案：如果预算紧张，提出移除优先级较低的消融实验，并请 Codex 确认

第 5 步：实施并运行

1. 为每项消融实验创建配置文件/脚本（优先只修改配置）
2. 完整运行前，对每项消融实验进行冒烟测试
3. 按建议顺序运行，并使用描述性名称（例如 ablation-no-module-X）
4. 将结果记录到 EXPERIMENT_LOG.md
5. 所有消融实验完成后 → 在 findings.md 中更新研究发现

规则

• 由 Codex 主导设计。在 Codex 查看消融实验列表之前，CC 不得预先筛选或影响列表。 Codex 要像审稿人一样思考；CC 要像工程师一样思考。
• 每项消融实验都必须明确填写 what_it_tests 和 expected_if_component_matters。不得进行“只是试试看”的实验。
• 只需修改配置的消融实验优先于需要修改代码的实验（更快、更不易出错）。
• 如果总计算量超出预算，CC 应提出精简方案并请 Codex 重新确定优先级——不要擅自省略消融实验。
• 组件消融（移除/替换）优先于超参数扫描。
• 对与基线完全相同的组件，不要设计消融实验（无效消融）。
• 将所有消融实验结果记录到 EXPERIMENT_LOG.md，包括负面结果（移除组件后没有影响也是重要发现）。