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