企业官网建设流程全解析

领奖下台之后，队友问了我一个问题：“如果让我们重新比一次，你会改哪里？”我想了很久，最后得出的答案让所有人都有些意外——不是模型再高级一点，也不是代码再快一点，而是把选题决策做得更坚决一点。很多队伍把华为杯当成拼脑力的比赛，但以我这一届拿到一等奖的经历来看，它更像一场拼流程、拼决策、拼细节管理的工程实战。

这篇总结和复盘，围绕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的预测误差对比（alpha=0.3时最优）”；
• 同一篇论文内，风格统一，字体大小一致，配色不花哨，避免混淆；
• 能用表格的地方不要全部堆表格，能用图的地方不要全部堆文字。

在可视化上，我们花了不少时间做“过程图”。除了最终的结果图，我们还会画数据处理流程图、模型结构示意图、实验设计逻辑图。这三类图的作用是让评委快速理解工作量和思路。

我发现很多队伍低估了“示意图”的价值。他们觉得示意图不产生分数，实际上恰恰相反，一张好的模型流程图，能让评委在30秒内理解你做的事情，胜过你写五百字描述。评委也是人，人都喜欢轻松地接收信息。

4.3 公式和符号：让评委毫不费力地读懂

建模竞赛的论文一定会涉及大量公式。公式写得规范，会从细节处传递出专业度。我们对公式和符号的处理有几条铁律：

• 所有符号必须在第一次出现时定义，并统一列入符号说明表；
• 同一个概念全文只能用一个符号，绝不允许这里用x、那里用X；
• 公式编号规范，在正文中提及公式时用“式(3)”而非“上述公式”；
• 公式推导要展示关键步骤，但不要事无巨细地把所有代数展开都写上去，这会稀释重点。

一个常见的错误是：变量符号使用很混乱，评委看公式时要来回翻上下文才能搞清。这就等于我们给自己设置阅读障碍。我们花了一个多小时专门统一符号，把全文的变量表整理出来，放在模型部分的开头。这半个多小时看似耽误时间，但在评委那里赢回了很多印象分。

我们还有一个习惯：在正文中写清楚“为什么选这个模型”以及“这个模型的假设条件有哪些”。很多人只写“我们用了SVM，因为处理小样本有优势”，但没有解释为什么在这个问题里小样本是有利的，SVM的什么特性匹配这个任务的什么特征。这种逻辑链的完整性能明显提升论文说服力。

4.4 附录与参考文献：最后的“干净度”检查

附录和参考文献是论文的“最后一段评分空间”，也是最容易被忽略的部分。

附录我们只放三类内容：核心代码、补充数据表、补充的实验结果。不放与主线无关的探索性实验、不放调试代码、不放未使用的数据说明。附录的意义是证明“我们有充分的实现支撑”，不是证明“我们做了很多失败尝试”。

参考文献方面，我们不追求数量多，但每一条都必须“真正被引用过”。之前训练时，我们见过一些论文列了三十篇参考文献，但正文里大量内容是“借鉴”了网络的非学术性文章，审稿人会立刻看出来。我们的参考文献一般控制在一半模型方法类、一半实际数据集或业务背景类，且全文引用位置准确。

最后，提交前我们会做一次全篇“干净度检查”，重点看：

• 图表编号与正文引用是否一一对应；
• 参考文献格式是否统一；
• 页眉页脚页码是否正确；
• 目录是否更新；
• 是否有残留的中英文混排标点；
• 是否有从模板里带来的无用占位文本。

这些细节每一项单独看都很小，但加起来就是评委体验的分水岭。

注意：论文写作过程中，即使是格式问题，也不要攒到最后一起处理。我们的做法是每天睡觉前花十五分钟统一检查当天写入内容的格式。最后一天再查一遍，工作量小很多，也不容易出错。

5. 复盘：一等奖带给我的真实收获和三条建议

奖项公布之后，我们做了两次复盘，一次是小组内部，一次是和指导老师一起。复盘时我们意外发现，大多数“有效动作”都发生在正式比赛之前，而不是比赛期间。

5.1 领奖之后，我们给队伍的复盘画像

我们给自己画了一条“比赛时间线”，标注了每个阶段的关键事件和状态，从训练赛、选题、第一天草稿摘要到最终提交，逐段回顾。

印象最深的几个结论：

第一，准备阶段的决策质量决定了上限。选题选得好、资料库足够全、训练闭环走得足够多，这些都是赛前完成的事情。比赛那几天我们做的更多是“执行”，而不是“创造”。

第二，流程远比单个环节重要。单看建模能力，我们未必是最强的；单看编程速度，队友A也遇到过很多比他快的人；单看写作水平，队友B也并非是顶尖选手。但当我们把这三个能力用合理的流程串起来，整体战斗力就上了好几个档次。

第三，心态管理在工作量之上。四天比赛最难熬的不是身体，是心理。最后一天队伍内部那个“要不要再加新模块”的争论，就是心态的写照。现在我们总结出一个朴素标准：当时间只剩20%的时候，任何“新增”都要默认否决，只做“稳定”和“表达”。

5.2 给下一届参赛者（也给你们队伍）的三条建议

基于2023年的经历，如果要给正在备赛的队伍三条最有限的建议，我会说：

第一条：正式比赛之前，至少走完一次全流程模拟。哪怕你的题目选得不好、模型做得不完整，也必须在限时内提交一份完整论文。只有体验过“最后一天论文还没写完”的恐慌，你才会在正式比赛时对时间有真实的敬畏感。

第二条：不要攒大招，把功夫下在平时的“流程”和“细节”里。很多队伍期待比赛时灵光一闪，突然想出一个惊艳的模型。这种想象不现实。真正决定名次的是把一个普通的模型流程做得滴水不漏：数据合理、假设清晰、公式规范、图表完整、摘要有力。华为杯一等奖的含金量，不在“谁最聪明”，而在“谁把复杂任务完成得最可靠”。

第三条：确保队伍里有一个人能随时拉出“全局视图”。这个人不一定要写最核心的代码，但他要清楚每一块工作现在进行到哪、和主线的匹配度如何、下一步最应该做什么。一旦失去这个全局视角，队伍各干各的，再厉害的能力也发挥不出来。

写在最后

每次写完复盘，我总会再想起领奖那天的场景。队友问我的那个问题，“如果重新比一次会改哪里”，我想最终的答案其实不是“把某个模型做得更好”，而是“更早地意识到流程和决策才是竞赛的底层框架”。

数学建模大赛的比赛结果，当然不仅仅是方法论，也包括赛题的匹配、团队当时的状态、一点点偶然因素。但方法论能保证的是：当机会来临时，你不会因为自己的低级失误、时间耗尽、论文表达不清这些可控因素把它丢掉。

如果这份复盘对你有一点帮助，那就足够了。祝你们队伍也能在数学建模竞赛里，打出自己的节奏，拿到你们想要的结果。