# mathmodel-skill

> 把 72–96 小时的数学建模协作，变成一条可恢复、可检查、可交付的流程。

[](./.codex-plugin/plugin.json) [](https://github.com/handsomeZR-netizen/mathmodel-skill/actions/workflows/ci.yml) [](./scripts/doctor.py) [](./competitions/) [](./LICENSE)

mathmodel-skill 是面向 CUMCM、MCM/ICM 与电工杯的 Agent 工作流。它把选题、拆题、模型选择、求解、稳健性、写作和终审串成 10 个阶段，并用一份可读的决策日志，让团队在长时间、高压力的协作里依然知道：我们做过什么、为什么这样做、下一步该检查什么。

支持 Codex Skills、Codex Plugin 与 Claude Code。核心流程不要求你手工维护 JSON，也不要求你记住每个脚本的参数；关键节点由 Agent 用编号选项与你确认，状态和产物由流程接住。

[为什么要做](#凌晨两点之后真正难的是什么) · [设计取舍](#为什么不是其他几种做法) · [精心设计](#一些刻意做小但很重要的设计) · [快速开始](#quick-start) · [可信边界](#边界与可信度)

## 凌晨两点之后，真正难的是什么

代码终于跑出了结果。可队友正在使用另一套符号，摘要仍然引用下午已经放弃的模型，灵敏度分析还没有开始。

数学建模论文不是一次回答，而是一串有前后依赖的决定：选题决定数据和方法，假设决定模型边界，模型决定结果，结果又决定摘要里能不能写出可信的数字。单次回答可以很聪明，但如果这些依赖只留在聊天窗口里，一次上下文切换就足以让它们脱节。

mathmodel-skill 从这里出发。它不试图成为“最会答题的 Prompt”，而是把一场比赛中容易遗忘的流程、决策和检查点，写成一套可以执行、恢复和复核的工作协议。

它做三件事：

- 把流程显式化：从团队启动到提交前终审，10 个阶段各自有输入、产出和退出条件。 - 把决策显式化：选了哪道题、为何放弃另一模型、哪个假设影响了哪些子问，都进入 `state/decision_log.json`，而不是沉在聊天记录里。 - 把质量检查显式化：阶段内评分、跨阶段一致性回检、终稿多视角评审与合规门各司其职；发现问题时优先定向修补，不轻易整篇重来。

它不替团队做出正确模型，也不承诺奖项。它解决的是另一个更现实的问题：不让关键假设丢失，不让符号悄悄漂移，也不让某个薄弱子问被整篇平均分掩盖。

## 从题目到终稿，只有一条共享主线

```mermaid flowchart TD A["题目与团队约束"] --> B["10 阶段主流程"] C["竞赛特化包"] --> B D["decision_log.json"] <--> B B --> E["模型、结果、图表与论文"] E --> F["L1 / L2 / L3 / L4 反馈"] F -->|"定向修补"| B ```

主流程负责阶段顺序和状态；`competitions/<comp>/` 负责竞赛规则、写作模式、评分覆盖与 LaTeX 模板；辅助脚本负责可重复的评分、差分应用、预检、装配和 AI 使用披露。模型仍然由团队判断，脚本只把能确定的部分做得确定。

## 这套流程实际带来了什么

| 竞赛现场的常见问题 | mathmodel-skill 的处理方式 | |---|---| | 聊天一长，之前的选择和理由找不到 | 所有阶段共用 `decision_log.jso