1. 写在前面：一等奖背后的真实体感
2023年华为杯第二十届中国研究生数学建模竞赛，我们队拿了一等奖。查成绩那天下午，三个人盯着屏幕反复刷新，看到结果后没有欢呼，而是长出一口气——四天三夜高度透支的疲惫感，到那一刻才真正落地。这篇复盘拖了小半年，一直想写，一是给自己一个交代，二是想告诉打算冲击华为杯的同学们：所谓一等奖，并没有想象中那么玄乎，靠的是赛前一个月的刻意准备、比赛期间严格的节奏感、以及把细节抠到极致的习惯。
“华为杯”中国研究生数学建模竞赛和本科阶段的国赛、美赛不一样，参赛者基本都是研究生，队伍里大概率会有理工科背景的选手，整体水平更高，题目也更贴近实际工程和数据科学场景。2023年是第二十届，参赛队伍数量已经非常夸张，一等奖比例被压得很低。能在这么多高水平队伍里拿到一等奖，我们并不是那种“人均算法天才”的组合，三个人分别来自通信、统计和机械专业，唯一的共同点是都愿意在赛前做大量琐碎准备。如果你也正在准备下一届比赛，或者经历过一次失利想更上一层楼，这篇复盘里的经验你大概率用得上。
我需要先说清楚一个基本判断：数学建模竞赛的比赛结果，七成取决于你对“竞赛”这两个字的理解，三成才取决于你的数学功底。模型再漂亮，如果摘要写得像说明书、图表没有信息量、代码逻辑一团乱，评委根本不可能给你高分。反过来，一个足够稳的基础模型，配上一套严密的验证流程和清晰的论文表达，就足以进入获奖区间。这篇文章会围绕“准备—选题—建模—写作—时间管理—避坑”这条线展开，把我们在2023年华为杯现场踩过的坑、验证过的经验、最后关头改善得分的关键动作都记录下来。
2. 赛前准备：把不确定性提前消灭掉
2.1 组队与分工：不只选强的，要选“能吵完还能一起吃饭的”
很多队伍在组队时最大的误区是“人人都要会建模”。实际上，数学建模竞赛的四天里，每个人的角色必须清晰到不需要开会讨论就知道下一步该干什么。我们队的结构是：我负责建模和整体进度控制，队友A负责代码实现和数据挖掘，队友B负责论文写作与图表规范化。这个分工不是按“谁擅长什么”简单切一刀，而是按“出现问题的时候谁能最快速地兜底”来设计的——比如A虽然主攻代码，但他也具备基本的模型调参能力；B虽然主攻写作，但他能看懂我们的公式并转化为通俗语言。
这里有一个非常现实的经验：组队一定要找“能吵完架还能继续合作”的人。四天高压环境下，出现分歧是必然的，有时候甚至因为一个参数设置就能吵到面红耳赤。我们队之所以没有内耗，是因为在赛前就约定了一个决策机制：建模问题以我为准，代码问题以A为准，论文文字以B为准。其他成员可以提出观点，但最终拍板的人明确，这让很多潜在争执在萌芽期就被解决。如果你找的队友是那种“嘴上不说但心里不服”的性格，比赛第三天很容易出现消极怠工，那比模型不收敛更可怕。
2.2 知识储备与工具箱
数学建模竞赛发展到今天，早已不是“会几个经典模型就能拿奖”的时代了。2023年华为杯的赛题，几乎每一道都是综合题：数据清洗、特征提取、多模型对比、灵敏度分析、决策建议，五个环节缺一不可。因此，赛前一个月我们做的不是刷题，而是搭了一套“可复用的工具箱”。
工具箱分三层。第一层是代码模板：Python为主，NumPy、Pandas、Scikit-learn是基本盘。我们对数据读取、缺失值处理、标准化、常用可视化代码做了标准化封装，比赛时不需要现场查API，直接改参数就能用。第二层是算法库：常见的回归、分类、聚类、时间序列、优化求解器（如Gurobi、Scipy.optimize）都提前跑通了一遍，并且把每种算法在什么场景下容易失效的教训记录下来。第三层是论文写作模板：LaTeX追加了竞赛专用样式，图表生成统一用Matplotlib和Seaborn，颜色、字号、坐标轴密度都提前调好，让论文视觉风格一致。
这里再说一个容易被忽略的工具：版本管理。我们用Git做代码备份，服务器上同步一份，U盘再放一份。2023年比赛期间我们没有出现“代码被覆盖”的灾难，但我知道有队伍在最后一天因为文件损坏导致前功尽弃。比赛不是写作业，任何一次本地保存失败、同步冲突都可能让你损失两个小时以上，而这些时间本来应该用来打磨摘要。
2.3 提前演练：至少做一次完整模拟赛
模拟赛的价值不在于让你押中题目，而在于把“四天节奏”提前暴露出来。我们赛前两周用往年华为杯C题做了一次模拟，严格按照四天时间走，结果发现三个致命问题：第一，我们第一天花在选题上的时间超过8小时，这在正式比赛里等于自杀；第二，论文写作和建模过程完全脱节，B在第三天晚上才开始动笔，导致后面内容仓促；第三，代码质量太差，A的部分代码逻辑混乱，自己都看不懂，后续想加功能很难。
这次模拟赛之后，我们重新调整了作战节奏：第一天中午前必须定题，第一天晚上做完数据预处理，第二天全天建模和计算，第三天上午完成全部核心计算，第三天下午开始一边补计算一边写论文，第四天一整天用于论文打磨、排版和检查。这个节奏我们写成了时间表，贴在每个人电脑旁边。正式比赛时，尽管题目和模拟赛完全不一样，但流程高度可复用，心里始终有底。
当然，模拟赛还有一个重要产出，就是训练出“快速判断题目是否可做”的直觉。四天比赛里，你不可能把一个完全陌生的题目从论文读到代码实现，所以必须在最短时间内判断出这道题的“技术栈”你是否熟悉、数据量是否可控、结果好不好验证。这个直觉，只有通过真实模拟才能建立起来。
3. 选题决策：我们为什么放弃了“看起来最好做”的题
3.1 2023年赛题的整体印象
2023年华为杯赛题公布后，我们快速浏览了全部题目。总体印象是：题目来源非常贴近工业界和科研前沿，有的涉及通信系统的优化调度，有的涉及数据分析与预测，有的则偏重微分方程和物理机理建模。相较于本科阶段的竞赛，华为杯的题目在数据规模、问题复杂度、对工程背景的理解要求上都高出一截，不是光靠套模型就能应付的。
这里必须提醒一句：不要被题目字数的多少迷惑。有的题目写得非常简短，读起来像一个开放性的科研问题，反而最难，因为它需要你自行定义目标和约束；有的题给你一堆数据文件和几十页说明，看上去很吓人，但其实很多细节已经帮你限定好了，只要耐心读题就能找到突破口。我们一开始注意到一道题干很短的题，觉得发挥空间大，但仔细分析后发现，题目涉及的专业背景我们三个人都几乎没有积累，需要现场补大量领域知识，风险太高。琢磨了两个小时后，我们果断放弃。
3.2 避开“伪简单”：如何判断题目陷阱
选题时我们总结了一套“三问”测试法：第一问，这道题的核心目标是什么？能不能用一句话说清？如果说不清，说明题目本身定义模糊，后续很难做；第二问，用什么数据？数据量有多大？缺失情况是否有预案？第三问，结果的评价标准是什么？如果题目没有给出明确指标，那么论文里必须自己“造”一套合理的评价标准，这会增加很大的工作量。
以一道看起来“简单”的题为例：它给了很多文献和背景，让你提出一个改进方案。乍一看不需要写代码，只需要归纳分析，但这样的题通常是“陷阱”。因为评委无法通过分数来客观判断你的方案好坏，最终只能看论文的故事线和逻辑，这对表达能力要求极高。我们队虽然在写作上有优势，但B明确表示，如果题目缺少量化结果，她写作时也很难撑起一篇有说服力的论文。所以我们最终放弃了这种偏“文科”的题，选择了一道数据特征明显、有明确量化输出、同时包含优化决策环节的题目。
3.3 我们的最终选题与第一轮拆解
最终我们选择的赛题是那种“典型的数据+优化”问题：需要在给定大量实际数据的基础上，建立一套机制来评估某些对象的状态，并在此基础上给出最优调度或分配方案。这种类型的题在华为杯里出现频率很高，因为它能综合考察数据挖掘、数学建模、算法设计和业务理解四个维度，也最容易体现队伍的综合实力。
确定选题之后，我们在第一天下午做了一件很关键的事：把整道题拆成三个子问题，并且给每个子问题标注“必须完成时间”和“理想结果形式”。第一问是数据分析和特征提取，要求我们对原始数据进行清洗和统计，输出若干关键指标；第二问是基于这些指标建立数学模型，对对象进行综合评估；第三问是在模型基础上引入约束条件，求解一个优化问题。拆解完之后，我们立刻意识到，第三问的优化模型是整个论文的理论高峰，也是评委判断“建模深度”的关键。因此我们把最强的建模精力放在第三问，同时提醒A不要在前两问上死磕炫技模型，够用就好。
4. 核心建模过程：从问题到可计算的模型
4.1 第一问：数据预处理与特征工程
很多队伍一上来就调各种高级算法，结果连原始数据的长什么样都没搞清楚。我们在这道题上第一问花了大半天，纯粹在做数据预处理和特征工程。先把数据导入Python，逐个字段查看缺失率、异常值、分布情况，并且用可视化把关键字段画成直方图和箱线图。这个环节看起来琐碎，但恰恰是后续模型能否成立的基石——如果数据里有大量异常值，而你没有处理，后面的训练结果会被少数极端样本带偏。
我们当时遇到了三个典型的脏数据问题：数据缺失、时间戳格式不统一、某些对象的字段完全为空。缺失值我们先用中位数填充，但对于“字段完全为空”的对象，直接选择剔除，而不是强行填充，因为强行填充会引入噪声。时间戳格式不统一的问题，用Pandaso解析后统一成标准格式，并提取了“小时”“星期”等循环特征。这一步做完，我们构建了一个基本特征集，大概二十多个字段。接着用相关性矩阵筛选掉高度冗余的特征，避免后续模型出现多重共线性。
现在回看，第一问的核心产出其实不是模型，而是“对数据的理解”。我们把它写在了论文里，包括数据量、缺失比例、异常值处理方式。评委非常看重这一部分，因为它说明你的结果是建立在严谨的数据基础之上的，而不是拍脑袋建模。
4.2 第二问：模型选择与数学表达
第二问需要把这些特征整合成一个综合评价模型。我们最初考虑了两类方案：一类是传统的加权综合评分法，权重通过层次分析或熵权法确定；另一类是机器学习方法，用数据驱动的方式学习出一个得分函数。传统方法可解释性强，但需要人为设定权重，容易显得主观；机器学习方法更客观，但可解释性弱，且需要足够的标签数据。幸运的是，赛题本身提供了一些可用于验证的结果或标签，这让我们可以用监督学习来训练模型。
综合考虑后，我们采用了“主成分分析+加权得分”的多维评价框架。先用主成分分析把高维特征降维到少数几个综合因子，保留累计方差贡献率超过85%的主成分，然后用熵权法计算每个主成分的信息量权重，得到最终的综合得分。这样做的优势在于：一是有数据基础，不是纯拍权重；二是可解释性强，每个主成分都能在业务上找到对应含义；三是计算简单稳定，不容易过拟合。
不过，仅靠这个传统方法，我们觉得深度不够。为了突出建模水平，我们又在综合评价基础上引入了一个机器学习模型作为“交叉验证”：用随机森林回归对同一目标进行预测，再把随机森林的预测结果与综合评价得分做一致性分析。当两套评价体系对大多数样本给出相似排序时，说明模型稳健；当出现明显分歧时，我们就去检查是不是特征工程遗漏了关键信息。这种“机理+数据”双重验证的思路，后来被我们写进了论文，成为加分项。
4.3 第三问：优化与决策分析
第三问是整个赛题的“压轴戏”。我们需要在第二问建立的评价体系基础上，设定若干约束条件，求解一个最优分配或调度方案。这类问题本质上是约束优化问题，可以用整数规划、线性规划或者启发式算法求解。
我们一开始很自然地想到使用包含多个决策变量的整数规划模型，目标函数设为最大化整体效益，约束条件包括资源总量限制、每个对象的上下限、以及一些逻辑约束。在列写公式时，我们特别注意把目标函数和约束条件都用标准数学符号表达清楚，并且明确说明每个决策变量的物理含义。这一步做得越细，后面写论文越省力。
但在实际求解时，我们发现数据规模有点大，精确求解器跑得很慢，甚至可能出现内存溢出。这时候我们果断调整了策略：先用线性规划松弛版本求一个全局下界，再用遗传算法搜索近似最优解。两个结果放在一起对比，既体现了理论最优性分析，又展示了工程上的求解能力。为了让优化结果更可信，我们还做了灵敏性分析：随机改变资源约束的数值，观察最优目标的变化范围，判断模型是否稳定。这个环节在最终答辩和论文评审中都很加分，因为它展示了你对模型的理解不仅仅停留在“能跑出结果”，而是深入到“结果对参数是否敏感”。
4.4 灵敏度分析与结果呈现
数学建模竞赛里，结果呈现的质量往往决定了论文的档次。我们的原则是“每个结论必须配一张图，每张图必须说明一个问题”。灵敏度分析我们画了热力图，展示不同参数组合下目标函数的变化；优化结果的对比用了柱状图和折线图结合，把优化前后的效果差值用醒目颜色标出。同时，所有图表都统一采用同一套颜色主题，字体大小一致，坐标轴标题清晰，图例不遮挡曲线。
这里有个小细节：图表的数量不是越多越好，但质量必须高。我们论文里的图表，每一张都在正文里有明确的引用和分析，绝不出现“如图所示”但没有解释的情况。我们也尽量避免三维饼图、彩虹色渐变这类“看起来炫但信息量低”的可视化，评委会觉得你在掩盖内容的空洞。我们的图表库里，最常用的其实是散点图、箱线图、热力图和折线图，朴素但信息密度高。
5. 论文写作：把“做出来的东西”变成“评委看得懂的东西”
5.1 摘要写作：竞赛论文的半条命
如果你问任何一个参加过数学建模竞赛的获奖选手：“论文哪部分最重要？”答案几乎都是摘要。评委初审时，一篇论文可能只看摘要和结论，就初步定了档次。特别是比赛提交量巨大的情况下，摘要写得清晰与否，直接决定了你的论文是被精读还是被快速扫过。
我们写摘要有一个固定的“五句话”框架：第一句写研究背景和问题目标；第二句写数据来源和预处理思路；第三句写第一问/核心评价模型；第四句写第二问/优化决策模型；第五句写灵敏度分析和结果结论。每句话都要有具体的数值或方法名称，不能泛泛而谈“建立了综合评价模型”“提出了优化算法”——这等于什么都没说。要写“基于熵权法的主成分综合评价模型”，要写“采用遗传算法在资源约束下得到全局近似最优解，总效益较当前方案提升12.3%”。
另外，摘要必须单独成页，字数控制在800字以内，但信息密度要非常高。我们在正式提交前一天反复朗读摘要，发现任何一句“读起来不顺”都可能是信息冗余或者逻辑跳跃。最终版摘要，我们三个一起盯着改了十几遍，确保评委在60秒内能完全抓住我们的模型链条。
5.2 图表体系与可视化的三个原则
论文写作过程中，最容易出现的问题就是“图和文字分离”。很多队伍先跑完所有代码，再让写论文的同学对着图表编故事，结果图和文字经常对不上。我们的做法是：每完成一个子问题，马上让B去写这个子问题的结果描述，A负责把相关图表生成好，我来把关公式和逻辑。这样每一节的图和文字都是一起生长的，不存在最后“补图”的尴尬。
可视化的核心原则有三个。第一，图要自洽：单独看图，不读正文，也能大致明白它的结论。所以每张图都要有清晰标题、图例、坐标轴标签和关键注释。第二，表要规范：超过三行的数据，全部用三线表，数字保留有效数字，并标注单位。第三，图与图之间的比例和配色要一致，不能第一张图是蓝色，第二张变成了绿色。彩色打印并不是常态，所以我们的配色即使转成灰度也不会丢失信息，用不同的线型和标记辅助区分。
我们还做了一个很细节但很有用的操作：每张图下面加一句“图注”，这句话直接由我和A在生成图时口头说给B听，B再整理成规范文字。这样做的好处是，B不需要重新理解算法细节，也能准确描述图里的信息，极大减少了沟通成本。
5.3 附录与代码组织的细节
论文附录里放代码是竞赛的常见要求，但评委大概率不会仔细读完整段代码，而是会看代码结构是否清晰、注释是否到位、能不能看懂关键实现。我们队以把最容易复现代码贴在附录，同时只保留核心算法，不贴几十行数据清洗过程。每个函数都写清输入输出和关键参数，变量命名使用有意义的英文名，不在代码中出现任何无关的实验性片段。
代码本身我们也做了压缩和整理，整体体量控制在附录允许的范围内。值得一提的时，我们提交的代码包里包含一个README文件，说明如何运行，需要哪些依赖库，运行结果大概是什么。这个细节不算分数，但能体现你们队伍的专业态度。评委如果恰好对你的算法感兴趣，愿意跑一跑你的代码，一套清晰的工程结构会给他留下极好的印象。
总结一下论文写作的心态：你要假想评委是一个水平不低但完全不了解你题目背景的人，你的论文要让他不费力地看懂你们做了什么、为什么这么做、结果是否可靠。任何“高深”的模型，如果不能在论文里被清楚地解释，都会变成扣分项，而不是加分项。
6. 四天比赛的时间管理与现场操作
6.1 每日作战计划
我们赛前制定的四天节奏，在实际比赛中基本得到了严格执行。第一天上午完成全部赛题浏览和初步可行性分析，中午前定了题；第一天下午到晚上，全部时间用在数据预处理上，期间A用脚本分批检查数据质量，我在草稿纸上列模型候选方案，B开始搭建论文框架、填写背景和问题重述部分。第一天的经验是：绝不熬夜。如果第一天就通宵，后面三天状态会崩，性价比极低。
第二天是“建模日”。上午我们完成了第一问的完整建模和结果输出，下午开始做第二问。第二问的模型迭代比较耗时，前后尝试了三个版本：先跑基线模型，然后改进特征选择，再引入随机森林交叉验证。这个过程中，我和A频繁交流算法细节，B则通过看我们生成的图表和公式同步理解模型，为晚上动笔写初稿做准备。第二天晚上我们工作到凌晨一点，但保证了必要睡眠。
第三天是最关键的一天，我们的目标是“把所有核心结果都算完”。上午完成第二问的最终版本，下午集中攻坚第三问优化模型。优化求解时遇到性能问题，我们临时调用启发式算法，最终在晚饭前得到了完整的优化结果。晚饭后，我们把三问的结果目录发给B，B通宵整理成果材料，我和A则把灵敏度分析补完，并整理出摘要初稿。第三天晚上是唯一真正熬大夜的时间，不过因为前期节奏好，我们并没有感到极度混乱。
第四天看似轻松，实际上分水岭就在这一天。上午我们把重点放在摘要、结论、模型评价上，下午开始逐字检查全文，包括公式编号、图表引用、参考文献格式、附录代码的完整性。我们还做了一件很重要的事：把论文打印出来，三个人各自完整读一遍，拿红色笔圈出所有“看起来不顺眼”的地方。这个习惯帮助我们发现了大约十几处逻辑不通和错别字，避免了提交前最后的低级失误。
6.2 版本管理与文件备份
四天比赛会产生大量文档、代码、图表和中间版本，如果没有一套文件管理规范，后期一定会混乱到想哭。我们在开赛当天就建立了统一个文件目录，以“赛题序号/子问题/版本号”为层级，例如“Code/Q2/v3_feature_select.py”代表第二问第三个版本的特征选择脚本。每个文件在命名里都体现时间或版本，绝不使用“final_final.py”这种命名方式。
代码和论文分别用Git和云文档双备份。每天中午和晚上固定两次提交，把当前所有更新同步到服务器。比赛现场的网络环境并不总是稳定，我们不依赖单一工具。论文使用LaTeX时，每过半小时就Ctrl+S，并且保留主文件的所有历史版本。这里特别提醒：永远不要只靠“自动保存”。我们B有一次差点因为磁盘空间满了丢失最新版本，从那之后，她每写两三段就会手动另存一个版本号。
6.3 突发状况处理
比赛第三天下午，我们的第三问求解速度越来越慢，一度怀疑是不是模型约束条件写错了。当时我先停下来检查约束矩阵的稀疏性，发现有个约束条件因为索引错误导致数量爆炸，修正后速度立刻恢复。这个教训告诉我们：遇到性能问题，先检查代码逻辑有没有“约束重复”，而不是急着换算法。
另一次突发状况是A的Python环境突然崩了，很多依赖库无法导入。因为我们所有代码都有标准化的requirements.txt文件，直接在另一台电脑上重建虚拟环境，几分钟就恢复了。所以，赛前一定要准备好环境备份，至少保证队伍里有两个人可以独立运行整套代码。如果环境依赖出现问题才开始折腾，很可能在最后一天占用大量宝贵时间。
7. 常见问题与避坑实录
7.1 数据问题：缺失值、异常值与量纲陷阱
数学建模竞赛的数据题，数据质量几乎永远是最大的坑。我见过很多队伍直接拿原始数据进模型，结果因为量纲差异过大，距离类算法完全失效；也见过有队伍把缺失值全部填0，导致模型训练出明显偏差。我们的经验是：先做缺失率统计，缺失率超过50%的字段谨慎使用；对于异常值，不只是简单剔除，要判断异常值有没有可能本身携带着关键信息——比如某些极端情况恰恰是论文要讨论的核心场景。
量纲问题，我们会在特征标准化前先做一次“业务量纲”的思考。比如某些特征天然是比率值，有些是绝对值，直接标准化可能会抹掉它们的业务含义。所以对于比率类特征，我们一般保持原值，只在模型输入时标准化。这些细节在论文里也要点出来，它体现了你的工程判断力。
7.2 模型边界：为什么训练集很好的模型分数不高
很多队伍在第二问会陷入“刷分数”的怪圈，不断调参让模型在已知数据上表现完美。但是竞赛题往往存在测试集或评价标准的不同，你在自己手里的样本上表现好，不一定能应对未知数据。我们的原则是：模型不能只看拟合，要看泛化。所以我们在建模过程中留了一部分数据作为验证集，并且用交叉验证来评估稳定性。如果某个模型在训练集上达到了98%的准确率，但在验证集上只有80%，那我们就会果断放弃这个模型，而不是强行解释这个差距。
另一个容易出问题的点是“模型复杂度”。华为杯评委通常在论文评审中更看重“可解释性”，一个简单模型加上清晰的业务解释，往往比一个复杂黑盒模型更受好评。我们并没有使用深度学习，而是选择了传统统计模型和机器学习模型结合，原因之一就是它们可解释性更强，能写出更清晰的公式和逻辑链条。
7.3 论文格式与提交：功亏一篑的低级失误
每年都有队伍因为忘记检查PDF打印质量、公式编号错乱、附录缺失而被扣分。我们队把最后一天的下午完全留给了“格式审查”。逐页检查公式是否溢出边界、图表编号是否连续、参考文献是否都有正文引用、页眉页脚是否正确。有时候一个公式过长导致编译警告，我们也会花时间调整，而不是忽略它。
提交之前，我们把论文PDF在线预览了两次，确保无乱码。另外，所有提交材料统一用压缩包，压缩包内文件层级清晰。我们在压缩包解压后试运行了代码，防止出现“代码能跑但提交版本是坏文件”的惨剧。这些都是最无聊但又最重要的活儿，却是决定你能不能拿到一等奖的最后一环。
7.4 团队沟通：比赛到一半想换题怎么办
第四种常见问题是团队内部在比赛中期产生动摇，觉得“这道题做不下去了，要不要换个题”。我们队在第二天下午也经历过类似的动摇，当时第二问的模型效果一直不理想，大家情绪很低落。我作为建模负责人，做了一个关键决定：不换题，而是把目标缩小。我们重新定义第二问的“最小可行结果”——哪怕精度不高，先把完整流程跑通，再逐步优化。这个策略避免了推倒重来的灾难性后果。
如果你在比赛中也遇到这种情绪，我建议使用“三小时止损法则”：如果当前问题经过三小时尝试后仍然没有任何进展，才考虑换一个子问题或调整思路；否则就坚持原路线，因为重新选题的成本远大于你想象的。四天比赛最怕的就是不断推翻、不断重来，最后什么都只做了一半。
8. 比赛后的复盘思考
8.1 我们做对了什么
回头看，我们做对的第一个决定是在赛前建立了“以写作为中心”的流程。所有建模和代码工作都以论文内容为导向，而不是“先把算法跑出来再写论文”。这种思路让我们避免了最后一天疯狂赶工的狼狈。第二个决定是选题时刻意避开纯背景分析类题目，选择了有客观数据、有明确量化结果的题目，让我们的模型有据可评。第三个决定是在优化问题遭遇性能瓶颈时，果断采用精确算法和启发式算法的组合，既保证了理论深度，又保证了工程可行性。
这些经验不一定适用于每一个人，但放在2023年华为杯这套赛题下，确实非常有效。比赛评奖从来不是单维度的“数学模型比拼”，而是综合实力的竞争，数据和工程能力同样重要。
8.2 我们做错或差点做错的事
我们也有过明显的失误。第一是第一天上午选题时，我们花了很长时间纠结一道“看起来有意思”的题目，结果发现它需要大量领域知识，白白浪费了三个小时。如果早点使用三问测试法，就能更快排除它。第二是第二问建模时，A一开始为了实现更好的精度，把特征工程做得很复杂，导致变量数爆炸，模型训练速度骤降。后来我们用主成分分析降维，才回到正轨。这说明“克制”是建模竞赛里非常重要的能力，不要为了炫技而堆砌无用功。第三是我个人在第三天通宵时精神状态下降，导致审摘要时不够仔细，摘要里有一处表述不准确，第二天早上被B发现并及时改正。竞赛再紧张，也要保证决策质量。
8.3 对后续参赛者的一点建议
如果你正在准备下一届华为杯，我最想告诉你的是：不要迷信“天赋型选手”的故事。拿到一等奖的队伍，大多是在备赛阶段把流程练成了肌肉记忆。建议你至少提前六周开始准备，前三周侧重熟悉往年题目和算法库，第四周和第五周做至少两次模拟赛，最后一周只做两件事：完善自己的论文模板和整理错误清单。
比赛期间，把“完成比完美重要”这句话贴在电脑屏幕边上。你不需要在四天里创造一个惊天动地的模型，你需要的是把一个完整、自洽、有数据支撑、能讲清楚的故事呈现在评委面前。这一等奖里的七成，都是这种“讲好一个故事”的笨功夫。
我个人在赛后反复回味的一个体会是：数学建模竞赛不是学术研究，它是一种“限时工程实践”。能够在高压下定义问题、拆解任务、用有限工具产出可靠结论的人，才是评委真正想找到的人。拿到一等奖当然高兴，但更宝贵的是，你真的会带着这一套方法论进入后面的科研和工作中，遇到任何复杂问题时，你都会下意识地开始拆解它、量化它、并且寻找一个可验证的解法。这个习惯，比奖状本身更值钱。
