MathorCup数学建模竞赛全流程实战指南：从优化建模到论文写作

1. 从“妈妈杯”到实战：一份写给建模新手的深度参赛指南

如果你正在为2026年的MathorCup数学建模挑战赛（圈内人常亲切地称之为“妈妈杯”）做准备，或者对数学建模竞赛跃跃欲试，那么这篇文章就是为你准备的。我参加过多次数学建模竞赛，也指导过不少队伍，深知从零开始备赛的迷茫与拿到题目时的无措。MathorCup作为国内颇具影响力的数学建模赛事，其题目往往紧扣前沿科技与社会热点，兼具理论深度与应用广度，对参赛者的综合能力是极佳的考验。这篇文章不会给你一份空洞的“万能模板”，而是试图拆解一套从赛前准备、赛中解题到赛后复盘的全流程实战策略，并结合历年典型赛题，为你提供可复现的解题思路、论文撰写心法以及代码资源的管理逻辑。无论你是初次参赛的“小白”，还是希望突破瓶颈的“老手”，都能从中找到有价值的参考。

2. 赛前准备：构建你的“建模武器库”

很多队伍一上来就急着找算法、看论文，这其实是本末倒置。扎实的赛前准备，是你在72小时高压比赛中保持清醒、高效产出的基石。这个阶段的核心是构建一个属于你们队伍的、立即可用的“武器库”。

2.1 团队角色与协作模式的固化

三人队伍最常见的角色分工是建模、编程、写作。但我的经验是，这种分工不能僵化，更理想的状态是“主攻+辅助+全能补位”。建模手需要对各类模型（优化、预测、评价、仿真等）的原理、适用场景和优缺点如数家珍，他的核心能力是快速将实际问题抽象为数学问题。编程手不应只是代码打字员，而应是“算法实现与数据处理的专家”，精通至少一门科学计算语言（如Python/Matlab），并对常用库（如NumPy, Pandas, Scikit-learn, Gurobi等）有实战经验。写作者是团队的“首席产品经理”，负责将思路和结果转化为逻辑严谨、表达清晰的论文，他必须深刻理解建模的全过程，才能写出有灵魂的论文。

注意：最致命的错误是三个人各干各的。我们团队的做法是，从备赛期开始，就强制进行“交叉评审”。建模手要向写作者解释模型，写作者要对着代码跑出的结果向编程手提问。这个过程能暴露出大量理解偏差和逻辑漏洞，是提升团队默契的关键。

2.2 核心技能树的针对性点亮

根据MathorCup近年赛题趋势（如2025年A题“新能源城市配送优化”、历年国赛C题等），以下几个技能点必须重点打磨：

1. 优化建模与求解能力：这是MathorCup和国赛的绝对核心。你必须掌握线性规划、整数规划、非线性规划的基本模型，并知道如何用PuLP（Python）、Gurobi、MATLAB Optimization Toolbox等工具求解。更重要的是，要能识别问题中的决策变量、目标函数和约束条件，这是将文字描述转化为数学方程的第一步。
2. 数据分析与机器学习基础：数据预处理（缺失值、异常值处理）、特征工程、以及经典的回归、分类、聚类算法（如线性回归、决策树、K-Means）必须会用。虽然复杂深度学习模型在短时竞赛中不常用，但像Scikit-learn这样的库提供了快速实现经典算法的途径。
3. 评价模型与仿真能力：当问题涉及方案比较时，综合评价方法（如AHP层次分析法、TOPSIS法、熵权法）就是你的利器。对于动态、随机性问题（如排队论、元胞自动机），掌握基础仿真思路比精通某个复杂软件更重要。
4. 文献检索与快速学习能力：72小时内，你很可能需要快速了解一个陌生领域（如“波浪能最大输出功率设计”、“煤矿巷道支护”）的基本原理和关键参数。熟练使用知网、Google Scholar、arXiv等平台，并具备快速阅读学术论文摘要和结论部分的能力，至关重要。

2.3 资源库的标准化建设

不要在比赛时才开始找模板、下代码。建立一个团队共享的云端文件夹（如坚果云、OneDrive），并标准化其结构：

MathorCup_2026_Team_Resource/ ├── 01_论文模板/ │ ├── MathorCup官方Word模板.docx │ ├── LaTeX模板（含常用宏包）/ │ └── 历年优秀论文精选（分析其结构）/ ├── 02_代码仓库/ │ ├── Python基础工具包/ │ │ ├── data_preprocessing.py (数据清洗、标准化函数) │ │ ├── evaluation_metrics.py (各种评价指标计算) │ │ └── visualization.py (绘图函数，如热力图、三维图) │ ├── 经典算法实现/ │ │ ├── optimization/ (线性规划、遗传算法示例) │ │ ├── machine_learning/ (回归、分类、聚类示例) │ │ └── evaluation/ (AHP, TOPSIS, 熵权法示例) │ └── 第三方求解器/ │ ├── Gurobi安装与配置指南.md │ └── 常用API速查.md ├── 03_数据资源/ │ ├── 中国统计年鉴（近五年）/ │ └── 公开数据集链接（如Kaggle, UCI）清单.md └── 04_历届赛题分析/ ├── 2025_MathorCup_A题_新能源配送_思路拆解.md ├── 2024_国赛C题_思路与代码参考/ └── 问题分类索引.md (将问题归类为优化、预测、评价等)

这个资源库的价值在于，比赛时你可以像在自家仓库取工具一样，快速找到所需模块，极大节省时间。

3. 72小时实战：拆解解题全流程与核心策略

拿到赛题的那一刻，真正的战斗开始。这72小时是智力、体力和协作能力的综合考验。下面我以一个虚构的、但融合了历年赛题特点的题目为例，展示我们的实战流程。假设题目为：“某城市共享单车智能调度优化研究”——给定历史骑行数据、站点分布、车辆状况，要求设计动态调度方案以最小化运营成本并最大化用户满意度。

3.1 第一天上午（0-6小时）：破题、定调与任务分解

前6小时决定了论文的生死。切忌一上来就埋头编程或查文献。

1. 集体精读题目（1小时）：三人一起，逐字逐句阅读题目，每人用不同颜色的笔在打印出的题目上划出关键词：“共享单车”、“调度”、“优化”、“成本”、“满意度”、“动态”。讨论并统一对每一个术语的理解。例如，“动态”是指按小时、按天还是实时？ “满意度”如何量化？是等待时间、步行距离还是车辆可用性？
2. 问题重述与分解（2小时）：将庞大的原问题分解为几个逻辑递进或并列的子问题。这是我们团队的分解示例：
   • 子问题一（数据分析与需求预测）：基于历史数据，建立各站点在不同时段（早高峰、晚高峰、平峰）的借车/还车需求预测模型。
   • 子问题二（静态调度模型）：在已知全天预测需求的情况下，设计每日凌晨的初始车辆投放方案（哪个站点放多少车），使得初始状态最优。
   • 子问题三（动态调度模型）：在运营过程中，根据实时需求偏差和车辆分布，设计动态调度车（卡车）的路径规划方案，何时、何地、调度多少车辆，以应对潮汐现象。
   • 子问题四（综合评价与仿真）：建立成本-满意度综合评价体系，并设计仿真程序，对比不同调度策略的效果。
3. 文献速览与思路碰撞（2小时）：根据子问题，分工进行快速文献检索。搜索关键词如“bike-sharing repositioning problem”、“demand forecasting”、“vehicle routing problem”。目标不是精读，而是快速获取：1）这类问题通常用什么模型（如需求预测用时间序列或机器学习，路径规划用VRP模型）；2）关键参数有哪些（如调度成本、用户等待时间成本）；3）有无开源代码或数据可以参考。用1小时开会，分享检索结果，确定每个子问题的初步技术路线。
4. 制定详细计划与开始写作（1小时）：将72小时划分为几个阶段，明确每个时间节点的交付物。写作者立即开始撰写论文的“问题重述”、“模型假设”、“符号说明”部分。这部分不依赖具体模型，可以尽早完成，并为后续内容定下清晰的框架。

3.2 第一天下午至第二天全天（6-48小时）：模型构建、求解与迭代

这是攻坚阶段，也是最容易产生分歧和陷入困境的时期。

1. 并行开发与日间同步：建模手和编程手紧密配合，针对子问题一和子问题二开始工作。

   • 子问题一（预测模型）：尝试多种模型对比。例如，对每个站点，可以先用ARIMA（时间序列）做基准，再用LightGBM或XGBoost（机器学习）引入天气、工作日等特征进行预测。编程手快速实现这些模型，并用历史数据的一部分进行训练和验证，比较MAE、RMSE等指标。关键不是追求最复杂的模型，而是快速得到一个可用的、能解释的预测结果。
   • 子问题二（静态调度）：这本质上是一个网络流优化问题。我们可以将其建模为一个整数线性规划模型。
     • 决策变量：x_ij表示从站点i调度到站点j的自行车数量。
     • 目标函数：最小化总调度成本（与调度距离和数量成正比） + 惩罚项（预测需求与调度后库存的偏差）。
     • 约束条件：车辆守恒（调度走的车等于调度来的车）、车辆总数守恒、非负整数约束等。
     • 求解：使用Gurobi或PuLP（对于小规模问题）进行求解。编程手负责将数学模型“翻译”成求解器能识别的代码。
   • 写作者同步撰写“模型建立”部分，描述预测模型和静态调度模型的数学公式，并开始绘制技术路线图或模型框架图。

2. 夜间整合与模型衔接：第一天晚上，必须完成前两个子问题的初步结果，并开始思考它们的衔接。例如，将子问题一的预测结果，作为子问题二模型的输入参数。此时可能会发现预测结果不理想，需要回头调整特征或模型参数，这是一个正常的迭代过程。

3. 攻克核心难点（子问题三）：动态调度是本题的难点和亮点。它比静态问题复杂得多，因为调度车本身也在移动，且需求是随时间变化的。一个可行的简化思路是采用滚动时域优化：

   • 将一天划分为多个时段（如每2小时一个时段）。
   • 在每个时段开始时，根据当前各站点的车辆库存和未来短期（如下两个时段）的需求预测，为调度车规划一个当前时段内的最优路径（一个带时间窗的车辆路径问题，VRPTW）。
   • 求解这个VRPTW问题，可以使用启发式算法，如遗传算法或模拟退火算法，因为精确求解在有限时间内可能不现实。编程手需要实现或调整一个现有的VRP算法框架。
   • 执行本时段的调度，然后时间推进到下一个时段，重复上述过程。
   • 写作者需要清晰地阐述这个“滚动优化”的逻辑，并用流程图加以说明。

4. 可视化与中间结果分析：编程手在产出数据结果的同时，必须同步生成可视化图表。例如：各站点需求预测的时序图、静态调度方案的网络流图、动态调度车的路径动画示意图等。这些图表是论文的“眼睛”，能让评委快速理解你的工作。

3.3 第三天（48-72小时）：论文冲刺、模型检验与收尾

最后一天是论文的成型和打磨期，心态容易焦躁，必须严格执行计划。

1. 完成模型求解与仿真（子问题四）：设计一个简单的仿真程序。输入：你的静态和动态调度策略。模拟：用户随机到达、借车、还车的过程。输出：一系列运营指标，如平均用户等待时间、车辆闲置率、调度总里程等。同时，可以设计一个对比实验，例如：对比“仅静态调度”、“静态+动态调度”和“无调度”三种策略的仿真结果。用表格和对比柱状图清晰展示。
2. 模型检验与灵敏度分析（至关重要！）：这是区分普通论文和优秀论文的关键。你需要检验模型的稳健性。
   • 灵敏度分析：改变关键参数（如调度车的单位成本、用户等待时间的惩罚系数），观察目标函数和最优解的变化。如果最优解对某个参数极其敏感，就需要在论文中讨论其现实意义，或说明如何更准确地估计该参数。
   • 模型对比：如果你的动态调度用了启发式算法，可以将其结果与一个简化版的精确解（在小规模问题上）进行对比，说明启发式算法的有效性和效率。
3. 论文全文整合与精修：写作者在此阶段承担核心压力。
   • 填充所有章节：将“模型求解”、“结果分析”、“模型检验”等内容填入论文。
   • 撰写摘要：摘要是一篇论文的灵魂，必须最后写，但要用最多的时间打磨。好的摘要应独立成篇，包含：问题背景、你的主要思路、所用模型、求解方法、主要结论和模型亮点。避免空洞的形容词，用数据和事实说话。例如：“本文针对共享单车动态调度问题，提出了一个融合需求预测与滚动时域优化的两阶段优化框架。首先，利用XGBoost模型预测站点级时段需求，准确率达85%；进而建立整数规划模型确定初始投放方案；最后，基于滚动时域和遗传算法，设计动态调度路径。仿真结果表明，相较于无调度方案，本模型可将用户平均等待时间降低40%，同时减少15%的调度总成本。”
   • 检查逻辑流：通读全文，确保从问题重述到模型建立，到求解分析，逻辑链条完整、自洽。
   • 格式与细节：检查图表编号、引用、公式格式、参考文献格式。一个排版精美、细节无误的论文，能给评委留下极好的第一印象。
4. 最终检查与提交：留出至少2小时进行最终检查。三人交叉检查：编程手检查结果数据和图表是否与论文描述一致；建模手检查模型描述是否准确；写作者进行最后的语法和格式校对。确认所有文件（论文PDF、支撑材料、代码压缩包）按要求命名并提交。

4. 论文撰写心法：如何让评委“看懂”并“认可”

数学建模论文的本质是一份技术报告，它的目标是清晰、准确、有说服力地展示你的工作。文笔优美是加分项，但逻辑严谨才是生命线。

4.1 结构为王：遵循标准但突出亮点

标准的论文结构（问题重述、假设、符号、模型建立、求解、检验、结论）必须完整。但在这些框架内，你要学会“藏”亮点。

• 在“模型建立”部分：不要平铺直叙地罗列模型。要用一个小节叫“模型整体框架”，用一张技术路线图（如流程图）来统领全局，让评委一眼就明白你的解题逻辑。例如，可以画一张图，展示从“数据输入”到“预测模型”，到“静态优化”，再到“动态滚动优化”，最后到“仿真输出”的完整流程。
• 在“模型求解”部分：除了说“我们用遗传算法求解”，更要说明为什么用遗传算法（因为问题是NP-Hard，精确求解耗时），关键参数怎么设（种群大小、交叉变异概率的设置依据），以及算法具体如何适配本问题（染色体如何编码、适应度函数如何定义）。这体现了你对工具的深刻理解，而非简单套用。

4.2 图表说话：一图胜千言

• 结果可视化：趋势用折线图，分布用柱状图或箱线图，关联用散点图或热力图，网络关系用网络图，地理信息用地图。确保每个图表都有自解释的标题和清晰的图例。
• 模型示意图：对于复杂的模型或算法，一张示意图的价值巨大。例如，解释滚动时域优化时，画一条时间轴，标明每个“优化窗口”和“执行窗口”，评委瞬间就懂了。
• 表格归纳：对比不同方案的结果、展示灵敏度分析数据、列出模型参数，多用三线表格，简洁明了。

4.3 表达精准：杜绝模糊与夸大

• 慎用“我们”：虽然常用，但避免通篇“我们”。可以直接描述客观过程，如“首先对数据进行标准化处理，以消除量纲影响”。
• 量化描述：不要说“模型效果很好”，要说“模型预测的均方根误差（RMSE）降低了20%”。不要说“调度方案更优”，要说“该方案在保证用户满意度不低于90%的前提下，将总成本降低了15%”。
• 承认不足：在结论或模型检验部分，可以客观指出模型的局限性，例如：“本模型假设用户需求是确定性的，未来可考虑引入随机性进行更精细的建模。” 这体现了科学的严谨性，反而是加分项。

5. 代码与资源：不只是附件，而是复现性的证明

提交的代码和资源包，是支撑你论文结论的“证据链”。混乱的代码会让评委怀疑你结果的真实性。

5.1 代码组织的艺术

一个优秀的代码仓库应该像一篇可执行的论文。

BikeSharing_Optimization/ ├── README.md # 项目总说明：问题、环境、如何运行 ├── requirements.txt # Python依赖包列表 ├── data/ │ ├── raw/ # 原始数据 │ └── processed/ # 清洗后的数据 ├── src/ │ ├── 01_data_preprocessing.py │ ├── 02_demand_forecasting.py │ ├── 03_static_scheduling.py │ ├── 04_dynamic_routing.py │ └── 05_simulation_evaluation.py ├── results/ │ ├── figures/ # 生成的所有图表 │ └── tables/ # 生成的结果数据表 └── main.py # 主运行脚本，按顺序调用各模块

README.md文件必须详细，应包含：1）项目简介；2）运行环境配置指南（如Python 3.8+， 安装pip install -r requirements.txt）；3）数据准备说明；4）运行步骤（如python main.py）；5）各模块输出结果说明。

5.2 代码本身的质量

• 注释：关键步骤、复杂算法、自定义函数必须有清晰的注释，解释“做什么”和“为什么这么做”。
• 模块化：将不同的功能封装成函数或类，避免一个脚本成千上万行。
• 可复现性：设置随机数种子（如np.random.seed(42)），确保每次运行的结果一致。
• 错误处理：对于可能出错的地方（如文件读取、数据缺失），要有基本的异常处理，避免程序中途崩溃。

5.3 支撑材料的内容

除了代码，支撑材料可以包括：

• 中间结果：大规模运算的中间结果文件（如优化模型的详细输出日志）。
• 参考文献列表：论文中引用的所有文献的PDF或链接。
• 算法伪代码：对于核心的自定义算法，可以提供一个单独的伪代码文档。
• 额外分析：由于篇幅限制未写入正文的额外敏感性分析或场景测试。

参加MathorCup或任何数学建模竞赛，其价值远不止于奖项。它是对你问题拆解、知识整合、团队协作和极限抗压能力的一次全面淬炼。我个人的体会是，备赛过程中系统构建的知识体系，比赛中培养的“快速学习-建模-求解-表达”的闭环能力，以及和队友在深夜并肩作战结下的情谊，这些才是比赛留给你的最宝贵财富。不要过于纠结于某个模型是否“高级”，用合适的工具解决明确的问题，并将整个过程清晰、可信地呈现出来，你就已经战胜了大多数对手。最后一个小建议：从现在起，就找两个靠谱的队友，选定一个过往赛题，模拟一次72小时的全流程实战，你会发现所有纸上谈兵的经验，都会在真实的压力下变得具体而深刻。