# Solve Plan

> 将建模方案转化为详细的求解计划。子问题驱动的求解步骤、灵敏度分析、计算时间预算。当用户说"求解计划"、"solve plan"、"怎么求解"时使用。

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

---


# 求解计划: 子问题驱动的求解路线图

生成求解计划: **$ARGUMENTS**

## Overview

Use this skill after the modeling approach is stable enough that the next question becomes: **what exact calculations should we run, in what order, to solve each sub-problem?** If the user wants the full chain in one request, prefer `/model-refine-pipeline`.

The goal is not to generate a giant analysis wishlist. The goal is to turn a modeling approach into a **子问题 -> 方法 -> 求解顺序** roadmap that supports four things:

1. the approach actually solves the competition problem
2. each sub-problem has a clear mathematical method
3. the approach is implementable within competition time constraints
4. sensitivity analysis and model validation are planned

## Constants

- **OUTPUT_DIR = `refine-logs/`** — Default destination for 求解计划文件.
- **MAX_PRIMARY_SUBPROBLEMS = 5 — Maximum sub-problems to plan for.
- **MAX_CORE_BLOCKS = 5 — Keep the must-run solving blocks compact.
- **MAX_ALTERNATIVE_METHODS = 3 — Prefer a few strong alternative methods for comparison.
- **DEFAULT_RUNS = 3 — Use 3 runs when stochastic variance matters (e.g., Monte Carlo).

## Workflow

### Phase 0: Load the Proposal Context

Read the most relevant existing files first if they exist:

- `refine-logs/FINAL_PROPOSAL.md`
- `refine-logs/REVIEW_SUMMARY.md`
- `refine-logs/REFINEMENT_REPORT.md`

Extract:

- **Problem Anchor**
- **Dominant contribution**
- **Optional supporting contribution**
- **Critical 评委 concerns**
- **Data / compute / timeline constraints**
- **Which 创新 primitive is central, if any**

If these files do not exist, derive the same information from the user's prompt.

### Phase 1: Freeze the Paper Claims

Before proposing experiments, write down the claims that must be defended.

Use this structure:

- **Primary claim**: the main mechanism-level contribution
- **Supporting claim**: optional, only if it directly strengthens the main 论文逻辑
- **Anti-claim to rule out**: e.g. "the gain only comes from more parameters," "the gain only comes from a larger search space," or "the modern component is just decoration"
- **Minimum convincing evidence**: what would make each claim believable to a strong 评委?

Do not exceed `MAX_PRIMARY_CLAIMS` unless the paper truly has multiple inseparable claims.

### Phase 2: Build the Experimental Storyline

Design the paper around a compact set of 求解模块. Default to the following blocks and delete any that are not needed:

1. **Main anchor result** — does the method solve the actual bottleneck?
2. **方法对比验证** — does the dominant contribution itself matter?
3. **Simplicity / elegance check** — can a bigger or more fragmented version be avoided?
4. **Frontier necessity check** — if an 创新数学方法 component is central, is it actually the right tool?
5. **Failure analysis or qualitative diagnosis** — what does the method still miss?

For each block, decide whether it belongs in:

- **论文正文** — essential to defend the core claims
- **附录** — useful but non-blocking
- **Cut** — interesting, but not worth the 论文篇幅

Prefer one strong baseline family over many weak baselines. If a stronger modern baseline exists, use it instead of padding the list.

### Phase 3: Specify Each Experiment Block

For every kept block, fully specify:

- **Claim tested**
- **Why this block exists**
- **Dataset / split / task**
- **Compared systems**: strongest baselines, 灵敏度分析s, and variants only
- **Metrics**: decisive metrics first, secondary metrics second
- **Setup details**: 基础框架, 固定 vs 可调 parts, key hyperparameters, 计算预算, 随机种子
- **Success criterion**: what outcome would count as convincing evidence?
- **Failure interpretation**: if the result is negative, what does it mean?
- **Table / figure target**: where this result should appear in the paper

Special rules:

- A **simplicity check** should usually compare the final method against either an overbuilt variant or a tempting extra component that the paper intentionally rejects.
- A **创新方法必要性检查** should usually compare the chosen modern primitive against the strongest plausible simpler or older alternative.
- If the proposal is intentionally non-创新, say so explicitly and skip the 创新 block instead of forcing one.

### Phase 4: Turn the Plan Into an Execution Order

Build a realistic run order so the user knows what to do first.

Use this milestone structure:

1. **Sanity stage** — data pipeline, metric correctness, one quick overfit or toy split
2. **Baseline stage** — reproduce the strongest baseline(s)
3. **Main method stage** — run the final method on the primary setting
4. **Decision stage** — run the decisive 灵敏度分析s for 创新性, simplicity, and 创新 necessity
5. **Polish stage** — robustness, qualitative figures, appendix extras

For each milestone, estimate:

- compute cost
- expected turnaround time
- stop / go decision gate
- risk and mitigation

Separate **must-run** from **nice-to-have** experiments.

### Phase 5: Write the Outputs

#### Step 5.1: Write `refine-logs/SOLVE_PLAN.md`

Use this structure:

```markdown
# 求解计划

**Problem**: [problem]
**Method Thesis**: [one-sentence thesis]
**Date**: [today]

## Claim Map
| Claim | Why It Matters | Minimum Convincing Evidence | Linked Blocks |
|-------|-----------------|-----------------------------|---------------|
| C1    | ...             | ...                         | B1, B2        |

## Paper Storyline
- 论文正文 must prove:
- 附录 can support:
- Experiments intentionally cut:

## 求解模块

### Block 1: [Name]
- Claim tested:
- Why this block exists:
- Dataset / split / task:
- Compared systems:
- Metrics:
- Setup details:
- Success criterion:
- Failure interpretation:
- Table / figure target:
- Priority: MUST-RUN / NICE-TO-HAVE

### Block 2: [Name]
...

## Run Order and Milestones
| Milestone | Goal | Runs | Decision Gate | Cost | Risk |
|-----------|------|------|---------------|------|------|
| M0        | ...  | ...  | ...           | ...  | ...  |

## Compute and Data Budget
- Total estimated compute-minutes:
- Data preparation needs:
- Human evaluation needs:
- Biggest bottleneck:

## Risks and Mitigations
- [Risk]:
- [Mitigation]:

## Final Checklist
- [ ] 论文正文 tables are covered
- [ ] Novelty is isolated
- [ ] Simplicity is defended
- [ ] Frontier contribution is justified or explicitly not claimed
- [ ] Nice-to-have runs are separated from must-run runs
```

#### Step 5.2: Write `refine-logs/SOLVE_TRACKER.md`

Use this structure:

```markdown
# 求解追踪

| Run ID | Milestone | Purpose | System / Variant | Split | Metrics | Priority | Status | Notes |
|--------|-----------|---------|------------------|-------|---------|----------|--------|-------|
| R001   | M0        | sanity  | ...              | ...   | ...     | MUST     | TODO   | ...   |
```

Keep the tracker compact and execution-oriented.

#### Step 5.3: Present a Brief Summary to the User

```
Experiment plan ready.

Must-run blocks:
- [Block 1]
- [Block 2]

Highest-risk assumption:
- [risk]

First three runs to launch:
1. [run]
2. [run]
3. [run]

Plan file: refine-logs/SOLVE_PLAN.md
Tracker file: refine-logs/SOLVE_TRACKER.md
```

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

- **Every experiment must defend a claim.** If it does not change a 评委 belief, cut it.
- **Prefer a compact 论文逻辑.** Design the main table first, then add only the 灵敏度分析s that defend it.
- **Defend simplicity explicitly.** If complexity is a concern, include a deletion study or a stronger-but-bloated variant comparison.
- **Defend 创新 choices explicitly.** If a modern primitive is central, prove why it is better than the strongest simpler alternative.
- **Prefer strong baselines over long baseline lists.** A short, credible comparison set is better than a padded one.
- **Separate must-run from nice-to-have.** Do not let appendix ideas delay the core paper evidence.
- **Reuse proposal constraints.** Do not invent unrealistic budgets or data assumptions.
- **Do not fabricate results.** Plan evidence; do not claim evidence.

## Composing with Other Skills

```
/model-refine-pipeline -> one-shot method + 求解计划ning
/model-refine   -> method and claim refinement
/solve-plan   -> detailed 求解路线图
/run-solver    -> execute the runs
/auto-optimize-loop  -> react to results and iterate on the paper
```