Model Creator

建模方案生成器

为数模赛题生成建模方案: $ARGUMENTS

Overview

给定数模竞赛赛题，系统性地生成、验证和排序可行的建模方案。本 skill 与 /problem-analysis、/feasibility-check、/model-review 组合形成完整的建模方案发现流水线。

Constants

• VERIFY_MAX_MINUTES = 15 — Skip any quick verification estimated to take > 15 minutes. Flag as "needs manual verification".
• VERIFY_TIMEOUT_MINUTES = 20 — Hard timeout: kill verification exceeding 20 minutes. Collect partial results if available.
• MAX_VERIFY_APPROACHES = 3 — Verify at most 3 approaches in parallel. Additional approaches are validated on paper only.
• MAX_TOTAL_COMPUTE_MINUTES = 60 — Total compute budget for all verifications combined.
• REVIEWER_MODEL = gpt-5.4 — Model used via Codex MCP for brainstorming and review. Must be an OpenAI model (e.g., gpt-5.4, o3, gpt-4o).

💡 Override via argument, e.g., /model-creator "赛题" — verify budget: 20min per approach, 90min total.

Workflow

Phase 1: 赛题解读与方法检索 (5-10 min)

分析赛题结构，理解已有数据，检索适用的经典方法。

1. 读取赛题分析: Check PROBLEM_ANALYSIS.md in the project directory for existing analysis. If available, use it as baseline. If not, scan data/ and reference/ for problem context.

2. 检索经典方法 using WebSearch:

   • 数模竞赛优秀论文中对类似问题的建模方法
   • 经典教材中的标准方法（统计/优化/微分方程/图论/ML）
   • Use 5+ different query formulations
   • Read summaries of the top 10-15 relevant methods and past solutions

3. Build a method landscape map:

   • Group methods by type (统计分析/优化/微分方程/图论/机器学习/模拟仿真)
   • Identify which methods are commonly used for this type of problem
   • Note limitations and applicable conditions for each method
   • Flag creative combinations or novel applications of classic methods

4. 识别建模难点与创新空间:

   • Methods that work for similar problems but haven't been applied to this specific scenario
   • Conflicting approaches in past solutions (opportunity for improvement)
   • Standard assumptions that could be relaxed for better results
   • Data characteristics that suggest non-standard approaches
   • Sub-problems that require different methods (multi-model strategy)

Phase 2: 建模方案生成 (brainstorm with external LLM)

Use the external LLM via Codex MCP for divergent thinking:

mcp__codex__codex:
  model: REVIEWER_MODEL
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    你是一位数学建模竞赛资深指导教师，正在为参赛队伍设计建模方案。

    赛题描述: [赛题原文]

    已有分析:
    [paste method landscape map from Phase 1]

    建模难点与创新空间:
    [paste gaps from Phase 1]

    请生成 5-8 种可行的建模方案。对每种方案:
    1. 方案名称和一句话概述
    2. 核心数学方法（主方法 + 辅助方法）
    3. 最小验证实验（用最少的计算量验证方案可行性）
    4. 预期贡献类型: 精确求解 / 近似优化 / 统计预测 / 模拟仿真 / 评价决策
    5. 风险等级: LOW (经典方法，稳妥) / MEDIUM (有一定挑战) / HIGH (创新方法，有风险)
    6. 预估实现时间: 小时级 / 半天 / 一天

    优先推荐的方案应:
    - 可在个人电脑上用 Python/MATLAB 在合理时间内计算完成
    - 数学含量高（体现建模能力，不是纯数据处理）
    - 有创新点（方法组合、模型改进、新视角）
    - 与数据特征匹配（不要用数据不支持的方法）

    兼顾稳健性和创新性。一个好的方案既要能出结果，又要有亮点让评委眼前一亮。

Save the threadId for follow-up.

Phase 3: 初步筛选

For each generated approach, quickly evaluate:

1. 可行性检查: Can we actually implement and solve this with available resources?

   • 计算复杂度（预估计算分钟数）
   • 数据匹配度（现有数据能否支持该方法）
   • 实现复杂度（Python/MATLAB 是否有现成库）
   • Skip approaches requiring > 1 day of implementation or unavailable data

2. 创新性快速检查: For each approach, do 2-3 targeted searches to see if past competition papers used the same method for similar problems. Full /feasibility-check comes later for survivors.

3. 评委印象评估: Would a competition judge score this highly?

   • "数学含量" test: does the approach demonstrate solid mathematical modeling ability?
   • Is the approach well-suited to the problem structure or just a generic application?

Eliminate approaches that fail any of these. Typically 5-8 approaches reduce to 3-5.

Phase 4: 深度验证 (for top approaches)

For each surviving approach, run a deeper evaluation:

1. 可行性验证: Use the /feasibility-check workflow (data-method compatibility + compute estimation + GPT-5.4 cross-verification) for each approach

2. 评委视角审查: Use GPT-5.4 via mcp__codex__codex-reply (same thread):

   以下是筛选后的候选建模方案:
   [paste surviving approaches with feasibility check results]
   
   请以数模竞赛评委的视角审查每个方案:
   - 评委最可能提出的质疑是什么？
   - 该方案最可能的失败点在哪里？
   - 按国赛一等奖/美赛O奖标准排序，哪些方案最有竞争力？
   - 你会推荐队伍选择哪 2-3 个方案？
   

3. Combine rankings: Merge your assessment with GPT-5.4's ranking. Select top 2-3 approaches for quick verification.

Phase 5: 快速验证计算 (for top 2-3 approaches)

Before committing to a full modeling effort, run quick verification calculations to get empirical signal. This is the key differentiator from paper-only validation.

1. Design verifications: For each top approach, define the minimal calculation that would give a positive or negative signal:

   • Small data subset, simplified model (e.g., 2D instead of 3D, fewer variables)
   • Target: 5 min - VERIFY_MAX_MINUTES per verification locally
   • Estimate compute-minutes BEFORE launching. If estimated time > VERIFY_MAX_MINUTES, simplify the model or flag as "needs manual verification"
   • Clear success metric defined upfront (e.g., "if R² > 0.8 on subset, signal is positive")

2. Run locally: Use /run-solver to launch verifications on local Python/MATLAB:

   Verification 1: Approach 1 — simplified model on data subset
   Verification 2: Approach 2 — basic implementation on sample data
   Verification 3: Approach 3 — toy example to test method feasibility
   

   Use run_in_background: true to launch all at once.

3. Collect results: Use /monitor-solver to check progress. If any verification exceeds VERIFY_TIMEOUT_MINUTES, kill it and collect partial results. Once all verifications complete (or timeout), compare:

   • Which approaches showed positive signal?
   • Which showed null/negative results? (eliminate or deprioritize)
   • Any surprising findings that suggest a pivot?
   • Total compute-minutes consumed (track against MAX_TOTAL_COMPUTE_MINUTES budget)

4. Re-rank based on empirical evidence: Update the approach ranking using verification results. An approach with strong verification signal jumps ahead of a theoretically appealing but untested approach.

Note: Skip this phase if the approaches are purely analytical or if computation is not feasible yet. Flag skipped approaches as "needs verification" in the report.

Phase 6: Output — 建模方案排名报告

Write a structured report to MODEL_REPORT.md in the project root:

# 建模方案报告

**赛题**: [competition problem title]
**Generated**: [date]
**方案评估**: X generated → Y survived filtering → Z verified → W recommended

## 方法地图概要
[3-5 paragraphs on applicable methods and their suitability]

## 推荐方案 (ranked)

### 方案 1: [title]
- **核心方法**: [one sentence]
- **最小验证**: [concrete description]
- **预期效果**: [what success/failure looks like]
- **创新性**: X/10 — 最接近的已有方案: [reference]
- **可行性**: [compute, data, implementation estimates]
- **风险**: LOW/MEDIUM/HIGH
- **贡献类型**: 精确求解 / 近似优化 / 统计预测 / 模拟仿真 / 评价决策
- **验证结果**: [POSITIVE: R²=0.95 / NEGATIVE: no convergence / SKIPPED: needs full data]
- **评委可能质疑**: [strongest counterargument]
- **推荐理由**: [1-2 sentences]

### 方案 2: [title]
...

## 淘汰方案 (for reference)
| 方案 | 淘汰原因 |
|------|---------|
| ... | 数据不支持该方法 |
| ... | 计算复杂度超出时间限制 |
| ... | 数学含量不足，难以拿高分 |

## 快速验证结果
| 方案 | 环境 | 耗时 | 关键指标 | 信号 |
|------|------|------|---------|------|
| 方案 1 | Python | 8 min | R²=0.95 | POSITIVE |
| 方案 2 | Python | 5 min | RMSE=12.3 | WEAK POSITIVE |
| 方案 3 | MATLAB | 12 min | 不收敛 | NEGATIVE |

## 建议执行顺序
1. Start with 方案 1 (positive verification signal, lowest risk)
2. 方案 2 as backup (weak signal, may need parameter tuning)
3. 方案 3 eliminated by verification — negative result documented

## Next Steps
- [ ] Scale up 方案 1 to full data (complete dataset, all sub-problems)
- [ ] If confirmed, invoke /auto-optimize-loop for iterative improvement

Key Rules

• Large file handling: If the Write tool fails due to file size, immediately retry using Bash (cat << 'EOF' > file) to write in chunks. Do NOT ask the user for permission — just do it silently.

• The user provides a COMPETITION PROBLEM, not a modeling approach. Your job is to generate the approaches.

• Quantity first, quality second: brainstorm broadly, then filter ruthlessly.

• A failed verification is just as informative as a successful one. It eliminates bad approaches early and saves precious competition time.

• Don't fall in love with any approach before validating it. Be willing to kill approaches.

• Always estimate compute time. An approach that needs hours of computation is risky in a 72-hour competition.

• "Directly apply standard method X" is acceptable but won't score high. Push for creative combinations and improvements.

• Include eliminated approaches in the report — they save time by documenting what doesn't work.

• If the user's problem description is too vague (e.g., just "优化问题" without specifics), STOP and ask them to provide the full competition problem text. A good input includes the complete problem statement, available data files, and any constraints. Without sufficient specificity, generated approaches will be too generic to implement.

Composing with Other Skills

After this skill produces the ranked report:

/model-creator "赛题"          → ranked modeling approaches
/feasibility-check "top approach" → deep feasibility verification (already done in Phase 4, but user can re-run)
/model-review "top approach"   → external critical feedback from competition judge perspective
implement                      → write solver code
/run-solver                    → run locally
/auto-optimize-loop            → iterate until submission-ready for competition