problem-decomposer

name	problem-decomposer
description	多子问题拆解与依赖分析。触发词: 子问题拆解、拆题、problem decomposition、依赖关系、求解顺序、时间分配、并行安排。
argument-hint	["competition-problem-or-problem-file"]
allowed-tools	Bash(*), Read, Write, Edit, Grep, Glob, Agent, mcp__codex__codex, mcp__codex__codex-reply

多子问题拆解

执行描述: $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. 记录输入来源，后续报告中要明确哪些判断来自题面，哪些来自上游分析。

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. 若交叉验证与你的判断冲突，以题面原文为最终裁决依据，并把原因写进报告。

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

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

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