TapRoot事故调查
概述
接收用户输入的任意格式事故调查报告（文本粘贴、Word/PDF/Excel 文件、图片 OCR 结果等），按 TapRooT 方法论重构为标准调查报告，并给出独立审核意见。报告结构遵循用户的流程图样板与空白事故分析表格模板。
配套资源
references/methodology.md— TapRooT 流程要点、SnapCharT 编写规则、15 个筛查问题、纠正措施规则、评分规则、边界处理。每次执行必读。references/root-cause-tree.md— 根本原因树完整中文结构（顶层四分类 + 设备分支 + 人员绩效 7 个基本原因分类的全部节点）。过树分析时必读。references/dictionary.md— 根本原因词典（约 3.7 万字符），各节点的判别问题。节点验证时按需查阅；节点均以## 节点名（第N页）为标题，用关键词 grep 定位（如grep -n "无程序\|培训" dictionary.md）。references/report-template.md— 标准输出报告模板与 Excel JSON 数据结构。输出前必读。assets/事故分析表格-空白模板.xlsx— 空白事故分析表格（Flowchart + Root Causes & CA's 两个工作表）。scripts/fill_report_xlsx.py— 将报告数据 JSON 填入空白模板生成 Excel 交付物（三中文工作表：起因事件链 / 根本原因与纠正措施 / SnapCharT事件时间线，表格自动美化可直接交付）；流程图页自动渲染 TapRoot 流程图（黄=事件、绿=条件、红八边形=事故、琥珀倒三角旗=CF 标记统一挂在图形右下角外侧、箭头连接，PIL 绘制嵌入 B5），默认打开「起因事件链」工作表，依赖 openpyxl + Pillow，用法见脚本 docstring。注意：此脚本依赖assets/事故分析表格-空白模板.xlsx模板文件，若技能安装包中未包含该模板则会失败。scripts/generate_xlsx.py— 无模板版 Excel 生成脚本，不依赖assets/目录中的空白模板，直接用openpyxl.Workbook()从零创建工作簿。功能与fill_report_xlsx.py完全一致（三中文工作表 + 流程图 + 美化表格），适用于技能安装包未包含模板文件的场景。用法：python generate_xlsx.py report_data.json 输出.xlsx。关键经验（openpyxl 图片缩放坑）：XlImage.width/XlImage.height属性设置后不会真正改变图片在 Excel 中的显示尺寸——openpyxl 在 save 时会按 PNG 原始像素尺寸嵌入，忽略运行时设置的 width/height。正确做法是在 PIL 层面用Image.resize((new_w, new_h), Image.LANCZOS)将 PNG 预缩放到目标显示尺寸后再嵌入 BytesIO 传给XlImage。generate_xlsx.py的build_flowchart_image()函数已实现此逻辑（max_display_w=2600），流程图原图宽度通常超过 4000px，预缩放到 2600px 后嵌入 Excel 字体清晰可读。scripts/md_to_pdf.py— 中文 Markdown → PDF 渲染（reportlab + 微软雅黑 msyh.ttc），支持标题层级（h1 自动居中 S_TITLE、h2-h4 蓝色）、表格（全篇统一缩放到 USABLE_W，左右边界对齐页边距 + 蓝底白字表头+斑马纹+细边框+列宽按内容动态分配（max 估算 + cap/floor 双字典算法，见下） + 长文本自动换行）、嵌套列表（缩进深度区分）、引用块、粗体/行内代码、dingbat 兜底（✔→√、✘→×）。MD 标题写法（HTML 标签，跨渲染器兼容）：H1 + H2 用<h1 style="text-align:center;">…</h1>/<h2 style="text-align:center;">…</h2>（H1 额外用<br/>手动断行：第一行字数略多、第二行略少、差距不大），H3+ 保持左对齐；md_to_pdf 自动识别 HTML h 标签 + 兼容<div align="center">容器（跳过 div 行）。用法：python md_to_pdf.py 报告.md 报告.pdf。汇总表列宽微调：自动识别表头关键词——"责任人"列上限 80pt（内容紧凑）、"纠正措施"列下限 110pt（长文本更宽）。表格左右边界对齐：所有表格以"因果因素（直接原因）识别"表为基准，强制缩放到 USABLE_W 保持左右边界一致。列宽与内容匹配：用sum(_disp_len(col))而非max估算列宽，使"支撑证据"列（多个 bullet 总字符数 > 其它列）按比例获得最宽列；同时移除旧的 220pt 全局上限（之前会破坏"内容多→列宽大"的比例关系）。关键词匹配用 CJK 词边界正则_cjk_word_match——避免"时间"误中"时间线""总时间"等子串。依赖 reportlab（隔离 venv 已装 5.0.0）。
输入要求
接受以下任一形式：
1. 粘贴的事故报告全文或摘要；
2. 文件路径（doc/docx/pdf/xlsx/txt/md 等，先转换为文本再分析）；
3. 多条零散事实描述（访谈记录、现场记录等）。
最低信息门槛：事故经过（何时/何地/何人/何事）、后果（伤亡/损失/环境影响）。低于门槛时不得强行分析，按"边界处理"输出信息补充清单。
处理步骤
严格按以下顺序执行，不得跳步：
- 读取与解析输入：文件先转文本（markitdown 或对应工具）。提取全部事实要素：时间、人物、动作、设备、环境、程序、后果。
- PDF 解析坑（本环境）：markitdown 未安装[pdf]可选依赖，对 PDF 会报MissingDependencyException而返回空。改用 PyMuPDF 兜底：python -c "import fitz; d=fitz.open(p); open(out,'w').write('\n'.join(p.get_text() for p in d))"（隔离 venv 已装 pymupdf 1.28）。扫描件无文本层时再走 OCR。 - 读取 methodology.md，按其流程执行后续步骤。
- 构建 SnapCharT 时间线：事实按时间升序排列，区分"事件"与"条件"，标注待核实假设。发现输入内部矛盾时记录，不在时间线中擅自调和。
- 识别因果因素（CF）：逐个写出 CF1、CF2…，每个 CF 给出"消除即可防止/显著减轻"的检验依据与证据位置。
- 过根本原因树：读取 root-cause-tree.md，对每个 CF 从顶层四分类选择/淘汰；人员绩效类先答 15 个筛查问题定位基本原因分类，再逐级下钻到叶节点。
- 词典验证：对候选节点在 dictionary.md 中查判别问题，逐条回答"是/否+依据"；答不出"是"则退回上层或标"候选（证据不足）"。
- 制定纠正措施：按 methodology.md 第四节规则（控制层级优先序、SMART、字段齐全）。
- 知识库交叉验证：见下节。
- 独立观点判断与评分：按 methodology.md 第五节输出缺失项、矛盾项、论证不足项、五维度完整性评分（百分制）、待完善事项清单。
- 组装输出：读取 report-template.md，按模板输出中文 Markdown 报告；用户要求 Excel 时，构造 JSON 并运行
scripts/generate_xlsx.py（无模板版，推荐）或scripts/fill_report_xlsx.py（需模板文件）生成，附在交付中。
知识库联动（EHS 交叉验证）
用户拥有多个 ima 知识库，验证时必须全量枚举，不得只搜一个库就下结论：
- 枚举：
get_knowledge_base_list必须带type参数（KBT_MINE_KB/KBT_SHARED_KB/KBT_SUBSCRIBED_JOIN_KB各调一次），默认/空参会报 "KBT_UNUSE" 错误。 - 重点库：EHS全景知识库（id 7452912192067832，主力）、探安~安全生产ima知识库（7463747757018376，含事故案例汇编）、EHS法规库五点半（7452722638887720）、安全生产管理分享（7381944069278667）等。
search_knowledge单库返回可能超过 10 万字符，结果会被存入 tool-results 大文件；不要直接全量读入上下文，用 python 解析其 JSON 的searched_knowledge_list，按knowledge.title+highlight_content正则过滤关键词（从事故中提取：物料/设备/作业类型/伤害类型，如"泄漏""受限空间""机械伤害"）。- 验证三类内容：① 事实类（同类事故的典型原因模式、物料危害特性、接触限值）；② 原因判定类（类似事故是否曾判定到相同树节点）；③ 措施类（法规标准要求的纠正措施、行业良好实践）。
- 每条验证结论标注来源库与文档名，结论分为：支持 / 矛盾 / 无相关资料。知识库意见与树分析结论冲突时，以树＋词典证据为准，并在独立观点中说明分歧。
输出要求
- 术语规范（全技能强制）：
Flowchart不译为"流程图"，统一译为「起因事件链」（与中文工作表名一致）。SnapCharT时间线统一译为「SnapCharT事件时间线」（与中文工作表名一致）。- 方法论英文术语后附中文标注（出现在标题、报告头"分析方法"、附注"分析方法声明"等处）：
SnapCharT事件时间线 + Root Cause Tree根原因树 + Dictionary词典。 - "因果因素" 一律写「因果因素（直接原因）」（统一术语，便于读者理解"直接原因"与"根本原因"的区分）。
- 根原因树中英文缩写翻译（出现在下钻路径、词典判别问题引用、RC 描述等处）：
NI(Needs Improvement) → 需改进（执行 NI → 执行需改进、理解 NI → 理解需改进、采购 NI → 采购需改进、危险分析 NI → 危险分析需改进、PM NI → 预防性维护需改进）SPAC(Standards, Policies, Administrative Controls) → 标准/政策/行政管控（无 SPAC → 无标准/政策/行政管控、缺防静电 SPAC → 缺防静电标准/政策/行政管控）QC(Quality Control) → 质量控制（独立 QC → 独立质量控制、监督/QC → 监督/质量控制）
- 保留原文：TapRooT / SnapCharT / CF 编号 / RC-CFn-x 编号 / Q1-Q15 筛查问题编号 / GB·AQ·DB 等标准号 / AS-EX80·IV-802 设备型号 / DHA。
- 术语改动必须五处同步（脚本常量、SKILL.md、report-template.md、MD 报告、PDF/XLSX 实际产物），不得遗漏。
- 全部中文输出（含 Excel 交付物的表头、工作表名、流程图标题与图例）；结构严格按
references/report-template.md（报告头 → 事故概述 → SnapCharT → 因果因素 → 过树分析 → 根本原因与纠正措施汇总表 → 知识库交叉验证 → 独立观点判断 → 附注）。 - 标题排版：
-
MD 主标题 + 二级章节标题用 HTML 原生标题标签 + 内联 CSS
style="text-align:center;"实现居中。内联 CSS 的 specificity=1000，最高优先级，能压过 ima 内置浏览器 / 腾讯文档预览 / GitHub / Typora 等任何渲染器自身的h1,h2{text-align:left}默认样式表，确保跨渲染器一致居中。H3+ 保持左对齐避免小标题居中显得过于突兀。主标题额外使用<br/>手动断行（第一行字数略多、第二行略少，差距不大保证视觉美观；典型比例 20:17 字）。示例：
```markdown
<h1 style="text-align:center;">TapRooT 事故调查报告：公司名"日期"<br/>事故简述</h1><h2 style="text-align:center;">0. 报告头</h2>
`` - **为什么必须用<h1 style="text-align:center;">（写错会翻车，三种坑都见过）**： 1. vs<h1 align="center">：**实测不居中**。align是已弃用 HTML 写法（specificity 极低）；ima 的内置 markdown 浏览器基于 markdown-it，会附h1,h2{text-align:left}默认 CSS 覆盖align属性 → 标题仍然左对齐。这是本技能早期踩过的坑。 2. vs<div align="center"># …</div>或<div style="text-align:center;"># …</div>：**div 内的# 标题不会被解析为 heading**（CommonMark 规范：块级 HTML 内部按字面 HTML 处理，不二次解析 Markdown）→ 标题变成普通段落文本，即便 div 居中了。 3. vs 在标题行前后手动加空格/全角符号"伪居中"：**渲染器无关但不可靠**，等宽字体下才居中，变字体立刻跑偏。 - **唯一跨渲染器都可靠的写法：原生<h[1-2] style="text-align:center;">HTML 标签 + 内联 CSS**。md_to_pdf.py parse_md 的通用正则<(h[1-6])(?:\s+[^>])?>(.)</\1>识别任意<h1 ...>/<h2 ...>并按级别处理（style属性被忽略，不影响 PDF 渲染）。 - **PDF 主标题**由 md_to_pdf.py 自动用 S_TITLE（16pt 加粗居中）渲染 +<br/>换行；H2+ 仍用 S_H2（蓝色左对齐）保持"主标题居中、章节标题分层"的视觉层级。 - md_to_pdf.py 同时兼容：①<div align="center">…</div>容器（跳过 div 行，解析内嵌 Markdown 标题）；②<h1 style="text-align:center;">…</h1>/<h1 align="center">…</h1>/ 任意<h1 …>HTML 标签（直接识别为 h1 级别）。**新生成的报告统一使用style="text-align:center;"内联 CSS 写法**。 - **表格对齐（双层规则）**： 1. **左右边界**：PDF 报告内**所有表格**（报告头表 / SnapCharT 时间线表 / 因果因素表 / 知识库交叉验证表 / 汇总表 / 引用块等）无条件缩放到USABLE_W（A4 横向页面可用宽度），使所有表格**最左边线 = 最右边线 = 页边距**，以"因果因素（直接原因）识别"表为对齐基准；md_to_pdf.py 在_table_flow中无条件缩放 + 最小列宽 32pt 保护（保证"CF1"等短文本+padding 还能 TA_CENTER），避免窄列被压到不可用宽度。 2. **单元格对齐**：单元格内容TA_LEFT左对齐（S_CELL）；居中列（短文本/编号）保持TA_CENTER（S_CELL_C）；表头TA_CENTER蓝底白字。**注意**：CJK 混排表格不要用TA_JUSTIFY（两端对齐）——CJK 字符按字宽比例撑满整行时，会在"第 287 行"这种 ASCII 词边界插入额外空白导致可见间距。S_CELL 已统一为TA_LEFT彻底避免此问题。 3. **列宽按内容动态分配（v4 双字典算法，关键规则）**：md_to_pdf.py _table_flow用 **max 估算**（取列内最长单格_disp_len × 5.2pt + 12pt；单格长列只需容纳其最长一行，无需sum全列 → 之前的sum会让"时间"这种每格都长的列被 7 行全量叠加成 145pt 超宽）作为原始宽；再用两张关键词字典约束——_HEADER_WIDTH_CAPS（列宽上限，防单格超长列独占宽度挤压短数据列）与_HEADER_WIDTH_FLOORS（列宽下限，保证"单行优先"列不被压到换行）。**四阶段流程**：① 按 max 估算原始宽；② 逐列取max(min(cap, 估算宽), floor)（cap 截断 + floor 拉宽，**floor 永远赢**）；③ floor 列固定最终宽度，剩余空间按"非 floor 列当前宽"比例分摊（保证总宽 = USABLE_W、全篇表格左右边界一致）；④ 任何列 < 32pt（MIN_COL）兜底，差额从最宽列扣回。**设计原则**：单行优先列（时间/责任人/目标完成日期/维度/关联CF/完成情况/序号/编号/类型/满分/得分/合计）给 **floor**（列宽下限，确保单行不换行）；长内容列（因果因素/根本原因/纠正措施）给 **cap**（列宽上限，让自然 max 估算主导，如 根本原因 cap=100 让其紧凑换行、比纠正措施窄）；**列数多（>5 列）的表慎加过多 floor**——floor 总宽别超 USABLE_W 的 80%，否则非 floor 长内容列会被过度压缩到接近 MIN_COL。**CJK 词边界匹配**_cjk_word_match避免短关键词在长表头中被子串误触发（如"时间"不中"时间线"）。**已验证效果（吸尘器闪爆 v10）**：SnapCharT 时间 90pt（"2025-08-28 08:40" PyMuPDF 实测单行）/关联CF 70pt（"CF2、CF3" 单行，仅第 3 个 CF 才换行）；汇总表 责任人 130pt（加宽）/目标完成日期 70pt（"2026-09-30" PyMuPDF 实测单行）/根本原因 被 cap 压缩到约 32pt（见下注）；完整性评分 维度 125pt（加宽）/扣分说明 288pt。 4. **关键词匹配用 CJK 词边界**：表头关键词（如"时间"、"编号"）用_cjk_word_match做 CJK 词边界正则匹配（(?<![一-鿿])keyword(?![一-鿿])），避免短关键词在长表头中被子串误识别。**反面案例**："支撑证据（时间线/事实来源）"中含子串"时间"，原in匹配会把 70pt 的"时间"列宽上限错加给支撑证据列，导致该列被压到 ~10pt；改用 CJK 词边界后"时间"不中"时间线"，支撑证据列才能按内容宽度正常分配。 - **Excel 默认打开工作表**：脚本保存前wb.active = wb.sheetnames.index("起因事件链")，确保双击文件直接看到流程图而非数据表；脚本末尾的 print 已加入默认打开「起因事件链」提示。 - **汇总表字段（全中文表头）**：序号 / 因果因素（直接原因） / 根本原因 / 纠正措施 / 责任人 / 目标完成日期 / 完成情况。一个 CF 多个根本原因时各占一行，沿用上行字段留空（同样板填法）。 - **PDF 汇总表列宽微调**（md_to_pdf.py 双字典规则，见_HEADER_WIDTH_FLOORS/_HEADER_WIDTH_CAPS）： - "责任人" 列 **floor 110 / cap 130pt**（加宽，容纳"部门 / 岗位"长值；cap 防独占，长值仍换行） - "目标完成日期" 列 **floor 70 / cap 80pt**（"2026-09-30" 单行不换行） - "根本原因" 列 **不设 cap**（长内容列，按内容量比例分配，自然落在「因果因素」与「纠正措施」之间；曾设 cap=100 会把该列在 7 列表自然宽溢出 USABLE_W 时被比例分摊压到接近 MIN_COL、反而比内容更少的「因果因素」还窄，违背"列宽按内容量分配"原则，故移除——若某报告该列实际内容很少希望兜底，可再给 floor 抬高下限） - "完成情况" 列 **floor 45pt**（"未开始/进行中/已完成" 单行） - "纠正措施" 列按内容自动估算（无 floor/cap，由 max 估算主导，通常最宽） - 其它短列（序号/编号 ≤38、满分/得分 ≤40、合计 ≤55）按关键词封顶 - 总宽统一缩放到 USABLE_W（493.2pt），≤4 列最小 40pt、5–7 列最小 26pt、>7 列最小 20pt。 - **流程图 CF 倒三角旗规则**：统一挂在图形**右下角外侧**（标签在三角正下方，不遮挡框内文字）；事件、条件、事故框**均可**标注 CF——与模板内嵌的公司样板一致（样板中 CF1 标在事件框底边、CF2 标在条件框右侧），并非只标条件；图例中 CF 项标注为「CF 因果因素（直接原因）」，明确与"根本原因（Root Cause）"的区别。 - **双格式交付（MD + PDF）**：交付报告时默认生成两份，MD 便于编辑与版本管理，PDF 便于分发与查阅；Excel 仍可选。md_to_pdf.py与generate_xlsx.py（无模板版，推荐）或fill_report_xlsx.py`（需模板文件）均在技能 scripts/ 中配套使用。
- SnapCharT 除文字表格外，可用 show_widget 绘制示意图（矩形=事件、椭圆=条件、菱形=CF）。
- 报告交付后调用 present_files 呈现；如有 Excel/MD/PDF 多份交付物一并呈现。
边界处理（信息不足时）
- 低于最低门槛：不输出分析报告，改输出"信息补充清单"，列明需要的最低事实集（事故经过、时间、人员、设备、环境、后果），请用户补充。
- 部分事实缺失：SnapCharT 照实画（缺失处标"未知"），受影响 CF 标"暂定"，根本原因标"候选（证据不足）"，完整性评分相应扣分，并在待完善事项清单中逐条说明。
- 禁止事项：不得编造事实/时间线/根本原因；不得把输入报告的作者结论直接当作根本原因（必须经树＋词典独立验证）；不得停留在树的中间层级充当根本原因；涉及事故定级与法律责任时仅给参考意见并注明"以政府主管部门认定为准"。
