从华为杯一等奖复盘看数学建模竞赛的流程管理与决策智慧

领奖下台之后队友问了我一个问题“如果让我们重新比一次你会改哪里”我想了很久最后得出的答案让所有人都有些意外——不是模型再高级一点也不是代码再快一点而是把选题决策做得更坚决一点。很多队伍把华为杯当成拼脑力的比赛但以我这一届拿到一等奖的经历来看它更像一场拼流程、拼决策、拼细节管理的工程实战。这篇总结和复盘围绕2023年“华为杯”第二十届中国研究生数学建模竞赛展开。我不会在这里贴完整的获奖论文也不会复述题目原文而是把我们队伍从赛前准备、选题决策、四天节奏、论文打磨到赛后反思的完整链路拆开讲清楚哪些做法真正起到了作用哪些坑差点让我们翻车。队伍三人都是第一次打华为杯最后能拿到一等奖靠的绝不是运气而是一套可以复用的操作流程。这篇内容适合正在准备研究生数学建模竞赛的团队阅读也适合那些明明会建模、却总在比赛中发挥不出的同学参考。1. 赛前三个月一等奖的真正分水岭很多人以为华为杯的较量从比赛第一天早上八点开始其实不是。真正的分水岭在赛前三个月就埋下了。我们队伍能拿到一等奖很大一部分原因是在正式比赛之前已经把“该踩的坑”踩过了一遍。1.1 三人队伍的本质不是“分工”而是“补位”中国研究生数学建模竞赛要求三人组队常见的组合是“建模手编程手写作手”我们一开始也这么安排。我是负责建模和总协调的队友A是计算机方向、主攻编程实现队友B是金融方向、主攻论文写作和可视化。但第一次模拟训练之后我们就发现这种“各管一摊”的分工有个致命问题一旦某个人对自己负责的环节理解有偏差整个链条就卡住了。比如队友A写出来的代码很漂亮但他不了解模型假设背后的业务含义参数调整方向经常跟我们的推导相反队友B的论文文笔很好但她需要知道代码每一步在做什么才能把算法描述写准确。所以我们把分工逻辑改成了“一人主导、两人补位”建模手不只在白板上写公式也要能读懂代码的主要逻辑编程手不只实现算法也要参与讨论模型假设是否合理写作手不只排版也要能指出模型推导里“跳步”的地方。三个人对同一道题各自有自己的完整理解只是侧重不同。这样最大的好处是任何一个人在关键时刻掉线另外两人都能顶上而不是集体抓瞎。这个调整在比赛最后一天起了决定性作用。当时负责编程的队友因为连续熬夜状态明显下滑我和写作队友接手了他的调参和代码验证工作尽管慢一些但没让进度停摆。1.2 训练赛的正确打开方式按比赛流程走完整闭环备赛期间我们做了大量往年华为杯真题但回看训练记录真正有效的不是“做完了多少题”而是“按比赛流程走完了多少次闭环”。什么意思很多人训练时只练建模和代码写完就丢从不写完整论文也从不对着评阅标准打分。这样的训练只能练出“局部能力”练不出“比赛能力”。我们定的规矩是每一次训练赛都必须完全模拟比赛流程——限时四天、按时交卷、按官方评分细则打分。哪怕题目难度不合适哪怕最后的模型很粗糙这个闭环必须走完。第一次全流程模拟我们惨不忍睹第三天下午还在改模型方向第四天晚上论文还有三章没写最后交上去的东西连我们自己都不忍心看。但正是这次溃败逼出了后面真正的进步。模拟之后我们做了三件事把评阅标准打印出来逐条对照找出“文档没有体现出我们做了很多工作”这一类扣分点记录每一道题我们耗费的时间分布找到时间黑洞在哪里收集评委公开点评整理成一份“评委厌恶清单”。这三件事没有一个是做新题却比做三套新题都管用。到了正式比赛时我们基本不会再犯低级错误因为大部分低级错误都在训练里犯过了。1.3 资料库与模板最容易被人忽视的隐形资产如果说训练闭环解决的是“流程感”那资料库解决的就是“起跑速度”。比赛总共不到一百个小时如果在代码、排版、查文献这些环节浪费哪怕半天后期就会非常被动。我们提前建了一个共享资料库分成四类代码库常用算法的Python实现、MATLAB脚本、调参模板、可视化代码片段论文库近年华为杯一等奖论文、优秀论文按赛题方向分类供快速查阅排版库定制的LaTeX模板、表格样式、图注规范、参考文献格式业务库一些跨学科的背景知识笔记比如交通调度常用评价指标、金融时间序列的常见处理方法、生物医学数据的典型分析路径。这个资料库看上去不难建但关键在于“按比赛场景整理索引”。我们是按“如果比赛遇到某类题我整个人需要调出哪些材料”来整理的而不是按学科分类。比赛第二天上午我们要做数据预处理时直接在资料库里翻出了别人优秀论文的数据清洗思路笔记省去了大量回忆和搜索时间。提示资料库不是越多越好而是“可调用”才好。备赛阶段不要只收藏不消化每一个放进去的代码、模板、笔记都应该你自己亲手跑过或用过否则比赛时你根本不敢用。2. 选题关键时刻的决策能力决定上限华为杯的赛题一般有多道选择题覆盖不同领域。市面上有个共识赛题难度和获奖概率不是简单的正比关系选题选得好等于比赛提前赢了一半。我们在这方面的体会非常深。2.1 拿到赛题后的第一个完整小时我们做了什么很多队伍拿到赛题的第一反应是——“这道题我好像能做”然后立刻开始看数据、翻文献。我们没有这样做。开放下载后的第一个小时我们做了一套标准化的快速评估。首先三个人各自用15分钟静默阅读所有题目不做讨论。这一步是为了避免“队友说哪道好就跟着看哪道”的锚定效应。接着我们对每道题填写一张评估表打分维度包括数据量级与预处理难度模型与算法的熟悉度题目中“可发挥空间”的大小论文写作时能否讲出清晰的故事线预估完成时间这个方法其实不复杂但它逼迫我们在被题目细节吸引之前先从宏观上判断哪些题“性价比更高”。我们当时还习惯性地在每道题旁边写一句话的直觉评价比如“数据量大但结构规范估计重点是特征工程”“这题偏向机理建模需要领域知识”“这个目标函数不明确开放性高写作发挥空间大”。大约第50分钟我们统计打分表选定了方向。后面经过讨论最终确认整个过程没有超过90分钟。这个决策速度在参赛队伍里属于很快的但正因为决策坚决我们的后续时间没有被“要不要换题”反复消耗。2.2 我们避开了哪一类“看着简单”的题复盘时我们确认了一个关键判断我们避开了那一类“数据干干净净、任务描述清清楚楚”的题。这类题看起来最好上手甚至第一眼就知道该用什么模型但往往也是大部分队伍的选择竞争最为拥挤。这类题有三面陷阱数据太干净意味着题目真正的坑会藏在“评价指标怎么定”或者“隐藏约束怎么发现”上模型反而只是配角上手越容易后期越难拉开差距因为所有人都会想到同一种方法如果只是普通地做一遍论文几乎不会有“记忆点”评委在几百份论文里很难对你的工作留下印象。当然这不是说不能选这类题而是说我们要清醒判断自己的竞争力。以我们队伍当时的配置优势在于跨学科的建模视野和写作能力劣势在于算法强度不够极致。选一道“拼综合能力”的题比选一道“拼算法硬实力”的题更符合我们的特点。后来事实也证明选题选得对后面写论文时会顺畅很多因为你是在“讲故事”而不是在“交答案”。2.3 最终选定的依据能讲故事能写等式能画流程图我们最终选定的题目为避免影响后续参赛者这里不透露具体题目用三个标准验证过第一能讲故事。题目背后有一个清晰的实际业务逻辑我们可以把它转成一条通顺的分析主线“现状问题—数据特征—模型设计—结果验证—优化建议”。这条主线从头到尾都在没有任何一段会显得像硬凑字数。第二能写等式。建模竞赛归根到底要落到数学模型上。我们判断题目能不能写出“数学味道”浓的方案标准很简单能否用规范化的符号系统将问题表达为优化模型或统计模型。如果一道题只能靠自然语言描述解决思路不能提炼成明确的数学表达式那建模竞赛的优势就发挥不出来。第三能画流程图。这不是开玩笑。我们习惯在选题阶段就画出大致的求解流程图包括数据输入、预处理步骤、模型构建、验证环节和输出结果。画得出来说明我们对解题路径有整体把控画不出来说明可能有一块我们对形势估计不足后面容易卡住。这三个标准本质上是一个这道题能不能让我们发挥出队伍的真实水平有的题很有挑战性但发挥不出我们的优势有的题太简单但竞争过于激烈。选题不是选“最难的”也不是选“最有把握的”而是选“综合回报最高的”。注意选题阶段一定要全员参与讨论不能让一个人拍脑袋决定。我们在训练中遇到过这种情况——一个人陷在题目细节里出不来非要选那道题结果整个队伍陪着做一个不适合自己的方向。后来我们就定死规矩超过两个人反对这道题无条件放弃不讨论。3. 比赛四天拼的不是智商是流程管理正式比赛的四天是一台精密运转的机器。我的感受是这场比赛到最后拼的已经不是“谁的算法更厉害”而是“谁的时间管理更扎实、谁的流程更顺畅、谁的心态更稳”。3.1 第一天不写代码先写“草稿摘要”这是我们从第一次训练赛的惨败里总结出来的习惯也是我觉得最值得分享的一条经验。比赛第一天很多队伍会迫不及待地开始写代码仿佛“动起来”才有安全感。我们反其道而行第一天除了继续完善对题目的理解、整理数据和梳理假设之外最重要的一件事是做了一件事写一版“草稿摘要”。这版草稿摘要不需要写得很完整但必须包含题目背景和我们要解决的问题我们的核心建模思路哪怕只是一个大方向预估采用的主要方法希望能得到什么结论。写完这版草稿摘要放在共享文档里置顶后面每一天都要打开它、修改它。这个做法的价值在于它强制我们在第一天就想清楚“故事主线”和“最终打分点”而不是做一步看一步。比赛中最可怕的不是进度慢而是做了三天之后发现方向跑偏最后一天推倒重来。草稿摘要相当于给整个队伍插了一根定海神针大家做任何决策都先对照它这个操作对故事主线有没有帮助如果没有优先级自动降低。而且等到正式写摘要时我们只会比第一天更了解题目绝不会更少。从“草稿摘要”到“正式摘要”是迭代关系不是从空白开始现场想关系。3.2 并行流水线建模、编程、写作如何各干各的比赛第二、三天我们进入并行工作模式。很多队伍的习惯是先建模等模型确定了再编程等程序跑完了再写论文。这个串行流程的问题是时间完全不够用——建模两天、编程一天、论文一天最后仓促提交。我们的做法是让三条线同时开工建模线由我负责持续完善模型框架、推导公式、明确假设条件并把模型的新变化同步给队友编程线由队友A负责对已经确定的模块立刻实现不等整个模型全部定稿再动手先搭好数据处理流程和模型骨架后续只需要替换核心模块写作线由队友B负责先写那些不会因为模型变而变的内容比如问题背景、数据来源描述、符号说明、模型总览。模型细节等建模确定后再填入。为了让三条线对齐我们每天固定两个时间点开短会早上9点和晚上9点。每次会不超过二十分钟只同步三件事当前进度、阻塞问题、下一步优先级。这个模式坚持下来之后我们的论文框架在第二天就已经成型了。到第三天晚上论文已经完成大半模型部分虽然还没有最终结果但所有空位、图表框架、公式占位符都预留好了。最后一天我们只需要做“填空打磨”而不是从零开始写。3.3 最后24小时我们只对模型做了一件事比赛最后一个整天往往是最焦虑的。当时我们面临一个典型诱惑模型已经有一个稳定结果但还剩一些可以优化的方向比如把算法复杂度降下来、或者增加一个更精细的子模型。队伍内部产生了分歧。一方想“反正还有时间再优化一下”另一方认为“现在的结果已经能写成一个完整故事再改动可能引发连锁问题”。最终的决策是进入“冻结模式”只做稳定验证不再增加任何新功能。也就是说最后24小时我们只对已完成的模型做参数微调、鲁棒性分析和关键结果验证不添加新的模块、不更换重要算法、不大改数据预处理流程。这个决定被证明是非常理性的。我们身边有队伍在最后一天坚持要换一个更花哨的模型结果代码没调通连累了整个论文框架最后草草收场。数学模型比赛拼的是“完整交付”不是一个单独的性能指标。一个稳定、完整、可解释的模型远胜过一个华丽但没有跑通的设计。当然“冻结”不等于什么都不做。我们最后24小时的时间分配大致是上午跑完最后一组参数实验记录结果检查异常值下午把实验结果填进论文更新图表让写作队友完成模型描述晚上三人逐段阅读全文重点检查摘要、结论、图注、公式编号最后两小时统一格式、打印PDF、检查附件是否齐全。最后两小时不写新内容只做“交付检查”。提示最后一天的“待办清单”应该在第三天晚上就列好。不要一边做着模型一边想接下来要做什么那会白白消耗注意力。我们当时把清单贴在白板上完成一项划掉一项心理压力小很多。4. 论文里的另外50分评委视角下的细节工程华为杯的评分有一半以上看论文本身。很多队伍花大量时间把模型做得很复杂最后论文却没能把这份复杂度表达出来。我们队长有一句话贯穿整个比赛“要把我们做了多少工作让评委毫不费力地看见。”这句话指导了论文的所有细节。4.1 摘要第一页决定第一印象摘要的重要性怎么强调都不过分。评委的审阅时间有限摘要几乎决定了他们对你的论文是“带着好感读”还是“带着怀疑读”。我们写摘要采用了一个三段式结构但进行了改进让它更适合建模竞赛第一段用两三句话说清楚问题用自己的语言转述不要直接抄题目第二段描述整体思路“针对XX问题提出了XX模型/方法”一定把模型的数学形式或算法名明确写出来第三段给出具体结果数据和结论必须有数字不能只写“结果优于对比方法”。第三点是最容易被忽视的。很多队伍的摘要写“本文提出了一个神经网络模型取得了较好的效果”这种写法等于没说。我们当时在摘要里写清了核心指标提升到多少、比基准方法高出多少个百分点、在什么条件下有效这种信息密度完全不是一个量级。另外摘要的语言要像“结论汇报”不要像“计划说明”。不要说“本文试图尝试”要说“本文提出并实现了”。这虽然只是措辞但会影响评委对你完成度的印象。我们有个小技巧摘要写完之后把它拿给一个完全不了解题目的人看对方如果能复述出你做了什么、达到了什么效果那这个摘要就合格了。如果对方听得云里雾里说明摘要还不够直白。4.2 图表把“做了很多工作”直接画出来评委没有时间去挖你藏在附录里的图表。所有重要的图表都应该在正文里有明确的位置和合理的引导。我们在图表方面有几个操作规范每张图必须有完整的图题、坐标轴标签、单位、图例、必要的文字说明图标题不只是描述性文字还要包含图中最重要的结论比如“不同alpha取值下模型M的预测误差对比alpha0.3时最优”同一篇论文内风格统一字体大小一致配色不花哨避免混淆能用表格的地方不要全部堆表格能用图的地方不要全部堆文字。在可视化上我们花了不少时间做“过程图”。除了最终的结果图我们还会画数据处理流程图、模型结构示意图、实验设计逻辑图。这三类图的作用是让评委快速理解工作量和思路。我发现很多队伍低估了“示意图”的价值。他们觉得示意图不产生分数实际上恰恰相反一张好的模型流程图能让评委在30秒内理解你做的事情胜过你写五百字描述。评委也是人人都喜欢轻松地接收信息。4.3 公式和符号让评委毫不费力地读懂建模竞赛的论文一定会涉及大量公式。公式写得规范会从细节处传递出专业度。我们对公式和符号的处理有几条铁律所有符号必须在第一次出现时定义并统一列入符号说明表同一个概念全文只能用一个符号绝不允许这里用x、那里用X公式编号规范在正文中提及公式时用“式(3)”而非“上述公式”公式推导要展示关键步骤但不要事无巨细地把所有代数展开都写上去这会稀释重点。一个常见的错误是变量符号使用很混乱评委看公式时要来回翻上下文才能搞清。这就等于我们给自己设置阅读障碍。我们花了一个多小时专门统一符号把全文的变量表整理出来放在模型部分的开头。这半个多小时看似耽误时间但在评委那里赢回了很多印象分。我们还有一个习惯在正文中写清楚“为什么选这个模型”以及“这个模型的假设条件有哪些”。很多人只写“我们用了SVM因为处理小样本有优势”但没有解释为什么在这个问题里小样本是有利的SVM的什么特性匹配这个任务的什么特征。这种逻辑链的完整性能明显提升论文说服力。4.4 附录与参考文献最后的“干净度”检查附录和参考文献是论文的“最后一段评分空间”也是最容易被忽略的部分。附录我们只放三类内容核心代码、补充数据表、补充的实验结果。不放与主线无关的探索性实验、不放调试代码、不放未使用的数据说明。附录的意义是证明“我们有充分的实现支撑”不是证明“我们做了很多失败尝试”。参考文献方面我们不追求数量多但每一条都必须“真正被引用过”。之前训练时我们见过一些论文列了三十篇参考文献但正文里大量内容是“借鉴”了网络的非学术性文章审稿人会立刻看出来。我们的参考文献一般控制在一半模型方法类、一半实际数据集或业务背景类且全文引用位置准确。最后提交前我们会做一次全篇“干净度检查”重点看图表编号与正文引用是否一一对应参考文献格式是否统一页眉页脚页码是否正确目录是否更新是否有残留的中英文混排标点是否有从模板里带来的无用占位文本。这些细节每一项单独看都很小但加起来就是评委体验的分水岭。注意论文写作过程中即使是格式问题也不要攒到最后一起处理。我们的做法是每天睡觉前花十五分钟统一检查当天写入内容的格式。最后一天再查一遍工作量小很多也不容易出错。5. 复盘一等奖带给我的真实收获和三条建议奖项公布之后我们做了两次复盘一次是小组内部一次是和指导老师一起。复盘时我们意外发现大多数“有效动作”都发生在正式比赛之前而不是比赛期间。5.1 领奖之后我们给队伍的复盘画像我们给自己画了一条“比赛时间线”标注了每个阶段的关键事件和状态从训练赛、选题、第一天草稿摘要到最终提交逐段回顾。印象最深的几个结论第一准备阶段的决策质量决定了上限。选题选得好、资料库足够全、训练闭环走得足够多这些都是赛前完成的事情。比赛那几天我们做的更多是“执行”而不是“创造”。第二流程远比单个环节重要。单看建模能力我们未必是最强的单看编程速度队友A也遇到过很多比他快的人单看写作水平队友B也并非是顶尖选手。但当我们把这三个能力用合理的流程串起来整体战斗力就上了好几个档次。第三心态管理在工作量之上。四天比赛最难熬的不是身体是心理。最后一天队伍内部那个“要不要再加新模块”的争论就是心态的写照。现在我们总结出一个朴素标准当时间只剩20%的时候任何“新增”都要默认否决只做“稳定”和“表达”。5.2 给下一届参赛者也给你们队伍的三条建议基于2023年的经历如果要给正在备赛的队伍三条最有限的建议我会说第一条正式比赛之前至少走完一次全流程模拟。哪怕你的题目选得不好、模型做得不完整也必须在限时内提交一份完整论文。只有体验过“最后一天论文还没写完”的恐慌你才会在正式比赛时对时间有真实的敬畏感。第二条不要攒大招把功夫下在平时的“流程”和“细节”里。很多队伍期待比赛时灵光一闪突然想出一个惊艳的模型。这种想象不现实。真正决定名次的是把一个普通的模型流程做得滴水不漏数据合理、假设清晰、公式规范、图表完整、摘要有力。华为杯一等奖的含金量不在“谁最聪明”而在“谁把复杂任务完成得最可靠”。第三条确保队伍里有一个人能随时拉出“全局视图”。这个人不一定要写最核心的代码但他要清楚每一块工作现在进行到哪、和主线的匹配度如何、下一步最应该做什么。一旦失去这个全局视角队伍各干各的再厉害的能力也发挥不出来。写在最后每次写完复盘我总会再想起领奖那天的场景。队友问我的那个问题“如果重新比一次会改哪里”我想最终的答案其实不是“把某个模型做得更好”而是“更早地意识到流程和决策才是竞赛的底层框架”。数学建模大赛的比赛结果当然不仅仅是方法论也包括赛题的匹配、团队当时的状态、一点点偶然因素。但方法论能保证的是当机会来临时你不会因为自己的低级失误、时间耗尽、论文表达不清这些可控因素把它丢掉。如果这份复盘对你有一点帮助那就足够了。祝你们队伍也能在数学建模竞赛里打出自己的节奏拿到你们想要的结果。