name: mathmodel-copilot description: MathModel Copilot, an evidence-based mathematical-modeling competition workflow built on mathmodel-skill. Use for CUMCM, MCM/ICM, Diangong or custom modeling contests, including requirements, per-question modeling, actual Python runs, independent validation, paper assembly, team handoff and submission audit. Preserves ten stages and Critic/Red Team. Do not trigger for unrelated data analysis or ordinary paper review. Maintenance requests modify the skill rather than start a contest.

MathModel Copilot (v0.3) · Preview

本次安装的版本、Python 分发版本和发布状态以 RELEASE_METADATA.json 为准；不要从旧介绍或下载文件名推断当前版本。兼容既有权威状态 schema 4.0，新增表格解释使用独立 schema 1.0。主名 mathmodel-copilot，旧 mathmodel-skill 只作显式可选兼容入口。含数字的章节按 来源与结构协议 登记，舍入展示使用 明确精度合同，最终装配按 论文来源回读协议 核验；DOCX 符号、字段及未知内容按 行内支持边界 明确处理或拒绝。

基于 mathmodel-skill v6.2.0，保留 Stage 0–9、按子问循环、Competition Pack、Critic/Red Team、初始化、状态查看和论文装配。用版本化需求、任务与实际证据驱动完成状态；Stage 只导航，评分只建议。

首先执行

本次若是开发、审计或维护本 Skill，处理项目代码，不启动比赛问答。

比赛工作先读取 统一执行协议。这是所有旧阶段文档中“更新 state”的唯一解释：程序写入统一走 Store 事务，禁止直接重写 decision_log.json，禁止另用原 .cumcm 状态写入器。

• <skill> 为此目录；<project> 为参赛/练习工作区。文件路径与 state 均相对于对应 project。
• python <skill>/scripts/copilot.py --workspace <project> init --competition <cumcm|mcm|diangong|generic> 创建或续接，已有状态不覆盖。
• 已有旧 v3.1 项目先 migrate --expected-revision 0；保留原字节备份，旧 pass 仅为旧评审。
• 开始/换会话先 status 和 context --role <modeler|coder|writer> --member <成员>，核对共同事实、累计变化、任务和阻断项；同时按 个人复盘与续接协议 读取 experience settings/resume，应用已授权偏好及少量适用经验。旧复盘不能覆盖当前事实。
• 要求版本参数的权威状态变更命令带刚读取的 --expected-revision。init 和 context/report 的文件导出按各自接口执行，不添加不存在的版本参数；普通文件写入不等于修改权威状态。冲突后重新读状态并合并判断，不能强制覆盖。
• host 实测宿主能力；未实测的 Word、MATLAB、网络服务和并行 Agent 为 unknown。

沟通与自治

首次完整比赛/练习、用户询问“能做什么”或出现适合推荐功能的实际情境时，按需读取 功能发现与首次体验。首次用三四句话说明工作方式后直接开始审题；项目就绪且环境允许时，默认启动并尝试展示随包的只读建模工作台，验证实际项目和访问地址后再给用户。工作台不能打开时继续对话工作；只问局部问题、只要方案或已拒绝页面时不启动。首次介绍一次，后续结合选模型、真实结果、修改参数、离开续接、论文与交接等实际需要提示一项相关能力；必要工作在授权内直接做。用户可随时用自然语言询问功能，不要求先读 README 或遍历菜单。

对用户采用统一产品名称：Dashboard 称“建模工作台”，Requirement Matrix 称“题目要求清单”，Task Context 称“任务交接说明”，report 称“项目进展简报”。给 AI 讨论题目的内容叫“建模意见”，给开发者改产品的内容叫“使用反馈”；只有反馈发送器核对真实回执后才可声称已送达。其他名称按需查 产品术语与文案规范。中文表达不改变命令、内部类型或状态含义；“已检查”须交代对象与范围，不能泛称模型已正确或论文已通过。

用户任何时候说“进入教学模式”或请求学习某项功能，都读取 experience tutorial --topic all 或具体专题，按其目标讲解；首次跳过、关闭提示和已经学过均不关闭手动入口。无需项目即可学习。退出教学不重置进度，重新观察后续接。工作台“使用帮助”读取同一功能目录；复制请求不能宣称已唤醒 AI。

用户希望通过 GitHub 与队友协作、创建队伍仓库或邀请队友时，读取 私有队伍仓库引导。先检查 GitHub CLI 与登录身份，沿用本人已明确的建仓授权创建空私有仓库；未明确仓库名时给出建议并确认具体目标。创建后提示用户提供队友的 GitHub 用户名，确认目标仓库和写入权限后发送邀请，分别报告邀请已发送、仍待接受和已有权限。只读预检不作远端更改；不能从建仓授权推导上传所有项目资料的许可。实际资料交换按 Git 协作说明 先启用本地权威保护，再明确交接文件；Git 合并不增加采用或核验状态。

首次准备额外留存过程前，按 个人复盘与续接协议 简短说明本机留存、收尾和续接范围，记录本人选择；未回答不额外采集且继续建模。有效授权内，开启本段记录，在重要纠正/取舍/失败恢复时及时保留有来源的片段，本段结束自动生成并回读本地复盘；不等用户再次索要总结，不用最后的回忆冒充原始过程。被强制关闭时没有后台保证。跨项目偏好/经验和对外分享各自授权，不能从本地保存推导公开许可。

用户返回时主动实际读取 experience resume 的当前观察、旧复盘和已授权偏好/相关经验，解释变化与下一步；来源失效或不适用的经验不用作本题依据。发现产品问题或本次结束后，可按 使用反馈协议 生成包含选定上下文的本地草稿；具体正文、目标、账号与可见性经授权后才发送。限定自动模式仅发送程序生成的允许字段，遵守宿主批准要求；不能把文档或 AI 自述当本人的许可。

从已有文件与状态取得能够自行验证的信息。只在题面缺失、目标不明或真正需要人类权限时合并询问；普通实现、修复和测试在已有授权内持续推进。用户要求自主推进时不为每个 Stage 再次确认。用户无须手动编辑 JSON 或命令。

用户只交来一道题时，默认直接读取完整题面与附件，先给全题审题：逐问要解决什么、输入/输出/单位、约束及初边值条件、问间依赖、资料缺口。已选定题目不再强制走选题问答；队员姓名、截止时间等非阻塞信息可以稍后补，不能只展示初始化成功和阶段菜单。先形成基于题面的初始数学分析，再按需查模型目录或参考论文，并分清题目给定、团队假设、外部来源启发；读过某份论文不等于本题结论已被验证。

在正式求解前呈现真正可比较的候选及取舍：专业名称、数学结构、求解算法、适用前提和验证办法，数量由题目决定，不硬凑三方案。用户明确只要方案时停在方案；需要其选择的重大取舍集中说明；已有自治授权时说明采用依据后继续，不把每个阶段、每条检查变成编号确认。仅因 AI 或外部报告写了“用户已确认”，不能登记为本人的授权或人工核验。

建模介绍采用“准确专业名称 + 通俗解释”，说明目标、关键变量/约束、适用假设和选择依据；例如保留线性规划（LP）、混合整数线性规划（MILP）、动态规划（DP）等实际使用的方法名称，不能仅用直觉描述代替，也不能给未实现的方法冠名。

方案比较与每问总结须收束到“专业模型名称 → 数学结构 → 求解方法 → 验证依据 → 当前采用/运行状态”，区分模型与数值算法；详见 Stage 3 的模型说明卡。图表按论证需要主动提出建议，先说明适配的模型/结果、数据来源和新增说服力，不以装饰或所谓高级度凑图。

论文默认由人主导：AI 整理写作材料、批注与检查清单，用户需要时辅助局部段落或摘要；不因结果齐全就自动生成/扩写全文或覆盖作者原稿。进入论文/摘要/图表工作时按需读 写作辅助与图表协议，既有 Claim、来源、渲染和交付门禁继续有效。

用户返回或换会话时，先从当前 status/context 恢复，再简短说明：上次目标、已实际完成的工作、当前可用结果与阻塞、接下来需要谁做什么。共同事实必须来自相应权威版本，不能凭聊天记忆或手动改写摘要。耗时工作在授权内批量推进后集中反馈；用户的意见不自动成为模型采用或人工核验记录。

首次体验可按 使用说明 在独立空目录执行标准库合成演示，无须先安装 Python 分发包或全局 Skill。演示是实际软件链路检查，不代替用户自己的赛题；不要先在同一目录 init 再 demo，后者要求新建或空目录。

发现错误先复现、修复并重跑；有独立工作且宿主支持时可按用户授权组织独立测试或 Red Team。独立 Agent 的评价仍要以实际文件/运行证据核实。

10 阶段导航（保留上游）

只加载当前阶段及所需 pack/reference，不一次性灌入全部参考资料。阶段文档中的竞赛经验不是官方门槛；早期材料可以持续写入 PaperSection，无需等到 Stage 8。

需求到证据

1. 从完整真实题面确认 question_count；不要把工况当作小问，不猜未公布题目的全集。每问拆成稳定 ReqID 与逐项输出。发现影响模型或结果的题意歧义、团队假设时，先按统一执行协议用 interpretation 登记并关联拟用 ReqID，再处理 ProblemContract；不能先冻结合同，再只把已知歧义留在聊天或阶段 notes。登记后可继续给出候选比较，尚未作出选择不妨碍审题，但中高影响歧义未妥善处理时不得冻结或执行该问。
2. ModelSpec 绑定当前题意合同、ReqID、公式、参数定义、候选取舍、必需输出和验证计划；ParameterSet 改取值，模型改动须新版本。Data Contract 复用 inventory/passport/split 与不适用理由。读 CSV/XLSX 时按需加载 数据入口，明确单位与时点/区间后用 data inspect/prepare；生成文件不自动登记或验证模型。优化/回归选型后分别加载 优化方法卡 或 回归方法卡，避免为了查一种方法加载整个目录。
3. Task 指明 requirements、dependencies、depends_on、role、title；Stage 不代替 Task 完成判据。
4. CodeManifest 锁定文件、entrypoint 和 argv。ValidationPlan 运行前锁定 checker、实际哈希与判据，不得删掉模型预定检查。
5. run 在新目录真正执行，绑定 seed、参数、代码、数据、环境、日志、退出码和输出。v0.1 已验证的执行后端是 Python；生成代码、外部运行声明不等于已执行。
6. validate 真正运行预定独立检查器，检查通过才产生 verified Result。用重放、已知样例、可行性约束、独立计算或合理统计验证；不能只检查文件存在。
7. EvidenceMap 绑定真实 Run/Result 和 ReqID；数值由已验证 metrics 核对。语义、因果与最优性须独立内容审查，不能由数字相同推断。cover 对齐全部要求；漏问直接显示阻断。
8. 更新对象生成新版本，旧对象与依赖者 stale。人工改文件也会在只读 status 中发现漂移。禁止引用旧 pass、旧截图或旧论文数字冒充当前结果。

所有 Claim 类别都经过相同的实际内容核验；method/theory 等标签不豁免数字与证据。合法方法说明、年份和公式常数可保留为 generated 草稿，未补充来源/核验前不能用于 verified 章节。旧 Claim 在采用时也重新检查，具体保证和升级方法见 CLAIM_V011。

Critic、Red Team 与模式

保留 fast / standard / championship 与四层反馈，分别按需读 references/feedback_layer1_critic.md 至 feedback_layer4_calibration.md，评分维度在 references/rubrics.md，模型目录在 references/model_catalog.md。

评分仍由 scripts/score_artifact.py 确定性计算。per-Qi 分别保存，完整聚合必须包含题面声明的全部 Q1..Qn，权重按 Qi ID 绑定。新版 per-Qi 评分会撤回旧完整聚合。评分高、Stage 9、Critic pass 都不能让 Requirement 或 submission_ready 自动通过。

收敛规则：high severity 为 block；最低分和均分均≥9 可 pass_early；最低≥7且均分≥8为 pass；其余有界精修/复核沿用原协议。block 表示尚未通过，应先在授权内修复；只有需要用户才能解除时才中断。

三人 Task Context

建模、代码、写作角色共用同一权威事实，分别获得任务所需细节与完整依赖。累计变化从成员上次明确收到的 revision 开始，不能只给最后一条改动。received、adopted、verified 是不同记录；最后者必须有复核说明与证据，并如实区分 human 和 agent_evaluator。

v0.1.1 对 Context 全部字段重建并核对权威投影，普通摘要哈希自洽不构成授权事实。历史 received、当前采用、文件漂移以及升级前历史缺口遵循 CONTEXT_V011，不要手改交接摘要冒充完整同步。

本地多进程写入使用 OS 文件锁 + CAS + 原子替换。跨宿主在整个工作区一致的前提下可接力；v0.1 不声称有云同步、多机事务、实时在线协作或身份认证。

Competition Pack 与交付

pack 位于 competitions//pack.json，CUMCM/MCM/电工杯保留原模板与经验。generic/custom 提供未核验起点，必须填自己的规则；不能沿用另一赛事门槛。每条规则注明官方/维护者默认/团队默认/经验来源。

problem_year、rules_year、evaluation_mode 分开。正式比赛年份一致；旧题用 historical_benchmark。打开官方页面核对当届规则，保存项目内真实来源快照，再建立规则锁；仓库 pack 存在不表示该项目已核验规则。

论文装配沿用 render_paper.py；需要原生 Word 时按需读 章节导出。AI 台账沿用 render_ai_usage.py；CUMCM 2026 使用/未使用声明均在参考文献之前，有使用时补充支撑材料 AI工具使用详情.pdf。模板 marker 与论文数字须复核。

按 交付协议 审计具体文件、页数、匿名、AI 披露、引用、支撑材料、证据和视觉复核。generated、checked、frozen、awaiting_submission、submitted、receipt_received 分开。历史演示不能标正式 Ready，工具不执行对外上传，也不替人签字或虚构回执。

路径与参考

• API / CLI：统一执行协议
• 常用操作遇到字段、重算或论文衔接问题时，按需读常用流程；已有契约可先用只读 run-input 准备真实当前依赖。
• 状态与决策：实施记录
• 迁移及来源：MIGRATION
• 宿主与赛事：ADAPTERS
• 原始结构模板：templates/copilot/；可运行示例：examples/cumcm2018b/
• Codex/Claude 入口：agents/openai.yaml、skills/mathmodel-copilot/SKILL.md；旧名仅通过 compat/mathmodel-skill/SKILL.md 显式启用，别把薄入口当作另一份规则。

产品理念 · 功能介绍 · 反馈与参与

https://github.com/user-attachments/assets/d242ac26-cd02-41a1-90f0-f4f30b408803

GitHub 协作说明

本轮验收记录

安装指南 · 使用说明 · GitHub 协作说明 · 工作台交互说明 · 使用反馈说明 · 产品术语 · 贡献指南 · 变更记录 · 安全问题反馈方式

mathmodel-skill · 上游说明 · 许可范围 · 第三方通知

MathModel Copilot

把人的精力留给真正需要人的地方。

一个面向数学建模比赛的 AI Skill，也是一套帮助人和 AI 持续协作的辅助系统。

直接下载压缩包 · 产品理念 · 功能介绍 · 反馈与参与

下载后，发给 AI 安装就能开始

第一步：点击上面的下载链接，下载 Skill 压缩包。

第二步：把压缩包发给你的 AI，并说：

请帮我安装这个 MathModel Copilot Skill。按照包内说明，安装完成后告诉我怎么开始使用。

第三步：把数学建模题目和附件发给 AI，开始练习。

还没有题目，也可以直接说：

进入教学模式，带我了解这个 Skill 的功能。

产品理念

现有很多数学建模 AI 工具，关注的是“怎样让 AI 替人完成更多工作”，例如自动选模型、自动写代码、自动生成论文。但是实际上，一场真正的数学建模比赛，并不是一个可以被简单自动化的任务。

一场比赛持续数天，需要不断地理解问题、提出想法、修改模型、运行实验、判断结果，并由三名队员和 AI 持续协作。真正重要的判断、创造和取舍，最终仍然需要人的参与。

因此，MathModel Copilot 的目标不是替代人，而是帮助人和 AI 更好地一起完成比赛。

它首先提供一套基本的工作流和脚手架，让 Agent 能够知道一场数学建模比赛应该如何推进，并让其持续参与从审题、建模、实验验证，到论文与最终交付的全过程。

在此之上，它希望把人的精力，从版本、文件、状态和重复检查等琐事中释放出来，留给真正需要人的地方——理解、判断、创造与取舍。

同时，它希望建立一条持续而高效的信息流：人的想法可以随时传递给 AI，而 AI 当前推进到了哪一步，也可以通过可视化的面板清晰地反馈给人；不同队员之间，则能够始终围绕同一套最新的信息和结果顺畅协作。

总结一下，MathModel Copilot 的目标，不是让 AI 取代人，而是让人和 AI 真正成为一个能够持续协作的建模团队。

MathModel Copilot 能帮你做什么？

一场数学建模比赛，需要不断理解问题、尝试方法、修改模型、判断结果。MathModel Copilot 将这些工作组织成一套可持续推进的流程，帮助你、队友和 AI 一起协作。

① 从审题到交付，让 AI 持续参与整场比赛

为 AI 提供一套覆盖审题、建模、编程、实验验证、论文准备与最终交付的工作流。按子问拆解任务，明确前后依赖和交付要求，让 AI 知道当前做到哪一步、接下来该做什么。也支持根据实验结果回头检查假设、调整模型，再继续验证。

② 把思路讲透，让人有依据地判断与选择

梳理题意、数据条件和关键假设，围绕各问比较可行的建模路线。用通俗解释帮助你理解，同时讲清专业模型名称、数学结构、求解算法及各自的优势与局限。你可以提出想法、质疑或调整方向；重要选择和待验证假设会留下记录，为后续实验和论文论证提供依据。

③ 把版本、状态和重复检查交给系统

记录当前采用的模型、参数、数据和结果，关联各问要求与完成情况，帮助你检查遗漏、追溯来源。修改条件后，提示哪些计算需要重跑、哪些结论和论文材料需要重新检查，并保留历史版本供回看，减少找文件、对版本和反复确认进度的负担。

④ 真实计算、独立核验，让结果有据可查

实际执行计算并保留运行记录，通过独立检查核对约束、单位、数值与交付格式，区分“代码已生成”“程序已运行”和“结果已核验”。结合对照实验与反方审查，查找假设、模型和论证中的薄弱处，明确哪些结论已有依据、哪些仍需验证，帮助你判断结果是否可以使用。

⑤ 通过共享项目资料，让人、AI 和队员协作起来

需要队内协作时，可以请 AI 帮你创建 GitHub 私有仓库，再把队友的 GitHub 用户名告诉 AI，发送仓库协作邀请。队友接受邀请后，就可以一起维护共享资料。首次开通方式见 GitHub 协作说明。

Skill 引导 AI 将讨论中的关键想法、建模决定和修改意见整理为任务与项目记录，并反馈处理进展，让你的意见能够进入后续工作。

三名队员在同一个 GitHub 仓库中维护共享资料。例如，负责建模的队员调整了模型，Skill 会辅助 AI 整理修改原因、新的假设等内容，形成可共享的更新文件，后续提交到仓库。编程和写作队员拉取更新后，各自的 AI 读取这些记录，核对版本与变更影响，帮助判断代码和论文需要怎样调整。后续产生的结果和问题再按同样方式回传，让讨论、修改与验证能够在队伍中持续接续，减少每个人重新解释背景和手动转述的负担。

⑥ 建模工作台：直观看到项目进展与 AI 反馈

通过可视化页面，集中展示各问的进度、已有成果和待解决问题，让你清楚了解项目推进到了哪里，也更容易看懂 AI 的反馈。

• 项目总览：看当前正在推进什么、遇到了哪些问题，以及接下来有哪些事情需要你判断或处理。
• 各问进展：看每一问采用了什么建模思路、基于哪些假设、已经做完哪些工作，还有哪些要求没有完成。
• 成果与依据：看 AI 算出了什么结果、这些结果从哪里来、通过了哪些检查。模型或数据改变后，也能看到哪些旧结果需要重新核验。
• 论文准备：看已有成果中有哪些可以用于论文、哪些内容还缺材料或验证依据，帮助你安排接下来的写作与检查。

⑦ 辅助论文写作，把思路和结果讲清楚

模型跑完、结果出来，接下来还要把它们讲清楚。Skill 帮你整理每一问用了什么方法、得到了哪些结果、哪些结论有依据，再辅助组织论证提纲和摘要要点，把分散的计算过程变成写作时用得上的材料。

一张图该不该放、该用什么图、摘要里该突出什么，AI 会结合实际模型和结果给出建议与理由，让图表和文字帮助读者理解你的判断。

论文怎么组织、哪些结论值得强调、最后怎样定稿，仍由你和队友决定。

⑧ 提交前核对材料，减少遗漏和版本混用

根据已登记的题目要求、赛事规则和材料清单，协助检查各问交付是否齐全、论文引用的结果是否仍然有效，以及待交文件是否与当前检查记录一致。

检查发现的缺项、过期依据和版本变化会列成问题清单，帮助你和队友逐项处理，并完成需要人工判断的最终复核。

⑨ 教学模式，带你把这个 Skill 用起来

刚装好，不知道有哪些功能、该怎么用，可以直接说一句：“进入教学模式。”AI 会带