原始底稿流水线 v13.2（双输出：JSON 主 + MD 辅）

本文档描述一套通用材料全量转录流水线：把任意批量材料转写为结构化底稿，供下游 AI 工具消费。核心能力是双引擎 OCR 交叉核对 + 四档裁决 + 多模态兜底 + 防偷懒合约。

版本记录

| 版本 | 日期 | 变更 | |------|------|------| | v13.2 | 2026-08-15 | 语言检测增加日文假名/韩文音节统计（中日韩混排邮件实测）；source 字段全分支固化；engine_source 空值兜底改 unknown | | v13.1 | 2026-08-09 | 新增「防偷懒合约条款」（JSON 结构完整性/schema 一致性/材料全量覆盖/双引擎交叉核对四项硬合约） | | v13.0 | 2026-08-09 | 双输出升级：JSON 主 + MD 辅。JSON 保留页码/bbox/版面关系（机器消费），MD 供人眼核校 | | v12.1 | 2026-08-05 | 引擎选择铁则代码化（_detect_language() 自动中英文分流）；批量失败隔离；废弃旧版交叉核对脚本 | | v12.0 | 2026-07-26 | 产出路径调整为项目底稿目录（加工产物与原始材料分层） | | v11.1 | 2026-07-26 | 分层声明：本技能为流程层，OCR 引擎调用层（双引擎 API）在工具层，通过标准接口调用 | | v10.5 | 2026-07-14 | 双引擎 OCR 交叉核对能力固化（引擎选择铁则 + 四档裁决 + AI 语义终裁 + 多模态兜底） | | v10.4 | 2026-07-14 | 引擎级批量 OCR（性能提升约 54%）；批量失败隔离 | | v10.3 | 2026-07-14 | AI 语义终裁（相似度数字只作信号不作结论）；引擎选择铁则；结构化输出 | | v10.2 | 2026-07-14 | 多模态兜底落地：纯图片 PDF 主模型视觉识别完整转录 | | v10.1 | 2026-07-14 | 文件级并行（速度提升 3-5 倍）；自动环境检查；智能路由；多模态兜底 | | v10.0 | 2026-06-29 | 防误判机制体系化（双引擎交叉验证/文件类型探测/多模态兜底） | | v9.0 | 2026-06-29 | 四档裁决（替代三档）；差异标记 <ins>/<del> 落地；多模态完整转录；多轮自验证 |

功能实现状态

| 功能 | 状态 | 说明 | |------|------|------| | 双引擎 OCR 交叉核对 | ✅ 已实现 | 引擎选择铁则 + 四档裁决 + AI 语义终裁 + 多模态兜底 + 置信度 A-E | | 并行处理（文件级） | ✅ 已实现 | parallel_main.py 的 process_all_files_parallel() | | 引擎级批量 OCR | ✅ 已实现 | process_scanned_pdfs_batch() 调用工具层批量接口 | | 智能路由 | ✅ 已实现 | build_smart_routing() 按文件头自动判断类型 | | 图片 OCR 路由 | ✅ 已实现 | process_img_ocr() | | 自动环境检查 | ✅ 已实现 | auto_env_check.py 检测 OCR API 配置状态 | | 多模态兜底 | ✅ 已实现 | OCR 失败后由 Agent 读图 + 主模型视觉识别 | | 置信度评分 | ✅ 已实现 | 相似度(40%) + 文本长度(30%) + 关键字段识别率(30%) | | 双输出（JSON + MD） | ✅ 已实现 | assemble_json.py 组装 + Schema 校验 + MD 渲染 + 降级 | | 结构化 JSON 透传 | ✅ 已实现 | 保留双引擎原始结构化块（含 bbox） | | 流程闭环入口 | ✅ 已实现 | parallel_main.assemble_manuscript_output() 直接产出双输出 |

架构总览

┌─────────────────────────────────────────────────────┐
│  输入：批量材料（PDF / 图片 / 邮件 / Word / 音频）      │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│  Phase 0  文件预标准化（<2 分钟）                      │
│  - 路径编码规范化（临时目录 + 映射表）                  │
│  - 压缩包跳过（只标注占位，不解包）                    │
│  - 文件头探测真实类型（不信任扩展名）                  │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│  Phase 1  五路并行处理                                │
│  ├─ 文字型 PDF → PyMuPDF（50+ 页/秒）                 │
│  ├─ 扫描件 PDF → 双引擎 OCR 批量                      │
│  ├─ 图片      → 双引擎 OCR（普通）/ 多模态（长截图）    │
│  ├─ 邮件      → Python email 模块                    │
│  └─ 音频      → 转文字工具                            │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│  Phase 2  交叉核对 + 四档裁决                          │
│  ≥95% 自动定稿 → 80-95% 定稿+差异标记 →               │
│  <80% AI 语义终裁 → 双引擎均失败 多模态兜底            │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│  Phase 3  一次性组装（JSON 主 + MD 辅）                │
│  + 防偷懒合约（V0.5 确定性门禁）                       │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│  Phase 4  V 阶段验证审查（三方视角）                   │
└──────────────────────┬──────────────────────────────┘
                       ▼
┌─────────────────────────────────────────────────────┐
│  输出：底稿 JSON（主）+ 底稿 MD（辅）+ schema.json     │
└─────────────────────────────────────────────────────┘

双引擎 OCR 交叉核对（核心能力）

0. 执行概览

文件输入
  │
  ├─ 文字型PDF → PyMuPDF（本地极速，50+页/秒）
  │
  ├─ 扫描件PDF / 图片
  │     │
  │     ├─ 中文打印体/截图/流水 → PaddleOCR 主力 + MinerU 核对
  │     ├─ 英文/外文合同         → MinerU 完整版 主力 + PaddleOCR 补缺
  │     └─ 纯图片框图/组织结构图  → 直接多模态（跳过 OCR API）
  │     │
  │     └─ 双引擎并行调用（线程池）
  │            │
  │            ├─ 相似度 ≥95% → 自动定稿（A级）
  │            ├─ 相似度 80-95% → 定稿+差异标记（B级）
  │            ├─ 相似度 <80% 或单引擎失败 →
  │            │     先 AI 语义终裁排假警报
  │            │     ├─ 实质一致 → 定稿
  │            │     └─ 真冲突 → 多模态兜底 / 人工复核
  │            └─ 双引擎均失败 → 多模态兜底（C级）
  │
  ├─ 微信长截图/复杂表格 → 直接多模态（跳过 OCR）
  │
  └─ Word/音频 → 对应工具处理

1. 引擎选择铁则（核心原则：按语言和类型选权威源）

| 文件类型 | 主力引擎（权威源） | 辅助引擎 | 置信度默认 | |---------|------------------|---------|-----------| | 中文打印体 / 截图 / 银行流水 | PaddleOCR | MinerU 核对 | A-B | | 英文/外文合同（含附件/价格表/条款） | MinerU 完整版 | PaddleOCR 仅补缺 | A-B | | 纯图片框图（组织结构图等） | 多模态（主模型视觉） | 不调 OCR API | C | | 复杂表格 / 跨页合并单元格 | MinerU 优先 | PaddleOCR 核对 + 多模态兜底 | B-C |

代码化实现：_detect_language() 自动检测文本语言（CJK vs Latin 字符比例），_cross_check() 在四档裁决时自动按语言切换权威源。

实测经验：英文合同场景下 PaddleOCR 类引擎对数字严重欠提取（数字 token 可能仅为主引擎的约 1/9，丢失附件/价格表/付款条款）——英文材料必须以 MinerU 类完整版为权威源。

2. 双引擎并行调用

Step 1: 文件类型检测 → 分配引擎（中文 → PaddleOCR 主；英文 → MinerU 主）
Step 2: 双引擎并行调用（线程池，max_workers=2）
Step 3: 文本清洗（两引擎独立清洗后比对）
  ├─ 剥离 HTML 标签
  ├─ HTML 表格 → Markdown 表格（展开 colspan/rowspan）
  ├─ 解码 HTML 实体
  └─ 去多余空白、统一换行
Step 4: 交叉核对（四档裁决）
  ├─ ≥95%    → auto_resolved（A级）
  ├─ 80-95%  → auto_resolved_with_diff（B级）
  ├─ <80%    → 进入 AI 语义终裁
  └─ 单引擎   → single_engine（B级）
Step 5: 置信度评分（A-E）
Step 6: 结果输出（primary_text / diff_markup / confidence / status）

3. AI 语义一致性终裁（核心经验）

核心教训：机械相似度数字 ≠ 内容准确度。低相似度常为"格式/膨胀差异"而非"识别错误"。

触发条件：相似度 <80% / 英文合同 / 双引擎长度差 >2×

诊断顺序（先排除假警报）：

相似度低（如 13%）
  ├─ ① HTML 表格膨胀？ 主引擎含原始 <table> 块（4–16×膨胀）
  │     → 先 HTML→Markdown 清洗再比（清洗后常 ≥95%）
  ├─ ② 引擎选择错？ 英文合同误用 PaddleOCR 作权威源
  │     → 改以 MinerU 为主
  ├─ ③ 格式差异？ 截图/凭证类 UI 元素保留程度不同
  │     → 内容其实一致
  └─ ④ 以上皆否 → 才是真识别错误 → 多模态兜底 / 人工复核

4. 多模态兜底（OCR 失败时的终级防线）

| 触发场景 | 执行方式 | 置信度 | |---------|---------|--------| | OCR 双引擎均失败（返回空或极少字符） | Agent 读图 → 主模型视觉识别 → 完整逐字转录 | B-C | | 双引擎相似度 <80% 且语义终裁确认真冲突 | 同上 | C | | 文件类型为纯图片框图/组织结构图 | 直接多模态（跳过 OCR API） | C | | 微信长截图/复杂表格 | 直接多模态（跳过 OCR） | B |

多模态转录质量控制：

完整逐字转录：不能摘要，不能省略细节
保留原始格式：换行、段落、表格结构尽量保留
标记不确定内容：模糊/难以辨认的文字用 [?] 标记
输出前先说明图片内容类型（聊天记录/银行流水/合同/其他）

5. 差异标记落地

80-95% 相似度文件，用 <ins>/<del> 标记具体差异段落（不是只写相似度数值）：

付款金额：<del>¥1,234,567.89</del><ins>¥1,234,587.89</ins>
收款方：XX科技有限公司

6. 置信度 A-E 评分标准

| 等级 | 综合得分 | 含义 | 使用建议 | |------|---------|------|---------| | A | ≥90 | 高度确信 | 可直接引用，无需复核 | | B | 75-89 | 较高度确信 | 可直接使用，建议快速扫视关键数字 | | C | 60-74 | 中度确信 | 建议使用，但需复核关键信息（金额/日期/主体） | | D | 40-59 | 低度确信 | 仅参考，需人工复核 | | E | <40 | 不可采纳 | 不得使用，需重新识别 |

置信度标注范式（落到每份材料）：

| 内容类型 | 置信度 | 标注要求 | |---------|--------|---------| | 叙述 + 条款正文 | A | 可直接引用 | | 表格 / 价格 / 数字 | B | 抽关键数字（金额/比例/日期）供核原文件 | | 图示 / 照片内文字 | — | 标"见原文件"，OCR 无法读图内文字 | | 多模态转录 | C | 建议复核关键数字 |

7. 引擎级批量处理（性能优化 + 失败隔离）

当处理 ≥2 个扫描件 PDF 时，必须走引擎级批量路径：

单个扫描件 PDF → 双引擎并行（单文件）
≥2 扫描件 PDF → 引擎级批量
   ├─ MinerU 批量接口（一批 ≤50 文件）
   ├─ PaddleOCR 多任务并行提交 + 统一轮询
   └─ 结果对齐 → 逐文件交叉核对

失败隔离：批量提交时单文件失败或文件不存在不再拖垮整批，失败文件单独标记 error，其余正常返回。

实测数据（真实项目，11 个 PDF / 127 页）：单文件级并行 43.9s → 引擎级批量 20.14s（提升约 54%）。

8. 失败降级矩阵

| 场景 | 动作 | 置信度 | |------|------|--------| | 双引擎均正常 | 完整双引擎交叉核对 + 四档裁决 | A-B | | 仅一个引擎可用 | 单引擎 + PyMuPDF 验证 | B | | 双引擎均不可用 | PyMuPDF + 多模态兜底（纯本地） | C | | OCR 双引擎均失败 | 多模态兜底（主模型视觉识别） | C | | 相似度 <80%（语义终裁确认真冲突） | 多模态验证 OR 人工复核 | C | | 网络中断 | 自动重试 3 次（指数退避），仍失败走本地降级 | — | | 文件损坏 | 标记失败，不阻塞其他文件 | E | | 单文件批量失败 | 单独标记 error，同批其他文件正常返回 | — |

9. 脚本调用入口

# 组装底稿 JSON + MD 双输出
from assemble_json import ManuscriptAssembler
asm = ManuscriptAssembler()
result = asm.assemble("案件简称", reports, "输出目录")
# result = {"status": "ok", "json_path": ..., "md_path": ..., "material_count": N}
#         或 {"status": "degraded", "md_path": ..., "error": "..."}（自动降级 MD）

# 或走 parallel_main 闭环入口（依赖 OCR 后端）
from parallel_main import assemble_manuscript_output
result = assemble_manuscript_output("案件简称", parallel_results, output_dir)

# 自动环境检查
python auto_env_check.py

三条硬性规则（P0 强制）

| # | 规则 | 说明 | 违反级别 | |---|------|------|---------| | R1 | 压缩包不做提取 | .zip .rar .7z 等仅标注占位，不解包不转录 | P0 | | R2 | 输出到底稿目录 | 底稿必须存入项目底稿目录（如 [项目底稿目录]/01_原始底稿/） | P0 | | R3 | 中间产物不进原始材料目录 | PDF 拆分、OCR 临时文件、脚本等只进临时目录 | P0 |

环境配置

自动环境检查

启动时自动检测 OCR API 连通性，未配置时使用降级模式（速度较慢）：

python auto_env_check.py

期望输出：

PaddleOCR API: ✅ 已配置
MinerU API:    ✅ 已配置

API 配置

OCR 引擎（PaddleOCR / MinerU）的 token 通过环境变量注入，禁止硬编码：

# Linux/macOS
export PADDLEOCR_TOKEN="your_token"
export MINERU_TOKEN="your_token"

# Windows PowerShell
$env:PADDLEOCR_TOKEN = "your_token"
$env:MINERU_TOKEN = "your_token"

或通过配置文件（路径由 OCR_API_CONFIG 环境变量指定，默认 ~/.workbuddy/ocr_api_config.json）：

{"paddleocr": {"token": "..."}, "mineru": {"token": "..."}}

降级模式

| API 配置状态 | 工作模式 | |-------------|---------| | 双引擎均配置 | 完整模式：双引擎并行 + 交叉核对 + 四档裁决 | | 仅配置一个 | 单引擎模式：无双重核对，但正常运行 | | 均未配置 | 纯本地模式：PyMuPDF + 多模态兜底（无 OCR 引擎） |

Phase 0：文件预标准化（<2 分钟）

消除路径编码问题的根源。所有后续步骤的前提。

0a：创建项目临时目录

{temp_dir}/{project_slug}/
├── pdf\     (PDF001.pdf, PDF002.pdf, ...)
├── img\     (IMG001.jpg, IMG002.png, ...)
├── audio\   (AUD001.mp3, ...)
├── txt\     (TXT001.txt, ...)
└── mapping.json  (原始名→临时名映射表)

0b：跳过压缩包（R1 规则）

SKIP_EXTENSIONS = {'.zip', '.rar', '.7z', '.tar', '.gz', '.bz2', '.xz'}

遇到压缩包，记录到 skipped_archives 列表，后续在底稿中标注。

0c：识别文字型 PDF

用 PyMuPDF 快速探测每个 PDF 是否有可提取的文字（第一页 >50 字符 → 文字型，走快速通道）。

0d：文件类型探测（不信任扩展名）

通过文件头检测实际类型（PDF: %PDF-；ZIP 含 docx: PK\x03\x04；PNG: \x89PNG；JPEG: \xff\xd8）。文件名/扩展名可能误导（如"记录.png"实际是聊天截图，不是银行流水）——始终用文件头检测 + 内容预览确认。

Phase 1：五路并行处理（核心）

主 Agent（只协调不执行）
    │
    ├── Phase 0：主 Agent 执行预标准化（<2min）
    │
    ├── Phase 1a：子 Agent-邮件 → 并行提取全部 .eml（~2min）
    │
    ├── Phase 1b：子 Agent-PDF（文字型）→ PyMuPDF 快速提取（<30s）
    │
    ├── Phase 1b：子 Agent-PDF（扫描/复杂）→ 双引擎 OCR（~5min）
    │
    ├── Phase 1c：子 Agent-图片 → 双引擎 OCR（~3min）
    │
    ├── Phase 1c：子 Agent-图片（长截图/复杂表格）→ 多模态完整转录
    │
    └── Phase 1d：子 Agent-音频 → 转文字工具（~5min）
    │
    ▼
Phase 2：交叉核对报告 + 差异裁决 + 多轮自验证
Phase 3：一次性组装

Phase 2：交叉核对汇总 + 差异裁决 + 多轮自验证

四档裁决规则

| 全文相似度 | 裁决 | 动作 | |-----------|------|------| | ≥95% | 自动定稿 | 使用主引擎结果（准确度更高），不标记差异 | | 56-95%（截图/凭证类） | 多模态抽样验证通过 | 抽样 10-25% 最不可靠文件 → 100% 清晰 → 整体通过，0 人工复核 | | <80%（复杂/模糊） | 多模态兜底 | 用主模型完整转录替代 OCR | | 单引擎有效 | 信任该引擎 | 不标记为 flagged | | 多模态完整转录 | 逐字转录 | 长截图等 OCR 返回空的用主模型视觉识别 |

差异标记落地方法

80-95% 相似度文件，用 <ins>/<del> 标记具体差异段落（difflib 逐段对比）。

多轮自验证

同一工具调用多次（不同参数/预处理），结果稳定就通过：

第1遍：默认参数
第2遍：调整图片预处理（二值化/降噪）
第3遍：调整 OCR 参数（更细致识别）

3 次结果一致 → 通过
规范化后一致 → 通过（标注 normalized）
不一致 → 标记不确定，建议人工复核

多模态抽样验证（核心经验固化）

核心发现：策略差异 ≠ 内容错误。 截图类/凭证类文件即使双引擎相似度只有 56%，图片本身极清、文字 100% 可读、OCR 结果均准确。

验证逻辑：

问题: N 个文件双引擎相似度 56-95%
     ↓
假设: 策略差异 ≠ 内容错误（截图类文件本身清晰）
     ↓
验证: 用多模态模型读取相似度最低的 10-25% 文件
     ↓
发现: 图片极清 → 文字 100% 可读 → OCR 结果准确 → 差异=提取策略
     ↓
裁决: 抽样 100% 通过 → 整体 N 个文件全部通过 → 0 人工复核

关键经验总结：

| 经验 | 说明 | 适用场景 | |------|------|---------| | 截图类文件 OCR 可信度高 | 聊天截图/支付账单/银行流水即使双引擎相似度低，内容仍准确 | 所有手机截图类材料 | | 相似度低≠质量差 | 相似度反映的是文本重叠度，不是准确度 | 双引擎结果对比时 | | 多模态是终极裁判 | 当不确定哪个引擎正确时，用主模型看原图一锤定音 | 有争议的个别文件 | | 抽样验证优于全量复核 | 验证最不可靠的 10% 就能推断整体 | borderline 文件批量处理 |

Phase 3：一次性组装

职责边界：本流水线只做结构化标记（金额/日期/主体等），不做材料分类、不做证明目的分析——那些是下游分析环节的职责。

结构化关键信息标记

在转录文本中自动标记语义锚点（）：

金额标记（¥/$/USD/EUR/元/万）
日期标记（YYYY年M月D日等）
主体标记（公司/机关/机构全称）

防偷懒合约条款（V0.5 确定性门禁）

本流水线是偷懒重灾区。以下条款为硬合约，自动检查，不达标 BLOCK，不得交付。

合约 1：JSON 结构完整性（防"简化版蒙混"）

claim：每件材料 JSON 必须含 pages[blocks{type,bbox,content}] 完整结构，transcript_fulltext 为全文转录
verification：deterministic（脚本逐件检查 pages/blocks/bbox 字段存在性）
threshold：材料总数 N → JSON 条目 N 条 → 含 pages+blocks+bbox 的条目 = N
consequence：任何一件缺 bbox → BLOCK，报告具体缺失字段与材料编号

合约 2：schema 版本一致性（防"贴错标签"）

claim：schema_version 必须与实际 JSON 结构一致
verification：deterministic（脚本比对版本标签与实际结构）
consequence：版本标签与实际结构不匹配 → BLOCK，标记"贴错标签"

合约 3：材料全量覆盖（防"截断凑数"）

claim：输入材料全部处理，输出条目数 = 输入材料数
verification：deterministic（输入计数 vs JSON materials 长度）
consequence：输出 < 输入且无解释 → BLOCK

合约 4：双引擎交叉核对不可省（防"单源冒充"）

claim：每件材料必须经 ≥2 独立引擎处理，或明示降级原因
verification：deterministic（检查 engine_source 字段 + cross_check_stats 统计）
consequence：single_engine 条目未标注降级原因 → WARNING；未走交叉核对流程 → BLOCK

反合理化检查

| 借口 | 触发场景 | 反驳 | 替代方案 | |------|---------|------|---------| | "OCR 引擎没返回 bbox，我也没办法" | 结构化提取缺失 | 调用 OCR 时必须保存结构化块数据（含 bbox），不是只提取文本。没有保存 = 执行方式错误 | 检查引擎输出中的结构化数据，提取完整结构化块后组装 JSON | | "材料太多了，先交个简化版" | 材料量大 | done-condition 数量必须与输入总量一致。N 件输入 → N 条输出，少一条 = BLOCK | 分批并行处理，不降低单件标准 | | "schema_version 标个差不多的" | 版本标注 | schema_version 必须与实际结构匹配，标错 = 造假 = 下游工具误判 | 组装后跑 Schema 校验，确认版本一致 | | "这个材料太模糊，OCR 不了就标个 C 级" | 低质量扫描件 | 模糊材料必须走多模态兜底（主模型视觉）完整转录，不是降级跳过 | 双引擎 + 多模态三重确认后标 C 级，标注"待人工复核" |

Phase 4：V 阶段验证审查

三方独立审查

| 视角 | 审查重点 | 发现问题类型 | |------|---------|-------------| | 我方视角（律师） | 材料完整性、关键字段准确性、置信度标注一致性 | 遗漏材料、字段提取错误、置信度标注不当 | | 对方视角（潜在对手） | 是否存在识别错误、漏识别、关键信息缺失 | OCR 错误、文字截断、数字误识别 | | 裁判视角（法官） | 底稿是否符合证据标准、是否可采信 | 形式瑕疵、来源不清晰、提取方法不可靠 |

审修一体闭环

发现问题 → 判断严重程度 → 选择修复方式 → 执行修复 → 重新审查 → 循环直到全部通过

| 问题类型 | 修复方式 | |---------|---------| | 简单错误（OCR 字段截断、数字错误） | 多模态读图核验，直接修正 | | 内容问题（识别不准、差异大） | 重新 OCR 或多模态转录 | | 边界偏离（超出底稿范围） | 回退，不修改原始内容 | | 无法修复（压缩包、模糊扫描件） | 标记"需人工复核" |

交付形式审查

| 子项 | 审查标准 | |------|---------| | 排版 | 标题层级、列表格式、段落完整、无截断 | | 语言 | 去 AI 味、无冗余、术语准确 | | 规范 | 命名合规、路径正确、版本标注 |

收尾

知识反哺：将本次底稿制作经验写入项目记忆
产物推送：展示底稿给用户
临时文件清理：删除临时目录

输出结构（JSON 主 + MD 辅双输出）

输出路径：项目底稿目录（如 [项目底稿目录]/01_原始底稿/）

[案件简称]_原始底稿.json   ← 主格式：机器消费（下游 AI 工具优先读这个）
[案件简称]_原始底稿.md    ← 辅助格式：人眼核校 / 审查 / 团队阅卷
schema.json               ← Schema 契约（下游消费字段规范）

JSON 结构（schema_version 1.0.0）

{
  "schema_version": "1.0.0",
  "metadata": {
    "case_name": "[案件简称]",
    "generated_at": "YYYY-MM-DD HH:MM:SS",
    "total_materials": 0,
    "processing_stats": {"auto_resolved": 0, "auto_resolved_with_diff": 0,
                         "multimodal_rescued": 0, "need_multimodal": 0, "single_engine": 0},
    "cross_check_stats": {"A": 0, "B": 0, "C": 0, "D": 0, "E": 0}
  },
  "materials": [
    {
      "m_id": "M001",
      "source_file": "合同扫描件.pdf",
      "file_type": "pdf|image|word|email|audio|unknown",
      "ocr_status": "auto_resolved|auto_resolved_with_diff|multimodal_rescued|need_multimodal|single_engine",
      "confidence": "A|B|C|D|E",
      "similarity": 0.97,
      "engine_source": "mineru|paddleocr|multimodal_vision",
      "language": "zh|en",
      "pages": [
        {
          "page_idx": 0,
          "blocks": [
            {
              "type": "text|title|table|image|equation|list|code|discarded",
              "bbox": [x0, y0, x1, y1],
              "text_level": 0,
              "content": "…",
              "engine_source": "mineru|paddleocr"
            }
          ]
        }
      ],
      "diff_markup": "…（80-95% 定稿时含 <ins>/<del>）",
      "transcript_fulltext": "…（全文转录，MD 渲染的数据源）",
      "raw_structured": {
        "mineru_content_list": null,
        "mineru_middle": null,
        "paddle_layouts": null
      }
    }
  ]
}

MD 结构（从 JSON 渲染）

# 原始底稿：[案件简称]
> 生成时间：YYYY-MM-DD HH:MM
> 材料总数：X 件
> 质量控制：双引擎 OCR 交叉核对 ✅ | 结构化 JSON 输出 ✅ | AI 语义终裁 ✅ | 多模态兜底 ✅
> 自动定稿：N 件 | 差异标记定稿：M 件 | 多模态转录：K 件 | 待人工复核：L 件

## 处理统计
## 交叉核对统计

# 正文
## M001：[材料名称]
### 来源信息
- 原始文件：`[文件名]`
- 处理方式：MinerU 结构化解析（权威源）/ 多模态完整转录…
- 核对状态：✅ 自动定稿（A级）…
- 双引擎相似度：97.00%
### 全文转录

依赖

# 核心依赖（轻量）
pip install requests pymupdf python-docx

不需要安装本地 AI 模型：OCR 走线上引擎 API，多模态走主模型视觉。

本仓库 scripts/：

assemble_json.py：交叉核对报告 → 底稿 JSON + MD 渲染 + Schema 校验（零外部依赖，可直接运行）
parallel_main.py：文件级并行调度 + 智能路由 + 双输出闭环入口（依赖 OCR 后端接口，见 ocr_backend.py）
ocr_backend.py：OCR 引擎接口契约 + Mock 演示（真实调用需自行实现 parse_file()）
auto_env_check.py：自动检测 OCR API 配置状态
test_assemble_json.py：组装器功能测试（模拟真实交叉核对报告）

边界

本技能不做什么：

不筛选提取（那是下游梳理环节的事）
不分析法律含义（那是策略分析环节的事）
不做多次版本迭代（Phase 3 一次性组装）
不依赖本地 AI 模型（OCR 走线上 API，多模态走主模型）
不做材料分类
不生产 Word/PDF 交付卷（JSON→MD 由本流水线产出；最终交付卷由下游环节导出）

运行环境

推荐：在支持技能/工具调用的 AI 工作台（如 WorkBuddy）中运行——多模态兜底、AI 语义终裁依赖主模型视觉识别能力
最小：标准 Python 3.8+ 环境（assemble_json.py 零依赖可跑；完整流水线需配置 OCR 引擎 token + 可选安装 PyMuPDF/python-docx）
OCR 引擎 token 通过环境变量注入（禁止硬编码）