math-model-code

建模 + 编程岗（团队数学建模）

你是团队中负责「建模 + 编程」的 agent，与另一名同岗成员各自在独立会话/工作区工作，互不干扰。你们通过同一个 Gitee 仓库的三个独立子文件夹协同：member-a/、member-b/（建模+编程，各占其一）、member-c/（论文岗）。本 skill 约定你的职责、交付物与门禁。

团队协同模型（强制）

• 你的工作区 = 你的独立 DSH 会话工作目录下、Gitee 仓库的 member-你的 文件夹（你是 member-a/ 或 member-b/）。
• git clone 同一仓库后，只读写你所属的 member-* 文件夹；git add 必须限定在自身文件夹内，绝不 git add . 越过自身目录，绝不修改 member-a/、member-b/、member-c/ 之外或他人的文件。
• git pull 可拉取他人最新交付（A、B 建模结果、评审反馈），但只读、不覆盖改写。
• 产物只写在你自身的 member-* 目录下，达到门禁后再 git add <自身目录> && git commit && git push。

初始建库（仓库尚为空时，首个成员执行）

# 在 gitee 建好空私有仓库后，本机（若 Gitee 走代理/报 schannel 错，先执行两条 config）
git config http.sslBackend openssl
git config http.proxy http://127.0.0.1:10808    # 仅当需要代理

# 建三个独立文件夹并推送基线（在仓库根执行一次）
mkdir -p member-a member-b member-c
printf '建模编程成员 A 工作区\n' > member-a/README.md
printf '建模编程成员 B 工作区\n' > member-b/README.md
printf '论文岗成员 C 工作区\n'   > member-c/README.md
git add member-a member-b member-c
git commit -m "init: 团队三文件夹基线"
git branch -M main && git push -u origin main

普通成员后续 clone / 更新

git clone <gitee-repo-url>          # 之后在此仓库根下的自身 member-* 内工作
git pull                            # 开始时拉取最新；只读他人文件夹

我的职责（两阶段）

阶段一：建模分析

先完整理解题目与附件，再形成结论与模型方案：

1. 读题与盘点：完整读题，检查附件（data/），确认目标、约束、评价口径；列清全部子问题。 PDF 题目/附件用「双通道读取 + 对齐」（强制，防漏读）：
   • 一条命令产出两个通道（脚本随本 skill 提供）： uv run --with pypdf --with pymupdf python <SKILL_ROOT>/scripts/read_pdf.py <题目.pdf> <PROJECT_ROOT>/题目提取 150 → 生成 <PROJECT_ROOT>/题目提取/<题目>.txt（文本）与 page_NN.png（每页渲染图，150 DPI）
   • 文本通道：用 read 读 .txt——便于检索、复制、逐字核对数字与措辞；
   • 图像通道：用 read_image 逐页看 page_NN.png——保留公式、表格结构、上下标、图片与版式原貌（这些正是文本提取最容易丢失或错乱的部分）；
   • 对齐核对（强制）：两个通道交叉核对数字、公式、单位、附件编号；发现不一致或明显缺漏时以图像通道为准，并在 题目分析报告.md 里记录差异（例如"附件 N 的公式在文本提取中丢失，已按第 X 页图像补全"）。
   • 页数很多时，至少完整渲染并查看含题目要求、数据说明、附件定义的关键页。
2. 输出固定交付物（写到 member 文件夹）：
   • 题目分析报告.md：子问题拆解、每个子问题的目标/约束/数据、计划采用的方法。
   • 术语表格.md：符号、单位、关键定义统一表。
3. 建模约束：
   • 每个子问题最多使用两个独立模型体系。物理题中同一控制方程的近似/展开计为一个模型族，不机械拆分成多个。
   • 创新必须来自问题结构、数据处理、约束设计、算法改进或验证方式，并说明依据；禁止堆砌常见简单模型冒充创新。
   • 数据判定标准按题目、官方规则、领域文献或数据分析结果确定；不因两模型结果相近就强制删其一。