1. 从“解题”到“解题+”：一次建模竞赛的深度复盘

又一年MathorCup落幕，作为连续几年都带着学生队伍参赛，自己也偶尔下场“客串”指导的老兵，每次赛后复盘，总感觉比比赛本身更有价值。2023年的MathorCup，给我的整体印象是：它正在从一个纯粹的“数学建模能力测试场”，悄然向一个更综合的“问题解决与工程实践预演场”转变。如果你只是把它看作一道放大了的数学题，那可能只看到了冰山一角；今年的赛题，尤其是A、B两道大题，对参赛者的要求已经远远超出了建立模型和求解算法的范畴。

为什么这么说？因为题目里埋的“坑”，或者说设计的“挑战点”，越来越贴近真实产业场景中的复杂性。它不再问你“理论上最优解是什么”，而是问你“在诸多现实约束下，一个可行的、可解释的、甚至要考虑落地成本的方案是什么”。这其中的差别，就像从解一道完美的几何证明题，到去设计一栋能抗八级地震、兼顾采光与造价、还得让住户觉得舒服的大楼。评价这样一场竞赛，就不能只看最后论文里公式漂不漂亮，更要看队伍在整个过程中，是如何拆解模糊问题、处理脏数据、权衡多目标，以及最关键——如何将数学语言翻译成决策者能听懂的业务语言的。接下来，我就结合今年赛题的特点，聊聊我的观察和思考。

2. 赛题风向标：从理想模型到“带刺的玫瑰”

纵观今年的几道赛题，一个非常明显的趋势是：“干净的”理想化场景在减少，“毛糙的”现实问题在增加。出题人似乎有意在模拟科研或工程中最初接到任务时的状态：信息不全、需求模糊、数据质量参差不齐。

以典型的A题（通常是优化类或预测类）为例，往年可能给一个结构清晰的数据集，要求你预测未来趋势。但今年，题目中可能嵌套了多个环节的数据缺失、量纲不统一，甚至存在明显的逻辑错误或异常值。它不直接告诉你“请处理异常值”，而是把问题藏在一个更大的背景描述里。这就要求队伍首先得具备强大的问题界定与数据诊断能力。你得像侦探一样，从题目描述和杂乱的数据中，还原出业务本来的逻辑链条，判断哪些数据是可信的，哪些是“噪音”，甚至要基于常识和领域知识去补全或修正数据。

例如，某道涉及供应链调度的题目，给出的历史运输时间数据里，就混入了几个明显不符合物理规律（如速度超过音速）的离群点。新手队伍可能直接拿平均值或中位数去填充，但老手会多问一句：这个异常是记录错误，还是代表了某种特殊事件（如紧急空运）？如果是后者，在建模时是应该剔除，还是单独建立一个“应急模式”？这种判断，没有标准答案，但你的处理方式和理由，恰恰体现了对实际问题理解的深度。这不再是单纯的数学技巧，而是数据素养与业务直觉的结合。

B题（通常是评价、决策或机理分析类）则体现了另一个趋势：多目标与评价体系的复杂性。题目很少会直接给出一个明确的、量化的、单一的目标函数。更多时候，它会描述一个涉及多方利益、多个维度的决策场景，比如既要经济效益高，又要环境影响小，还要社会满意度好。你需要自己从描述中提炼出关键的评价指标（KPI），并为这些常常相互冲突的指标设计合理的权重或妥协机制。

这里最大的陷阱在于，许多队伍会不假思索地直接套用层次分析法（AHP）或熵权法去确定权重。但评委想看到的，恰恰是你为什么选择这个方法，以及权重背后的逻辑。例如，在涉及公共政策的题目中，“公平性”和“效率”的权重，就不能仅仅通过数据计算得出，而需要结合题目背景进行价值判断和论述。你的模型，实际上是你价值观和问题理解的一个数学化呈现。忽略这一点，模型再精巧，也容易显得“不接地气”。

3. 解题工具箱：什么在“卷”，什么被忽视？

在这样的大趋势下，参赛队伍的技术栈和准备策略也在悄然变化。说几个我观察到的现象：

第一，编程与可视化能力成为新的“硬通货”。早些年，能用MATLAB解出方程、用SPSS跑个回归，就算技术不错了。但现在，这几乎是入门门槛。Python因其强大的数据科学生态（Pandas, NumPy, Scikit-learn）和丰富的机器学习库，已经成为绝对主流。但更“卷”的是可视化。评委在短时间内审阅大量论文，清晰、美观、信息量大的图表是抓住眼球的关键。动态图、交互式图表（虽然论文里是静态截图，但可以说明你做了）、地理信息可视化（如果赛题涉及）等，都能极大提升论文的专业感和表现力。像用Plotly、Pyecharts做出的图表，就比Matplotlib默认样式更具冲击力。但这也有个度，切忌华而不实，图表的核心是服务于结论阐述，而非炫技。

第二，机器学习模型从“加分项”变为“常规武器”，但理解深度是分水岭。随机森林、XGBoost、神经网络，这些名词在论文里已经司空见惯。单纯地调用sklearn的API跑出一个结果，价值已经不大。评委更关注的是：你为什么选择这个模型？你做了哪些特征工程？模型的参数是如何调优的？（是网格搜索，还是基于对模型原理的理解进行手动调整？）你如何评估和解释模型的结果？（例如，用了SHAP值进行特征重要性分析吗？）对于预测类问题，如果两支队伍精度相差无几，那么那个能清晰阐述模型决策过程、能进行误差分析的队伍，无疑会占得先机。这意味着，对机器学习“黑箱”进行“白盒化”解释的能力，越来越重要。

第三，传统运筹优化与启发式算法找到新舞台。在A类复杂的优化问题中，当问题规模稍大，精确算法（如单纯形法、分支定界）可能无法在有限时间内求得最优解。这时，遗传算法（GA）、模拟退火（SA）、蚁群算法（ACO）等启发式算法就有了用武之地。但这里的关键不是简单套用代码，而是针对具体问题设计高效的编码（染色体）方式、适应度函数以及进化操作。比如一个路径规划问题，你的染色体是直接编码城市序列，还是采用更高效的“随机密钥”表示法？你的交叉算子是否能有效保留父代优良片段？这些细节的设计，直接决定了算法的效率和最终解的质量。能在这方面展现出定制化思考和创新的队伍，会非常亮眼。

第四，一个被普遍忽视的“软技能”：文档与代码的规范性。很多队伍把全部精力放在建模和写作上，提交的代码往往是一堆杂乱无章的脚本，变量命名随意，没有注释，运行依赖不明确。这在越来越强调可复现性的学术环境下，是一个隐形失分项。一个结构清晰、有README说明、用函数封装关键步骤、甚至写了单元测试的代码仓库，不仅方便自己调试和队友协作，更能向评委传递出严谨的科研态度和工程素养。这虽然可能不是评分细则里的明文规定，但绝对是高下立判的“印象分”。

4. 论文写作：从“证明过程”到“说服艺术”

论文是竞赛成果的唯一载体，其写作思路也在进化。它不再是一份数学证明的详细记录，而更像一份给领域专家或决策者看的技术报告或商业计划书。

摘要的“黄金三百字”是生死线。评委时间有限，摘要必须用最精炼的语言，讲清楚五个要素：1.问题是什么（用一两句话概括）；2.我们用了什么方法/模型（列出核心模型名称，如“建立了基于XGBoost的预测模型和结合模拟退火的多目标优化模型”）；3.我们得到了什么结果（给出关键数值结论，如“预测精度达到92.5%，优化后成本降低15%”）；4.我们的模型有什么优点（如“考虑了XX实际约束，具有较好的鲁棒性”）；5.得到了什么结论或建议。这五条，缺一不可，且要逻辑连贯。切忌在摘要里写细节推导和背景铺垫。

模型建立部分需要“双向翻译”。很多论文在这一部分直接堆砌公式，缺乏从“实际问题”到“数学语言”的过渡。好的写法应该是：先阐述针对问题的某个方面，我们计划采用什么思路（业务逻辑）；然后说明为了实现这个思路，我们引入了哪些假设和变量（模型假设）；最后才是具体的数学公式定义。例如，不要直接写“设目标函数为min Z = ...”，而应该写“为了最小化总运输成本，我们定义成本Z由固定成本和可变成本构成，其中可变成本与运输距离和货物重量相关，据此建立目标函数如式(1)所示”。这样读起来，才知道你的每一个公式都不是凭空产生的，而是为了解决一个具体的子问题。

结果分析要“有血有肉”。这是区分平庸与优秀论文的关键区域。不要仅仅展示几张图和几个表格，然后说“由图X可知，结果很好”。要深入挖掘数据背后的故事：

• 对比分析：你的结果和基准方法（或简单方法）比，好在哪里？为什么好？
• 灵敏度分析：模型中的关键参数（如权重、惩罚系数）变化时，结果如何波动？这说明了模型的什么特性？（是稳健的，还是对某些参数特别敏感？）
• 场景分析：如果某个外部条件发生变化（如需求增加20%），你的方案是否依然有效？如何调整？
• 归因分析：对于预测或分类结果，哪些因素是最重要的？你能从业务角度解释为什么是这些因素吗？

这些分析能将你的论文从“我们算出了一个答案”提升到“我们理解了这个问题的深层规律”的层次。

可视化图表的“心机”。一图胜千言，但图要会说话。折线图用来展示趋势，柱状图用于比较，散点图看相关性，热力图呈现矩阵或地理数据。每个图表都必须有自解释性的标题（不是简单的“图1：结果”），坐标轴标签清晰，必要时添加标注线或文字说明突出关键点。例如，在展示优化前后对比时，可以用双Y轴柱状图，或者用更直观的“旋风图”。将最重要的发现，用最直观的图表呈现出来。

5. 团队协作：三个大脑如何拧成一股绳？

数学建模是典型的团队作战，三个人的配合好坏，直接决定了72小时是高效冲刺还是混乱内耗。理想的分工是建模手、编程手、写手各司其职，但现实往往更复杂。

最理想的节奏是“螺旋式推进”，而非“流水线作业”。很多队伍采用“第一天建模、第二天编程、第三天写作”的线性模式，风险极高。因为建模者的想法可能无法实现，编程者可能发现数据有问题，写作者可能根本看不懂模型。更好的方式是：在第一天，三人就共同吃透题目，建立一个初步的、统一的问题框架和解决路线图。哪怕只是一个粗糙的思维导图。然后，建模者和编程者紧密协作，用最快的时间（比如头12小时）搭建一个最小可行模型（MVP），跑通一个最简单的案例，验证技术路线的可行性。写手此时就可以开始撰写问题重述、文献综述等前期部分，并密切关注MVP的进展。

一旦MVP跑通，团队就进入了“建模-实现-验证-写作”的快速迭代循环。建模者深化模型，编程者实现并调试，写手则不断将已确定的结果和分析转化为文字，并随时准备根据新发现调整论文结构。这个过程里，每日至少两次的集中讨论会至关重要，同步进展，解决卡点，调整方向。写手不是最后环节的“打字员”，而是贯穿始终的“整合者”和“质检员”，需要不断向建模和编程的队友提问，确保自己真正理解，才能写出准确的论文。

沟通的“暗礁”：专业术语与思维差异。建模手满脑子数学符号，编程手思考的是算法复杂度，写手关心的是叙述逻辑。经常出现“我这个东西很简单啊”但对方完全听不懂的情况。解决之道在于建立团队的“共同语言”。多用白板或绘图工具画示意图，用具体的、简化的小例子来解释抽象概念。编程手在给出结果时，不能只丢一个数字，要解释这个数字是怎么来的，可能有什么误差。写手在描述模型时，要反复向建模手确认：“我这样写，能准确表达你的意思吗？外行人能看懂吗？”

版本管理是生命线。强烈建议使用Git（配合GitHub或Gitee）来管理论文（LaTeX或Word）和代码。每天定一个提交节点，避免因误操作或电脑故障导致前功尽弃。对于论文，写手负责主分支，建模和编程的队友可以在各自分支上撰写自己负责的章节或提供素材，通过合并请求（Merge Request）进行整合。这能极大减少“最后时刻合稿”的混乱和冲突。

6. 给未来参赛者的几点务实建议

基于今年的观察，给打算参加未来MathorCup或类似比赛的同学几条非常具体的建议：

1. 技能准备上，要“一专多能”。每个人固然要有侧重点，但壁垒不宜过高。编程手至少要能看懂模型的大致逻辑和论文里的公式；建模手要了解基本算法的原理和局限性，知道什么模型大概需要什么样的数据输入；写手最好能运行一些简单的脚本，生成基础图表。这样协作起来才没有盲区。

2. 知识储备要“广而深”。“广”是指要对各类常见模型（预测、分类、优化、评价、聚类）都有所了解，知道它们能解决什么问题。“深”是指在队伍选定的一两个主要方向上（比如机器学习、运筹优化），要钻得足够深。不仅会用工具包，还要读一两篇经典的综述或教材章节，理解其数学原理和演进脉络。这样在选题和遇到困难时，才有更多的备选方案和调整空间。

3. 实战演练至关重要。在赛前，至少用2-3道往年的赛题进行48或72小时的全程模拟。严格按照比赛时间，从下载题目、讨论、建模、编程到写作、提交。赛后进行彻底的复盘：时间分配合理吗？沟通顺畅吗？遇到了什么意料之外的问题？这次模拟暴露的问题，就是你们备赛最需要弥补的短板。很多队伍第一次合作就是在正式赛场上，那种磨合成本是巨大的。

4. 学会利用工具，但别依赖工具。ChatGPT等AI工具在信息检索、代码调试、甚至写作润色上确实能提高效率。你可以用它来快速生成某个算法的代码框架，或者帮你解释一个复杂的概念。但是，绝对不能让它替你思考模型架构、分析结果、或者撰写核心论述。评委很容易分辨出哪些是机器生成的泛泛而谈，哪些是经过深入思考的真知灼见。工具是“副驾驶”，你才是“司机”。

5. 保持心态弹性，管理预期。72小时的高强度竞赛，一定会遇到卡壳、争论和疲惫。事先约定好争议解决机制（比如投票，或者以建模手的意见为主）。遇到难题时，不要钻牛角尖，及时退一步，看看是否有更简单的替代方案。记住，完成比完美更重要。一个完整、自洽、表述清晰的解决方案，远胜过一个半途而废的“完美”构想。享受团队为一个共同目标脑力激荡的过程，这份经历本身，就是比赛最大的收获之一。

回过头看，2023年的MathorCup像一面镜子，映照出当前高等教育对复合型创新人才的需求变化：不仅要会解“题”，更要会解“事”。它考验的不仅是数学和编程的硬技能，更是问题定义、数据思维、权衡决策、团队协作和沟通表达的软实力。对于参赛者而言，无论最终成绩如何，这段在高压下将知识转化为解决方案的极限体验，以及过程中暴露出的知识盲区和能力短板，才是通往真实科研和工程世界最宝贵的敲门砖。