团队分工指南：建模手工作指南（深度版）

建模手是队伍的『大脑』：把现实问题翻译成数学模型，并贯穿求解到解释的全过程。

分类：👤 按角色　适用：担任建模手的队员、数学/统计背景较强的成员、负责选题与模型选型的角色

一、这个指南适合谁（适用场景）

担任建模手的队员
数学/统计背景较强的成员
负责选题与模型选型的角色

二、分工模型 / 角色清单

问题拆解：把大题拆成可建模的子问题
模型选型：评价/预测/优化/分类怎么选
假设与符号：写清前提，保证可解
推导与求解：给出可计算的数学形式
结果解释：把数字翻译成结论

三、协作的底层逻辑

建模手的核心能力不是"数学最深"，而是把模糊的现实问题结构化、可计算化的翻译能力。从信息论看，建模是一个"编码"过程：把高维、含混、带噪声的现实，压缩成一个保留判别性、且可被算法求解的数学对象（变量、约束、目标）。好的建模要在两个张力间取舍——①保真度（模型多贴近现实）与②可解性（能否在赛时限内算出可信结果）。过度保真往往不可解，过度简化则失去判别力。建模手的另一半功力在"解释"：模型产出的数字本身没有意义，只有被翻译成"这说明什么、是否稳健"的结论，才构成评委能打分的证据。所以建模手是"现实↔数学↔结论"的双向翻译器。

四、协同机制与推导

问题树的信息守恒：总目标 $G$ 分解为 $m$ 个互不重叠的子问题 $g_1,\dots,g_m$ ，其信息量满足（无冗余分解时）

$I(G)\approx\sum_{i=1}^m I(g_i)$

若分解有重叠（子问题耦合），则 $\sum I(g_i)>I(G)$ ，产生冗余推导；若有缺口，则 $\sum I(g_i)<I(G)$ ，存在漏解风险。故"先画问题树"的底层作用是保证覆盖且无重——这正是评委看"问题分析"一节时暗查的维度。

可计算性判据（规格签名）：建模手交付编程手的不是论文公式，而是可计算规格——每个符号有类型、每个公式有输入输出签名。设公式 $F$ 的输入向量 $\mathbf{x}\in\mathcal{X}$ 、输出 $y\in\mathcal{Y}$ ：

$F:\mathcal{X}\to\mathcal{Y},\quad y=F(\mathbf{x};\theta)$

当 $\mathcal{X},\mathcal{Y},\theta$ 全部明确时， $F$ 可被直接编码；任一缺失即导致编程手返工。这是"把公式写成输入X→输出Y"的硬理由。

保真—可解权衡：设模型复杂度 $c$ ，现实保真度 $f(c)$ 随 $c$ 增（边际递减），求解成本 $s(c)$ 随 $c$ 增（常超线性）。最优复杂度取

$c^*=\arg\max_c\bigl[\lambda f(c)-s(c)\bigr]$

$\lambda$ 为"保真相对求解"的偏好权重，由赛时限决定——时限越紧， $\lambda$ 越小， $c^*$ 越低（选更简单可解的模型）。这解释了"能跑出、能解释比复杂更重要"。

五、拿到题目后怎么分工与协作（流程）

先画『问题树』：总目标→子问题→每个子问题用什么方法。
选模型前想清楚『我要输出什么』（排名?预测值?方案?），再倒推方法。
假设要少而必要，每条都能在文中解释；别为了好解堆一堆不成立假设。
推导过程让编程手能『照着写代码』，变量名、公式、输入输出讲清楚。
拿到结果先自己解释：这说明什么？稳健吗？再交给写作手。

六、逐角色 / 逐环节怎么干（指南）

问题树：写在共享文档，三人可见，随时改。
模型选型：不确定就查『算法速成手册』对应条目。
与编程手对接：把公式写成『输入X→输出Y，用Z方法』的规格，别只给论文公式。
与写作手对接：每节给一句『这节核心结论』，写作手直接扩写。

七、常见坑与对策

模型越复杂越好 → 能解释、能跑出、能对比才是好模型。
只给公式不给规格 → 编程手返工。
不解释结果 → 写作手不知道写啥。
假设过度 → 评委一眼看穿不严谨。

八、分工自检清单

有可视问题树且三人共识
每个子问题有明确方法与输出
假设少且可解释
公式可翻译为代码规格
结果已自行解释并交底

九、配套资源与搭配

算法速成手册（评价/预测/优化/分类）
标准三人铁三角分工
敏感性分析与误差分析

本指南由 MCM520 资料站自动生成（深度版），配套赛题规划与论文模板可在资源页下载。

10、实战案例

案例：建模手工作流（以优化问题为例）

步骤1：问题翻译

原始描述：「最小化运输成本，满足配送需求」
→ 数学表述：min Σ c_ij * x_ij, s.t. Σ x_ij ≥ d_j

步骤2：模型选择

问题特征	推荐模型
线性目标+线性约束	线性规划 (LP)
含整数变量	整数规划 (IP)
多目标冲突	多目标优化 (MOP)
动态演化	微分方程 / 差分方程

步骤3：求解策略

小规模（n<100）：直接使用求解器（Gurobi/CPLEX）
中等规模：启发式算法（遗传/模拟退火）
大规模：简化模型或分段求解

实战案例

建模手工作实战

场景：建模手是技术核心，把实际问题翻译成数学模型。
任务：从读题到给出可求解模型文档。

完整代码（text）

工作流：
1. 问题分解：把大题拆成子问题（目标/约束/变量）
2. 模型选型：查往届类似题，选成熟方法打底
3. 公式推导：写明假设、符号、目标函数、约束
4. 可行性预演：手算小例子验证模型有意义
5. 交付伪代码：给编程手明确输入/输出/步骤

避坑：假设不要过多；先简单模型跑通再升复杂度。

运行效果

建模手产出物：

模型文档（假设+公式+符号表）
伪代码（编程手可直接转代码）
实验设计（测什么、怎么比）
质量标志：编程手拿到文档能无歧义实现。