企业官网建设流程全解析

凌晨两点半，实验室只剩下三个人对着三块屏幕，一个人调参、一个人画图、一个人往 Word 里贴公式，桌上摆着已经凉透的外卖。这是华为杯研究生数学建模竞赛的第三天夜里，也是绝大多数参赛队的真实状态。数学建模这件事，外人看着像是"写论文比赛"，真正下场做过的人才知道，它更像是一次三天限时的迷你工程交付：题目是甲方需求，附件是原始数据，论文是验收文档，而评委只看你交上去的那几十页。华为杯作为研究生阶段关注度很高的建模赛事之一，题目偏工程、偏应用，对模型的落地性要求比本科生国赛更硬一些，所以备赛思路也不能照搬本科那套。下面这些内容，是我自己和身边几支拿过奖、也翻过车的队伍反复讨论后整理出来的，从赛制理解、选题、建模、编程、写作到提交，尽量把每个环节"为什么这么做"讲透，适合第一次参赛的新手，也适合打过一两次但成绩卡在中间的队伍。

1. 先把赛制拆开看：华为杯到底在考什么

很多人备赛的方式是直接开始刷题，连比赛规则都没完整读过一遍，结果到了赛场上才发现附件里有个说明文档没看、提交格式写错、论文里带了学校名字。这类失误看着低级，但每年都会真实发生，而且一旦触发就是直接扣分甚至作废。备赛的第一步应该是把赛制当成一道阅读理解题做掉，把官方通知、竞赛章程、论文格式要求、提交说明全部打印出来读一遍，重点标注时间节点、文件格式、页数限制、是否盲审这几项，因为这些是硬约束，不会因为你模型做得好就网开一面。

1.1 三天赛程的真实节奏

华为杯的赛程通常集中在秋季学期初，连续三天左右，具体开赛与截止时间每年以官方通知为准。真正的节奏不是"三天平均用力"，而是明显前松后紧：第一天上午读题选题，第一天下午到第二天上午完成主体建模和初步求解，第二天下午到第三天上午是反复调优、补做灵敏度分析、补齐图表的高峰，最后半天几乎全部用来排版、检查、导出、提交。这个分布决定了你的时间预算应该怎么切——真正留给"从零想出一个新模型"的窗口其实只有第一天到第二天上午，后面的时间基本都在打磨和验证，所以不要把核心创新点拖到第二天晚上才开始想。

还有一个很多人忽略的点：赛程中间一定要安排睡眠。听起来像废话，但连续熬夜到第三天的人，写出来的论文逻辑是断的，公式会抄错，图表会贴反。比较实际的做法是三班倒式的"错峰休息"，保证每个时间点至少有两个人清醒，另一个睡两到三小时，轮换着来。三人队里如果两个人同时崩掉，剩下的那个人基本就放弃治疗了。

1.2 评委的评分链路与我见过的失分方式

评委评一份论文的时间通常很有限，阅读顺序基本是：摘要、图表、结论、模型部分，最后才回头看细节推导。这就意味着你的论文必须"倒着写"——先把最想让评委看到的东西放在最显眼的位置。我见过太多队伍模型其实做得不错，但摘要里通篇是"本文建立了某某模型，进行了求解"，一个具体数字都没有，评委看完摘要不知道你到底算出了什么结果，这就是把分数主动送出去。

常见的失分方式，我大致归成四类，你可以在备赛阶段对着自查：

1.3 研赛和国赛不是一回事

打过本科生国赛的同学要注意，研究生赛事的题目风格差别不小。国赛的A、B题偏机理与物理建模，C题偏数据，整体上"给定条件明确、标准答案边界清晰"的题更多；而研究生赛的题目往往更接近真实工程问题，题干更长、约束更模糊、可选路径更多，甚至有些题目本身就带着"没有唯一正确解"的属性，比的是谁的方案更自洽、更可落地。奖项方面，一等奖的名额占比很低，具体比例每年不同，以官方公布为准，但可以确定的是竞争集中度很高，靠"套一个现成模型"很难突围。下面这张对照表是我按经验整理的，帮你快速切换思路：

2. 选题那半小时比后面三十小时更贵

每年赛题发布后，最常见的画面是三个人围着六道题，二十分钟后队长拍板"就做C题吧，数据多看起来好写"。这个决定往往决定了整场比赛的下限。选题不是选"看起来简单"的，而是选"你们这支队能在三天内做出完整闭环"的。所谓完整闭环，指的是从数据或条件出发，能建立模型、能算出结果、能验证结果、能写出一篇自洽的论文，缺任何一环都会在最后一天集中爆雷。

2.1 读题的三个动作

我建议的读题流程是"三遍法"，总共花40分钟到1小时，不要省。

第一遍快速扫，只看每道题的问题编号和最后一句问的是什么，判断题型：是预测、优化、评价，还是仿真。这一遍的目的是排除掉明显不在你能力圈里的题，比如完全没接触过流体力学却硬上机理建模题。

第二遍精读，重点看三样东西：附件里给了什么数据、问题之间是否有递推关系、有没有给出评价指标。附件数据量、字段含义、是否有缺失，直接决定你后面几个小时是花在清洗数据还是花在建模上。问题之间的递推关系也很关键——如果第四问要用到第二问的模型输出，那你的第二问就不能随便糊弄。

第三遍是带着"最坏情况"读：假设第一问就卡住，你们队有没有备选路径；假设某个关键参数拿不到，能不能用假设代替并在论文里说清楚。这一遍读完，再决定选哪道题。很多人省掉第三遍，结果第二天下午发现某个必需的数据根本不在附件里，只能临时编参数，论文的说服力立刻掉一个档次。

2.2 六道题的类型分布与队伍技术栈匹配

研究生赛题一般会覆盖几大类：机理仿真与工程建模类、优化调度类、数据分析与预测类、评价决策类，以及交叉学科或管理科学类。不同类别对技能栈的要求差异很大，选错类型等于让写代码的人去干推导，让推导的人去写论文。

• 机理仿真类：需要微分方程、物理量纲分析、数值求解（Runge-Kutta、有限差分）。适合物理、机械、能源背景的队伍。
• 优化调度类：需要线性/整数规划、启发式算法（遗传、模拟退火、粒子群）、多目标优化。适合运筹、自动化、计算机背景。
• 数据分析与预测类：需要特征工程、时间序列、机器学习模型。适合统计、计算机、经管背景。
• 评价决策类：需要熵权法、层次分析、TOPSIS、模糊综合评价。适合管理、经济背景，也是最容易出"看起来完整但没有灵魂"的论文的一类。
• 交叉学科类：题干长、背景杂，往往需要自己定义问题边界，适合阅读理解和抽象能力强、跨专业搭配好的队伍。

队伍组建时最好保证"一个会推公式的、一个会写代码的、一个会写文字的"这三条腿都有，但千万别把分工做成硬隔离。我见过最舒服的三人组是：每个人都能建模、能写代码、能写字，只是主攻方向不同，这样任何一环卡住都有人临时补位。

2.3 一个可落地的选题决策表

把主观判断变成打分，能显著减少"拍脑袋选错题"的概率。下面这张表可以按你们的实际情况调整权重，赛前就定好，赛场上直接套用：

打分做完之后，如果前两名只差一两分，选那个"第一问就能明确动手"的题。开门能动手，队伍的状态和士气完全不一样，这在三天赛程里非常真实。

3. 从附件数据到可求解模型：建模主线怎么走

建模最忌讳的是一上来就翻工具箱："这题用LSTM吧""这题上遗传算法吧"。工具是最后一步，前面还有大量判断工作。我给一个比较通用的推进顺序：先看数据能支撑什么，再看问题要什么，最后才看用什么方法把这两者接上。这个顺序反过来做，大概率会得到一份"方法很炫但和题目关系不大"的论文。

3.1 数据先过一遍"体检"

拿到附件数据，别急着建模，先花一小时做数据体检，我一般按这几项过：

1. 规模与结构：多少行、多少列、每列什么类型、有没有多张表需要关联。
2. 缺失情况：哪些字段缺、缺多少、是随机缺失还是成片缺失。成片缺失往往意味着数据采集本身有问题，需要在论文里说明处理方式。
3. 异常值：用箱线图或三倍标准差粗筛，判断是录入错误还是真实的极端事件。这两者的处理完全相反，前者要修正，后者要保留甚至重点分析。
4. 量纲与取值范围：不同字段差几个数量级是常态，做距离类算法或聚类前必须标准化，否则大数量级字段会主导结果。
5. 时间对齐：有多个时间序列时，检查采样频率是否一致，不一致就统一到同一时间粒度，常用重采样加插值。

数据体检的结果要写进论文，别觉得"清洗数据不算工作"。恰恰相反，把清洗逻辑和判断依据讲清楚，是体现严谨性的加分点。常见做法是先描述原始数据的问题，再给出处理规则，最后报告处理后的样本量变化，形成一个可追溯的链条。

3.2 模型不是越高级越好，而是越贴合假设越好

这是我最想强调的一点。评委看过太多"用深度学习硬套小样本问题"的论文：附件只有两百条记录，上来就是一个多层神经网络，最后过拟合得一塌糊涂，测试集表现还不如线性回归。模型选择的第一原则是匹配数据规模与问题结构，第二原则才是追求性能。

我一般用一张简易的方法对照表来筛选，先确定问题类型，再在候选里挑两到三个备选，用简单版本快速跑通，比较结果之后再决定最终方案：

选完之后，一定要在论文里交代"为什么是它"，哪怕只是一句话："考虑到样本量为210且存在明显非线性，先用随机森林做基线，再与梯度提升对比，最终选用交叉验证误差更小的随机森林。"这句话的价值远超过多写一段公式推导。

3.3 以调度优化类题目为例走一遍完整链路

假设你拿到的是一道典型的调度优化题，比如需要在若干约束下安排任务顺序、分配有限资源，追求总完成时间最短或者总成本最低。这类题的推进链路大致是这样的：

第一步，把自然语言约束翻译成数学符号。用 $x_{ij}$ 表示任务 $i$ 是否分配给资源 $j$，取值0或1；用 $c_{ij}$ 表示对应成本；总目标就是最小化 $\sum_{i}\sum_{j} c_{ij}x_{ij}$。约束至少包括：每个任务必须且只能分配一次、每个资源的负载不超过容量、任务之间存在先后依赖时要有顺序约束。

第二步，判断问题规模。变量数量在几千以内且约束都是线性的，直接上求解器；变量上万或者约束里带逻辑判断，就转启发式算法。这个判断很关键，很多人一上来就写遗传算法，其实用线性规划求解器几十毫秒就能出最优解，白白浪费一天调参数。

第三步，跑出基线结果。别追求第一版就精致，先让程序跑通、输出一个可行解，把结果存成表格。有了基线，后面所有改进都能对比。

第四步，做参数与结构上的改进。比如发现瓶颈集中在某几个资源上，就尝试引入优先级规则，或者把单目标扩展成"时间最短 + 负载最均衡"的双目标，画出帕累托前沿。这一步是拉开差距的地方，因为它体现了你对问题的理解深度。

第五步，验证与敏感性分析。把关键参数上下浮动10%、20%，看结果变化幅度，如果结果对某个参数极其敏感，就要在论文里说明这个参数的设定依据，并讨论现实中的影响。

3.4 灵敏度分析：性价比最高的一块加分

灵敏度分析是所有队伍都能做、但只有一部分队伍会做的事，性价比极高。做法很朴素：选三到五个关键参数，每个参数取若干档位，重跑模型，把结果画成折线图或者热力图，观察趋势。如果结果稳定，就说明模型稳健；如果某参数一扰动结果就剧烈变化，那就是一个值得展开讨论的发现点，甚至可以单独写一小节。

我在实际操作中发现一个细节：很多人做灵敏度分析时只改参数不固定随机种子，导致结果波动里混进了随机误差，看起来模型很不稳定，其实是自己的实验设计有问题。做这类实验一定要固定种子、固定其他所有条件，只改一个变量，这才叫控制变量。另外，如果用的是启发式算法，最好每个参数档位重复跑十次取均值和标准差，否则单次结果说明不了什么。

4. 编程落地：把临时脚本改造成能扛72小时的赛题工作台

比赛和平时做作业最大的差别是：你没有时间重构代码。平时写崩了可以推倒重来，比赛时第二天上午写崩，基本就来不及了。所以备赛阶段真正应该练的，不是"会写某个算法"，而是"能在压力下不把工程写崩"。这需要赛前就准备好一套模板，赛场上只做填空。

4.1 目录结构与参数管理

我推荐一个简单到不会出错的目录结构，赛前就建好模板：

project/ ├── data/ # 原始附件，只读，永不修改 ├── src/ # 代码 │ ├── preprocess.py │ ├── model_q1.py │ └── plot.py ├── figs/ # 输出图片 ├── out/ # 输出结果表 ├── params.yaml # 所有参数集中在这里 └── paper/ # 论文文件

关键点是data/目录只读。我见过队伍在原始数据表上直接改，改到后面自己都记不清哪列是原始值哪列是处理过的，最后论文里的数据描述和实际跑的结果对不上。正确做法是读进来、处理后写到out/，原始文件永远不动。

参数全部集中在params.yaml里，别散落在各个脚本中。原因很简单：最后一天你要调参重跑，如果参数散在五个文件里，你会漏改，然后得到一组自己都解释不通的结果。集中管理之后，改一处、全部重跑，干净利落。

4.2 随机种子、结果落盘与可复现

import numpy as np import random import json SEED = 20260919 np.random.seed(SEED) random.seed(SEED) # 每次实验的结果都落盘，不要只打印到控制台 def save_result(tag, metrics): with open(f"out/result_{tag}.json", "w", encoding="utf-8") as f: json.dump(metrics, f, ensure_ascii=False, indent=2)

这段代码看着简单，但救过很多次命。第三天要核对论文里某个数字时，你翻控制台历史基本是白费劲，翻输出文件才是正解。我的习惯是每跑完一组实验就落盘一次，文件名带上参数标识，比如result_lr_s1.json、result_rf_s2.json，后面写论文时直接对照。

关于随机种子，还有一点经验：论文里如果写了"重复十次取平均"，那你必须真的能复现这十次。固定种子之后，随机性部分至少是可追溯的，评委追问时你也答得上来。

4.3 绘图脚本要独立、统一、可批量重跑

图表在建模论文里的分量很重，但很多队伍的图是"随手截的"：字号不统一、颜色刺眼、坐标轴没单位、图注位置乱飞。我的建议是把绘图代码单独放在plot.py里，赛前就定好一套样式：中文字体、字号12、线条宽度1.5、色板选一套柔和的、图片dpi设为300，然后所有图都调用同一套配置。

import matplotlib.pyplot as plt plt.rcParams["font.sans-serif"] = ["SimHei"] plt.rcParams["axes.unicode_minus"] = False plt.rcParams["font.size"] = 12 plt.rcParams["figure.dpi"] = 300 def save_fig(fig, name): fig.tight_layout() fig.savefig(f"figs/{name}.png", bbox_inches="tight")

样式统一之后，论文的观感会立刻上一个档次，而且批量重跑时不用一张一张调。这里有个真实的坑：很多人最后一天改了数据，图却忘了重画，导致论文里的图和结果表对不上。把绘图做成脚本、跑一次全出，就能避免这个问题。

5. 论文是唯一交付物：摘要和图表决定第一印象

建模做得再好，最终交出去的只有一篇论文。评委看不到你调参时的艰辛，也看不到你放弃的那些方案，他只能通过这几十页判断你的水平。所以写作不是最后一天的收尾工作，而是贯穿全程的整理工作——每完成一个问题，就立刻把方法、公式、结果写进去，别攒到最后。

5.1 摘要的六句话结构

摘要我建议用固定结构写，长度控制在600到800字，包含具体数值。结构大概是：

第一句，问题背景与目标，两三行讲清楚这道题要解决什么。第二句，总体思路，说明你用了什么方法论。第三到第五句，针对每一问，分别写"用了什么模型、关键改进是什么、得到了什么结果"——这三句里必须出现具体数字，比如"总成本较初始方案降低23.6%"或者"预测误差控制在4.2%以内"。第六句，结论与推广，说明模型的优势、局限和可扩展方向。

很多队伍摘要写不好，核心原因是结果还没算完就着急写摘要，只能写方法不能写数字。所以我建议把摘要留到最后一轮再定稿，但提前把"结果数值"这一栏填好，模型部分先写，数字最后补。

5.2 符号说明表最容易写错的地方

符号说明几乎是每篇论文的标配，但真正写对的不多。常见错误有三种：一是符号表和正文不一致，正文用了 $\alpha$ 表里写的是 $a$；二是把所有中间变量都塞进表里，搞出三四十行，评委根本不想看；三是只写符号不写单位，涉及物理量时这是硬伤。

我的做法是：符号表只列全局使用的、核心的符号，控制在15到20行以内，分三列——符号、含义、单位（无量纲就写"无"）。局部小符号在首次出现时就地解释，不放进总表。另外，公式里的每一个符号都必须在正文里有明确定义，别指望评委自己推断。

5.3 图表和排版的硬规矩

排版的规范程度直接影响评委对"专业度"的判断，这部分没有捷径，就是把规矩守住：

• 所有图表必须有编号和标题，图题在图下方，表题在表上方。
• 三线表是默认选择，不要用带花边框的表格。
• 坐标轴必须有物理量名称和单位，图例不要遮挡数据曲线。
• 公式统一编号，正文引用时写"由式(3)可得"，不要写"由上式可得"。
• 结论里出现的每个数字，都要能在正文或者附表里找到出处。
• 论文页数按当年要求控制，宁可精炼也不要堆砌无关内容。

还有一个容易被忽略的点：论文里不要出现任何能识别队伍身份的信息，包括学校名称、指导老师姓名、学号等。绝大多数这类竞赛都实行盲审，一旦出现身份信息，后果可能非常严重。定稿前用搜索功能把所有相关关键词查一遍，两分钟的事，能避免大麻烦。

6. 最后12小时与提交环节的自救清单

最后一天的混乱程度往往超出预期，因为所有工作都在收口：数据要重跑、图要重画、摘要要重写、格式要统一。这时候最需要的是流程，而不是热情。我建议在赛程还剩12小时的时候，队伍停下来开一个十分钟的短会，把剩下的任务列成清单，明确谁负责哪一项、几点前完成。

6.1 倒排时间线

一个我实际用过、比较稳的倒排安排是这样的（以截止时间为基准往前推）：

"冻结模型"这一条非常重要。总有队伍在最后十小时突然想换个方法，结果新的方法没跑通，旧的代码又被改坏了，两头落空。模型定型之后，所有精力放在表达和验证上，这才是正确的资源分配。

6.2 提交前的检查清单

提交环节的失误最不可接受，因为它和水平无关。我整理了一份检查清单，每个队伍都可以照着过一遍：

• 文件命名是否符合规则，题号、队号是否写对。
• 论文是否为PDF，是否加密，是否能正常打开。
• 附件压缩包是否符合格式要求，是否包含所有必要文件。
• 论文里是否有身份信息泄露。
• 是否所有图表清晰可读，有没有糊掉的截图。
• 提交后是否收到系统回执，是否截图留证。
• 是否有第二个设备、第二个网络环境做过备份提交尝试。

6.3 系统卡顿与常见意外

提交前一小时系统拥堵是很常见的情况，页面转圈、上传失败、验证码刷不出来，都可能发生。应对方式不是临场祈祷，而是提前准备：至少提前两小时完成打包，用两台不同的设备、两种不同的网络环境各尝试一次，文件同时存在本地、移动存储和云端三处。我还见过队伍因为压缩包过大反复上传失败的，所以打包时就该确认附件里没有塞进无关的大文件，图片和中间数据都不要往里放。

另外提醒一点：提交成功不代表结束，务必在截止时间之后保留回执截图和原始文件，万一后续有核对需求，这些都是凭证。

7. 复盘：那些年我们翻过的车

讲完流程，说几个真实度高、也最容易重演的翻车场景。这些问题和技术水平关系不大，更多是协作和判断层面的，但杀伤力一点不小。

7.1 分工崩盘与沟通断档

最典型的情况是"队长一个人干完建模和代码，另外两个人负责写论文和画图"，听着合理，实际上论文的两个人根本不知道模型在做什么，写出来的方法部分全是术语堆砌，和代码跑的东西对不上。到了第三天，队长累到说不出话，另外两个人也帮不上忙，整个队伍陷入停滞。

比较健康的做法是让每个人都深入参与建模讨论，至少做到"每个人都能讲清楚自己负责的那部分是怎么来的"。我们队后期养成了一个习惯：每六个小时做一次五分钟同步，每个人说三句话——做完了什么、遇到什么卡点、接下来两小时干什么。这个习惯成本极低，但能有效避免两个人重复做同一件事、或者某件事三个人都以为别人在做。

7.2 规则红线与学术规范

关于学术规范，有几条必须说清楚。第一，不要抄任何往届论文。竞赛通常会有相似度检测，直接搬运大段文字或者整段结构，风险极高。第二，不要照搬网上流传的所谓"完整解答"，很多是错的方向或者残缺的思路，抄进去反而把自己的框架带偏。第三，使用任何自动化工具辅助写作或编程时，必须遵守当届竞赛规则中关于工具使用的约定，规则不允许的部分坚决不做，规则允许的部分也要在必要处如实说明。第四，数据、文献引用要标注来源，哪怕是官方附件里的数据，也建议在参考文献中列出说明。

7.3 赛后复盘的用法

比赛结束当天不要立刻解散，趁记忆还新鲜，花两个小时做一次复盘：哪个环节用时超出预期、哪个判断事后看是错的、哪个工具在关键时刻掉了链子。把这些写成一个复盘文档存下来，下次备赛直接拿出来看。我个人觉得复盘的价值甚至高于多刷一套题，因为题目年年变，但你们队伍的问题模式往往很稳定，不改的话下次还会在同一个地方摔。

8. 赛前两个月的训练安排（可直接照抄）

备赛不是比赛前一周才开始的。真正有效的准备是两个月左右，节奏不用太紧，但要成体系。下面这套安排我们试过，也推荐给过身边的学弟学妹，反馈还算不错。

8.1 真题演练的节奏

赛前八周开始，前两周用于补齐短板：谁不熟优化算法就补优化，谁不熟时间序列就补时间序列，目标不是精通，而是"知道什么时候该用、能跑通一个最小示例"。第三到第六周做两到三套历年真题，建议做完整的三天限时模拟，至少做一次全流程，包括论文写作和模拟提交。第一次模拟大概率会超时和质量不达标，这很正常，重要的是把问题暴露出来。第七周专门练写作，把之前模拟写出的论文拿出来重写一遍摘要和结论，对比两版差距。第八周进入物资和环境准备，把代码模板、绘图模板、论文模板全部整理好。

真题演练时有一个建议：不要一开始就去看优秀论文，先自己做完、跑出结果、写完论文，再去看别人怎么做的。这个顺序下你才能真正看出差距在哪，否则很容易产生"我懂了"的错觉，实际动手还是不会。

8.2 优秀论文的正确读法

读优秀论文不要从头读到尾，那样效率很低。我的读法是分三轮：第一轮只看摘要和每节的小标题，梳理它的整体框架和问题拆解方式；第二轮只看它的模型部分，重点是"假设怎么提的、变量怎么设的、约束怎么写的"，这部分是真正能迁移的能力；第三轮看它的图表和验证部分，学习结果是怎么呈现的、灵敏度怎么做的。三轮下来，一篇论文大概花40分钟到1小时，收获比漫无目的地读三小时大得多。

还要注意一点：读的时候要有意识地区分"这篇论文好在哪"和"这篇论文的套路能不能套到今年的题上"。有些优秀论文的亮点在于它抓住了题目的特殊结构，这种思路是迁移不了的；而写作结构、验证方式、图表组织这些是可以直接复用的，把这两类东西分开记。

8.3 赛前一周的物资与环境清单

最后一周别再做难题了，把精力放在环境检查上。清单大致如下：

• 编程环境：Python及各主要库版本确认可用，求解器、绘图库、并行库全部装好并跑通示例。
• 代码模板：数据读取、清洗、结果落盘、绘图四类模板各准备一份，赛前跑一次确认无误。
• 论文模板：封面、目录、章节样式、公式编号、三线表、参考文献格式全部配置好。
• 数据备份：历年赛题、常用数据集、参考手册存本地一份，别依赖网络。
• 设备与网络：至少两台可用电脑，确认网络稳定，准备移动存储备用。
• 身体状态：赛前三天调整作息，别在开赛前熬夜，这条听起来像废话但真的重要。

我个人在实际操作中的体会是，比赛里真正拉开差距的往往不是谁用了更高级的算法，而是谁在混乱中还能保持流程不乱、表达清楚。能跑通一个朴素但完整、验证扎实的方案，远比一个半途而废的复杂模型值钱。赛前把模板备好，赛场上把时间切好，第一天就想清楚"我们最后要交出去的那篇论文长什么样"，剩下的就是把每一步做扎实。