model-formulation

name	model-formulation
description	Meta-model-agent 基于问题契约建立数学机制、公式体系、求解路线与校验方案。适用于数学机制构造与算法规划。

数学机制系统构造

稳定执行契约

• 执行目标：依据问题契约形成可计算、可验证的数学机制、公式体系和求解路线。
• 调用参数：[problem-analysis-or-topic]。
• 权威输入：问题分析.md、用户数据、适用知识库与用户约束。
• 允许交付：建模报告.md，以及必要的当前工作与状态记录。
• 禁止写入：不得越权修改已冻结的上游事实、用户原始文件或本协议未授权的目录。
• 可用工具边界：Bash(*), Read, Write, Edit, Grep, Glob, WebSearch, WebFetch, Agent。
• 最小交付：逐问模型、符号定义、假设、推导、算法、基线、验证方案与回退条件。
• 恢复入口：优先读取当前工作、状态记录和已有产物，从最近一次通过门禁的位置继续。
• 失败回退：模型无法闭合时先退回补齐变量、约束或数据；不得用文字包装不可计算的方案。
• 收口顺序：先核对输入，再完成产物，再运行本环节门禁，最后登记状态；门禁未通过不得宣告完成。

基于问题情境解构开展数学建模与求解：$ARGUMENTS

常量

• COMPETITION / PROBLEM_ID — 从 Additional Parameters 查阅

• TOOLS — 默认 python

• CUSTOM_REQUIREMENTS — 用户自定义要求

输入

1. 问题分析.md — 问题情境解构报告（务必出现）

2. 用户数据/ — 赛题附件数据

⛔⛔⛔ 完成铁律（最高优先级，违反则当前环节失败）

当前环节务必产出 建模报告.md（≥ 1.5KB，完整的建模与求解报告）。

⛔ 结束前必跑产出校验：

[ -f 建模报告.md ] && SZ=$(wc -c < 建模报告.md) || SZ=0

[ "$SZ" -ge 1500 ] && echo "✅ 建模报告.md ($SZ bytes)" \

    || echo "❌ 建模报告.md 缺失或过小 ($SZ bytes) — 必须补全后重新跑验证, 不要结束本步骤"

工作过程

工作节点 1：查阅分析报告 + 方法对照 + 防错复核

提取子问题列表、推荐方法、变量定义、数据特征。

⛔ 对照 问题分析.md 的推荐方法： 若选取了不同于推荐的方法，务必在 建模报告.md 中清晰标明阐明理由（为什么推荐方法不适用、替代方法的优势）。不可无声地忽略推荐方法。

⛔⛔⛔ 强制审视问题情境解构的"经典问题升级"结论（防止升级被忽略）：

关键要求：先完整审视问题情境解构的升级推荐 → 尽可能在建模中满足 → 如有异议务必给出充分理由。

问题情境解构阶段（Phase 5.6）会交付以下表格，建模阶段务必逐条审视：

• 覆盖度核验表（标注 ⚠️/❌ 的句子是需额外建模的机制）

• 反向对照核验（题目某句子指出需升级到某变体）

• 经典问题升级确认表（清晰标明标注"初步映射 X → 终版模型 Y"）

⛔ 实施环节：

echo "=== 审视问题情境解构的升级结论 ==="

echo ""

echo "--- 标为⚠️/❌的覆盖度缺口（需要在建模中审视是否补上）---"

grep -A 1 '⚠️\|❌' 问题分析.md | head -40

echo ""

echo "--- 经典问题升级表（需要审视是否采用最终模型）---"

sed -n '/经典问题升级/,/^##/p' 问题分析.md | head -30

echo ""

echo "--- 反向对照的升级要求 ---"

sed -n '/反向对照/,/^##/p' 问题分析.md | head -30

⛔ 三段式决策过程（各个升级推荐都务必走完）：

第一段：审视

• 逐条查阅问题情境解构的升级推荐（如 "Orienteering → Multi-Trip OP"）

• 理解升级的触发缘由（如 ASSURANCE"可充电"→多架次飞行）

• 判定升级对终版结果的影响（如不用 Multi-Trip 会导致覆盖数被严重低估）

第二段：尽可能满足（默认行为）

• 若升级在技术上可实现 → 务必采用问题情境解构推荐的变体

• 若升级增加复杂度但不超出求解能力 → 务必采用

• 若升级是题目清晰标明要求的机制（如"可充电"）→ 无论如何务必采用

第三段：有异议给理由（特殊情况）

若建模阶段认为某个升级不应采用，务必在 建模报告.md 中给出充分理由：

• 物理/业务不可行：如"题目说可充电但物理上无法实现（如太阳能电池）"

• 数据不支撑：如"题目没给充电时间参数" → ⛔ 这不是跳过升级的合法理由！务必做合理假设（如假设充电瞬时/固定X分钟/等于飞行时间的X%），随后继续建模升级版

• 超出求解能力：如"完整 Multi-Trip Stochastic OP 是 PSPACE-hard，简化为序贯单趟 OP，误差预计 < 15%"

• 评审标准考虑：如"简化后仍能回答题目的关键问题，且提升求解效率"

⛔⛔⛔ 尤其警告：以下理由不是跳过升级的合法理由（等同于无声忽略）：

• ❌ "题目未给 XXX 参数" → 应做合理假设继续建模，不是跳过

• ❌ "子问题1可简化，留给子问题2/3扩展" → 子问题1也要考虑完整机制

• ❌ "通过其他方式实现类似效果"（如"多机接力代替充电"）→ 这不等同于题目给定的机制

• ❌ "避免增加模型复杂度" → 复杂度本身不是跳过的理由

• ❌ "短续航无人机覆盖有限，就让它覆盖少" → 这恰恰是升级要解决的问题

⛔ 缺参数的无误处理过程：

1. 识别缺失的参数（如充电时间）

2. 做合理假设，假设值基于常识/文献/类似赛题

3. 在假设列表中清晰标明声明"假设 XXX = Y，依据是 Z"

4. 灵敏度分析中扰动该假设参数

5. 用假设值完整建模升级版，而不是跳过全部机制

⛔ 禁止行为：

• ❌ 无声忽略升级推荐（连"审视"都没做，直接用简单模型）

• ❌ 不读问题情境解构的 7.2/7.3 节就启动建模

• ❌ 有异议但不写理由 → 等同于无声忽略

• ❌ 用"单次XXX作为基线，后续扩展"作为借口跳过升级

• ❌ 用"题目未给参数"作为借口跳过升级

⛔ 若采用了升级的简化版本（如"简化的 Multi-Trip OP"），务必在模型中不少于保留升级的关键机制：

• Multi-Trip → 务必建模"多次访问同一 base 点"

• 带时间窗 → 务必建模"访问时刻 ∈ [a, b]"

• 随机/鲁棒 → 务必建模不少于 2 个场景并对比

• 多阶段 → 务必建模不少于 2 个阶段的转移

不可"简化"为名把升级完全去掉。

⛔ 防错复核（必做）： 查阅 参考资料/error_prevention.md，依据本题涉及的题型（优化/微分方程/统计/评价/图论/几何/动态规划），对照相应章节的"务必做"和"禁止做"条目。在 建模报告.md 末尾写一行：本题涉及题型：[X, Y, Z]，已对照防错手册审查。

工作节点 2：模型假设

各个假设务必有合理性阐明。假设要合理且必要，不做不切真实的简化。

⛔ 假设参数化原则： 关键假设务必在代码层面做成可切换的参数，而不是硬编码到逻辑里。这样发现假设错误时，改一个参数就能修正，不需重写全部求解逻辑。

在 建模报告.md 中，各个假设旁边务必写明：

假设 1: [假设内容]

  - 理由: [为什么这样假设，不能留空]

  - 参数化: [对应代码中的哪个变量/开关]

  - 替代假设: [如果这个假设不成立，替代方案是什么]

示例：

假设 3: 每类设备允许多台并行分担同一工序的工程量

  - 理由: 题目说"各类设备须分别完成该工序对应的工程量"，"各类"指设备类型而非单台设备；且问题四增加预算购买设备才有意义

  - 参数化: ALLOW_PARALLEL = True（代码中的开关变量）

  - 替代假设: 每类设备只用 1 台（ALLOW_PARALLEL = False），但这会导致问题四退化为问题三

⛔ 若某个假设写不出有力的理由，阐明这个假设需再推敲。 回到 问题分析.md 的假设预检结果重新审视。

工作节点 3：逐子问题建模

各个子问题：

1. 方法调研 — 用 WebSearch 搜索"[问题类别] 数学建模 方法"或"[problem type] optimization method"，了解这类问题的主流求解方法。避免只凭训练知识选方法——同一类问题在不同规模下最优方法可能完全不同（如 TSP 小规模用精确求解，大规模用 LKH 启发式）

2. 模型选取与理由 — 为什么选这个模型，与候选模型的优势对比，引用调研到的文献支撑

3. 数学公式推导 — 完整严谨，采用 LaTeX 数学环境（目标函数+约束条件）

4. 求解算法设计 — 伪代码或过程描述

方法选取参考 参考资料/methods_table.md。

工作节点 4：符号阐明表

保证全部公式中的符号都有定义：

| 符号 | 含义 | 单位 | 取值界限 | 首次出现 |

|------|------|------|----------|----------|

工作节点 5：模型检验与灵敏度分析设计

1. 模型检验：回代检验、交叉校验、残差分析

2. 灵敏度分析：关键参数的变化界限和影响

3. 鲁棒性检验：数据扰动下的稳定性

工作节点 5.5：⛔ 合理性预校验 + 结果预期界限表（建模完成后必做）

关键原则：物理约束 > 数据忠实度 > 计算正确性

编码阶段是纯实施者，遇到"结果不对"仅可按建模阶段的预案操作，严禁自行发明修正方法。由此建模阶段务必把全部决策做完。

实施环节：

1. 对照防错手册复核模型：重新查阅 参考资料/error_prevention.md 中本题相应题型的"务必做"和"禁止做"条目，逐条确认模型是否满足。不满足的当场调整模型。

2. 交付建模报告的 5 项必备内容（在 建模报告.md 末尾，computational-realization 务必对照实施）：

① 结果约束清单（硬边界，超出即判定代码有误）：

## 结果约束清单

- [变量名] ∈ [下界, 上界]，物理含义：[为什么是这个范围]

- [变量名] 的符号/方向约束：[说明]

- [守恒量]：[应满足的恒等式或误差上限]

② 预期行为描述（定性描述合理结果的"形状"）：

## 预期行为

- 时间尺度：系统应在 [X] 时间内达到 [什么状态]

- 稳态特征：[哪些量] 应趋于常数/周期/衰减

- 瞬态特征：[初始阶段应该看到什么现象]

- 单调性/对称性：[哪些量应该单调递增/对称/...]

③ 异常处理预案（每种异常只给一种修正方法，不留选取空间）：

## 异常处理预案

若出现 [具体异常描述]：

  → 原因判断：[最可能的原因]

  → 唯一修正方法：[具体步骤]

  → 禁止：[不允许的替代方案]

④ 方法唯一性声明（各个计算环节指定唯一方法，涵盖预处理/后处理/插值/滤波）：

## 方法指定

步骤 N：[做什么]

  方法：[唯一指定的方法名 + 关键参数]

  输入：[从哪来]

  输出：[到哪去]

  禁止替代：[不允许用的方法，以及为什么不用]

⑤ 验证检查点（编码阶段务必实施的 pass/fail checklist）：

## 验证检查点

□ [检查项]：[判定条件]，若 fail → [跳转到哪个异常预案]

□ [检查项]：[判定条件]，若 fail → [跳转到哪个异常预案]

□ 最终：所有输出量均在约束清单范围内

⑥ 优化结果结构性校验输入（优化类子问题务必给出，编码阶段的 structural_validation() 依赖这些信息）：

## 结构性验证输入（供 computational-realization 层级 5 使用）

### 约束活跃性预期

- [约束名1]：预期活跃/不活跃，理由：[为什么这个约束应该/不应该取等号]

- [约束名2]：预期活跃/不活跃，理由：[...]

- 如果所有约束都不活跃 → 说明 [什么情况]，需要 [什么操作]

### 决策变量合理范围与预期行为

| 变量 | 物理含义 | bounds | 预期取值区间 | 若取到边界说明什么 |

|------|---------|--------|-------------|------------------|

| x_1 | [含义] | [lb, ub] | [预期在哪个子区间] | [取到上界=资源耗尽/取到下界=该资源无用] |

### 灵敏度方向表

| 决策变量 | 增大时目标函数方向 | 预期灵敏度量级 | 若方向相反说明什么 |

|----------|-------------------|---------------|------------------|

| x_1 | ↓（减小=更优） | 高（主导项） | 目标函数符号写反了 |

### 稳定性预期

- 问题是凸的/非凸的？

- 预期有几个局部最优？（1个=结果应完全稳定；多个=允许 CV<5%）

- 可接受的变异系数阈值：[X]%

### 资源利用率预期

- [资源1]：预期利用率 [X%-Y%]，若为 0 说明 [什么问题]

- [资源2]：预期利用率 [X%-Y%]，若为 0 说明 [什么问题]

⛔⛔⛔ 建模阶段强制修复原则（不可跳过）：

复核中发现任何问题，务必当场修复模型再继续，不可留给 computational-realization 阶段：

• 模型缺少约束 → 立即补充约束条件

• 开环积分可能漂移 → 立即加入反馈/阻尼/去漂移机制

• 守恒律不满足 → 立即补充遗漏项

• 极端输入导致发散 → 立即加入饱和/截断/正则化

⛔ 禁止的做法：

• ❌ 发现问题但写"留给 computational-realization 阶段处理"

• ❌ 在预期界限表里写了修正方案但不调整模型本身

• ❌ 只在文字中提到"需注意XXX"但模型公式没变

⛔ 检测到问题 = 务必修复。解释缘由 ≠ 处理完毕。当前环节不准许带着已知问题交付 建模报告.md。

工作节点 6：交付

留存到 建模报告.md：模型假设、符号阐明、各个子问题的模型/公式/算法、检验方案、灵敏度分析方案、计算实验实现要点。

⛔ 务必将 问题分析.md 中的图形与表格预规划带入 建模报告.md。 在报告末尾附上图形与表格预规划章节（从 问题分析.md 复制或更新），保证 evidence-visualization 能读到完整的图形与表格清单。若建模过程中发现需额外的图形与表格（如灵敏度分析曲线、模型对比热力图），在此处补充。

⛔ MANDATORY: 交付前自检（写完 建模报告.md 后务必按项核验）：

echo "=== 建模报告自检 ==="

[ -f 建模报告.md ] || { echo "❌ 建模报告.md 不存在！"; exit 1; }

# 1. 子问题覆盖度

PROB_COUNT=$(grep -c '问题[一二三四五六七八九十0-9]' 问题分析.md 2>/dev/null || echo 0)

MODEL_SECTIONS=$(grep -c '## .*问题[一二三四五六七八九十0-9]\|## .*Problem' 建模报告.md 2>/dev/null || echo 0)

echo "赛题子问题数: $PROB_COUNT, 建模报告覆盖: $MODEL_SECTIONS"

[ "$MODEL_SECTIONS" -lt "$PROB_COUNT" ] && echo "❌ 有子问题未建模！"

# 2. 每个子问题是否有目标函数或模型公式

OBJ_COUNT=$(grep -c '目标函数\|min\|max\|最小化\|最大化\|objective\|模型公式\|数学模型' 建模报告.md 2>/dev/null || echo 0)

echo "目标函数/模型公式出现次数: $OBJ_COUNT"

[ "$OBJ_COUNT" -eq 0 ] && echo "❌ 未找到任何目标函数或模型公式！"

# 3. 约束条件（优化类必须有）

CONSTRAINT_COUNT=$(grep -c '约束\|s\.t\.\|subject to\|限制条件\|≤\|≥' 建模报告.md 2>/dev/null || echo 0)

echo "约束条件出现次数: $CONSTRAINT_COUNT"

# 4. 符号说明表是否存在

grep -q '符号.*说明\|符号.*含义\|Symbol.*Description' 建模报告.md && echo "✅ 符号说明表存在" || echo "❌ 缺少符号说明表"

# 5. 灵敏度分析方案是否存在

grep -qi '灵敏度\|sensitivity\|鲁棒性\|robustness\|稳健性' 建模报告.md && echo "✅ 灵敏度/鲁棒性分析方案存在" || echo "⚠ 缺少灵敏度分析方案（评审加分项）"

# 6. 图表预规划是否带入

grep -qi '图表预规划\|fig_\|TABLE_\|DrawIO' 建模报告.md && echo "✅ 图表预规划已带入" || echo "❌ 缺少图表预规划（evidence-visualization 步骤需要）"

# 7. 计算实验实现要点是否存在

grep -qi '编程\|实现要点\|Python\|算法步骤\|伪代码' 建模报告.md && echo "✅ 计算实验实现要点存在" || echo "⚠ 缺少计算实验实现要点（computational-realization 步骤需要）"

# 8. 问题递进性检查（最关键）

echo ""

echo "=== 问题递进性检查 ==="

echo "⛔ 人工审查：在你的模型下，每个问题的结果是否比前一个有明显变化？"

echo "   如果某个后续问题的结果和前一个几乎相同，说明模型假设可能有问题。"

echo "   特别检查：新增的变量/资源/约束是否对目标函数有边际效益？"

echo "   如果没有 → 回到 问题分析.md 的假设预检重新审视。"

# 9. 假设参数化检查

PARAM_COUNT=$(grep -c '参数化:\|ALLOW_\|ENABLE_\|USE_\|开关变量' 建模报告.md 2>/dev/null || echo 0)

echo "假设参数化标记数: $PARAM_COUNT"

[ "$PARAM_COUNT" -eq 0 ] && echo "⚠ 未找到假设参数化标记——关键假设应该在代码中做成可切换参数"

若有 ❌ 项，务必补充后再结束当前环节。⚠ 项推荐补充但不强制。

关键准则

• 公式务必严谨：各个变量定义，各个等式有推导依据

• ⛔ Markdown 中的 LaTeX 公式格式标准（保证前端能无误渲染）：

  • 块级公式：$$ 务必独立占一行，前后各空一行

  • 行内公式：用 $...$，内部避免用 _ 做下标时与 markdown 斜体冲突，复杂公式用块级

  • \begin{aligned} 等多行环境必须放在 $$...$$ 块级公式中，不要放在行内 $...$ 中

  • 避免在公式中使用 \text{} 包裹中文（KaTeX 对中文支持有限），中文说明放在公式外面

• 模型假设是评审重点：合理、必要、有说服力

• 符号阐明表务必完整

• 灵敏度分析不可省（评审加分项）

• 计算实验实现要点要具体：算法、库、输入交付格式

• ⛔ 主交付文件：建模报告.md。避免在根目录写额外报告

• ⛔ 当前环节只交付 建模报告.md，避免写 Python/MATLAB 代码文件。 代码实现是下一步 computational-realization 的工作项。当前环节只需在报告中描述算法伪代码、求解思路、计算实验实现要点即可。若需校验某个公式或做简单计算，可用 Bash 内联 Python 一次性脚本，但避免建立 程序/*.py 文件

• ⛔ 分段写入：每一次 Bash heredoc < 150 行。 建模报告.md 一般情况下很长，务必分 3-4 段追加写入（cat << 'EOF' >> 建模报告.md），避免一次性写完整个文件

⛔⛔ 建模阶段通用禁止声明

详细条目见 参考资料/error_prevention.md，以下为最高优先级的两条硬性禁止：

1. 禁止未声明的几何/物理简化 — 务必用实体完整几何作为约束判据，禁止降维简化（矩形→线段、实体→质心点）。若确需简化务必明示声明适用条件和误差上界。

2. 禁止约束遗漏 — 题目中各个"不超过/不少于/务必满足"都务必相应一个数学约束表达式。物理接触约束（不可穿透/重叠/超出边界）务必明示建模为不等式约束。