lupynow/math-modeling-paper
数学建模竞赛论文写作全流程指导。覆盖国赛(CUMCM)和美赛(MCM/ICM),从论文结构规划、各章节撰写、模型检验、参考文献规范到最终格式检查。与math-modeling-solver形成"解题→写作"配对——可接收solver输出的论文草稿片段直接展开写作。当用户提及数学建模论文写作、建模比赛、国赛/美赛/电工杯/亚太杯/深圳杯/华为杯论文、CUMCM、MCM/ICM、数模论文结构、摘要写作、模型检验、灵敏度分析、latex建模模板、word建模排版、Memo/Letter写作、模型命名、Our Work流程图,或需要写/修改/优化/检查建模论文的任何部分时,都必须使用此 skill。
npx skills add https://github.com/Lupynow/math-modeling-skills --skill math-modeling-paper
收到写作任务后,按以下步骤操作:
先判断用户是否已完成建模:
math-modeling-solver 完成建模,有论文草稿片段 → 识别 [PAPER_READY] 信号或用户说"建模做完了/准备写论文",直接加载草稿片段,从对应章节开始写作math-modeling-solver 完成建模,或直接进入 Step 1 确定写作阶段向用户确认(如果信息不全):
根据比赛类型加载详细指南:
references/cumcm-guide.mdreferences/mcm-icm-guide.md必读:
references/literature-review.md(模型选择理由、参数溯源、引用格式必须有文献支撑)根据当前阶段按需加载:
references/abstract-writing.mdreferences/model-validation.mdreferences/common-phrases.mdreferences/problem-type-strategies.mdreferences/figure-and-code-guide.mdreferences/memo-writing.md按照论文结构顺序,对每个章节执行「目的 → 结构 → 写什么 → 红线」四步指导。具体规则见下文各节。
论文全文完成后,必须执行四轮系统性自审。加载以下两个文件:
references/self-review-framework.md — 四轮自审框架:论证逻辑 → 章节结构 → 表述质量 → 格式规范references/de-ai-writing.md — 去 AI 味写作指南:八类 AI 痕迹识别与去除 + 注入真实感自审流程:
de-ai-writing.md 逐条扫描 AI 痕迹,检查数据准确性每轮通过后才进入下一轮。如果时间紧迫,至少完成第一轮(论证逻辑)——这是区分三等奖和一等奖的关键差距。
| 章节 | 建议篇幅 | 核心要点 |
|------|---------|---------|
| 摘要 | 1页(500-800字) | 每问必须有量化结果 |
| 问题重述 | 0.5-1页 | 用自己的语言拆题,不是复制 |
| 问题分析 | 1-2页 | 为什么选这个模型,不是"将用什么方法";建议放整体建模流程图 |
| 模型假设与符号说明 | 1页 | 每个假设服务于建模,拒绝废话 |
| 数据处理 | 2-4页 | 说明为什么这么处理(如内容少可嵌入第一个子问题中) |
| 问题一建模与求解 | 4-6页 | 目标→理由→公式→求解→结果→分析→检验 |
| 问题二建模与求解 | 5-7页 | 同上(每个子问题末尾嵌入灵敏度/误差分析) |
| 问题三建模与求解 | 5-7页 | 同上 |
| 模型评价与改进 | 1-2页 | 优缺点+检验结论汇总;评价本模型,不是评价算法 |
| 参考文献 | 0.5-1页 | ≥6条,含期刊论文和英文文献 |
| 附录 | 按需 | 完整代码+支撑材料列表 |
正文总篇幅:20-28页(不含附录)
> 关于模型检验的位置:实际获奖论文中,灵敏度分析/误差分析通常嵌入在每个子问题求解的末尾(如 5.1.6 灵敏度分析),而非独立成章。如果检验内容充实(2页以上),可独立设「模型检验」章;如果每个子问题检验内容较短,在「模型评价与改进」章汇总检验结论即可。
| 章节 | 建议篇幅 | 核心要点 |
|------|---------|---------|
| Summary Sheet | 1页 | 英文,hook句+量化结果全覆盖 |
| Table of Contents | 0.5页 | 自动生成 |
| Introduction | 2-3页 | Background + Restatement + Literature Review + Our Work 流程图 |
| Assumptions & Notations | 1-2页 | 5-6条,每条有 Justification |
| Data Processing | 1-2页 | 独立成章,方法+理由 |
| Model 1-3 (per task) | 每模型4-6页 | 每个模型起名字+缩写,含算法伪代码 |
| Sensitivity Analysis | 1-3页 | 多方法验证,独立或嵌入均可 |
| Strengths & Weaknesses | 1页 | 针对本模型的具体评价 |
| References | 1页 | ≥5条,期刊为主 |
| AI Usage Report | 1页 | 声明 AI 工具使用 |
| Appendix | 按需 | 代码 |
正文总篇幅:25-26页
国赛:点明研究对象 + 核心方法。如《基于多目标优化与灵敏度分析的XX调度模型》
美赛:创造有记忆点的标题+模型名。如《Golden Dynamics: Bayesian-AI Olympic Forecasting》
避免:直接抄赛题、太虚的标题
这是评审第一轮筛选的依据。两地比赛都必须遵守的黄金规则:
红线 1:每问必有一数。 摘要中每个子问题都必须包含至少一个具体的定量结果。禁止只写方法不写结果。对比:
| 错误写法 | 正确写法 |
|---------|---------|
| 建立了多元线性回归模型对影响因素进行分析 | 共热解过程中,焦油产率与INS含量呈显著负相关(R²=0.873, p<0.01) |
| 使用遗传算法求得最优解 | 最优种植方案总利润为4024.48万元,较基准方案提升23.7% |
红线 2:结果要精确。 不要只给范围或不给数据。美赛论文更要给出置信区间、NRMSE、覆盖率等误差指标。
国赛摘要结构:问题背景(1句) → 总体思路(1句) → 问题一方法+结果 → 问题二方法+结果 → 问题三方法+结果 → 模型检验/优点(1-2句) → 关键词(3-5个)
美赛摘要结构:Hook句(1句) → 问题陈述(1-2句) → 每个Task的模型名+方法简述+量化结果 → 关键结论 → 关键词(6-8个)
详细模板和句式见 references/abstract-writing.md。
用自己的语言重新拆题,不要复制粘贴题目原文。
好的做法:先概括题目背景,再把任务拆成小问题,最后说明每个问题的解题目标。
篇幅控制:国赛 0.5-1 页,美赛 2-3 页(含背景和研究综述)。
这是区分"套模型"和"理解问题"的关键章节。获奖论文在此投入 1-2 页深入分析,而不是简单罗列方法。
红线:不要写成"我们将用A方法做X"。 这是方法罗列,不是分析。
正确的写法遵循「为什么」逻辑:
格式:按子问题分开写,每个子问题一段独立分析(如 2.1 问题一分析、2.2 问题二分析)。
强烈建议:在问题分析末尾放一张整体建模流程图(框图/箭头图),展示各子问题对应的模型及其之间的数据流。获奖论文中约 70% 包含此图。
示例写法(好):
> 问题一要求评价不同方案的综合效益。这是一个典型的多指标综合评价问题。评价类问题常用方法有层次分析法(AHP)、TOPSIS法和模糊综合评价法。考虑到本问题指标数量较多且部分指标具有一定模糊性,本文选用模糊综合评价法,既能处理定量指标也能处理专家对定性指标的模糊判断。指标权重的确定采用熵权法以降低主观性。问题一的评价结果将作为问题二优化模型的输入约束。
示例写法(差):
> 针对问题一,我们首先进行数据处理,然后使用模糊综合评价法进行评价,最后得到评价结果。
红线 1:禁止写废话假设。 以下类型的假设必须删除:
红线 2:每个假设必须在后文被用到。 写假设时就要想清楚它在模型中如何体现。
正确做法:假设应服务于建模,格式为「假设内容 + 为什么这样假设合理」。分类列出(如:物理简化类、数据类、参数类)。
只放核心变量,不要把所有变量堆进去。每个符号包含:符号、含义、单位(必须)。
红线:不能只写方法,要说明为什么。
内容覆盖:数据来源 → 缺失值处理 → 异常值处理 → 标准化/归一化 → 特征提取 → 可量化分析
每种处理要说明原因。例如:"由于不同作物产量量纲差异较大,采用Z-score标准化消除量纲影响"。
美赛论文将数据处理作为独立章节,这是加分项。
这是正文核心,每个子问题按以下结构展开:
标准六步结构:
红线 1:公式要有问题针对性。 禁止抄教科书通用公式而不做问题适配。从第一性原理推导,公式中的符号要对应到本题的具体变量。
红线 2:结果必须配解释。 每个表格/图片后面必须有 1-3 句话解释"这个结果说明了什么"和"为什么会出现这个结果",不能只描述"图中展示了……"。
红线 3:代码和论文必须一致。 论文中声称的方法必须在代码中实现。声称用 XGBoost 就写 XGBoost,不能代码跑的是线性回归。
美赛额外要求:每个模型起一个创意名称+缩写(如 HARMONIE、CHAMPS),提供算法伪代码框(Input / Output / Steps)。
这是从三等奖到一等奖的关键差距。实际获奖论文中,灵敏度分析/误差分析通常嵌入在每个子问题求解末尾(如 5.1.6 灵敏度分析),篇幅 0.5-1 页/子问题。
必做项:
加分项:
组织方式:
详细方法见 references/model-validation.md。
红线:不要只放图表不加解释。 每个图表后必须有分析段落。
分析三段式:
红线:评价的是「本模型」,不是「所用算法」。
| 错误写法(评算法) | 正确写法(评本模型) |
|-------------------|---------------------|
| 线性回归简单直观,易于实现 | 本模型将作物产量假设为晴雨因子的线性函数,结构清晰但未考虑交互效应 |
| 遗传算法容易陷入局部最优 | 本模型采用的AGA通过自适应交叉变异概率,有效改善了对XX问题的收敛性 |
缺点写 3-5 条,每条应是承认本模型具体建模选择带来的局限。不要写"数据依赖性强"这种放之四海皆准的话。
红线 1:禁止引用 CSDN 博客、知乎、百度百科、AI 工具(如 DeepSeek/ChatGPT)等非学术来源。
红线 2:正文中引用了就要列出,列出了就要在正文中出现。
数量要求:国赛 ≥6 条,美赛 ≥5 条。能引用英文期刊论文是加分项,但不强制。推荐美赛引用 8 条以上以体现文献调研深度。
正确来源:
必须包含:
代码规范:
references/problem-type-strategies.md)详细图表和代码规范见 references/figure-and-code-guide.md。
| 维度 | 国赛 CUMCM | 美赛 MCM/ICM |
|------|-----------|-------------|
| 语言 | 中文 | 英文 |
| 最重视 | 摘要量化结果、模型检验 | 模型创新性、多模型融合、原创新推导 |
| 模型命名 | 不必须,可直呼算法名 | 必须有创意名称+缩写 |
| 灵敏度分析 | 嵌入子问题或独立章 | 必做(1-3页,独立或嵌入均可) |
| 参考文献 | ≥6条 | ≥5条 |
| 文献综述 | 必须(可并入问题分析) | 近乎必须(Introduction 中必含 Literature Review);模型选择理由必须有文献支撑 |
| AI 使用报告 | 2024起建议 | ~37%论文包含(1页),列出工具+查询 |
| 流程图 | 推荐(问题分析中放整体框架图) | 近乎必须(Our Work 图,标志性特征) |
| Memo/Letter | 不涉及 | B/D/E/F 题常见,见 memo-writing.md |
| 摘要页 | 在正文第一页 | 独立 Summary Sheet(~400-550 词) |
| 评审侧重 | 方法正确性、结果合理性、模型检验 | 建模思路创新性、写作表达能力 |
论文完成后,逐项检查:
references/cumcm-guide.md — 国赛各章节详细写法references/mcm-icm-guide.md — 美赛各章节详细写法references/abstract-writing.md — 摘要模板和句式(中英双语)references/model-validation.md — 模型检验方法大全references/literature-review.md — 文献检索策略、综述写作、引用格式、参数溯源references/common-phrases.md — 常用学术句式(中英双语)references/problem-type-strategies.md — A/B/C 题差异化策略references/figure-and-code-guide.md — 图表规范与代码附录要求references/memo-writing.md — 美赛 Memo/Letter 写作指导references/de-ai-writing.md — 去 AI 味写作指南(八类 AI 痕迹识别 + 注入真实感 + 数模专用规范)references/self-review-framework.md — 四轮自审框架(论证逻辑→章节结构→表述质量→格式规范)Take lupynow/math-modeling-paper from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.