企业官网建设流程全解析

• AI 技能
• AI 插件

在数学建模竞赛中，稳健性分析（Robustness Analysis）往往是评委区分"会建模"和"想清楚了"的关键环节：模型换个权重、少掉 5% 的数据，结论会不会翻车？MathModeling-skills 是面向数学建模竞赛的 Claude Code / Codex 辅助技能包，它的robustness-checker技能专门负责这件事——只针对模型真正的风险点做检查，把证据落盘成可追溯的报告，让"我们的模型更优"这句话有底气。

为什么评委在意稳健性

数模论文的常见硬伤，几乎都能在稳健性分析中被提前拦截：

• 论文里写了"模型稳定"，但没有任何一次扰动实验支撑；
• 结论只在一组参数下成立，换个权重就变了；
• 主模型没有和 baseline 对比，"更优"无从谈起；
• 截止前夜改了 bug，论文里的数字还是旧的。

项目的设计理念很直接：没有 baseline 和稳健性检查，就不能下"我们的模型更好"这类结论（见 README-zh.md 与 skills-docs/design-principles.md 中的 "Keep a baseline" 与 "Be honest about uncertainty" 原则）。

稳健性分析在流程中的位置

在整套工作流里，robustness-checker运行在实验结果产出之后、论文写作之前（Gate G4 阶段）：

result-report-generator（整理实验结果） ▼ robustness-checker（风险针对性检查）★ 本文主角 ▼ final-method-explainer（撰写最终方法说明） ▼ figure-table-planner → math-figure-generator（出图） ▼ 论文写作与三道独立审计（Gate G5 / G6）

前置条件同样明确：主模型和可用 baseline 已执行完毕，且存在运行摘要、方法卡、风险探针摘要等产物——它不重跑主模型，只基于已有证据做检查。完整流程见 README-zh.md 的"整条流程"一节。

4 类风险检查详解

robustness-checker的核心原则是：检查来自模型的假设与决策风险，而不是凑清单（robustness-checker/SKILL.md 第 2 节）。其内置的 8 种检查手段，可以归纳为 4 类：

几类检查的典型做法：

• 参数扰动：对权重或关键参数施加 ±5% 之类的扰动，观察 top-k 排名重叠率等指标；
• 数据扰动：预测类问题检查数据划分有效性、残差行为；优化类问题检查约束可行性和容量敏感性；
• 种子稳定性：所有含随机性的实验必须固定种子（如项目约定SEED = 2026）重复运行，确认结果可复现；
• 基线对比：baseline 必须是"简单、可运行、可解释、输出类型可比"的真实参照，随机输出或纯诊断性参照不算数。

⚠️ 两个重要纪律：不为凑数量跑无关检查；看到结果后再定阈值，必须标注为探索性（exploratory）。这两条规则直接写在技能的 Rules 一节里。

方法选型阶段的风险探针（Gate G2）与这里的检查一脉相承，契约细节见 risk-probe-contract.md，它按题型给出针对性检查项：评估/排名类看权重主导与排名重叠，预测类看泄漏与区间覆盖，优化类看可行性与容量敏感性。

检查如何落盘：两份产物

检查不是聊完就散，而是按lean/submission两种严格度落盘：

机器摘要的契约（Summary Contract）要求每次检查都记录完整链条：

1. 被检验的声明/假设是什么；
2. 输入与结果的来源路径；
3. 扰动内容（及其合理性依据）；
4. 指标与预设阈值（如已预先声明）；
5. 观测值；
6. 状态：PASS/CONDITIONAL/FAIL；
7. 局限性说明；
8. 与备用方案触发条件的关联。

CONDITIONAL表示"有条件通过"——需要写清缓解措施或备用触发器，不能含糊带过。

稳健性报告怎么写：让数字自己说话

报告模板见 robustness-report-template.md，核心是一张"风险针对性检查"表，每一行对应一个真实风险：

模板还强制包含两个容易被忽略、但对评委极具说服力的部分：

• 边界与回退（Boundary and fallback）：模型在什么范围内稳定？已知的失效边界在哪？备用方案是否已触发？——主动交代"模型的边界"比隐藏它更得分；
• 人类判断（Human judgment needed）：只有当证据足以改变声明、方法或回退决策时，才弹出一张紧凑的选择卡，人的决定记录在methods/Qx/qx_decisions.jsonl。AI 出证据，人做判断，这条边界贯穿整个项目。

QA 阶段也会复查这一环：skills-docs/qa-checklist.md 把"无稳健性检查却宣称稳定""计划中的检查被写成已完成"列为阻断性问题（blocking issues），任何一条命中，终稿不允许组装。

检查失败怎么办

这是新手最容易卡住的地方。按项目规则，稳健性检查失败不是事故，而是证据——它是"调整参数 / 启用备用方法 / 降级声明强度"的依据，而不是让 AI 自行拍板的许可：

1. PASS：声明保持，写入报告；
2. CONDITIONAL：声明附带边界条件，写明触发备用方案的证据；
3. FAIL：回到方法层面——调整、启用 fallback 或把结论收窄为更诚实的范围。

注意一条反直觉的纪律：不要把稳定性指标直接换算成"人类信心结论"。指标是给决策提供输入，最终表述强弱由人决定。

快速上手：触发一次稳健性检查

安装完插件（install.sh 一键完成，克隆地址https://gitcode.com/gh_mirrors/mat/MathModeling-skills），新会话中先发送中文开场指令 Initial Prompt-zh.md。之后只跑稳健性，直接说人话即可，README 给出的标准说法是：

让 robustness-checker 跑 Q1，输入在 results/Q1/reports/， baseline 在 results/Q1/experiments/round2/。不要重跑主模型。

跑完后检查robustness/Qx/下的摘要与报告，确认每个主要结论都有对应的检查或明确的局限性说明——这正是技能自检清单（Verification 一节）的四条标准。

小结

• 4 类检查覆盖参数扰动、数据扰动、稳定性、基线对比与误差，全部服务于"最可能失败的声明"；
• 证据链完整：检查记录PASS / CONDITIONAL / FAIL状态、观测值与证据路径，论文数字可一路追溯到robustness_summary.json；
• 失败即信息：检查不过会引导你调整或收窄结论，而不是掩盖问题；
• 人做最终判断：选择卡 + 决策账本保证"模型更优"的表述由你负责。

评委看到的每一张稳健性表格背后，都是一次可复现的风险检查——这比任何华丽的措辞都更能证明你的模型经得起推敲。

延伸阅读：设计原则 · 方法选型树 · MATLAB/北太天元编码规范 · 语言选择指南

• AI 技能
• AI 插件