model-refine

name	model-refine
description	将粗略的建模思路精炼为赛题锚定、方法聚焦、实现导向的建模方案。通过迭代 GPT-5.4 评审不断改进。当用户说"精炼方案"、"refine model"、"打磨建模方案"、"细化方案"时使用。
allowed-tools	Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Agent, mcp__codex__codex, mcp__codex__codex-reply

建模方案精炼: 赛题锚定、方法聚焦的迭代改进

Refine and concretize: $ARGUMENTS

Overview

Use this skill when the competition problem is already understood but the modeling approach is still fuzzy. The goal is not to produce a bloated proposal or a method shopping list. The goal is to turn a vague modeling idea into a 赛题 -> focused method -> minimal verification document that is concrete enough to implement, rigorous enough for a high competition score, and innovative enough to stand out.

Four principles dominate this skill:

1. Do not lose the original problem. Freeze an immutable Problem Anchor and reuse it in every round.
2. The smallest adequate mechanism wins. Prefer the minimal intervention that directly fixes the bottleneck.
3. One paper, one dominant contribution. Prefer one sharp thesis plus at most one supporting contribution.
4. Modern leverage is a prior, not a decoration. When 统计/优化/微分方程/图论/ML / 方法简化 / 推断/预测-time scaling naturally fit the bottleneck, use them concretely. Do not bolt them on as buzzwords.

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-5.4): Review for fidelity, specificity, contribution quality, and method innovation
  -> 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: /solve-plan for a detailed execution-ready experiment roadmap

Constants

• REVIEWER_MODEL = gpt-5.4 — Reviewer model used via Codex MCP.
• MAX_ROUNDS = 5 — Maximum review-revise rounds.
• SCORE_THRESHOLD = 9 — Minimum overall score to stop.
• OUTPUT_DIR = refine-logs/ — Directory for round files and final report.
• MAX_LOCAL_REFS = 10 — Maximum local references to scan for grounding.
• MAX_CORE_VALIDATIONS = 3 — Default cap for core verification blocks inside this skill.
• MAX_PRIMARY_CLAIMS = 2 — Soft cap for paper-level claims. Prefer one dominant claim plus one supporting claim.
• MAX_NEW_MODEL_COMPONENTS = 2 — Soft cap for genuinely new model components. Exceed only if the modeling approach breaks otherwise.

Override via argument if needed, e.g. /model-refine "problem | approach" -- max rounds: 3, threshold: 9.

State Persistence (Checkpoint Recovery)

Long-running refinement sessions may fail mid-way (e.g., API timeout, context compaction, or session interruption). To avoid losing completed work, persist state to refine-logs/REFINE_STATE.json after each phase boundary:

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

Field definitions:

Field	Values	Meaning
phase	"anchor" / "proposal" / "review" / "refine" / "done"	Last completed phase
round	0–MAX_ROUNDS	Current round number
threadId	string or null	Reviewer thread ID for codex-reply continuity
last_score	number or null	Most recent overall score from reviewer
last_verdict	string or null	Most recent verdict (READY / REVISE / RETHINK)
status	"in_progress" / "completed"	Loop status
timestamp	ISO 8601	When state was last written

Write rules:

• Write after each phase completes (not before). Overwrite each time — only the latest state matters.
• On completion (Phase 5 finished), set "status": "completed".

Output Structure

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

Every round-N-refinement.md must contain a full anchored proposal, not just incremental fixes.

Workflow

Initialization (Checkpoint Recovery)

Before starting any phase, check whether a previous run left a checkpoint:

1. Check for refine-logs/REFINE_STATE.json:

   • If it does not exist → fresh start (proceed to Phase 0 normally)
   • If it exists AND status is "completed" → fresh start (delete state file, previous run finished)
   • If it exists AND status is "in_progress" AND timestamp is older than 24 hours → fresh start (stale state from a killed/abandoned run — delete the file)
   • If it exists AND status is "in_progress" AND timestamp is within 24 hours → resume

2. On resume, read the state file and recover context:

   • Read all existing refine-logs/round-*.md files to restore prior work
   • Read refine-logs/score-history.md if it exists
   • Recover threadId for reviewer thread continuity
   • Log to the user: "Checkpoint found. Resuming after phase: {phase}, round: {round}."
   • Jump to the next phase based on the saved phase value:

   Saved phase	What was completed	Resume from
   "anchor"	Phase 0 done	Phase 1 (read anchor from round-0 context)
   "proposal"	Phase 1 done	Phase 2 (read round-0-initial-proposal.md)
   "review"	Phase 2 or 4 done	Phase 3 (read latest round-N-review.md)
   "refine"	Phase 3 done	Phase 4 (read latest round-N-refinement.md)

3. On fresh start, ensure refine-logs/ directory exists and proceed to Phase 0.

Phase 0: Freeze the Problem Anchor

Before proposing anything, extract the user's immutable bottom-line problem. This anchor must be copied verbatim into every proposal and every refinement round.

Write:

• Bottom-line problem: What technical problem must be solved?
• Must-solve bottleneck: What specific weakness in current methods is unacceptable?
• Non-goals: What is explicitly not the goal of this project?
• Constraints: Compute, data, time, tooling, competition, deployment limits.
• Success condition: What evidence would make the user say "yes, this method addresses the actual problem"?

If later reviewer feedback would change the problem being solved, mark that as drift and push back or adapt carefully.

Checkpoint: Write refine-logs/REFINE_STATE.json with {"phase": "anchor", "round": 0, "threadId": null, "last_score": null, "last_verdict": null, "status": "in_progress", "timestamp": "<now>"}.

Phase 1: Build the Initial Proposal

Step 1.1: Scan Grounding Material

Check papers/ and literature/ first. Read only the relevant parts needed to answer:

• What mechanism do current methods use?
• Where exactly do they fail for this problem?
• Which recent 统计/优化/微分方程/图论/ML era techniques are actually relevant here?
• What 求解 objectives, representations, or interfaces are reusable?
• What details distinguish a real method from a renamed high-level idea?

If local material is insufficient, search recent top-competition/数模论文库 work online. Focus on method sections, 求解 setup, and failure modes, not just abstracts.

Step 1.2: Identify the Technical Gap

Do not stop at generic research questions. Make the gap operational:

1. Current pipeline failure point: where does the baseline break?
2. Why naive fixes are insufficient: larger context, more data, prompting, memory bank, or stacking more modules.
3. Smallest adequate intervention: what is the least additional mechanism that could plausibly fix the bottleneck?
4. 创新方法 alternative: is there a more current route using 数模竞赛 primitives that better matches the bottleneck?
5. Core technical claim: what exact mechanism claim could survive top-competition scrutiny?
6. Required evidence: what minimum proof is needed to defend that claim?

Step 1.3: Choose the Sharpest Route

Before locking the method, compare two candidate routes if both are plausible:

• Route A: Elegant minimal route — the smallest mechanism that directly targets the bottleneck.
• Route B: 创新方法 route — a more modern route that uses 统计/优化/微分方程/图论/ML / 方法简化 / 推断/预测-time scaling only if it gives a cleaner or stronger story.

Then decide:

• Which route is more likely to become a strong paper under the stated constraints?
• Which route has the cleaner novelty story relative to the closest work?
• Which route avoids contribution sprawl?

If both routes are weak, rethink the framing instead of combining them into a larger system by default.

Step 1.4: Concretize the Method First

The proposal must answer "how would we actually build this?" Prefer method detail over broad experimentation and prefer reuse over invention.

Cover:

1. One-sentence method thesis: the single strongest mechanism claim.
2. Contribution focus: one dominant contribution and at most one supporting contribution.
3. Complexity budget: what is 固定 or reused, what is new, and what tempting additions are intentionally excluded.
4. System graph: modules, data flow, inputs, outputs.
5. Representation design: what latent, embedding, plan token, reward signal, memory state, or alignment space is used?
6. 求解 recipe: data source, supervision, pseudo-labeling, negatives, curriculum, losses, weighting, stagewise vs joint 求解.
7. Inference path: how the 求解完成 components are used at test time and what signals flow where.
8. Why the mechanism stays small: why a larger stack is unnecessary.
9. Exact role of any 创新 primitive: if you use an 统计/优化/微分方程/图论/ML component, specify whether it acts as planner, teacher, critic, reward model, generator prior, search controller, or 方法简化 source.
10. Failure handling: what could go wrong and what fallback or diagnostic exists?
11. Novelty and elegance argument: why this is more than naming a module and why the paper still looks focused.

If the method is still only described as "add a module" or "use a planner," it is not concrete enough.

Step 1.5: Design Minimal Claim-Driven Validation

Experiments exist to validate the method, not to dominate the document.

For each core claim, define the smallest strong experiment that can validate it:

• the claim being tested
• the necessary baseline or ablation
• the decisive metric
• the expected directional outcome

Additional rules:

• Ensure one experiment block directly supports the Problem Anchor.
• If complexity risk exists, include one simplification or deletion check.
• If a 创新 primitive is central, include one necessity check showing why that choice matters.
• Default to 1-3 core experiment blocks and leave the full execution roadmap to /solve-plan.

Step 1.6: Write the Initial Proposal

Save to refine-logs/round-0-initial-proposal.md.

Use this structure:

# 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 数模竞赛方法体系:

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

## Proposed Method
### Complexity Budget
- 固定 / reused 基础模型框架:
- New 可调 components:
- Tempting additions intentionally not used:

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

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

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

### Modern Primitive Usage
- Which 统计/优化/微分方程/图论/ML-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 固定, what is 可调, 推断/预测 order]

### 求解 Plan
[Stagewise or joint 求解, 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 compute-minutes:
- Data / annotation cost:
- Timeline:

Checkpoint: Update refine-logs/REFINE_STATE.json with {"phase": "proposal", "round": 0, ...}.

Phase 2: External Method Review (Round 1)

Send the full proposal to GPT-5.4 for an elegance-first, 方法创新, method-first review. The reviewer should spend most of the critique budget on the method itself, not on expanding the experiment menu.

mcp__codex__codex:
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    You are 数模竞赛资深评委/阅卷专家.
    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 数模竞赛 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 统计/优化/微分方程/图论/ML 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 ===
    [Paste the FULL proposal from Phase 1]
    === END PROPOSAL ===

    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, 求解 stages, and 推断/预测 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. **Method Innovation**: Does the proposal use current 数模竞赛 primitives appropriately when they are the right tool, instead of defaulting to old-school module stacking?

    5. **Feasibility**: Can this method be 求解完成 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. **Competition Readiness**: If executed well, would the contribution feel sharp and timely enough for a top competition award?