# Modeling Discovery

> Workflow 1: 完整的建模方案发现流水线。编排 problem-analysis → model-creator → feasibility-check → model-review，从赛题到验证过的建模方案。当用户说'找方案全流程'、'建模方案发现'、'从零开始建模'时使用。

- Skill: `best6668/modeling-discovery` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add best6668/modeling-discovery`
- Raw SKILL.md: https://api.skillmd.com/api/skills/best6668/modeling-discovery/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: best6668 (https://skillmd.com/u/best6668)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/best6668/modeling-discovery

---


# Workflow 1: 建模方案发现流水线

Orchestrate a complete modeling discovery workflow for: **$ARGUMENTS**

## Overview

This skill chains sub-skills into a single automated pipeline:

```
/problem-analysis → /model-creator → /feasibility-check → /model-review → /model-refine-pipeline
  (survey)      (brainstorm)    (verify novel)    (critical feedback)  (refine method + plan experiments)
```

Each phase builds on the previous one's output. The final deliverables are a validated `MODEL_REPORT.md` with ranked 建模方案, plus a refined proposal (`refine-logs/FINAL_PROPOSAL.md`) and experiment plan (`refine-logs/SOLVE_PLAN.md`) for the top 建模方案.

## Constants

- **VERIFY_MAX_MINUTES = 15** — Skip any 快速验证 estimated to take > 15 minutes locally. Flag as "needs manual 验证" in the report.
- **VERIFY_TIMEOUT_MINUTES = 20** — Hard timeout: kill any running 验证 that exceeds 20 minutes. Collect partial results if available.
- **MAX_VERIFY_APPROACHES = 3** — Run 验证s for at most 3 top approaches in parallel. Additional 建模方案 are validated on paper only.
- **MAX_TOTAL_COMPUTE_MINUTES = 60** — Total compute budget across all 验证s. If exceeded, skip remaining 验证s and note in report.
- **AUTO_PROCEED = true** — If user doesn't respond at a checkpoint, automatically proceed with the best option after presenting results. Set to `false` to always wait for explicit user confirmation.
- **REVIEWER_MODEL = `gpt-5.4`** — Model used via Codex MCP. Must be an OpenAI model (e.g., `gpt-5.4`, `o3`, `gpt-4o`). Passed to sub-skills.
- **METHOD_SEARCH_DEPTH = standard** — When `true`, `/problem-analysis` downloads the top relevant 参考资料 during Phase 1. When `false` (default), only fetches metadata. Passed through to `/problem-analysis`.
- **COMPACT = false** — When `true`, generate compact summary files for short-context models and session recovery. Writes `MODEL_CANDIDATES.md` (top 3-5 建模方案 only) at the end of this workflow. Downstream skills read this instead of the full `MODEL_REPORT.md`.
- **REF_METHOD = false** — 参考方法 to base 建模方案 on. Accepts: local PDF path, 方法参考链接, or any paper URL. When set, the paper is summarized first (`REF_METHOD_SUMMARY.md`), then 建模方案 generation uses it as context. Combine with `base repo` for "improve this paper with this codebase" workflows.

> 💡 These are defaults. Override by telling the skill, e.g., `/modeling-discovery "topic" — ref method: https://method-search.org/abs/2406.04329` or `/modeling-discovery "topic" — compact: true`.

## Pipeline

### Phase 0: Load 赛题描述 (if available)

Before starting any other phase, check for a detailed 赛题描述 in the project:

1. Look for `PROBLEM_BRIEF.md` in the project root (or path passed as `$ARGUMENTS`)
2. If found, read it and extract:
   - Problem statement and context
   - Constraints (compute, data, timeline, venue)
   - What the user already tried / what didn't work
   - Domain knowledge and non-goals
   - Existing results (if any)
3. Use this as the primary context for all subsequent phases — it replaces the one-line prompt
4. If both `PROBLEM_BRIEF.md` and a one-line `$ARGUMENTS` exist, merge them (brief takes priority for details, argument sets the direction)

If no brief exists, proceed normally with `$ARGUMENTS` as the 赛题描述.

> 💡 Create a brief from the template: `cp templates/PROBLEM_BRIEF_TEMPLATE.md PROBLEM_BRIEF.md`

### Phase 0.5: 参考方法概要 (when REF_METHOD is set)

**Skip entirely if `REF_METHOD` is `false`.**

Summarize the 参考方法 before searching the 参考资料:

1. **If 方法参考链接** (e.g., `https://method-search.org/abs/2406.04329`):
   - Invoke `/method-search "ARXIV_ID" — download` to fetch the PDF
   - Read the first 5 pages (title, abstract, intro, method overview)

2. **If local PDF path** (e.g., `papers/reference.pdf`):
   - Read the PDF directly (first 5 pages)

3. **If other URL**:
   - Fetch and extract content via WebFetch

4. **Generate `REF_METHOD_SUMMARY.md`**:

```markdown
# 参考方法概要

**Title**: [paper title]
**Authors**: [authors]
**Venue**: [venue, year]

## What They Did
[2-3 sentences: core method and contribution]

## Key Results
[Main quantitative findings]

## Limitations & Open Questions
[What the paper didn't solve, acknowledged weaknesses, future work suggestions]

## Potential Improvement Directions
[Based on the limitations, what could be improved or extended?]

## Codebase
[If `base repo` is also set: link to the repo and note which parts correspond to the paper]
```

**🚦 Checkpoint:** Present the summary to the user:

```
📄 参考方法 summarized:
- Title: [title]
- Key limitation: [main gap]
- Improvement directions: [2-3 bullets]

Proceeding to 赛题分析 with this as context.
```

Phase 1 and Phase 2 will use `REF_METHOD_SUMMARY.md` as additional context — `/problem-analysis` searches for related and competing work, `/model-creator` generates 建模方案 that build on or improve the 参考方法.

### Phase 1: 赛题分析与方法检索

Invoke `/problem-analysis` to map the 方法地图:

```
/problem-analysis "$ARGUMENTS"
```

**What this does:**
- Search 数模优秀论文库, CNKI, 经典教材 for recent papers
- Build a landscape map: sub-directions, approaches, open problems
- Identify structural gaps and recurring limitations
- Output a 参考资料 summary (saved to working notes)

**🚦 Checkpoint:** Present the landscape summary to the user. Ask:

```
📚 Literature survey complete. Here's what I found:
- [key findings, gaps, open problems]

Does this match your understanding? Should I adjust the scope before generating 建模方案?
(If no response, I'll proceed with the top-ranked direction.)
```

- **User approves** (or no response + AUTO_PROCEED=true) → proceed to Phase 2 with best direction.
- **User requests changes** (e.g., "focus more on X", "ignore Y", "too broad") → refine the search with updated queries, re-run `/problem-analysis` with adjusted scope, and present again. Repeat until the user is satisfied.

### Phase 2: 建模方案 Generation + Filtering + 验证s

Invoke `/model-creator` with the landscape context (and `REF_METHOD_SUMMARY.md` if available):

```
/model-creator "$ARGUMENTS"
```

**What this does:**
- If `REF_METHOD_SUMMARY.md` exists, include it as context — 建模方案 should build on, improve, or extend the 参考方法
- Brainstorm 8-12 concrete 建模方案 via GPT-5.4 xhigh
- Filter by feasibility, compute cost, quick 可行性 search
- Deep validate top 建模方案 (full 可行性检查 + devil's advocate)
- Run parallel 快速验证s on available 本地计算 (top 2-3 建模方案)
- Rank by empirical signal
- Output `MODEL_REPORT.md`

**🚦 Checkpoint:** Present `MODEL_REPORT.md` ranked 建模方案 to the user. Ask:

```
💡 Generated X 建模方案, filtered to Y, 验证ed Z. Top results:

1. [建模方案 1] — 验证: POSITIVE (+X%)
2. [建模方案 2] — 验证: WEAK POSITIVE (+Y%)
3. [建模方案 3] — 验证: NEGATIVE, eliminated

Which 建模方案 should I validate further? Or should I regenerate with different constraints?
(If no response, I'll proceed with the top-ranked 建模方案.)
```

- **User picks 建模方案** (or no response + AUTO_PROCEED=true) → proceed to Phase 3 with top-ranked 建模方案.
- **User unhappy with all 建模方案** → collect feedback ("what's missing?", "what direction do you prefer?"), update the prompt with user's constraints, and re-run Phase 2 (建模方案 generation). Repeat until the user selects at least 1 建模方案.
- **User wants to adjust scope** → go back to Phase 1 with refined direction.

### Phase 3: Deep 可行性 Verification

For each top 建模方案 (positive 验证信号), run a thorough 可行性检查:

```
/feasibility-check "[top 建模方案 1 description]"
/feasibility-check "[top 建模方案 2 description]"
```

**What this does:**
- Multi-source 参考资料 search (数模论文库, Scholar, Semantic Scholar)
- Cross-verify with GPT-5.4 xhigh
- Check for concurrent work (last 3-6 months)
- Identify closest existing work and differentiation points

**Update `MODEL_REPORT.md`** with deep 可行性 results. Eliminate any 建模方案 that turns out to be already published.

### Phase 4: External Critical Review

For the surviving top 建模方案(s), get brutal feedback:

```
/model-review "[top 建模方案 with hypothesis + 验证结果]"
```

**What this does:**
- GPT-5.4 xhigh acts as a senior reviewer (数模竞赛评委水准)
- Scores the 建模方案, identifies weaknesses, suggests minimum viable improvements
- Provides concrete feedback on experimental design

**Update `MODEL_REPORT.md`** with reviewer feedback and revised plan.

### Phase 4.5: Method Refinement + Experiment Planning

After review, refine the top 建模方案 into a concrete proposal and plan experiments:

```
/model-refine-pipeline "[top 建模方案 description + 验证结果 + reviewer feedback]"
```

**What this does:**
- Freeze a **Problem Anchor** to prevent scope drift
- Iteratively refine the method via GPT-5.4 review (up to 5 rounds, until score ≥ 9)
- Generate a claim-driven experiment roadmap with 灵敏度分析s, budgets, and run order
- Output: `refine-logs/FINAL_PROPOSAL.md`, `refine-logs/SOLVE_PLAN.md`, `refine-logs/SOLVE_TRACKER.md`

**🚦 Checkpoint:** Present the refined proposal summary:

```
🔬 Method refined and experiment plan ready:
- Problem anchor: [anchored problem]
- Method thesis: [one sentence]
- Dominant contribution: [what's new]
- Must-run experiments: [N blocks]
- First 3 runs to launch: [list]

Proceed to implementation? Or adjust the proposal?
```

- **User approves** (or AUTO_PROCEED=true) → proceed to Final Report.
- **User requests changes** → pass feedback to `/model-refine` for another round.
- **Lite mode:** If reviewer score < 6 or 验证 was weak, run `/model-refine` only (skip `/solve-plan`) and note remaining risks in the report.

### Phase 5: Final Report

Finalize `MODEL_REPORT.md` with all accumulated information:

```markdown
# 建模方案发现报告

**Direction**: $ARGUMENTS
**Date**: [today]
**Pipeline**: problem-analysis → model-creator → feasibility-check → model-review → model-refine-pipeline

## Executive Summary
[2-3 sentences: best 建模方案, key evidence, recommended next step]

## Literature Landscape
[from Phase 1]

## Ranked 建模方案
[from Phase 2, updated with Phase 3-4 results]

### 🏆 建模方案 1: [title] — RECOMMENDED
- 验证: POSITIVE (+X%)
- 可行性: CONFIRMED (closest: [paper], differentiation: [what's different])
- Reviewer score: X/10
- Next step: implement full experiment → /auto-optimize-loop

### 建模方案 2: [title] — BACKUP
...

## Eliminated 建模方案
[建模方案 killed at each phase, with reasons]

## Refined Proposal
- Proposal: `refine-logs/FINAL_PROPOSAL.md`
- Experiment plan: `refine-logs/SOLVE_PLAN.md`
- Tracker: `refine-logs/SOLVE_TRACKER.md`

## Next Steps
- [ ] /run-solver to deploy experiments from the plan
- [ ] /auto-optimize-loop to iterate until 可提交
- [ ] Or invoke /mathmodel-pipeline for the complete end-to-end flow
```

### Phase 5.5: Write Compact Files (when COMPACT = true)

**Skip entirely if `COMPACT` is `false`.**

Write `MODEL_CANDIDATES.md` — a lean summary of the top 3-5 surviving 建模方案:

```markdown
# 建模方案候选

| # | 建模方案 | 验证 Signal | 可行性 | Reviewer Score | Status |
|---|------|-------------|---------|---------------|--------|
| 1 | [title] | +X% | Confirmed | X/10 | RECOMMENDED |
| 2 | [title] | +Y% | Confirmed | X/10 | BACKUP |
| 3 | [title] | Negative | — | — | ELIMINATED |

## Active 建模方案: #1 — [title]
- Hypothesis: [one sentence]
- Key evidence: [验证 result]
- Next step: /solve-bridge or /model-refine
```

This file is intentionally small (~30 lines) so downstream skills and session recovery can read it without loading the full `MODEL_REPORT.md` (~200+ lines).

## 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.

- **Don't skip phases.** Each phase filters and validates — skipping leads to wasted effort later.
- **Checkpoint between phases.** Briefly summarize what was found before moving on.
- **Kill 建模方案 early.** It's better to kill 10 bad 建模方案 in Phase 3 than to implement one and fail.
- **Empirical signal > theoretical appeal.** An 建模方案 with a positive 验证 outranks a "sounds great" 建模方案 without evidence.
- **Document everything.** Dead ends are just as valuable as successes for future reference.
- **Be honest with the reviewer.** Include negative results and failed 验证s in the review prompt.
- **Feishu notifications are optional.** If `~/.claude/feishu.json` exists, send `checkpoint` at each phase transition and `pipeline_done` at final report. If absent/off, skip silently.

## Composing with Workflow 2

After this pipeline produces a validated top 建模方案:

```
/modeling-discovery "direction"         ← you are here (Workflow 1, includes method refinement + experiment planning)
/run-solver                     ← deploy experiments from the plan
/auto-optimize-loop "top 建模方案"        ← Workflow 2: iterate until 可提交

Or use /mathmodel-pipeline for the full end-to-end flow.
```