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 ```