# Problem Decomposer

> 多子问题拆解与依赖分析。触发词: 子问题拆解、拆题、problem decomposition、依赖关系、求解顺序、时间分配、并行安排。

- Skill: `best6668/problem-decomposer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add best6668/problem-decomposer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/best6668/problem-decomposer/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/problem-decomposer

---


# 多子问题拆解

执行描述: $ARGUMENTS

## Constants

- **DECOMPOSITION_FILE = `PROBLEM_DECOMPOSITION.md`** — 主输出文件，供 `model-creator`、`solve-plan`、`paper-plan` 使用。
- **INPUT_ANALYSIS_FILE = `PROBLEM_ANALYSIS.md`** — 上游赛题分析报告，作为辅助上下文。
- **DEFAULT_TOTAL_HOURS = `72`** — 默认竞赛总时长，用于建议时间分配。
- **MAX_MAIN_SUBPROBLEMS = `5`** — 主子问题建议控制在 3-5 个，超过时需要合并或降级为支撑任务。
- **MAX_CANDIDATE_TASKS = `8`** — 候选任务超过 8 个时先做聚类合并，不直接写进主报告。
- **DEPENDENCY_LEVELS = `independent|weak|strong`** — 依赖强度枚举。
- **DIFFICULTY_LEVELS = `L1|L2|L3|L4`** — 难度档位，从基础数据处理到复杂优化求解。
- **REVIEWER_MODEL = `gpt-5.4`** — Codex MCP 交叉验证模型。
- **REASONING_EFFORT = `xhigh`** — 拆解复核时统一使用高推理强度。
- **ARTIFACT_DIR = `artifacts/`** — 存放中间结构化文件，避免只留下不可追溯的自然语言结果。

## Workflow

### Phase 1: 收集题面与上游分析

Input: `$ARGUMENTS`、`PROBLEM_ANALYSIS.md`、题面原文文件。
Output: `artifacts/problem_scope.json` 与标准化题面文本。

1. 优先读取题面原文，不要只依赖 `PROBLEM_ANALYSIS.md`。
2. 如果 `$ARGUMENTS` 是文件路径，读取全文。
3. 如果 `$ARGUMENTS` 是题面摘要，再检查 `PROBLEM_BRIEF.md`、`problem.txt`、`docs/` 目录中的题面文件。
4. 读取 `PROBLEM_ANALYSIS.md`，提取上游识别出的题型、候选方法、数据范围、显式难点。
5. 扫描题面中的显式问法锚点，如"问题一""第 2 问""(3)""Question C""Task 4"。
6. 扫描隐式交付要求，如"进一步评价""提出建议""考虑不确定性""分析模型稳定性"。
7. 把题面中的对象、时间范围、空间范围、评价标准、决策目标单独摘出。
8. 标准化子问题编号格式为 `Q1`、`Q2`、`Q3`，同时保留原题面锚点。
9. 如果题面只有一个大问题但包含多个动作动词，暂时先保留为候选任务，在后续阶段再合并。
10. 记录输入来源，后续报告中要明确哪些判断来自题面，哪些来自上游分析。

```python
from pathlib import Path
import json
import re

def load_problem_text(argument: str) -> str:
    candidate = Path(argument)
    if candidate.exists() and candidate.is_file():
        return candidate.read_text(encoding="utf-8")
    for fallback in ["PROBLEM_BRIEF.md", "problem.txt", "docs/problem.md"]:
        path = Path(fallback)
        if path.exists():
            return path.read_text(encoding="utf-8")
    return argument

text = load_problem_text("PROBLEM_BRIEF.md")
patterns = [
    r"问题[一二三四五六七八九十]+",
    r"第[一二三四五六七八九十]+问",
    r"\(\d+\)",
    r"Question\s+[A-Z]",
    r"Task\s+\d+",
]
anchors = []
for pattern in patterns:
    anchors.extend(re.findall(pattern, text, flags=re.IGNORECASE))

payload = {
    "anchors": anchors,
    "length": len(text),
    "has_analysis_file": Path("PROBLEM_ANALYSIS.md").exists(),
}
Path("artifacts").mkdir(exist_ok=True)
Path("artifacts/problem_scope.json").write_text(
    json.dumps(payload, ensure_ascii=False, indent=2),
    encoding="utf-8",
)
print(payload)
```

### Phase 2: 识别显式与隐式子问题

Input: 标准化题面文本、`PROBLEM_ANALYSIS.md`。
Output: `artifacts/subproblem_candidates.json`。

1. 先做显式拆解，按题面编号、标题、列表结构切分自然子问题。
2. 再做隐式拆解，从动词和交付物中识别"建模""预测""评价""优化""分类""策略建议"等任务。
3. 合并规则遵守"同一输入、同一目标、同一输出"原则。
4. 只要目标函数不同、评价指标不同或结果用途不同，就保留为不同子问题。
5. 如果题面写"建立模型并回答以下问题"，不要把"建模"误拆成一个独立主子问题。
6. 为每个候选任务记录：`id`、`original_anchor`、`goal`、`deliverable`、`required_data`、`likely_method_family`、`upstream_results_needed`。
7. 每个候选任务必须归到四大主类型之一：`优化`、`预测`、`评价`、`分类`。
8. 可附加副标签：`仿真`、`估计`、`调度`、`鲁棒性`、`政策分析`。
9. 对 CUMCM 常见"第一问基础建模、第二问扩展、第三问优化、第四问综合建议"结构，要区分主子问题与收尾任务。
10. 对 MCM 开放题，允许识别"指标构建""核心模型""方案比较""政策分析"四层结构，但主表尽量仍控制在 3-5 个。

### Phase 3: 构建依赖关系图

Input: 候选子问题清单、题面中的依赖提示语。
Output: `artifacts/problem_dependency_graph.json` 与拓扑顺序。

1. 依赖判断优先看输出耦合，而不是题面书写顺序。
2. `independent` 表示完全独立，可直接并行。
3. `weak` 表示共享数据、变量定义或指标体系，但可先并行预研。
4. `strong` 表示必须等待上游子问题的模型结构、参数或结果。
5. 识别强依赖的常见信号："利用前一问建立的模型""在上一问结果基础上""根据前述预测结果""沿用问题一的指标体系"
6. 识别弱依赖的常见信号：共用清洗数据、共用特征工程、共用变量定义、共用同一机制解释
7. 为每条依赖边写明原因，不能只画图不解释。
8. 如果依赖图出现环，说明拆分过细或判断错误，必须回滚到 Phase 2 调整。
9. 对独立或弱依赖问题，明确标注"可并行准备"的程度。
10. 生成拓扑顺序后，为后续时间分配和团队分工服务。

### Phase 4: 标注类型、难度与建议时间分配

Input: 子问题清单、依赖图、竞赛总时间。
Output: `artifacts/problem_schedule.csv` 与推荐顺序。

1. 每个子问题同时标注主类型与难点来源，不要只写"难"或"容易"。
2. 难度分为 `L1`、`L2`、`L3`、`L4`。
3. 评估难度时考虑：数据清洗复杂度、数学模型陌生度、参数估计难度、计算资源需求、论文叙述复杂度。
4. 建议时间分配必须总和为 `100%`。
5. 若用户未指定赛时，按 `72` 小时折算小时数。
6. 时间分配不做平均主义，主基础模型与综合决策通常占比更高。
7. 对强依赖链条，上游子问题必须留缓冲。
8. 对可并行子问题，要标明可提前准备的数据处理或验证动作。
9. 推荐顺序通常遵循：先基础模型、再高收益扩展、再鲁棒性和综合建议。
10. 如果题目最后要求"综合方案"或"政策建议"，把它视为独立收尾任务并单列。

### Phase 5: 使用 Codex MCP 交叉验证拆解结果

Input: 题面原文、候选子问题、依赖图、时间分配表。
Output: 修订建议与最终拆解确认。

1. 使用 `gpt-5.4` 与 `xhigh` 推理强度做独立复盘。
2. 提示词必须包含题面原文，而不是只给摘要。
3. 明确要求外部模型检查：是否漏掉隐含子问题、是否把支撑任务误拆成主子问题、是否存在不必要的串行安排。
4. 保存 `threadId`，如果你根据建议修改了拆解，再用 `mcp__codex__codex-reply` 做二次确认。
5. 若交叉验证与你的判断冲突，以题面原文为最终裁决依据，并把原因写进报告。

```yaml
mcp__codex__codex:
  model: gpt-5.4
  config: {"model_reasoning_effort": "xhigh"}
  prompt: |
    你是数学建模竞赛指导老师，请独立审查下面的赛题拆解是否合理。

    赛题原文:
    [粘贴题面全文]

    当前拆解:
    [粘贴子问题表、依赖表、推荐顺序、时间分配]

    请逐项回答:
    1. 是否遗漏了任何应单列的子问题或综合任务？
    2. 哪些子问题可以并行，哪些必须串行？
    3. 每个子问题的主类型判断是否准确：优化 / 预测 / 评价 / 分类？
    4. 当前建议时间分配是否失衡？如果失衡，请给出更合理的比例。
    5. 给出一个更稳妥的求解顺序，并说明原因。
```

### Phase 6: Output

将最终结果写入 `PROBLEM_DECOMPOSITION.md`，必要时保留机器可读中间文件。

1. 报告开头写 4-6 句总体摘要，交代主子问题数量、可并行部分、关键阻塞链。
2. 主表必须覆盖：子问题编号、原题面锚点、任务目标、类型、难度、依赖、建议时间占比、推荐顺序。
3. 追加一张"依赖关系说明表"，每条边写明强度和原因。
4. 追加一张"并行推进建议表"，便于团队分工。
5. 追加 "Open Questions" 区块，暴露仍未完全确定的拆分点。
6. 用简短段落说明这个拆解对 `model-creator` 的约束条件。

Output files:
| 路径 | 必需 | 内容 | 说明 |
|------|------|------|------|
| `PROBLEM_DECOMPOSITION.md` | Yes | 主报告 | 提供给 `model-creator` 与 `solve-plan` |
| `artifacts/problem_scope.json` | Recommended | 题面标准化结果 | 保留题面锚点和长度信息 |
| `artifacts/subproblem_candidates.json` | Recommended | 候选子问题列表 | 支持复查与再拆解 |
| `artifacts/problem_dependency_graph.json` | Recommended | 依赖图 | 支持拓扑排序和并行安排 |
| `artifacts/problem_schedule.csv` | Recommended | 时间分配表 | 支持排班与任务跟踪 |

## Key Rules

- **大文件处理**: 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.
- 始终以题面原文为最高依据；`PROBLEM_ANALYSIS.md` 只作辅助，不作唯一真相来源。
- 主子问题一般控制在 3-5 个；超过 5 个时必须说明哪些只是支撑任务。
- 依赖判断必须写出证据句；不要凭直觉把所有问题串成一条链。
- 时间分配必须总和严格为 `100%`，并体现难度与阻塞风险。
- 如果存在明显可并行任务，必须显式标注。
- 类型标签必须落到 `优化 / 预测 / 评价 / 分类` 四类之一。
- Codex MCP 交叉验证用于复核，不用于替代人工阅读题面。
- 报告中必须保留 `Open Questions`，为下游建模暴露边界条件。

## Composing with Other Skills

```text
problem-analysis
  -> problem-decomposer
  -> model-creator
  -> feasibility-check
  -> solve-plan

problem-decomposer
  -> data-preprocessing
  -> paper-plan
```