2026国赛30天数学建模备赛全攻略：团队协作与真题实战

2026 年国赛（全国大学生数学建模竞赛）如果按往年的节奏来算，真正能完整利用的备赛时间，通常就是 30 天左右。这个周期不长不短，足够把一支队伍从“会建模、会写代码、会写论文”拉到“能在 72 小时内稳定产出完整论文”的状态，但前提是每一天都要有明确的执行计划。

这篇备赛指南会直接给你一套可以照做的 30 天安排：每天练什么、用什么工具、模型代码怎么组织、论文怎么倒排工期、常见坑有哪些，以及团队协作时的任务流转方式。文章面向的是刚组队不久、想冲击省奖及以上、但又没有系统备赛节奏的队伍，也适合一个人先自查短板、再带着队友一起练的队长。

1. 核心能力速览

先把 30 天备赛的关键指标罗列出来，方便你对照自己队伍的情况判断重点。

从这些能力点能看出，30 天备赛的核心不是把数学建模所有算法全部刷一遍，而是把 72 小时竞赛流程完整跑通至少 2 到 3 遍。赛题千变万化，但流程是固定的：读题、分析、建模、求解、检验、写论文、提交。

2. 备赛目标与使用边界

2.1 30 天能解决什么问题

30 天备赛最值得投入的方向有三个。

第一个是快速形成团队共识。很多队伍直到赛前一周还在争论“到底谁负责写论文”“代码风格能不能统一”，这种内耗在竞赛中非常致命。30 天训练可以通过固定分工和流程模版，把这些问题提前解决。

第二个是建立自己的工具箱。不要求每个算法都能手推，但通用流程要能跑通：数据预处理、探索性数据分析（EDA）、建立基础模型、调参、结果可视化、导出表格和图表。每支队伍都应该有一套自己的代码模板，竞赛时直接复制修改，而不是现场从零写。

第三个是练出“72 小时节奏感”。3 天时间看起来很多，但实际分配给建模、编程、写作后，每个环节都非常紧张。30 天里至少要做一次完整的真题模拟，严格按照竞赛时间执行，才能找到适合自己的时间分配比例。

2.2 不切实际的期待要提前放弃

30 天备赛不能解决所有问题。如果队员连 Python 基础语法都没有系统学过，指望 30 天突击拿到国奖，概率很低。更合理的定位是：把已有基础转化为竞赛能力。

另外，不建议在这 30 天里去追求学习大量高深算法，比如非要啃完所有机器学习理论的推导，对竞赛产出来说性价比不高。优先把几类经典模型用熟：回归、分类、聚类、优化模型、预测模型、评价类模型。这些在国赛中出现频率高，覆盖大部分赛题方向。

2.3 版权与合规边界

备赛过程中会大量使用公开数据集、参考论文、开源代码。这里要注意：

训练用的数据集应来自官方赛题附件或可公开获取的数据源。不要拿未授权数据、付费数据冒充自建数据。参考论文可以学习其建模框架、图表表达方式，但不能整段照抄。开源代码可以复用，但要在论文中明确说明或按许可证要求标注。竞赛提交时，查重系统会比对论文文本和代码相似度，所以在日常练题时就要养成“用自己的语言重写、按自己的思路组装”的习惯。

涉及真实业务数据、隐私数据或敏感数据时，不要提交到公开平台，也不要在公开代码仓库中泄露。用脱敏或生成数据代替。

3. 30 天备赛总体规划

3.1 整体时间线

30 天建议分成 4 个阶段，最后留出缓冲时间。

下面逐个阶段说清楚每天做什么。

3.2 第一阶段：摸底与工具链建设

前 5 天不做真题，先把“基础设施”搞定。

先开一次团队会，对照赛题要求梳理三件事：

• 建模手熟悉哪些方法，哪些方法只会套公式、不会讲解；
• 编程手掌握哪些 Python 库，数据处理、可视化、模型训练是否都能独立完成；
• 写作手熟悉论文结构，是否能快速排版数学公式、插图、三线表。

然后统一工具链。建议团队统一使用 Python，版本建议安装较新的稳定版本，不要混用多个版本。编辑器建议 PyCharm 配合 Jupyter Notebook，PyCharm 用于写正式脚本，Jupyter 用于快速探索数据和模型调试。

# 创建独立 Python 虚拟环境并安装常用库 python -m venv mathmodel_env source mathmodel_env/bin/activate pip install numpy pandas matplotlib seaborn scipy scikit-learn openpyxl

这里用虚拟环境可以避免不同项目之间依赖冲突。把numpy、pandas、matplotlib、seaborn、scipy、scikit-learn作为基础库，后续遇到具体赛题再临时安装其他库。

第一阶段结束时，要确保以下内容已经跑通：

• 读取 Excel / CSV 数据，完成缺失值统计和简单清洗；
• 绘制直方图、散点图、相关性热力图；
• 训练一个简单的线性回归或逻辑回归模型，并输出评价指标；
• 论文模板中可以正常插入公式、表格、图片；
• Git 仓库建立，三人熟悉基本提交同步流程。

3.3 第二阶段：专项突破与模板沉淀

第 6 到 15 天是 30 天里最关键的训练阶段，目标是把常用赛题类型都过一遍，沉淀自己的“代码模板”。

按国赛常见题型拆分，至少覆盖以下方向：

针对每个方向，只练 1 到 2 个典型案例，不贪多。关键是把自己队伍能理解的解法做成标准化流程。

每天的训练节奏建议这样安排：

上午：团队讨论当天题型的方法体系 下午：编程手实现代码，建模手检查建模逻辑 晚上：写作手整理当天成果，形成模板文档

这个阶段不要追求做出一篇完整论文，而是要积累“可复用的零件”。比如数据处理、模型训练、画图、导出表格，这些过程应该封装成函数或脚本，竞赛时直接调用。

下面给一个典型的数据预处理和模型训练模板，可以根据赛题修改：

import pandas as pd import numpy as np from sklearn.model_selection import train_test_split from sklearn.ensemble import RandomForestRegressor from sklearn.metrics import mean_absolute_error, r2_score # 读取数据 df = pd.read_csv('data.csv', encoding='utf-8') # 基础清洗 df = df.drop_duplicates() df = df.fillna(df.median()) # 特征与目标 X = df.drop(['target'], axis=1) y = df['target'] X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, random_state=42 ) # 训练模型 model = RandomForestRegressor(n_estimators=200, random_state=42) model.fit(X_train, y_train) # 预测与评估 y_pred = model.predict(X_test) print(f'MAE: {mean_absolute_error(y_test, y_pred):.4f}') print(f'R2: {r2_score(y_test, y_pred):.4f}') # 保存结果到 CSV result = pd.DataFrame({'y_true': y_test, 'y_pred': y_pred}) result.to_csv('prediction_result.csv', index=False)

这只是模板，不是万能代码。赛题中特征工程、数据分布差异都可能影响结果，平时训练时要注意调试过程，而不是只复制代码。

3.4 第三阶段：真题实战模拟

第 16 到 26 天，完成 2 次完整真题模拟。

第一次模拟建议选较老、题型偏常规的题目，重点不是拿高分，而是完整走一遍 72 小时流程：

• 第一天：选题、理解题目、数据清洗、初步建模；
• 第二天：完善模型、求解、结果分析；
• 第三天：论文整合、摘要打磨、格式检查、提交。

模拟时严格计时，最好选周末，不要中断。如果第一次模拟发现时间不够，不要急着补练，先复盘时间花在哪里。

第二次模拟选最近一年的赛题，难度更接近真实比赛。这次要模拟真实提交场景：论文 PDF、代码包、支撑材料都要按比赛要求命名和整理。

真题模拟的核心检验标准：

• 摘要是否能在 300 字以内说清问题、模型、结果；
• 论文是否在 20 页以内完成（不同年份要求可能有差异）；
• 代码是否可复现，生成的所有图表是否能在论文中对应；
• 三人分工是否顺畅，是否存在某个人过度忙碌、其他人闲置的情况。

3.5 第四阶段：复盘与赛前检查

最后 4 天不再做新题，只做两件事：复盘和归纳。

复盘内容清单：

• 两次模拟赛中暴露的问题，比如数据清洗耗时过长、模型求解报错、论文排版混乱；
• 每个问题的解决方案是否已经沉淀到团队文档；
• 还有哪些代码没有封装成模板，是否需要补齐。

归纳内容清单：

• 最近几年国赛题目类型的变化趋势，比如是否越来越注重数据量和实际问题背景；
• 高频模型和方法的适用场景；
• 写作手整理的论文框架模板，包含常用板块的固定表述。

赛前检查可以做成一个清单，避免临场忘记重要操作：

[ ] 电脑电源适配器、电池充满 [ ] 比赛数据备份到两个以上位置 [ ] 论文模板已导入，字体、行距设置完成 [ ] Python 虚拟环境可正常启动 [ ] 所有常用代码模板已同步到 Git [ ] 队内共享文档链接可用 [ ] 手机联系方式互通，有备用联系方式 [ ] 确认比赛报名信息和提交时间

4. 备赛环境准备与项目工程化

竞赛不是只靠一个 Jupyter Notebook 就能顺利跑完的，环境越早整理好，比赛时越省心。

4.1 项目目录结构

建议每个赛题都使用统一的目录结构。比赛开始的第一个小时，先创建目录，把分工程序固定下来。

rails/ ← 根目录按比赛题目编号或题目简称命名 ├── data/ # 存放原始数据和清洗后数据 ├── code/ # 所有脚本和 Notebook ├── fig/ # 输出图表 ├── tables/ # 输出表格 ├── reference/ # 参考文献和阅读笔记 ├── paper/ # 论文源文件和导出 PDF ├── draft/ # 团队讨论草稿、模型思路记录 └── README.md # 记录团队分工、进度和注意事项

这个目录结构在正式比赛中非常有用。它能避免“某某的最终版”“改改2”这类文件名满天飞的混乱状态。

4.2 Git 团队协作

3 个人同时操作同一批代码文件一定会冲突，尤其是比赛后期时间紧张时，代码版本管理失误会造成很大代价。

推荐用 Git 做版本管理，比赛前就练熟基本操作：

# 初始化仓库 git init # 添加远程仓库（如 Gitee 或 GitLab 私有仓库） git remote add origin git@github.com:team/model-contest.git # 每天结束前提交一次 git add . git commit -m "day-07: add data preprocessing template" git push origin main

如果队员对 Git 不熟悉，不必强行使用复杂分支，只保留main分支、每天固定提交一次即可。重点是确保代码可恢复，而不是练习 Git 高级玩法。

4.3 文档协作与模型思路记录

代码之外，还要准备一个在线文档系统，如飞书或腾讯文档。竞赛中三人的讨论结论、模型调整过程、分工变更，全部记录到在线文档中。

建议每位队员每天更新自己的“工作日志”：今天做了什么、遇到什么问题、明天计划做什么。团队每晚花 15 分钟同步进度，避免思路偏差。

论文手还要单独维护一份“模型思路记录”，把建模手讲出的模型结构、假设、变量定义、公式推导过程都记录下来。这个文档是后续论文写作的核心素材，比比赛时重新问建模手要高效得多。

5. 核心技能训练与每日验收

5.1 数据处理能力

数据预处理是国赛中最容易消耗时间，但也是最容易通过训练提升的环节。

30 天训练中，建议专门花 2 到 3 天集中练习数据处理，覆盖这些场景：

• 缺失值处理：直接删除、均值/中位数填充、插值法；
• 异常值处理：3σ原则、箱线图筛选、业务规则过滤；
• 数据合并：多表关联、时间对齐、行列转换；
• 数据标准化：Z-score、Min-Max；
• 特征构造：分组聚合特征、时间特征、统计特征。

每天训练时，只挑一个场景，用一道简单题目做练习，把处理过程和结果整理成代码模板。

5.2 建模方法表达能力

很多队伍的问题不是不会模型，而是说不清楚模型为什么适用于这个题目。评审老师看论文时，非常看重建模逻辑的连贯性。

每做一个算法，都要能用 3 句话解释清楚：

• 这个算法解决什么问题；
• 它的基本假设是什么；
• 在这个赛题中，为什么适用。

建议建模手在第二阶段每天做一个小练习：随机找一道往年赛题，限时 15 分钟，用自己的话讲出建模思路，其他两名队员提问。这个训练能极大地提升 72 小时竞赛中的沟通效率。

5.3 论文写作能力

论文写作不能只靠写作手一个人，建模手和编程手必须对论文内容负责。写作手负责整体组织、语言润色、格式规范；建模手负责公式和模型解释的准确性；编程手负责图表和数值结果的一致性。

每天写作训练可以做这些事：

• 修改昨天写的段落，压缩到更简洁的表达；
• 将一段算法描述重写为符合竞赛语言风格；
• 整理图表，调整标题、坐标轴、单位；
• 练习写摘要，从 500 字压缩到 300 字以内且不丢信息。

30 天坚持下来，论文产出速度会明显加快。

6. 团队分工与自动化任务配置

竞赛三天中，三人不可能始终做同一件事。常见的分工方式是：

这里要注意，第三天所有人都要投入到论文和材料整理中，而不是继续写代码。代码能跑、结果能用就足够了，比赛评分的核心载体是论文。

建议在备赛阶段就建立一份“任务流转单”，每个任务包含负责人、截止时间、产出物、验收标准。例如：

任务：建立预测模型 负责人：编程手 截止时间：第二天 18:00 产出物：prediction_result.csv + 模型描述文档 验收标准：预测结果有评价指标、导出图表在论文中可见

这份任务流转单可以用在线表格管理，比赛时实时更新。虽然形式简单，但对避免“做完了却没人对接”的混乱非常有效。

如果队伍具备一定的编程能力，可以在备赛阶段写一些脚本生成固定格式的图表和报表，减少重复劳动。但不要过度自动化，比赛重压之下，脚本出错反而会增加麻烦。

7. 资源占用与性能观察方法

竞赛中如果只做统计建模、优化求解、基于树模型的机器学习，普通笔记本电脑的 CPU 就足够了。重点要注意的是运行时长的估算，避免模型训练时间过长而挤压论文时间。

在备赛第二阶段，建议用真题数据实际跑一次，记录不同模型的时间开销：

# 可在脚本内用 time 模块记录训练时间 import time start = time.time() model.fit(X_train, y_train) print(f"训练耗时: {time.time() - start:.2f}s")

如果涉及深度学习赛题，比如图像数据、文本数据，GPU 训练环境会明显提升效率。训练前先确认自己机器的显存和内存大小，以及是否能在合理时间内完成一个 Epoch。不建议竞赛当天第一次跑深度学习模型，最好在备赛时就把环境稳定住。

内存方面，处理大规模数据时要避免一次性读取过多数据到内存。如果 Excel 文件超过几百 MB，建议先做列裁剪或分块读取：

import pandas as pd # 分块读取大文件 chunks = pd.read_csv('large_data.csv', chunksize=10000) partial_stats = [] for chunk in chunks: partial_stats.append(chunk.describe())

训练时如果发现内存不足，优先减少数据量、缩小测试范围，而不是盲目增加内存或模型复杂度。

另外，建议在正式比赛前，检查自己的电脑是否安装了足够的新版驱动和依赖包。比赛开始后不建议频繁升级库版本，所有依赖以备赛环境为准。如果换电脑，提前把虚拟环境导出：

pip freeze > requirements.txt

在比赛电脑上恢复环境：

pip install -r requirements.txt

这个操作在赛前演练过一次，可以在比赛第一天节省大量环境配置时间。

8. 常见问题与排查方法

下面是备赛和竞赛中最高频出现的问题，每一项都来自历年参赛队伍的实际反馈。

备赛阶段每次遇到新问题，都把它登记到团队的问题清单中，并写下解决方案。到比赛时，大部分报错都能迅速找到对应处理方式，而不是浪费时间查文档。

9. 最佳实践与使用建议

9.1 保留一套最小可运行配置

正式比赛时，不要试图把所有代码都写到一个 Notebook 里。建议保留一套最小可运行配置，包含：

• 一个读取数据的脚本；
• 一个基础模型脚本；
• 一个画图脚本；
• 一个生成结果表的脚本。

这四个脚本必须能独立运行，并且输出格式固定。这样即使临时调整模型，也不会所有代码都牵连报错。

9.2 每天固定时间同步

30 天备赛阶段，每天晚上固定 30 分钟同步进度，不是可选项。很多队伍 30 天下来名存实亡，就是因为各自练各自的，没有形成合力。

同步时只聊三件事：

• 今天完成了什么；
• 明天计划做什么；
• 有没有需要其他队员协助的问题。

不需要形式化的长篇汇报，直接、简短、可执行。

9.3 素材和输出分目录管理

赛题附件、参考论文、训练数据、输出图表、最终论文，必须分目录管理。备赛阶段就养成这个习惯，竞赛时直接套用。

特别提醒：参考论文中如果有重要观点，在阅读时就标注来源和页码，避免论文写作阶段再去翻原文。

9.4 批量化出结果时加入失败重试

如果需要跑多组参数或多次随机实验，建议在代码里添加日志记录和简单重试机制，不要一次性把大批任务跑完而不检查。一次比赛最多三天，代码崩溃一次就可能损失大量时间。

import logging logging.basicConfig(filename='run.log', level=logging.INFO) def safe_run(func, params): try: result = func(params) logging.info(f"success: {params}") return result except Exception as e: logging.error(f"failed: {params}, error: {e}") return None

9.5 合规与学术道德再提醒

竞赛提交的论文必须是团队独立完成。可以使用公开的算法库、开源代码，但核心模型思路、公式推导、论文表达应当由团队自己组织和撰写。不要购买他人的完整论文，不要代做，不要使用未授权的代写服务。竞赛规则明确禁止的学术不端行为，一经发现会影响成绩甚至被禁赛。

10. 总结与下一步

30 天备赛最值得做的事情，不是逃避困难题型，而是把“做题流程”变成身体记忆。如果你现在刚开始准备，第一件事不是去找一堆算法论文，而是先把团队拉齐，确定工具链、创建项目目录、完成一次小数据量的完整流程。

最先应该验证的是：三个人是否能在 24 小时内，完成从数据清洗到基础模型再到一篇简单论文初稿的流程。如果这个流程都跑不通，后面 30 天安排再满也很难见效。

最容易踩的坑有三个：一是前期花费太多时间学习新算法，不沉淀代码模板；二是参加模拟赛时没有严格按照正式比赛时间执行；三是论文写作拖延，把模型调试当成最重要的事，最后只剩半天写论文。

接下来可以在这 30 天里继续做的事包括：每周做一次完整真题模拟并复盘、把常用算法封装成自己的工具库、强化摘要注意事项和论文图表规范、提前准备一份比赛当天快速检查单。把这些做完，2026 年国赛的 72 小时，你至少能保证团队稳定输出、不留低级遗憾。

建议把这篇文章收藏，备赛期间随时回看，也欢迎在评论区分享你的备赛节奏和踩坑经验。