# Model Creator

> 为数模赛题生成并排序建模方案。当用户说'生成方案'、'建模方案'、'model creator'、'有什么方法可以用'时使用。

- Skill: `best6668/model-creator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add best6668/model-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/best6668/model-creator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: best6668 (https://skillmd.com/u/best6668)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/best6668/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

2. **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

3. **识别建模难点与创新空间**:
   - 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:

```markdown
# 建模方案报告

**赛题**: [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
```