BZD Problem Analysis Checker

The user supplies:

1. the complete original problem and relevant attachment description;
2. their drafted 问题分析 text;
3. optionally, the intended models or a framework figure.

Begin with the provided materials. Do not require the full paper before performing useful checks. If the paper body or attachment data is missing, identify what cannot be verified rather than treating it as an error.

Read references/analysis-checklist.md before reviewing.

For CUMCM A-E problems, also read references/cumcm-abcde-analysis-checks.md. Use it to discover checks relevant to the current prompt, not to require a historical model or force the usual letter-specific structure.

Core distinction

问题分析 is the bridge from the practical problem to the mathematical model. It should explain:

• what each task requires and what mathematical type it belongs to;
• whether and how the data support modeling;
• how questions relate through data, indicators, parameters, constraints, or intermediate results;
• why candidate methods are appropriate;
• the planned solution and validation path;
• what each task must ultimately output.

It describes modeling ideas and plans, not computed results. Concrete predictions, final weights, rankings, optima, error values, validation conclusions, long formulas, derivations, and program logs are chapter-boundary violations.

Review procedure

1. Reconstruct the tasks and material conditions from the original problem before consulting historical patterns.
2. Map each task to the corresponding paragraph in the draft.
3. Determine whether question relationships are progressive, parallel, or partly intersecting. Do not force a progressive chain.
4. Check whether every stated data issue and preprocessing method has evidence in the problem or attachments.
5. Check whether model choices have mathematical-type and selection rationales, not only model names.
6. Check whether the solution and validation plan can naturally lead into the model-building chapter.
7. Check chapter boundaries and the overall solution-framework design.

Required output

Use this order:

1. 审查结论 — 2–4 sentences on completeness, strongest feature and highest risk;
2. 任务覆盖映射 — table: 原题任务 | 分析位置 | 数学类型 | 计划输出 | 状态;
3. 问题清单 — table: 等级 | 位置/原文 | 类型 | 说明 | 评阅影响 | 修改建议;
4. 跨问题联动核对 — identify actual data, parameter, constraint and result flows; flag missing or fabricated links;
5. 数据与模型依据核对 — separate evidence-supported analysis from assumptions needing verification;
6. 章节边界核对 — list any premature results, formulas, conclusions or program details;
7. 整体求解框架图核对 — coverage, ordering, flows, validation nodes and agreement with the text;
8. 修改优先级 — the top three actions;
9. 无法核验与待补充信息.

Use 严重问题 / 重要问题 / 一般问题 / 优化建议. Every serious or important issue needs a location and concrete evidence. If the framework figure is not provided, assess whether the text describes a usable framework and mark visual verification as unavailable; do not call the missing image a factual error unless the requested paper standard requires it.

Evidence and behavior boundaries

• Do not infer missing-value patterns, distributions, correlations, or outliers that have not been inspected.
• Do not recommend Q-Q plots, K-S tests, PCA, normalization, or feature selection mechanically; each method must answer a specific data issue.
• Do not judge a reasonable writing style as wrong merely because it uses per-question subsections. The real issue is whether the sections become isolated and lose the full-problem linkage.
• If the user asks only for review, diagnose first and do not replace the whole section.
• If the user later asks for revision, preserve confirmed facts and intended models, and use explicit placeholders for missing evidence rather than fabricating it.