数学建模竞赛这件事我前前后后参与了六届从最开始连模型两个字该怎么写进摘要都要纠结半天到后来能带着队伍稳定完成一篇结构完整的论文中间踩过的坑比想象中多得多。很多人第一次参赛时最大的误区是以为这比赛考的是谁数学好——实际上它考的是谁能在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_ubA_ub, b_ubb_ub, boundsbounds, methodhighs) 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 关于奖项的平常心最后说点实在的。数学建模竞赛的评奖有一定偶然性同样的论文在不同评委手里可能结果不同。所以别把奖项看得太重把注意力放在这次比上次进步在哪上。建模能力、编程能力、写作能力、协作能力这些才是真正能带走的东西。我在实际操作中的体会是认真完成一次竞赛的收获远大于敷衍参加三次。把每一道题都当成一个真实项目来做从读题到交稿的每个环节都认真对待这种训练带来的成长是实实在在的。至于奖项它是水到渠成的结果而不是唯一的目标。 
长河君 · 2026/10/24 1:27:28 · 阅读 1.2k 数学建模竞赛全流程实战指南：从选题到论文的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_ubA_ub, b_ubb_ub, boundsbounds, methodhighs) 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 关于奖项的平常心最后说点实在的。数学建模竞赛的评奖有一定偶然性同样的论文在不同评委手里可能结果不同。所以别把奖项看得太重把注意力放在这次比上次进步在哪上。建模能力、编程能力、写作能力、协作能力这些才是真正能带走的东西。我在实际操作中的体会是认真完成一次竞赛的收获远大于敷衍参加三次。把每一道题都当成一个真实项目来做从读题到交稿的每个环节都认真对待这种训练带来的成长是实实在在的。至于奖项它是水到渠成的结果而不是唯一的目标。