YangChen91 事故报告分析 (Accident Report Analysis)
从 Word（.docx/.docm）和 PDF 事故报告中提取结构化信息，合并重复报告，按时间排序后输出 Excel。
工作流程
- 确认输入文件夹（含
.docx、.docm、.pdf）和输出 Excel 路径。 - 运行提取脚本（见下方）。
- 检查输出列：事故时间、客户名称、问题类型、问题现象、问题原因、解决及优化措施、文件名。
- 若识别有误，查阅 reference.md 中的提取规则与客户列表。
推荐执行方式
python scripts/extract_accident_info.py --input "D:\Cursor_WorkSpace\质量加固\事故报告原始文档" --output "D:\Cursor_WorkSpace\质量加固\事故报告汇总.xlsx"
工作区默认目录结构：
| 路径 | 说明 |
|---|---|
质量加固/事故报告原始文档/ |
原始 Word/PDF 事故报告（MinerU 缓存在其下 .mineru_cache/） |
质量加固/事故报告汇总.xlsx |
提取结果 Excel |
质量加固/事故报告Dashboard.html |
统计 Dashboard（由 generate_dashboard.py 生成） |
通用命令（路径可替换）：
python scripts/extract_accident_info.py --input "事故报告文件夹路径" --output "输出.xlsx"
依赖安装：
pip install pandas openpyxl
npm i -g mineru-open-api
PDF 解析使用 pdf-converter-mineru 的 mineru-open-api flash-extract（无需 API Key，单文件 ≤10MB / ≤20页）。
首次运行较慢（约 69 个 PDF × 10 秒/份 ≈ 10～15 分钟），结果缓存在输入目录 .mineru_cache/。再次生成 Excel 会直接读缓存，速度与 pdfplumber 方案接近。
核心能力
| 能力 | 说明 |
|---|---|
| 文档解析 | DOCX/DOCM 按 body 顺序读段落+表格；PDF 用 MinerU flash-extract + HTML 表格提取 |
| 信息提取 | 多标题映射到各列；问题类型按现象关键词自动多选分类（顿号分隔） |
| 重复合并 | 按 (客户名称, 归一化文件名) 合并 (1)、- 副本 等同事故多份报告 |
| 空值填充 | 各列为空时从全文二次解析；事故时间优先落款与中文数字日期 |
| 排序 | 事故时间倒序，客户名称正序 |
脚本说明
| 脚本 | 用途 |
|---|---|
scripts/extract_accident_info.py |
CLI 入口，批量处理文件夹并输出 Excel |
scripts/core_functions.py |
核心解析、提取、合并逻辑（供脚本 import） |
核心函数见 reference.md。
文档命名建议
推荐格式：YYYY年MM月DD日客户名称问题描述.docx 或 .pdf
章节标题使用标准关键词（问题现象、原因分析、解决及优化措施等），并在文档开头附近写明事故时间。
故障排除
| 问题 | 处理 |
|---|---|
| DOCM 解析失败 | 脚本已用 zipfile 直接读 word/document.xml |
| 重复报告未合并 | 检查文件名是否含 (1)、- 副本 等，见 reference.md 归一化规则 |
| 客户名称识别错误 | 更新 core_functions.py 中 CLIENTS 列表 |
| 事故时间为空 | 确保文档含可识别日期格式；优先查落款时间、中文数字日期 |
| PDF 解析失败 | 确认已安装 mineru-open-api；大文件（>10MB 或 >20页）需改用 extract 模式 |
| PDF 文本乱码/空格 | MinerU 输出 Markdown，脚本会清理多余空格，保留日期时间间空格 |
| 某行三列全空或部分空 | 见下方「迭代经验」与 reference.md「解析陷阱与调优经验」 |
迭代经验（维护必读）
以下为实际批量提取 200+ 份报告后沉淀的规则，新增章节关键词或改解析逻辑时请先对照。
1. 章节映射：同一列可对应多种标题
报告模板不统一，不要假设只有「问题现象 / 原因分析 / 解决及优化措施」三个标准标题：
| Excel 列 | 常见文档标题（均应归入此列） |
|---|---|
| 问题现象 | 问题现象、故障经过、事件经过、事件影响、事件内容、事件处理流程、事件过程描述、事故内容/事故內容 |
| 问题原因 | 原因分析、事件原因 |
| 解决及优化措施 | 调整方案、优化建议、整改建议、事件责任建议、整改措施、Resolution |
英文报告（如 Incident Report 20210705(HTAI).pdf）：事件 = 问题。事故內容 / Incident Description → 问题现象；Root Cause → 问题原因；Corrective Action / Resolution → 解决及优化措施。华泰 HTAI 报告多为繁体，关键词需同时覆盖简繁。
同一文档内多个现象/措施章节（如「事件过程描述 + 事件影响」「整改建议 + 事件责任建议」）合并写入同一列，Excel 单元格内用换行分隔。
2. 表格内容：顺序拼接 + 按行换行
不少 Word 报告用表格承载核心信息（如事件处理流程、整改建议表）：
- DOCX 必须按
w:body子节点顺序交替读取段落与表格，不能先抽全部段落再抽全部表格。 - 表格每一行：从左到右拼接单元格 →
_beautify_table_row美化（补标点、去多余空格）→ 作为独立一行文本。 - 跳过表头行（时间、发生事件、处理方法、日期和時間 等）。
- PDF 经 MinerU 转 Markdown 后可能含 HTML
<table>，需_parse_html_tables同样按行提取。 - 写入 Excel 时，同一章节的多行内容用
\n连接，一行表格数据对应单元格内一行。
3. 页脚/截断规则：避免误杀正文
不要用宽泛关键词截断正文。典型踩坑：
- 正文写「处理人：恒云科技」时，若规则匹配任意含「恒云科技」的行，会导致整段现象/措施被丢弃（如广发 WMC 对账事件 docx 第 65 行曾因此三列全空）。
- 正确做法：仅匹配独立落款行（如
^恒云科技$）或含「特此说明 / ---完-- / 本文档为 / 文档编号」的行。
4. 段落合并与序号
normalize_section_items：前一条以句号类标点结尾时，下一条应新开一项，不能无脑拼接到上一条（否则「整改建议」与「事件责任建议」会合成一段）。add_line_numbers：列表序号用^[1-9]\d?[、.]，不要把2025.1.27这类日期当成已有编号。
5. 标题用词变体
实际文档标题常有细微差异，需一并注册到 SECTION_HEADERS：
- 「事件处理流程」vs「事件过程描述」（同一语义，不同写法）
- 繁体：問題現象、事故內容、解決方案、處理措施
新增空列案例时，先用调试方式打印 extract_text_from_docx / MinerU 文本的逐行输出，并对每行调用 _match_section，确认是未识别标题还是被页脚规则跳过。
6. PDF 与性能
- 首次全量 PDF 解析慢（MinerU 逐份转换），结果缓存在输入目录
.mineru_cache/*.md。 - 调整章节规则或表格逻辑后，DOCX 改动即时生效；PDF 若缓存未过期则直接读
.md，无需重跑 MinerU。 - 强制重转某 PDF：删除对应
.mineru_cache/xxx.md后再跑脚本。
7. 空列回填
合并去重后若仍有空列，fill_missing_fields 会基于 原始文本 二次解析 + 关键词启发式回填。但首选仍应修章节映射与表格解析，回填仅作兜底。
详细函数说明、关键词完整列表与调试步骤见 reference.md。