Paper Final Check（论文终稿检查）
概述
对论文 Word 终稿做投稿前质量检查，覆盖六类问题，每类问题都在 Word 副本中以黄色底纹标注出来，同时输出一份检查报告（含问题位置、原文、问题说明、修改建议）。检查只发现问题、不替用户改正文，修改决策权始终留给用户。
六类检查：
| 类别 | 检查内容 |
|---|---|
| ① 标点符号 | 中英文标点混用、全角/半角错误、重复标点、引号不配对 |
| ② 图表标注 | 图题/表题编号是否连续、有无跳号重复、图题位置、正文交叉引用对应 |
| ③ 标题格式 | 各级标题编号体系是否统一、有无跳级/断号、同级标题样式格式是否一致 |
| ④ 参考文献 | 正文引用与文末列表是否按顺序一一对应（GB/T 7714-2025 / IEEE），缺号/跳号/冗余 |
| ⑤ 作者信息 | 作者姓名、单位有无遗漏，中英文作者与单位是否一一对应 |
| ⑥ 错别字与表达 | 错别字、语病、表达不通顺的句子 |
工作流程总览
输入 .doc/.docx → Phase 1 预处理与解析 → Phase 2 确定性检查（脚本）
→ Phase 3 语义检查（LLM） → Phase 4 黄色底纹标注 → Phase 5 检查报告 → 交付
Phase 1：预处理与解析
- 确认输入：用户提供 .doc 或 .docx 论文文件。若是 .doc（老格式），先用 libreoffice 转为 .docx：
bash libreoffice --headless --convert-to docx --outdir /sandbox/workspace/tmp_check/ 论文.doc
后续所有步骤都在 .docx 上进行。 - 复制工作文件：在
workspace下建独立工作目录（如paper_check_<时间戳>/），复制 docx 进入，所有中间产物都放在该目录，避免污染用户原文件。 - 解析文档：运行
scripts/run_checks.py --dump提取文档结构（段落文本、Word 样式名、图片位置、表格位置），输出document.json，作为确定性检查与语义检查的共同基础。
Phase 2：确定性检查（脚本）
运行检查脚本，对五类可规则化的检查项做确定性扫描：
python3 scripts/run_checks.py 论文.docx --format auto --output issues.json
--format指定参考文献标准：gbt7714（GB/T 7714-2025 版，2026-07-01 起实施，默认新标准）、ieee、auto（自动识别，默认）。GB/T 7714-2025 的重点规则：西文作者姓氏仅首字母大写、无卷号期刊"年(期)"不加逗号、在线文献先判本体类型再补载体标识（[J/OL] 而非一律 [EB/OL]）且必须附 URL、学位论文强制标注引用页码、电子资源日期统一 YYYY-MM-DD。- 脚本输出
issues.json，包含全部确定性问题的结构化条目（类型、严重度、段落定位、问题说明、修改建议）。脚本内部执行： - 标点检查：按
references/punctuation-rules.md的规则扫描 - 图表标注检查：图题/表题编号连续性、位置、交叉引用
- 标题格式检查：编号体系、跳级、样式一致性
- 参考文献检查：正文引用与列表的对应关系（顺序、连续性、漏引/冗余），条目格式按 GB/T 7714-2025 细则判断（见
references/reference-formats.md） - 作者信息检查：中英文作者/单位对应
- 若脚本对某类检查置信度不足（如无法定位参考文献列表），在
issues.json中标记"unresolved": true，由你在语义检查阶段人工复核。
Phase 3：语义检查（LLM 错别字与表达）
错别字和语病无法用规则穷举，由你（Agent）基于 document.json 逐段检查：
- 从
document.json读取正文段落，跳过参考文献列表区域（避免把文献条目当正文）。 - 逐段判断：错别字（同音/形近字误用）、语病（成分残缺、搭配不当、语序混乱）、表达不通顺（歧义、重复啰嗦、逻辑断裂）。
- 将发现的问题按与
issues.json完全相同的条目格式追加到issues_semantic.json（可让脚本run_checks.py --merge issues.json issues_semantic.json合并，或直接手工维护同一 JSON）。定位信息（paragraph_index/start/end）必须基于document.json中的真实偏移，标注阶段依赖它定位。
判断标准：拿不准的不要报，避免误报干扰用户；宁可漏报可疑项，不可把正确表达标错。学术写作中的专业术语、缩写、人名地名，除非确凿错误，不标。
Phase 4：黄色底纹标注
合并所有问题（确定性 + 语义）后，在 Word 副本中标注：
python3 scripts/highlight.py 论文.docx issues_all.json --output 论文_终稿检查标注.docx
- 问题文本所在字符加 黄色底纹（Word 的 shading FFFF00，非字体高亮色）。
- 同一段落多处问题分别标注；标注不改动任何原文文字，只加底纹。
- 输出文件命名：
<原名>_终稿检查标注.docx，与原文件同目录或工作目录。
Phase 5：检查报告
输出一份 Markdown 检查报告 <原名>_检查报告.md，始终使用以下结构：
# 论文终稿检查报告
## 摘要
- 检查文件：<文件名>
- 参考文献标准：GB/T 7714-2025 / IEEE / 混合
- 问题总数：N（错误 X 处 / 警告 Y 处 / 建议 Z 处）
- 分类统计：标点 n 处、图表 n 处、标题 n 处、参考文献 n 处、作者 n 处、错别字与表达 n 处
## 问题清单
按类别分节，每处问题给出：
| 位置 | 原文 | 问题 | 修改建议 |
|（第几章/第几段/行号）|（原文摘录）|（问题说明）|（具体改法）|
## 修改建议汇总
按严重度排序的要点式总结，方便用户逐条处理。
报告与标注文件一起交付。若用户需要 Word 版报告，用 pandoc 或 python-docx 转换。
多轮修改
用户可能根据报告提出疑问或要求复查：
- 质疑某处标注：解释判断依据（引用对应规则或语言规范），用户认可后可从 issue 中剔除。
- 要求只保留某几类检查：重新过滤 issues 并重新标注，不需要重跑全流程。
- 修改后复查：重新走 Phase 1-5，检查修改是否引入新问题。
工作流示例
示例 1：期刊论文投稿前检查
用户上传 论文.docx，说"帮我终稿检查"。→ 解析 → 确定性检查（auto 识别出 GB/T 7714-2025）→ 语义检查 → 标注 + 报告 → 交付 论文_终稿检查标注.docx 和 论文_检查报告.md，报告中指出 12 处中英文标点混用、图 3 编号跳号（图 2 后直接是图 4）、正文引用 [5] 但参考文献列表无第 5 条等。
示例 2：IEEE 会议论文检查
用户说"按 IEEE 格式检查我的会议论文"。→ 指定 --format ieee，重点核查正文引用方括号编号顺序、文末条目结构（作者名缩写、卷期页码、会议名称缩写）是否合规。
示例 3：GB/T 7714-2025 新增规则检查
论文参考文献中含 [DS/OL] 数据集、[PP/OL] 预印本等 2025 版新增类型；某条西文作者写为 EINSTEIN A（全大写）、某条无卷号期刊写为 2025,(3) → 按 2025 版细则报 warning 并给出修改建议。
资源目录
scripts/run_checks.py— 确定性检查主脚本（含文档解析、五类规则检查、JSON 合并，参考文献按 GB/T 7714-2025 / IEEE 检查）scripts/highlight.py— 黄色底纹标注脚本references/punctuation-rules.md— 标点规范细则与常见错误清单references/reference-formats.md— GB/T 7714-2025 与 IEEE 参考文献格式细则references/quality-criteria.md— 图表标注、标题格式、作者信息的检查标准
