dsh-deep-reading-wl

把「给一本扫描版教材，读出能交付的读书心得」这条流程做成一条可重复的流水线。

原料是电子书 PDF，产物是读书心得的骨架——不是替你读书，是先让你知道该读哪几页。

PDF ──ocr──> txt ──scan──> 骨架与失真地图
                  ├─map────> 这一章该花多少时间
                  └─digest─> 压掉碎片的原文

四个工具

工具	速度	回答什么问题
ocr	1.2 秒/页	这堆图里写了什么字
scan	0.1 秒/本	几章几节、每章多厚、哪几节承重、哪几页有表
map	秒级	这一章先读哪节、哪节略读、哪几张表必须回原图
digest	秒级	哪些行值得亲读，哪些是 OCR 打散的表格碎片

ocr

扫描版 PDF 没有文字层，PyMuPDF 取字数为 0，所有靠 text layer 的阅读器在这里输出为零。这个模式用 RapidOCR v3 + OpenVINO 引擎把它变成带页标记的 txt：

• 单进程 16 线程，120 dpi，PP-OCRv6 small
• 同机 ONNXRuntime 方案 6 秒/页 → 1.2 秒/页
• 自动跳过扫描残页（墨迹极少且只落在上半页）
• 按纵坐标还原阅读顺序（找框顺序不是阅读顺序）

mode=doctor 体检环境，mode=page 试读一页。

scan

读之前的第一站。输出骨架 + 失真地图：

页数 625 / 正文字符 430324 / 正文行 31799
章 20 个，节 355 个
  第一章 绪论   (PDF19)
  ...
承重墙：公式 5 条，定义句 24 条，推导句 37 条，图 19 张
数据表 3 张（只标位置，行列须回原图看）
  表 2-3 环烷烃的摩尔燃烧热   PDF61  有表体
  表 2-4 …物理常数            PDF69  表体极少（跨页续表）

它不判表格好坏。 曾经想做「表格健康检查器」（数数值个数、查行列对齐），20 页试点四张表逐字核对后宣告失败：扫描件里「哪个数属于哪一列」的信息在 OCR 成纯文本那一刻就丢了，事后反推只能靠猜，猜错的代价是拿一张烂表当依据写心得。所以它降级成位置索引器——只告诉你哪几页有表，行列由你翻原图看（一张 2544×1804 的图看清行列没问题）。

map

把 scan 的结论翻译成动作。承重密度 = (公式 + 定义句 + 推导句) / 字符 × 1000——推导密集的节是重心，例题密集的节反而轻。

§11.5 典型复合反应        7630 字符  9.5%   重心
§11.1 化学反应的反应速率   …
§11.15 多相催化反应       17834 字符 22%   可以略读
4 张表 OCR 已损坏，心得里若要用数据必须回 PDF 第 240、281、294、310 页取原图

chapter 参数可只算一章。

digest

OCR 文本里约 75% 是表格被拆散的碎片（一张表能拆成「可燃气体」「爆炸下限」「H2」「1.3」等 30 多行）。但不能直接扔——「表11.7.1中列出某些可燃气体在空气中的爆炸界限」这句是「这张表在说什么」的唯一线索。

所以它做三件事：逐行分诊（正文/公式/表格碎片/噪声）→ 碎片换成一行 [表 11.7.1 在此，43 行已省略] → 节标题、公式编号、定义句原样保留。输出不是摘要，是一份更短的原文（通常保留 87%）。

from / to 可按页区间压缩。

安装

插件已在本机装机。装到别处：

# 1) 放进 profile 的 node_modules（用 junction，改代码即时生效）
cmd /c mklink /J "$env:APPDATA\dsh-desktop\harness\profiles\web\node_modules\dsh-deep-reading-wl" "C:\path\to\deep-reading-wl"

# 2) profile 的 package.json：dependencies 加
#    "dsh-deep-reading-wl": "link:C:/path/to/deep-reading-wl"
#    并把 "dsh-deep-reading-wl" 加进 dsh.profile.bundles

# 3) profile 的 cordis.patch.yml 末尾加（关键，缺这一步插件不会挂进树）
#    - insert:
#        - id: dsh-deep-reading-wl
#          name: 'dsh-deep-reading-wl'

为什么 patch.yml 那一步不能省：bundles 只声明「这个包可以被扫描」，真正把插件 insert 进配置树的是 profile 自己那层 cordis.patch.yml。只加 bundles 的话，日志里既没有报错也没有痕迹——它根本没被装载。

环境

需要 Python 3.10+ 与：

pymupdf  rapidocr  openvino  numpy

解释器按 DEEP_READING_PYTHON → FASTOCR_PYTHON → DSH Desktop 自带运行时 → C:\Python312 顺序找。

自测

# 先抽一次宿主模块（@deepseek-ai/* 是宿主单例，插件自己不会装）
& "C:\Program Files\nodejs\node.exe" scripts\pull.host.mjs

# 跑四个工具
& "C:\Program Files\nodejs\node.exe" scripts/selftest.mjs <某个 OCR txt> [某个 PDF]

必须用独立 Node（C:\Program Files\nodejs\node.exe）。DSH 里的 node 是 Electron（ELECTRON_RUN_AS_NODE=1），它的 fs 会把 app.asar 内部路径当归档成员去读，行为和独立 Node 不一致。

实测记录

书	页数	OCR 耗时	章节识别
物理化学上册	308	—	6 章
物理化学下册	389	—	6 章 66 节
有机化学（第七版）	624	13 分 04 秒（1.26 秒/页）	20 章 355 节
电气工程学概论	520	1.59 秒/页（试点）	3 章 11 节（20 页）

scan 在四本书上都做过随机 20 页试点，修掉了 20 多个识别 bug：目录页污染、章标题三种断法（第二章 烷烃 / 第二章烷烃 / 第二章 单独一行）、跨页续表、页眉页码粘连、表格数值冒充节号、题号冒充节号、章标题被当页眉过滤。

边界

三件事它不做，是故意的：

1. 不替你判断。哪一节是作者在立论、哪个推导是本章的地基，现在还得人读出来。硬把这一步自动化，只会把活的判断压成填空题。
2. 不修 OCR 的错。环已烷（应作环己烷）、CH3}、sp3/sp³ 混用——这些只能靠你在写心得时用领域知识识别。
3. 不还原表格。见上，位置给了，行列回原图。

License

MIT