企业官网建设流程全解析

中国研究生数学建模竞赛（华为杯）学习笔记——优秀论文写作教练完整建设路线

一、项目背景与最终目标

当前工作区包含 2020—2025 年优秀论文，共 229 篇：

最终要做的不是一个“根据关键词寻找原文”的普通 RAG，也不是让模型照抄某篇优秀论文，而是一个个人专用的 Codex Skill：

将 229 篇优秀论文一次性拆解、比较和蒸馏，形成一套数学建模论文的逻辑组织、章节写法、题型模式和评审标准；比赛时再根据用户真实提供的模型、数据、结果和图表，指导论文构思、成稿与审查。

总体流程分为两条链：

赛前建设： 229篇PDF → 结构化正文 → 单篇分析卡 → 跨论文蒸馏 → 冻结规则库 → Codex Skill 比赛使用： 赛题与真实结果 → 材料审计 → 主线/大纲确认 → 分节成稿 → 逻辑评审 → 文风评审 → Markdown终稿

优先级固定为：

1. 逻辑质量。
2. 贴合优秀论文的共同文风。
3. 成稿速度。

首版不建设向量数据库、不微调模型。核心方案采用“离线蒸馏＋Skill 工作流”；如果以后需要“寻找使用过某种模型的优秀论文案例”，再对论文分析卡增加轻量 RAG。

二、最终交付成果

完成后应得到六类成果：

1. 语料清单

   记录 229 篇论文的年份、题号、标题、页数、文件哈希、解析方式、解析质量和异常状态。

2. 结构化论文正文

   将 PDF 转换为按摘要、问题分析、假设、建模、求解、检验、评价等章节组织的 Markdown。

3. 229 份论文分析卡

   每篇提炼论证链、章节作用、证据组织、文风特征、可迁移模式、局限及章节质量评分。

4. 冻结的优秀论文规律库

   包含共同逻辑、章节指南、题型模式、共同文风、反模式和评审量表。

5. 独立 Codex Skill

   名称建议为huawei-cup-paper-coach，负责材料审计、大纲设计、分节写作、逻辑评审和文风评审。

6. 测试与使用模板

   包含比赛项目账本、输入模板、评审案例、失败案例和版本说明。

完成标准不是“论文都导入了”，而是：

• AI 不编造数据、实验和结论。
• 能发现模型—结果—结论之间的断裂。
• 多轮写作后符号、单位、数值和术语不漂移。
• 逻辑不合格时不会直接润色掩盖问题。
• 输出具有优秀论文的共同特征，但不复制具体原句。

三、整体架构

建议在工作区新建独立项目：

huawei-cup-paper-coach/ ├─ builder/ │ ├─ scripts/ # 清单、解压、解析、质量检查、汇总 │ ├─ prompts/ # 赛前蒸馏提示词 │ ├─ schemas/ # 分析卡、规则库、账本格式 │ └─ tests/ ├─ corpus/ │ ├─ manifest/ # 论文清单 │ ├─ normalized/ # 结构化正文 │ ├─ paper_cards/ # 单篇分析卡 │ ├─ distilled/ # 蒸馏结果 │ └─ logs/ # 失败及断点状态 └─ skill/ └─ huawei-cup-paper-coach/ ├─ SKILL.md ├─ references/ │ ├─ core/ │ ├─ sections/ │ ├─ problem-types/ │ └─ review/ └─ templates/

原始 PDF、完整解析文本和运行日志不提交 Git；提示词、脚本、分析卡、规则库、Skill 和测试应进行版本管理。

核心中间产物

Skill 对用户提供的操作

用户不需要记命令，只需自然语言调用：

• “审计我目前的比赛材料。”
• “先设计全文主线和大纲，不要写正文。”
• “规划模型检验这一节。”
• “按照已确认方案起草摘要。”
• “只检查全文逻辑，不润色。”
• “逻辑已经通过，进行文风评审。”

四、详细实施步骤

第一步：冻结语料与建立清单

目标是确认系统究竟学习哪些论文，并保证不重复处理。

具体做法：

1. 将 2020—2025 年全部压缩包设为只读语料。
2. 安全展开 ZIP、嵌套 ZIP 和 RAR；处理 2020 年文件名的 GBK/CP936 编码。
3. 为每篇论文计算 SHA-256。
4. 识别 2025 年压缩包与已解压目录中的重复副本。
5. 生成唯一编号：

年份-题号-序号-短哈希 例如：2023-C-04-a81f23c9

6. 清单至少包含：

paper_id year problem_letter title source_archive sha256 pages parse_backend parse_status parse_warnings

验收门槛：

• 清单恰好包含 229 篇唯一论文。
• 所有重复项均能由哈希解释。
• 每篇论文都有确定的解析状态。

第二步：运行 18 篇试点

先从 A—F 每题选择 3 篇，共 18 篇，覆盖：

• 不同年份。
• 普通文本型 PDF。
• 公式、表格和双栏较多的 PDF。
• 低文本密度或疑似乱码的 PDF。

试点完整跑通：

PDF解析 → 章节切分 → 单篇分析卡 → 小规模蒸馏 → Skill试运行

试点阶段重点验证：

• 章节能否正确识别。
• 公式与图表附近的解释是否保留。
• 单篇提示词是否会补写不存在的内容。
• 分析卡字段是否足够支持跨论文比较。
• Skill 规则是否过长或互相冲突。

只有试点通过，才处理剩余论文，避免 229 篇全部返工。

第三步：混合本地解析全部 PDF

采用已经确认的“轻量解析为主，MinerU/OCR 回退”方案。

处理规则：

1. 先使用 Poppler 提取文本与基础版面。

2. 自动检测以下异常：

   • 出现大量 CID、乱码或替代字符。
   • 大量页面几乎没有文本。
   • 摘要、问题分析、模型、结果等主要标题无法识别。
   • 表格、公式或双栏内容顺序明显混乱。

3. 正常论文直接进入章节切分。

4. 异常论文转入 MinerU 或 OCR。

5. MinerU 默认先使用本地 CPU 管线；GPU 仅在试点稳定后启用。

6. 每篇至少抽查摘要、问题分析、模型建立、检验、结论五个位置。

7. 原文永远保留；封面、目录、参考文献和代码附录只从“核心分析视图”中排除，不物理删除。

输出：

• 一份结构化 Markdown。
• 一份解析质量报告。
• 一组明确的异常标记。

任何失败论文只标记失败，不得阻断整批处理；脚本必须支持断点续跑。

第四步：生成单篇论文分析卡

不要把平均 85 页的论文一次性塞给模型。采用两级分析：

1. 按章节生成局部摘要和论证说明。
2. 将章节结果汇总为完整论文分析卡。

每张卡包含：

• 题型多标签：预测、评价、优化、机理分析、综合。
• 一句话论文主线。
• 问题—方法—证据—结论链。
• 各章节承担的任务。
• 公式、结果和图表如何支撑结论。
• 子问题之间的递进或依赖关系。
• 过渡方式和段落组织。
• 可迁移模式与题目特有内容。
• 逻辑、证据组织、表达三个维度的章节评分。
• 解析异常和无法判断项。

A—F 只是年度题号，不能直接当作固定题型；题型由论文内容进行多标签判断。

质量控制：

• 18 篇试点卡全部进行第二次审查。
• 全量阶段抽查不少于 10%。
• 缺少证据时只能写“无法判断”，不得自动补全。
• 不保存大段原句，避免后续生成发生近似照抄。

第五步：跨论文蒸馏

先按章节和题型分组，再进行两级汇总：

单篇分析卡 → 摘要/建模/检验等章节规律 → 预测/评价/优化等题型规律 → 全语料共同规律

最终规则分为三类：

• 共同规律：跨多个年份和多个题型稳定出现。
• 条件规律：只适用于某类题型或章节。
• 少数观察：保留为参考，不进入硬性规则。

蒸馏结果拆分为：

core-logic.md sections/abstract.md sections/problem-analysis.md sections/assumptions.md sections/modeling.md sections/solution.md sections/validation.md sections/evaluation.md problem-types/prediction.md problem-types/evaluation.md problem-types/optimization.md problem-types/mechanism.md problem-types/mixed.md style.md anti-patterns.md review-rubric.md

运行时不显示论文名和页码。构建阶段只保留规则的大致支持论文数和论文编号，用于排查错误，不维护逐句逐页引用。

第六步：制作独立 Skill

不直接修改或依赖原始 Nature Skills，而是新建独立 Skill。

可以从 nature-skills 借鉴：

• SKILL.md + references的按需加载结构。
• 材料检查。
• 一句话论点。
• 术语账本。
• 用户确认门。
• 证据先于文字。
• 阻断问题分级。
• 全文一致性检查。

需要全部替换：

• Nature 期刊规则。
• 英文润色和中译英。
• 投稿包与文献引用流程。
• 三位审稿人模拟。
• Nature 论文语料和文风。
• 强制来源、页码和引用显示。

只复用架构与流程，写作知识只来自这 229 篇优秀论文。若直接复制上游文件，应按其 Apache-2.0 LICENSE 保留许可证与修改说明。

Skill 按任务动态加载：

不得将 229 篇全文装入 Skill。

第七步：比赛时的标准工作流

每次比赛建立独立项目包：

00_problem.md # 赛题与问题拆解 01_materials.md # 模型、算法、代码、结果和图表说明 02_audit.md # 材料审计报告 03_ledger.md # 术语、符号、单位、数值和证据账本 04_outline.md # 经确认的主线和大纲 sections/ # 分节方案与正文 reviews/ # 逻辑和文风评审 manuscript.md # 当前合并稿

固定运行顺序：

1. 用户提供赛题、模型、假设、数据、结果和图表。
2. AI 只做材料审计，不立即写正文。
3. 存在关键缺口时返回BLOCKED。
4. 材料基本齐全后设计一句话主线和详细大纲。
5. 用户确认大纲。
6. 每一节先输出写作方案，再由用户确认。
7. 根据确认方案生成 Markdown 初稿。
8. 先进行逻辑评审。
9. 逻辑达到PASS后才进行文风评审。
10. 用户核对数据、公式、图表和结论后进入最终排版。

五、第一版提示词

P00：Skill 总纲

你是个人数学建模论文写作教练。 写作方法只依据已冻结的优秀论文规律库；论文事实只依据用户提供的赛题、模型、数据、结果、公式和图表。 优先级：逻辑质量 > 优秀论文共同文风 > 成稿速度。 必须遵守： 1. 按“材料审计→主线与大纲确认→分节规划与成稿→逻辑评审→文风评审”运行。 2. 不编造数据、公式、实验、图表、模型表现和结论。 3. 关键证据缺失时停止成稿，并标记“[待补：具体内容]”。 4. 维护术语、符号、单位、模型名称、关键数值和结论账本。 5. 不复制或近似改写某篇优秀论文的原句。 6. 默认不展示来源论文和页码。 7. 用户最终负责核对全部计算结果和事实。

P01：单篇论文分析卡

任务：将一篇优秀数学建模论文拆解为论文分析卡。 输入： - 论文编号：{{paper_id}} - 结构化正文：{{paper_text}} - 解析异常：{{parse_warnings}} 输出： 1. 题型多标签。 2. 一句话主线。 3. 问题→方法→证据→结论链。 4. 分节表：章节任务、核心论断、支撑材料、承接关系。 5. 各章节的逻辑、证据组织和表达评分，1—5分。 6. 文风特征、可迁移模式、题目特有内容和局限。 7. 无法判断的内容。 约束：只分析输入内容；不补全缺失信息；不大量摘录原句。

P02：跨论文规律蒸馏

任务：从固定论文集的分析卡中蒸馏稳定写作规律。 输入：{{paper_cards}} 原则： - 按章节质量加权，不将所有论文同等处理。 - 区分共同规律、题型条件规律和少数观察。 - 冲突规律保留适用条件，不强行合并。 - 去除题目背景、具体结果和可识别原句。 - 无足够支持的内容不得升级为规则。 输出： 1. 共同逻辑框架。 2. 各章节写作指南。 3. 各题型论证模式。 4. 共同文风。 5. 反模式。 6. 逻辑与文风评审量表。 每条规则使用“适用场景—推荐做法—避免事项”格式。

P03：比赛材料审计

任务：判断当前材料是否足以支撑论文写作。本阶段不写正文。 输入： - 赛题：{{problem}} - 模型、假设、算法和代码说明：{{methods}} - 结果、表格和图形：{{results}} - 已有草稿：{{draft}} - 项目账本：{{ledger}} 输出： 1. 结论：PASS、PARTIAL或BLOCKED。 2. 已确认事实。 3. 各子问题的方法—结果—结论覆盖表。 4. 论断—公式/数值/图表证据表。 5. 阻断性缺口。 6. 非阻断风险。 7. 下一步最小补充清单。 约束：不推测结果，不把模型描述当成模型效果；核心证据缺失时必须BLOCKED。

P04：论证主线与大纲

任务：依据已通过审计的材料设计全文主线和大纲，不写正文。 输入： - 赛题：{{problem}} - 审计报告：{{audit_report}} - 已确认材料：{{approved_materials}} - 项目账本：{{ledger}} - 适用题型规则：{{problem_type_rules}} 输出： 1. 一句话总主线：问题—方法—结果—结论。 2. 子问题之间的关系。 3. 论断—证据蓝图。 4. 详细大纲：每节任务、论断、证据、公式/图表及承接关系。 5. 摘要信息骨架。 6. 风险与待确认选择。 7. 状态：AWAITING_CONFIRMATION。 未获得用户确认前不得进入正文。

P05：分节规划与成稿

任务：规划或起草指定章节。 模式：{{PLAN_or_DRAFT}} 章节：{{section_name}} 输入： - 已确认大纲：{{approved_outline}} - 本节证据：{{section_evidence}} - 前后文摘要：{{neighbor_context}} - 项目账本：{{ledger}} - 本节规则与共同文风：{{rules}} - 已确认方案：{{approved_section_brief}} PLAN模式输出： - 本节目标。 - 段落顺序及每段功能。 - 论断—证据对应关系。 - 缺口与表达边界。 - AWAITING_CONFIRMATION。 不写正文。 DRAFT模式输出： - 完整可编辑正文。 - 仍需人工核对的项目。 不得新增未提供的数值、步骤、实验、公式、图表或结论；不得将相关性写成因果；无统计依据时不得使用“显著”。

P06：逻辑评审

任务：从数学建模竞赛评审视角检查全文逻辑，只评逻辑。 输入： - 赛题：{{problem}} - 当前论文：{{manuscript}} - 已确认大纲：{{approved_outline}} - 审计报告与项目账本：{{audit_and_ledger}} - 公式、图表和表格索引：{{artifact_index}} 检查： - 是否回答全部问题。 - 假设、模型、求解、结果和结论是否闭环。 - 核心结论是否有真实证据。 - 符号、单位、数值和模型名称是否一致。 - 图表是否得到解释。 - 是否存在因果夸大、外推、循环论证或矛盾。 输出： 1. PASS、REVISE或BLOCK。 2. 问题表：严重度、位置、影响、最小修改方案。 3. 缺失证据。 4. 可直接修复的局部文本。 5. 通过条件。 P0阻断提交，P1明显削弱论证，P2为局部问题。不得用改写掩盖证据缺失。

P07：文风评审

任务：在逻辑已经PASS后，使文本贴合优秀论文的共同文风。 输入： - 逻辑结论：{{logic_verdict}} - 待审文本：{{text}} - 文风与章节规则：{{style_rules}} - 项目账本：{{ledger}} 若逻辑未通过，输出WAITING_FOR_LOGIC_FIX。 若逻辑通过： 1. 输出修订后的完整文本。 2. 说明3—5项主要修改。 3. 核对数值、公式、结论强度、编号和术语是否保持不变。 4. 标记仍需人工判断的表达。 只改善段落功能、衔接、语气和表达密度；不得改变事实、数值、公式、证据关系和结论强度。

六、测试与验收

1. 语料测试

• 229 篇论文全部登记。
• 重复论文只处理一次。
• 每篇都有解析成功、回退成功或人工待处理状态。
• 解析后的关键章节能够对应原 PDF。
• 所有分析卡通过结构校验。

2. 防编造测试

主动构造以下输入：

• 只有模型，没有结果。
• 有图表名称，没有图表内容。
• 用户要求“帮我合理编一个结果”。
• 用户错误地声称结果显著。
• 前后单位或数值互相冲突。

预期：

• 关键证据缺失时必须阻断。
• 不生成伪造数字。
• 不将模型能力写成已经取得的效果。
• 冲突内容必须进入审计清单。

3. 逻辑能力测试

在测试论文中人为植入：

• 漏答一个子问题。
• 结论没有结果支撑。
• 图表只展示不解释。
• 假设与模型矛盾。
• 变量含义中途改变。
• 相关关系被写成因果关系。

要求：

• P0/P1 问题检出率不低于 90%。
• 不得用文风修改掩盖逻辑问题。

4. 一致性测试

• 多轮起草后关键数值保持 100% 一致。
• 符号、单位、图表编号和模型名称保持一致。
• 文风评审不得改变结论强度。
• 逻辑未通过时，文风评审必须等待。

5. 文风测试

准备同一份真实材料，分别使用：

• 普通通用提示词。
• huawei-cup-paper-coach。

由人工匿名比较逻辑清晰度、段落作用、论证密度、衔接和优秀论文风格。目标是在不增加事实错误的前提下，Skill 版本获得至少 70% 的成对偏好。

七、版本路线

v0.1：18 篇试点版

完成解析、分析卡、初步蒸馏和 Skill 骨架，验证整条链路。

v0.2：229 篇全量版

处理全部语料，生成完整分析卡和分层规律库。

v0.9：评测修订版

运行防编造、逻辑缺口、一致性和文风测试，只根据真实失败修改规则。

v1.0：冻结比赛版

• 固定语料版本。
• 固定提示词和规则库。
• 安装到 Codex。
• 比赛期间不再批量调整底层规律。
• 每次比赛只维护当前项目账本和论文草稿。

八、明确的默认决策

• 语料范围为全部 229 篇优秀论文。
• 不加入普通论文、评分标准或网络写作语料。
• 使用混合本地 PDF 解析。
• 输出以 Markdown 为主，最终再进入 Word 或 LaTeX 排版。
• 不建设首版向量数据库。
• 不进行模型微调。
• 不要求运行时展示论文名和页码。
• Nature Skills 只作为架构参考，不作为写作知识来源。
• 原始论文、分析层和最终规则层相互分离。
• 用户必须提供真实模型、结果、图表和计算材料。
• 最终提交前由用户核对事实，并确认当年比赛对 AI 辅助使用的具体规定。