research-refine

Research Refine：以问题为锚点、简洁优雅且紧跟前沿的方案优化

每次评审前，请遵循 可选择的评审者： 依次解析调用 → .aris/reviewer.json → Claude Code 默认配置（Codex MCP）， 并通过规范的辅助解析器使用 reviewer_route.py，保留本轮的等级、新上下文、源文件／图像输入及确定性门控。 下方的 Codex 示例／固定项仅适用于 backend=codex；其他路由使用各自的首次调用／回复约定。保存路由和实际返回的身份； 无法使用的选择应标记为 REVIEW_UNAVAILABLE。根据实际的模型系列／完成情况／范围判定是否接受。 将调用中的评审者／模型／effort 覆盖选项传递给包含评审者的子任务。生成工作线程保持不变。

优化并具体化：$ARGUMENTS

概述

当研究问题已经清晰，但技术路线仍然模糊时，使用此技能。目标不是产出冗长的提案或基准测试清单，而是将模糊的方向转化为一份问题 -> 聚焦方法 -> 最小验证文档，使其具体到足以实现、简洁优雅到足以成为论文成果，并且足够前沿，能契合基础模型时代。

本技能遵循四项核心原则：

1. 不要偏离原始问题。 固定一份不可变的问题锚点，并在每轮中重复使用。
2. 优先选择足够解决问题的最小机制。 直接解决瓶颈的最小干预方案为优。
3. 一篇论文，一个主要贡献。 优先采用一个鲜明的核心论点，最多再加一项辅助贡献。
4. 现代方法是先验，而非装饰。 当 LLM / VLM / Diffusion / RL / 蒸馏 / 推理时扩展自然适用于瓶颈时，应具体应用，不要为了追热点而生搬硬套。

User input (PROBLEM + vague APPROACH)
  -> Phase 0 (Claude): Freeze Problem Anchor
  -> Phase 1 (Claude): Scan grounding papers -> identify technical gap -> choose the sharpest route -> write focused proposal
  -> Phase 2 (Codex/GPT-6-Astra): Review for fidelity, specificity, contribution quality, and frontier leverage
  -> Phase 3 (Claude): Anchor check + simplicity check -> revise method -> rewrite full proposal
  -> Phase 4 (Codex, same thread): Re-evaluate revised proposal
  -> Repeat Phase 3-4 until OVERALL SCORE >= 9 or MAX_ROUNDS reached
  -> Phase 5: Save full history to refine-logs/
  -> Optional handoff: /experiment-plan for a detailed execution-ready experiment roadmap

常量

• REVIEWER_MODEL = gpt-6-astra —— 通过 Codex MCP 使用的评审模型。
• MAX_ROUNDS = 5 —— 最多进行的评审－修订轮数。
• SCORE_THRESHOLD = 9 —— 停止所需的最低总分。
• OUTPUT_DIR = refine-logs/ —— 轮次文件和最终报告的目录。
• MAX_LOCAL_PAPERS = 15 —— 用于奠定依据的本地论文／笔记扫描上限。
• MAX_CORE_EXPERIMENTS = 3 —— 本技能中核心验证环节的默认上限。
• MAX_PRIMARY_CLAIMS = 2 —— 论文级主张的软上限。优先采用一个核心主张加一个辅助主张。
• MAX_NEW_TRAINABLE_COMPONENTS = 2 —— 全新可训练组件的软上限。只有在论文无法以其他方式成立时才可超出。

如有需要，可通过参数覆盖，例如：/research-refine "problem | approach" -- max rounds: 3, threshold: 9。

状态持久化（检查点恢复）

长时间运行的优化会话可能中途失败（例如 API 超时、上下文压缩或会话中断）。为避免丢失已完成的工作，请在每个阶段边界后将状态写入 refine-logs/REFINE_STATE.json：

{
  "phase": "review",
  "round": 1,
  "threadId": "019cd392-...",
  "last_score": 6.5,
  "last_verdict": "REVISE",
  "status": "in_progress",
  "timestamp": "2026-03-22T20:00:00"
}

字段定义：

字段	取值	含义
phase	"anchor" / "proposal" / "review" / "refine" / "done"	最后一个已完成的阶段
round	0–MAX_ROUNDS	当前轮次
threadId	字符串或 null	用于 codex-reply 连续评审的评审线程 ID
last_score	数字或 null	评审者最近给出的总分
last_verdict	字符串或 null	最近的评审结论（READY / REVISE / RETHINK）
status	"in_progress" / "completed"	循环状态
timestamp	ISO 8601	上次写入状态的时间

写入规则：

• 每个阶段完成后写入（而非完成前）。每次覆盖——只保留最新状态。
• 完成时（第 5 阶段完成），将 "status" 设为 "completed"。

输出结构

refine-logs/
├── REFINE_STATE.json
├── round-0-initial-proposal.md
├── round-1-review.md
├── round-1-refinement.md
├── round-2-review.md
├── round-2-refinement.md
├── ...
├── REVIEW_SUMMARY.md
├── FINAL_PROPOSAL.md
├── REFINEMENT_REPORT.md
└── score-history.md

每个 round-N-refinement.md 都必须包含一份完整且以问题锚点为基础的提案，不能只写增量式修正。

工作流

初始化（检查点恢复）

开始任何阶段前，检查之前的运行是否留下了检查点：

1. 检查 refine-logs/REFINE_STATE.json 是否存在：

   • 如果不存在 → 从头开始（正常进入阶段 0）
   • 如果存在且 status 为 "completed" → 从头开始（删除状态文件，之前的运行已完成）
   • 如果存在且 status 为 "in_progress"，且 timestamp 早于 24 小时 → 从头开始（这是被终止或放弃的运行留下的过期状态——删除该文件）
   • 如果存在且 status 为 "in_progress"，且 timestamp 在 24 小时以内 → 恢复运行

2. 恢复运行时，读取状态文件并恢复上下文：

   • 读取所有现有的 refine-logs/round-*.md 文件，恢复之前的工作
   • 如果 refine-logs/score-history.md 存在，则读取该文件
   • 恢复用于保持评审线程连续性的 threadId
   • 向用户记录："Checkpoint found. Resuming after phase: {phase}, round: {round}."
   • 根据保存的 phase 值跳转到下一阶段：

   保存的 phase	已完成的内容	恢复位置
   "anchor"	阶段 0 已完成	阶段 1（从 round-0 上下文中读取问题锚点）
   "proposal"	阶段 1 已完成	阶段 2（读取 round-0-initial-proposal.md）
   "review"	阶段 2 或 4 已完成	阶段 3（读取最新的 round-N-review.md）
   "refine"	阶段 3 已完成	阶段 4（读取最新的 round-N-refinement.md）

3. 从头开始时，确保 refine-logs/ 目录存在，然后进入阶段 0。

阶段 0：锁定问题锚点

提出任何方案之前，提炼用户不可更改的核心问题。每份提案和每轮修订都必须逐字复制此锚点。

写明：

• 核心问题：必须解决什么技术问题？
• 必须解决的瓶颈：当前方法中的哪项具体弱点不可接受？
• 非目标：本项目明确不以什么为目标？
• 约束条件：计算资源、数据、时间、工具、发表场所和部署方面的限制。
• 成功条件：什么证据能让用户认定“该方法解决了实际问题”？

如果之后的评审意见会改变要解决的问题，应将其标记为偏题，并提出异议或谨慎调整。

**检查点：**写入 refine-logs/REFINE_STATE.json，内容为 {"phase": "anchor", "round": 0, "threadId": null, "last_score": null, "last_verdict": null, "status": "in_progress", "timestamp": "<now>"}。

阶段 1：构建初始提案

步骤 1.1：查阅依据材料

先检查 papers/ 和 literature/。只阅读回答以下问题所需的相关部分：

• 当前方法采用了什么机制？
• 它们在这个问题上具体在哪里失效？
• 哪些近期 LLM / VLM / Diffusion / RL 时代的技术与此问题真正相关？
• 哪些训练目标、表征或接口可以复用？
• 哪些细节能区分真正的方法与换了名称的高层构想？

如果本地材料不足，则在线搜索近期顶级会议或 arXiv 论文。重点关注方法章节、训练设置和失效模式，而不只是摘要。

步骤 1.2：识别技术差距

不要止步于泛泛的研究问题。要明确差距在实际操作中具体体现在哪里：

1. 当前流程的失效点：基线在哪里失效？
2. 简单修复为何不足：更大的上下文、更多数据、提示词、记忆库或堆叠更多模块为何不够？
3. 满足需求的最小干预：最少需要增加什么机制，才能有望解决瓶颈？
4. 契合前沿的替代方案：是否有更前沿的路线，利用基础模型时代的原语，更好地匹配该瓶颈？
5. 核心技术主张：哪项关于具体机制的主张能够经受顶级会议的审查？
6. 所需证据：为支撑该主张，至少需要哪些证据？

步骤 1.3：选择最精炼的路线

在确定方法之前，如果两条候选路线都可行，请先进行比较：

• 路线 A：优雅的最简路线——直接针对瓶颈的最小机制。
• 路线 B：前沿技术原生路线——仅当 LLM / VLM / Diffusion / RL / 蒸馏 / 推理时扩展能带来更清晰或更有力的论述时，才采用更现代的路线。

然后作出判断：

• 在给定约束下，哪条路线更有可能发展成一篇有竞争力的论文？
• 相较于最接近的相关工作，哪条路线的创新点论述更清晰？
• 哪条路线能避免贡献点发散？

如果两条路线都较弱，应重新思考问题的 framing，而不是默认将它们组合成一个更大的系统。

步骤 1.4：先具体化方法

提案必须回答“我们实际要如何构建？”优先详细说明方法，而非泛泛讨论实验；优先复用，而非另起炉灶。

请涵盖：

1. 一句话方法论点：最有力的单一机制主张。
2. 贡献重点：一个主要贡献，最多再加一个辅助贡献。
3. 复杂度预算：哪些部分保持不变或复用，哪些是新增的，以及有意排除哪些看似诱人的扩展。
4. 系统图：模块、数据流、输入、输出。
5. 表征设计：使用什么潜变量、嵌入、规划 Token、奖励信号、记忆状态或对齐空间？
6. 训练方案：数据来源、监督、伪标签、负样本、课程安排、损失函数、权重、分阶段训练还是联合训练。
7. 推理路径：训练好的组件在测试时如何使用，信号如何流转。
8. 机制为何保持精简：为何不需要更大的技术栈。
9. 任何前沿技术原语的确切作用：如果使用 LLM / VLM / Diffusion / RL 组件，请说明它的作用是规划器、教师、评判器、奖励模型、生成先验、搜索控制器，还是蒸馏来源。
10. 故障处理：可能出现什么问题？有哪些备用方案或诊断手段？
11. 创新性与优雅性论证：为什么这不只是给某个模块换个名字？为什么论文仍然重点突出？

如果方法仍然只是“添加一个模块”或“使用规划器”，就还不够具体。

步骤 1.5：设计以主张为导向的最小验证

实验用于验证方法，而非喧宾夺主。

针对每个核心主张，定义能够验证它的最小且有说服力的实验：

• 测试的主张
• 必要的基线或消融实验
• 决定性指标
• 预期的变化方向

其他要求：

• 确保有一个实验组能够直接支持问题锚点。
• 如果存在复杂度风险，加入一项简化或删除检查。
• 如果前沿技术原语是核心内容，加入一项必要性检查，说明这一选择为何重要。
• 默认安排 1-3 个核心实验组，完整的执行路线图留给 /experiment-plan。

步骤 1.6：撰写初始提案

保存至 refine-logs/round-0-initial-proposal.md。

使用以下结构：

# Research Proposal: [Title]

## Problem Anchor
- Bottom-line problem:
- Must-solve bottleneck:
- Non-goals:
- Constraints:
- Success condition:

## Technical Gap
[Why current methods fail, why naive bigger systems are not enough, and what mechanism is missing]

## Method Thesis
- One-sentence thesis:
- Why this is the smallest adequate intervention:
- Why this route is timely in the foundation-model era:

## Contribution Focus
- Dominant contribution:
- Optional supporting contribution:
- Explicit non-contributions:

## Proposed Method
### Complexity Budget
- Frozen / reused backbone:
- New trainable components:
- Tempting additions intentionally not used:

### System Overview
[Step-by-step pipeline or ASCII graph]

### Core Mechanism
- Input / output:
- Architecture or policy:
- Training signal / loss:
- Why this is the main novelty:

### Optional Supporting Component
- Only include if truly necessary:
- Input / output:
- Training signal / loss:
- Why it does not create contribution sprawl:

### Modern Primitive Usage
- Which LLM / VLM / Diffusion / RL-era primitive is used:
- Exact role in the pipeline:
- Why it is more natural than an old-school alternative:

### Integration into Base Generator / Downstream Pipeline
[Where the new method attaches, what is frozen, what is trainable, inference order]

### Training Plan
[Stagewise or joint training, losses, data construction, pseudo-labels, schedules]

### Failure Modes and Diagnostics
- [Failure mode]:
- [How to detect]:
- [Fallback or mitigation]:

### Novelty and Elegance Argument
[Closest work, exact difference, why this is a focused mechanism-level contribution rather than a module pile-up]

## Claim-Driven Validation Sketch
### Claim 1: [Main claim]
- Minimal experiment:
- Baselines / ablations:
- Metric:
- Expected evidence:

### Claim 2: [Optional]
- Minimal experiment:
- Baselines / ablations:
- Metric:
- Expected evidence:

## Experiment Handoff Inputs
- Must-prove claims:
- Must-run ablations:
- Critical datasets / metrics:
- Highest-risk assumptions:

## Compute & Timeline Estimate
- Estimated GPU-hours:
- Data / annotation cost:
- Timeline:

检查点： 使用 {"phase": "proposal", "round": 0, ...} 更新 refine-logs/REFINE_STATE.json。

阶段 2：外部方法评审（第 1 轮）

将提案发送给 GPT-6-Astra，进行一次优先考虑优雅性、兼顾前沿进展、以方法为先的评审。评审者应将大部分评审篇幅用于方法本身，而不是扩充实验选项。对于 Codex MCP，提示词变长后，不要内联整个评审标准和提案。请改为创建 refine-logs/codex_round_1_review_bundle.md，其中写入以下说明以及 refine-logs/round-0-initial-proposal.md 的绝对路径，然后保持 MCP 提示词简短：

先处理这个评审环节；以下是 backend=codex 的示例。

mcp__codex__codex:
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    Read the review bundle at <absolute path to
    refine-logs/codex_round_1_review_bundle.md> and follow all instructions in
    it.

捆绑文件内容：

    You are a senior ML reviewer for a top venue (NeurIPS/ICML/ICLR).
    This is an early-stage, method-first research proposal.

    Your job is NOT to reward extra modules, contribution sprawl, or a giant benchmark checklist.
    Your job IS to stress-test whether the proposed method:
    (1) still solves the original anchored problem,
    (2) is concrete enough to implement,
    (3) presents a focused, elegant contribution,
    (4) uses foundation-model-era techniques appropriately when they are the natural fit.

    Review principles:
    - Prefer the smallest adequate mechanism over a larger system.
    - Penalize parallel contributions that make the paper feel unfocused.
    - If a modern LLM / VLM / Diffusion / RL route would clearly produce a better paper, say so concretely.
    - If the proposal is already modern enough, do NOT force trendy components.
    - Do not ask for extra experiments unless they are needed to prove the core claims.

    Read the Problem Anchor first. If your suggested fix would change the problem being solved,
    call that out explicitly as drift instead of treating it as a normal revision request.

    Proposal path (read this file yourself): <absolute path to
    refine-logs/round-0-initial-proposal.md>

    Score these 7 dimensions from 1-10:

    1. **Problem Fidelity**: Does the method still attack the original bottleneck, or has it drifted into solving something easier or different?

    2. **Method Specificity**: Are the interfaces, representations, losses, training stages, and inference path concrete enough that an engineer could start implementing?

    3. **Contribution Quality**: Is there one dominant mechanism-level contribution with real novelty, good parsimony, and no obvious contribution sprawl?

    4. **Frontier Leverage**: Does the proposal use current foundation-model-era primitives appropriately when they are the right tool, instead of defaulting to old-school module stacking?

    5. **Feasibility**: Can this method be trained and integrated with the stated resources and data assumptions?

    6. **Validation Focus**: Are the proposed experiments minimal but sufficient to validate the core claims? Is there unnecessary experimental bloat?

    7. **Venue Readiness**: If executed well, would the contribution feel sharp and timely enough for a top venue?

    **OVERALL SCORE** (1-10): Weighted toward Problem Fidelity, Method Specificity, Contribution Quality, and Frontier Leverage.
    Use this weighting: Problem Fidelity 15%, Method Specificity 25%, Contribution Quality 25%, Frontier Leverage 15%, Feasibility 10%, Validation Focus 5%, Venue Readiness 5%.
    (This weighted-axis rubric is the repo's working precedent for
    `shared-references/taste-calibration.md`; if curated known-good/known-bad
    past proposals are available — e.g. from research-wiki's accepted/rejected
    idea history — score 3 of each on these axes FIRST to anchor the scale, and
    name in the review which anchor the proposal sits closest to.)

    For each dimension scoring < 7, provide:
    - The specific weakness
    - A concrete fix at the method level (interface / loss / training recipe / integration point / deletion of unnecessary parts)
    - Priority: CRITICAL / IMPORTANT / MINOR

    Then add:
    - **Simplification Opportunities**: 1-3 concrete ways to delete, merge, or reuse components while preserving the main claim. Write "NONE" if already tight.
    - **Modernization Opportunities**: 1-3 concrete ways to replace old-school pieces with more natural foundation-model-era primitives if genuinely better. Write "NONE" if already modern enough.
    - **Drift Warning**: "NONE" if the proposal still solves the anchored problem; otherwise explain the drift clearly.
    - **Verdict**: READY / REVISE / RETHINK

    Verdict rule:
    - READY: overall score >= 9, no meaningful drift, one focused dominant contribution, and no obvious complexity bloat remains
    - REVISE: the direction is promising but not yet at READY bar
    - RETHINK: the core mechanism or framing is still fundamentally off

重要：保存此次调用返回的 threadId，供后续所有轮次使用。

重要：逐字保存完整原始响应。

将评审保存到 refine-logs/round-1-review.md，并将原始响应放入 <details> 块中。

**检查点：**使用 {"phase": "review", "round": 1, "threadId": "<saved>", "last_score": <parsed>, "last_verdict": "<parsed>", ...} 更新 refine-logs/REFINE_STATE.json。

阶段 3：解析反馈并修订方法

步骤 3.1：解析评审意见

提取：

• 问题保真度
• 方法具体性
• 贡献质量
• 前沿技术杠杆
• 可行性
• 验证重点
• 投稿 venue 准备度
• 总体评分
• 评审结论
• 偏离警告
• 简化机会
• 现代化机会
• 按优先级排序的行动项

更新 refine-logs/score-history.md：

# Score Evolution

| Round | Problem Fidelity | Method Specificity | Contribution Quality | Frontier Leverage | Feasibility | Validation Focus | Venue Readiness | Overall | Verdict |
|-------|------------------|--------------------|----------------------|-------------------|-------------|------------------|-----------------|---------|---------|
| 1     | X                | X                  | X                    | X                 | X           | X                | X               | X       | REVISE  |

停止条件：如果总体评分 >= SCORE_THRESHOLD、评审结论为 READY，且没有尚未解决的偏离警告，则跳至阶段 5。

步骤 3.2：通过锚点检查和简洁性检查进行修订

进行任何更改之前：

1. 逐字复制问题锚点。
2. 编写锚点检查：
   • 原始瓶颈是什么？
   • 当前方法仍能解决它吗？
   • 哪些评审建议若盲目采纳会导致偏离？
3. 编写简洁性检查：
   • 当前的主要贡献是什么？
   • 哪些组件可以删除、合并或保持不变？
   • 哪些评审建议会增加不必要的复杂性？
   • 如果某项前沿技术是核心，其作用是否依然明确且合理？

然后处理评审反馈：

• 如果有效：强化机制，尽可能简化，或在确实能改善论文时进行现代化升级。
• 如果有争议：进行修订，但要以证据说明理由。
• 如果错误、偏离主题或过度复杂：依据本地论文和问题锚点提出异议。

修订时应优先考虑：

• 更鲜明的核心贡献
• 更少的组成部分
• 更清晰地复用强大的现有骨干
• 在有助于改善论文时，更自然地利用基础模型时代的技术优势
• 更精简、以论点为导向的实验

不要为了追求评分而加入多个并行贡献。如果评审者要求增加另一个模块，应先考虑能否通过在现有骨干上改进接口、蒸馏信号、奖励模型或推理策略，获得同样的收益。

将内容保存到 refine-logs/round-N-refinement.md：

# Round N Refinement

## Problem Anchor
[Copy verbatim from round 0]

## Anchor Check
- Original bottleneck:
- Why the revised method still addresses it:
- Reviewer suggestions rejected as drift:

## Simplicity Check
- Dominant contribution after revision:
- Components removed or merged:
- Reviewer suggestions rejected as unnecessary complexity:
- Why the remaining mechanism is still the smallest adequate route:

## Changes Made

### 1. [Method section changed]
- Reviewer said:
- Action:
- Reasoning:
- Impact on core method:

### 2. [Novelty / modernity / feasibility / validation change]
- Reviewer said:
- Action:
- Reasoning:
- Impact on core method:

## Revised Proposal
[Full updated proposal from Problem Anchor through Claim-Driven Validation Sketch]

**检查点：**使用 {"phase": "refine", "round": N, ...} 更新 refine-logs/REFINE_STATE.json。

阶段 4：重新评估（第 2 轮及后续）

将修订后的提案发回 GPT-6-Astra，且使用同一线程。同样，保持 MCP 载荷简短：创建 refine-logs/codex_round_N_review_bundle.md，写入以下重新评估说明、关键修改，以及 refine-logs/round-N-refinement.md 的绝对路径，然后请 Codex 阅读该 bundle 文件。

先解决此审阅者槽位；以下是 backend=codex 示例。

mcp__codex__codex-reply:
  threadId: [saved from Phase 2]
  # inherits the thread's model/effort — do not re-send
  prompt: |
    Read the re-evaluation bundle at <absolute path to
    refine-logs/codex_round_N_review_bundle.md> and follow all instructions in
    it.

Bundle 内容：

    [Round N re-evaluation]

    I revised the proposal based on your feedback.
    First, check whether the original Problem Anchor is still preserved.
    Second, judge whether the method is now more concrete, more focused, and more current.

    Key changes:
    1. [Method change 1]
    2. [Method change 2]
    3. [Simplification / modernization / pushback if any]

    Revised proposal path (read this file yourself): <absolute path to
    refine-logs/round-N-refinement.md>

    Please:
    - Re-score the same 7 dimensions and overall
    - State whether the Problem Anchor is preserved or drifted
    - State whether the dominant contribution is now sharper or still too broad
    - State whether the method is simpler or still overbuilt
    - State whether the frontier leverage is now appropriate or still old-school / forced
    - Focus new critiques on missing mechanism, weak training signal, weak integration point, pseudo-novelty, or unnecessary complexity
    - Use the same verdict rule: READY only if overall score >= 9 and no blocking issue remains

    Same output format: 7 scores, overall score, verdict, drift warning, simplification opportunities, modernization opportunities, remaining action items.

将审阅结果保存到 refine-logs/round-N-review.md。

检查点： 使用 {"phase": "review", "round": N, "threadId": "<saved>", "last_score": <parsed>, "last_verdict": "<parsed>", ...} 更新 refine-logs/REFINE_STATE.json。

然后返回阶段 3，直到：

• 总体评分 >= SCORE_THRESHOLD，且 verdict 为 READY，没有未解决的偏移
• 或者已达到 MAX_ROUNDS

阶段 5：最终报告和日志

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

此文件是逐轮审阅的概览记录。应说明：每轮试图解决什么、有哪些变化、解决了什么，以及还有什么未解决。

# Review Summary

**Problem**: [user's problem]
**Initial Approach**: [user's vague approach]
**Date**: [today]
**Rounds**: N / MAX_ROUNDS
**Final Score**: X / 10
**Final Verdict**: [READY / REVISE / RETHINK]

## Problem Anchor
[Verbatim anchor used across all rounds]

## Round-by-Round Resolution Log

| Round | Main Reviewer Concerns | What This Round Simplified / Modernized | Solved? | Remaining Risk |
|-------|-------------------------|------------------------------------------|---------|----------------|
| 1     | [top issues from review] | [main method changes]                    | [yes / partial / no] | [if any] |
| 2     | ...                     | ...                                      | ...     | ...            |

## Overall Evolution
- [How the method became more concrete]
- [How the dominant contribution became more focused]
- [How unnecessary complexity was removed]
- [How modern technical leverage improved or stayed intentionally minimal]
- [How drift was avoided or corrected]

## Final Status
- Anchor status: [preserved / corrected / unresolved]
- Focus status: [tight / slightly broad / still diffuse]
- Modernity status: [appropriately frontier-aware / intentionally conservative / still old-school]
- Strongest parts of final method:
- Remaining weaknesses:

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

此文件是整洁的最终版本文档。只应包含最终提案本身，不包含审阅讨论、轮次历史或审阅者原始输出。

# Research Proposal: [Title]

[Paste the final refined proposal only]

如果最终 verdict 不是 READY，仍应在此处写入当前最佳最终版本。

步骤 5.3：编写 refine-logs/REFINEMENT_REPORT.md

# Refinement Report

**Problem**: [user's problem]
**Initial Approach**: [user's vague approach]
**Date**: [today]
**Rounds**: N / MAX_ROUNDS
**Final Score**: X / 10
**Final Verdict**: [READY / REVISE / RETHINK]

## Problem Anchor
[Verbatim anchor used across all rounds]

## Output Files
- Review summary: `refine-logs/REVIEW_SUMMARY.md`
- Final proposal: `refine-logs/FINAL_PROPOSAL.md`

## Score Evolution

| Round | Problem Fidelity | Method Specificity | Contribution Quality | Frontier Leverage | Feasibility | Validation Focus | Venue Readiness | Overall | Verdict |
|-------|------------------|--------------------|----------------------|-------------------|-------------|------------------|-----------------|---------|---------|
| 1     | ...              | ...                | ...                  | ...               | ...         | ...              | ...             | ...     | ...     |

## Round-by-Round Review Record

| Round | Main Reviewer Concerns | What Was Changed | Result |
|-------|-------------------------|------------------|--------|
| 1     | [top issues]            | [main fixes]     | [resolved / partial / unresolved] |
| 2     | ...                     | ...              | ...    |

## Final Proposal Snapshot
- Canonical clean version lives in `refine-logs/FINAL_PROPOSAL.md`
- Summarize the final thesis in 3-5 bullets here

## Method Evolution Highlights
1. [Most important simplification or focusing move]
2. [Most important mechanism upgrade]
3. [Most important modernization or justification for staying simple]

## Pushback / Drift Log
| Round | Reviewer Said | Author Response | Outcome |
|-------|---------------|-----------------|---------|
| 1     | [criticism]   | [pushback + anchor / evidence] | [accepted / rejected] |

## Remaining Weaknesses
[Honest unresolved issues]

## Raw Reviewer Responses

<details>
<summary>Round 1 Review</summary>

[Full verbatim response from GPT-6-Astra]

</details>

...

## Next Steps
- If READY: proceed to `/experiment-plan` for a full experiment roadmap, then `/run-experiment`
- If REVISE: manually address the remaining mechanism weaknesses, then re-run `/research-refine`
- If RETHINK: revisit the core mechanism, possibly with `/idea-creator`

步骤 5.4：完成 score-history.md

确保其中包含使用新维度的完整评分演变表。

步骤 5.5：向用户简要汇报

Refinement complete after N rounds.

Final score: X/10 (Verdict: READY / REVISE / RETHINK)

Anchor status:
- [preserved / drift corrected / unresolved concern]

Focus status:
- [tight / slightly broad / still diffuse]

Modernity status:
- [appropriately frontier-aware / intentionally conservative / still old-school]

Key method upgrades:
- [method change 1]
- [method change 2]

Remaining concerns:
- [if any]

Review summary: refine-logs/REVIEW_SUMMARY.md
Full report: refine-logs/REFINEMENT_REPORT.md
Final proposal: refine-logs/FINAL_PROPOSAL.md
Suggested next step: /experiment-plan

检查点： 使用 {"phase": "done", "status": "completed", ...} 更新 refine-logs/REFINE_STATE.json。

输出协议

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

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

关键规则

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

• 每轮都要先锚定。 始终沿用相同的问题锚点。

• 一篇论文，一个主要贡献。 除非论文确实需要，否则避免提出多个并行贡献。

• 以足够小的机制为佳。 更大并不一定更好。

• 优先复用，而非发明。 从强大的现有骨干开始，只添加瓶颈所需的内容。

• 现代技术是先验，而非装饰。 只有在 LLM / VLM / Diffusion / RL 时代的组件能让方法更有力时才使用；不要只为让提案听起来新潮而使用。

• 实验从简。 在此技能中，实验只需证明核心主张。

• 审视机制，而非组件数量。 模块列表很长不代表有新意。

• 鼓励提出异议。 如果审阅者的反馈导致方向偏移或复杂度不必要地增加，应以证据据理力争。

• 所有 Codex 审阅调用都必须使用 config: {"model_reasoning_effort": "xhigh"}。

• 保存阶段 2 的 threadId，并在后续轮次使用 mcp__codex__codex-reply。

• 不得捏造结果。 只描述预期证据和计划开展的实验。

• 明确说明计算资源和数据假设。 含糊地说“我们会训练一个模型”是不够的。

• 记录一切。 保存每份原始审阅、每次锚点检查、每次简洁性检查，以及每项重大方法变更。

与其他技能协同

此技能位于创意探索与执行之间：

/research-refine-pipeline              -> one-shot refine + experiment planning
/idea-creator "direction"       -> candidate ideas
/research-refine "PROBLEM: ... | APPROACH: ..."  <- you are here
/experiment-plan                -> detailed experiment roadmap
/run-experiment                 -> execute the chosen method
/auto-review-loop               -> iterate on results and paper

典型流程：

1. /idea-creator 或本地阅读为你提供一个问题和模糊的方法方向
2. /research-refine 将其转化为有依据、精炼且了解前沿的方法计划
3. /experiment-plan 将最终提案转化为由主张驱动的详细实验路线图
4. 当用户希望在一次请求中完成两个阶段时，可使用 /research-refine-pipeline 一站式处理
5. /run-experiment 执行选定的运行
6. 后续迭代围绕结果展开，而不只是围绕想法

如果你已经明确问题，只需要将方法具体化，此技能也可以独立使用。