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