数学建模竞赛全流程实战指南：从选题到论文的72小时

数学建模竞赛这件事，我前前后后参与了六届，从最开始连"模型"两个字该怎么写进摘要都要纠结半天，到后来能带着队伍稳定完成一篇结构完整的论文，中间踩过的坑比想象中多得多。很多人第一次参赛时最大的误区，是以为这比赛考的是"谁数学好"——实际上它考的是"谁能在72小时内把一道模糊的现实问题，翻译成一套能自圆其说的数学语言，再用一篇论文把它讲清楚"。数学功底只是入场券，真正拉开差距的是建模思路的组织能力、代码实现的效率、以及论文写作的表达力。这篇内容就是把这套全流程拆开来讲，从读题、选模型、写代码、做检验，一直到论文的排版和摘要打磨，适合第一次参赛的新手，也适合参加过一两次但总卡在某个环节的队伍参考。我会尽量把每一步"为什么这么做"讲透，而不是只丢一堆步骤给你。

1. 竞赛的时间账本：72小时到底该怎么切

1.1 先算清楚你真正能用的时间

很多人一上来就埋头读题，结果第一天结束还在纠结选哪道题。我建议先把72小时当成一个项目来管理。扣掉睡觉、吃饭、开会讨论的时间，真正高效产出的时间大概只有40到45小时。这三天的分配我实测下来比较稳的比例是：选题与读题4小时，建模方案确定6小时，编程实现与数据处理15小时，结果分析与模型检验8小时，论文撰写与排版10小时，最后留2到3小时做通读和摘要打磨。

这个分配的核心逻辑是：论文写作必须留足时间，而且不能压到最后一天才开始。我见过太多队伍前两天代码跑得飞起，第三天下午才开始写论文，最后交上去的东西逻辑断裂、图表混乱。正确的做法是从第一天确定模型框架后，就同步开始写论文的框架和背景部分，让写作和建模并行推进。

1.2 选题不是选"看起来简单"的那道

选题环节有个反直觉的经验：不要选看起来数据最全、背景最熟悉的那道题。因为你觉得熟悉，别人也觉得熟悉，这类题往往竞争最激烈，评委看多了同质化的解法，反而难出彩。真正值得考虑的是那种"背景陌生但问题结构清晰"的题——你能快速抓住它的数学本质，而大部分人还在查背景资料。

具体判断标准我总结成三条：第一，题目问的问题能不能用你熟悉的模型族覆盖（比如优化、微分方程、统计回归、图论）；第二，数据是否够用，缺数据时能不能合理假设补上；第三，有没有明确的评价指标让你验证结果好坏。三条里满足两条以上，这道题就值得选。

提示：选题讨论不要超过4小时。我见过队伍争论到第一天晚上还没定题，后面全线崩盘。定题后如果发现走不通，最晚在第一天结束前换题，再晚就来不及了。

2. 从现实问题到数学语言：建模的翻译过程

2.1 建模的本质是"做假设"而不是"套公式"

新手最容易犯的错，是拿到题就开始想"这题该用哪个模型"。正确的顺序恰恰相反：先把现实问题里的关键因素列出来，再决定用什么数学工具描述它们之间的关系。举个例子，如果题目涉及某类资源在多个节点间的调度，你要先问自己：节点容量有限制吗？调度有先后顺序吗？目标是总成本最小还是总时间最短？把这些问清楚了，模型自然就浮出来了——可能是线性规划，也可能是网络流。

假设是建模的灵魂。任何模型都是对现实的简化，你必须明确写出"我假设了什么"。比如假设某类变化率是常数、假设各因素相互独立、假设数据无系统性偏差。这些假设不是随便写的，每一条都要能解释"为什么这样假设是合理的"，并且在后面的模型检验里说明"如果假设不成立会怎样"。

2.2 模型选型的对照思路

下面这张表是我常用的模型选型参考，按问题类型归类，方便快速定位：

选型时不要贪多。我见过一篇论文里塞了五六个模型，结果每个都讲不透。一个主模型加一到两个辅助模型验证，比堆砌模型更有说服力。主模型负责给出核心结论，辅助模型用来交叉验证或者做敏感性分析。

2.3 把假设、符号、模型写成一条清晰的链

建模部分在论文里的呈现顺序应该是：问题分析 → 模型假设 → 符号说明 → 模型建立 → 模型求解。这条链要环环相扣。符号说明尤其重要，很多论文败在这里——前面用了一个符号，后面又换了含义，评委看得一头雾水。

我的习惯是建一个符号表，所有符号在表里定义一次，全文统一。符号命名尽量有含义，比如用 $C_{total}$ 表示总成本，用 $x_{ij}$ 表示从节点i到节点j的流量，比用 $a$、$b$、$c$ 强太多。这一步花不了多少时间，但能极大提升论文的可读性。

3. 代码实现：让模型真正跑起来的那部分

3.1 工具选择要看队伍的实际能力

工具选型没有绝对的对错，关键看队伍里谁写代码、写得多熟。常见组合是 Python 加科学计算库，或者 MATLAB。Python 的优势是生态全、免费、数据处理方便；MATLAB 的优势是矩阵运算和内置工具箱成熟，写优化和微分方程求解很顺手。

我的建议是：如果队伍里有人 Python 熟练，就用 Python；如果大家都只学过 MATLAB，就别硬上 Python。竞赛期间现学工具是大忌，时间根本不够。下面是一个 Python 求解线性规划的典型骨架，用 scipy 就能跑：

from scipy.optimize import linprog import numpy as np # 目标函数系数（求最小值） c = [3, 5, 2] # 不等式约束 A_ub @ x <= b_ub A_ub = [[1, 2, 1], [2, 1, 3]] b_ub = [10, 15] # 变量下界 bounds = [(0, None), (0, None), (0, None)] res = linprog(c, A_ub=A_ub, b_ub=b_ub, bounds=bounds, method='highs') print("最优值:", res.fun) print("最优解:", res.x)

这段代码的价值在于它展示了"模型到代码"的映射关系：目标函数对应c，约束对应A_ub和b_ub，变量范围对应bounds。写代码时脑子里要始终清楚每一行对应模型里的哪一部分，这样调试起来才快。

3.2 数据处理是最容易被低估的环节

真实竞赛题给的数据往往不干净：有缺失值、有异常点、量纲不统一。数据处理花掉的时间经常超过建模本身。我的处理顺序是：先做描述性统计看数据分布，再处理缺失值（能补就补，不能补就说明并剔除），然后处理异常值（用箱线图或三倍标准差法识别），最后做标准化或归一化。

标准化这一步很多人忽略，但它直接影响结果。如果不同变量的量纲差异大（比如一个是金额上万，一个是比例零点几），不标准化会让数值大的变量主导模型。常用的标准化方法是 Z-score 标准化和 Min-Max 归一化，前者适合数据近似正态分布的情况，后者适合需要压缩到固定区间的情况。

注意：所有数据处理的步骤都要在论文里写清楚，包括你用了什么方法、为什么用、处理前后的数据量变化。评委很看重这个过程的严谨性。

3.3 结果的可视化不是"好看"而是"说清楚"

图表在论文里的作用是替你把结论讲清楚，不是为了好看。我见过太多论文堆了一堆花哨的图，但每张图想说明什么完全看不出来。正确的做法是：每张图都要有明确的"任务"——这张图是为了展示趋势、对比方案、还是验证假设？

常用的图类型和用途：折线图看趋势变化，柱状图做方案对比，散点图看变量相关性，热力图看矩阵型数据，箱线图看分布和异常。画图时注意坐标轴要有标签和单位，图例要清晰，标题要能概括图的内容。如果一张图需要看半天才能理解，那它就没完成任务。

4. 模型检验：让结论站得住脚的关键一步

4.1 敏感性分析是必做项

敏感性分析的意思是：改变模型里的某个参数，看结果变化大不大。如果某个参数稍微一动，结论就完全变了，说明这个模型不稳定，结论不可靠。这一步是区分"认真做的论文"和"随便跑跑的论文"的重要标志。

具体做法是选几个关键参数，让它们在一定范围内变动（比如上下浮动10%或20%），观察目标值的变化幅度。可以用表格呈现，也可以用折线图展示。如果结果对参数不敏感，说明模型稳健；如果敏感，就要在论文里讨论原因，并说明在什么条件下结论成立。

4.2 误差分析和模型对比

误差分析要回答两个问题：你的模型结果和真实情况差多少？这个差距来自哪里？差距可能来自数据误差、模型简化、算法精度等。把这些来源分析清楚，比单纯报一个误差数字有价值得多。

模型对比则是拿你的主模型和另一个方法做对照。比如你用回归做了预测，可以再用时间序列做一遍，看两者结果是否接近。如果接近，说明结论可信；如果差异大，就要分析原因。这种交叉验证的思路能让论文的说服力上一个台阶。

4.3 常见检验方法速查

这张表建议在建模阶段就对照着规划，别等到最后才发现漏了某项检验。

5. 论文撰写：把72小时的工作讲成一个完整故事

5.1 摘要决定评委的第一印象

摘要是整篇论文最重要的部分，没有之一。评委时间有限，往往先看摘要决定要不要细读。摘要要在一页以内把四件事说清楚：研究了什么问题、用了什么方法、得到了什么结果、结论有什么意义。这四件事对应摘要的四个层次，缺一不可。

写摘要的常见错误是写成"流水账"，比如"我们首先分析了问题，然后建立了模型，最后求解了"。这种写法没有任何信息量。正确的写法要具体，比如"针对某类资源调度问题，建立了以总成本最小为目标的整数规划模型，采用分支定界法求解，得到最优调度方案使总成本降低约18%"。

摘要里的数字要具体，方法要明确，结论要有支撑。我建议摘要最后写，但要在论文主体完成后反复打磨三遍以上。

5.2 论文结构的标准骨架

一篇规范的竞赛论文通常包含这些部分：摘要、问题重述、问题分析、模型假设、符号说明、模型建立与求解、模型检验、模型评价与推广、参考文献、附录。这个顺序不是随便定的，它遵循"提出问题—分析问题—解决问题—验证问题"的逻辑。

问题重述不是抄题，而是用自己的话把问题重新组织一遍，突出你关注的核心。问题分析要展示你的思考过程，说明为什么选这个方向。模型评价要客观，既讲优点也讲不足，只讲优点的评价反而显得不真诚。附录放代码和详细数据，正文里放核心结果。

5.3 排版和格式的细节坑

排版这件事看起来小，但直接影响阅读体验。几个我踩过的坑：公式编号不连续、图表编号和正文引用对不上、参考文献格式不统一、页眉页脚混乱。这些都要在最后通读时逐一检查。

公式用公式编辑器写，别用图片代替，否则缩放会糊。图表要有编号和标题，正文里要引用到，比如"如图3所示"。参考文献按统一格式列，正文引用处标上序号。这些细节做好了，论文的专业感立刻不一样。

提示：最后留出至少2小时做通读。通读时重点检查三件事：逻辑是否连贯、符号是否统一、图表是否都引用了。很多低级错误都是通读时才能发现。

6. 团队协作：三个人怎么拧成一股绳

6.1 角色分工要明确但不能僵化

典型的三人队伍分工是：一人主攻建模、一人主攻编程、一人主攻写作。但这个分工不能太死。建模的人要懂代码逻辑，编程的人要理解模型意图，写作的人要能看懂结果。理想状态是三个人都能理解整体方案，只是各有侧重。

我建议每天固定开两次短会：早上定当天目标，晚上复盘进度。会议要短，控制在15分钟内，只讲三件事：昨天完成了什么、今天要做什么、遇到什么卡点。这样能保证信息同步，避免有人闷头做了一天发现方向错了。

6.2 版本管理和文件命名

三个人同时改论文，最容易出现版本混乱。我的做法是用云文档协作，或者约定一个文件命名规则，比如"论文_v1_日期_修改人"。每次大改前先备份，别在同一个文件上反复覆盖。

代码也要管理好。主程序、数据文件、结果输出分开放，别全堆在一个文件夹里。关键代码要写注释，尤其是别人可能看不懂的部分。竞赛期间时间紧，但花几分钟写注释能省下后面大量的沟通成本。

6.3 心态管理：别在第二天崩溃

72小时高强度作战，第二天下午往往是士气最低谷。这时候如果模型跑不出结果、论文写不下去，很容易互相埋怨。我的经验是提前打好预防针：告诉队友"第二天下午大概率会很难受，这是正常的"。遇到卡点时，先停下来一起理一遍思路，而不是各自硬扛。

还有个小技巧：不管进度多紧，保证每天睡够5到6小时。通宵换来的效率损失，往往比多睡两小时更大。我见过通宵后第二天脑子转不动的队伍，反而拖慢了整体进度。

7. 赛后复盘：比拿奖更重要的事

7.1 把论文当成作品反复看

比赛结束后，隔一周再回头看自己的论文，你会发现很多当时没注意到的问题。这个复盘过程比比赛本身更有价值。重点看三件事：摘要是否说清了核心、模型逻辑是否有漏洞、论文表达是否有歧义。把这些问题记下来，下次就能避开。

我建议把每次参赛的论文都存档，形成自己的"论文库"。下次参赛前翻一翻，看看哪些结构可以复用、哪些错误不能再犯。这种积累是实打实的进步。

7.2 建立自己的模型和代码库

竞赛用到的模型和代码，赛后整理成模板存起来。比如线性规划的求解模板、数据标准化的函数、常用图表的绘制代码。下次遇到类似问题，直接调用改参数就行，能省下大量时间。

这个库不用多复杂，一个文件夹加几个注释清晰的脚本就够。关键是养成积累的习惯。我见过很多队伍每次参赛都从零开始，效率极低。而那些稳定出成绩的队伍，往往都有自己的工具箱。

7.3 关于奖项的平常心

最后说点实在的。数学建模竞赛的评奖有一定偶然性，同样的论文在不同评委手里可能结果不同。所以别把奖项看得太重，把注意力放在"这次比上次进步在哪"上。建模能力、编程能力、写作能力、协作能力，这些才是真正能带走的东西。

我在实际操作中的体会是：认真完成一次竞赛的收获，远大于敷衍参加三次。把每一道题都当成一个真实项目来做，从读题到交稿的每个环节都认真对待，这种训练带来的成长是实实在在的。至于奖项，它是水到渠成的结果，而不是唯一的目标。