摘要
PDF 文字提取做到什么程度才算能交付，需要核对用途和实际内容。本次对照里正常通知能读出文字，另一份页面外观相同的通知却复制乱码；还有一份能输出合法汉字，只是两处字变错了。我据此整理了一套面向个人开发者和小团队的接收、试做与交付检查。重点放在怎样约定目标、挑选验收样段、记录异常，以及何时向提供者索要源文件。
版本声明
文中记录来自 2026 年 9 月 30 日的这一轮核验。线上部分使用桌面 Chromium 和图映当前公开入口，截图视口为 1440×1000。独立对照使用 PyMuPDF 1.26.5、MuPDF 1.26.10、pypdf 6.10.2 和 PDF.js 5.6.205。主要通知由 ReportLab 生成，乱码版本由人工删除或改错字符映射得到。后续流程建议取自本次实验观察，文中没有加入虚构的客户事故和收费经历。
适用边界
文章面向要把已有 PDF 变成可用文字的独立开发者、个人站长和小团队。技术解释仅限于判断一份文字结果是否满足接收和使用条件。自造通知用来隔离问题，公开论文节选只作正常对照。这些样本无法代表所有合同、扫描件或复杂排版。文中的"交付约定"指工作范围与检查方式，不涉及法律条款或某种通用准确率承诺。
文章目录
1 PDF有输出为什么仍不能交付
- 完成状态没有检查文字内容
- 同样的字数也会出现错字
2 接收PDF时先确认什么目标- 可复制文字需要说清用途
- 原样提取和整理分开计入范围
3 怎样给一份PDF建立接收记录- 文件版本决定后续比较对象
- 样段需要覆盖实际要用的内容
4 首轮试做怎样看出真实差别- 正常通知先建立检查基线
- 换工具需要带着具体问题
5 PDF转图失败后还能怎么办- 页面图先通过可读性检查
- 图片OCR恢复了五行信息
6 怎样把样段变成验收依据- 页面与文本需要成对交付
- 空格和错字分开记录
7 什么时候该向对方要源文件- 多次重试需要带来新信息
- 源文件也要重新检查
8 一份文字交付包应包含什么- 结果与异常清单一起到达
- 修订记录帮助限定返工范围
9 小团队怎样安排人工复核- 复核投入跟着用途走
- 试做通过后再决定扩大范围
10 适用边界与风险提示- 样本成功不能升级成通用承诺
- 文本可用不等于原PDF修复
11 测量方法自身的坑- 工具计数需要保留原口径
- 抽查结果需要带上范围
12 下次接到文件可以怎样开始
参考资料
1 PDF有输出为什么仍不能交付
完成状态没有检查文字内容
这次测试里有一个很容易误判的界面：处理进度已经结束，结果区也有文字。要是我只负责把文件丢进工具、看到完成就交出去，这一步已经可以打勾。实际把结果与原页对照后中文大部分丢了，留下的主要是日期数字和英文。只是用户真正要用的内容没了。
我用的是一份专门造的五行通知。正常版与人工删掉字符映射的版本在独立阅读引擎里看起来相同，后者的文字提取却损坏。本次故障是主动构造的受控样本，来源与真实客户材料不同。造两份只改变一个条件的文件是为了看清交付判断能不能发现这种差别。结果说明"任务运行结束"与"内容可用"需要分开检查。
同一份坏样本转成 HTML 后界面还显示一页、五段和完成状态。页面和段落数量看着正常的结果依然保留了错误的文字。对个人开发者来说，工具未报错且文件可打开时很容易把剩余工作误认为只是整理格式。已经改变的文字内容无法通过整理标题、空行和样式恢复。
交付记录需要指明输入版本、所需内容、已核对位置以及尚存的问题。一份文字文件加上清楚的记录也能比只发一个处理完成截图更有用。后续讨论可以依据这些记录直接定位对方所说的"乱码"。
同样的字数也会出现错字
另一组结果更难靠外观发现。我保留映射表，只把其中"假"的目标改成"真"。页面继续显示"放假通知"，三个独立提取器都输出"放真通知"。同一个映射在正文也被使用，两处文字一起变错。提取结果仍含与正常通知等量的 56 个汉字，且没有出现常见替换符。
错映射文件直接暴露了仅按字数批准交付会遗漏的内容错误。字数可以用来发现极端异常，比如原本满页文字却只剩几个字。遇到合法字符替换时它可能一点变化也没有。三个工具给出相同答案也不能代替原文核对。它们可能一起读到错误映射。
如果这是一项只要求"把 PDF 里的文字提取出来"的任务，双方可能对完成程度有不同理解。处理者觉得所有页都生成了文本就算结束，使用者则默认文字与原文一致。分歧不一定出现在运行阶段，往往到真正使用时才暴露。本次样本足以说明约定验收范围的必要性，但不用于推算这种问题的行业发生率。
我会在开始前把一句模糊需求改成能观察的目标。这次通知可约定完整保留标题、日期、返岗说明、报销说明及英文句子，同时记录允许的空格变化。这比"提取准确"更具体。双方可以在批量处理前拿同一页核对这些明确要求，提前发现对交付目标的不同理解。
2 接收PDF时先确认什么目标
可复制文字需要说清用途
"可复制"只是一个起点。有人只需要把某段介绍贴进文章，有人要把全文放进站内搜索，还有人希望继续编辑原来的表格。以通知为例，单独引用放假日期时首先核对范围与关联说明；全文入库则还要检查标题和英文。检查对象需要按实际用途来选定，工具默认输出无法代替这种判断。
我会根据对方实际使用结果的目的确定交付形式。纯文本、保留段落的文档和新生成的可搜索 PDF 是不同结果，选择其中一项就会改变工作内容。纯文本没有页面外观，截图有外观却不直接提供可编辑文字。交付目标含糊会让后续围着格式反复进行无效修改。
对搜索用途我更关心文字能不能回到原页。对继续编辑的用途我更关心段落边界和明确的字符差异。对少量引用我会先把所需段落单独试做。这里只是根据用途安排检查，没有声称已经测了某个搜索系统或编辑器。当前样本能支持的判断是结果应当与使用动作相连，单独看文件是否生成不够。
还要把"全部"说清楚。它是全部页面、全部正文，还是包括页眉、脚注和图片中的字？本次只有五行的通知很容易通过逐项列举明确全部内容范围。真实文件可以先让提供者圈出马上要使用的部分，再决定剩余内容的处理范围。几句能够对照页面的具体说明通常就可以澄清需求，不必一开始编写繁琐文档。
原样提取和整理分开计入范围
提取和整理经常被一句"帮我转成文字"放在一起。实际工作里删除重复页眉、合并断行、改错别字和恢复标题层级都已经改变了输出。这些整理动作可以作为明确列入交付范围的服务内容。原始提取与人工修改混在一起会让后续错字无法定位到具体步骤。
这次通知的 OCR 结果去掉了一些中文与数字之间的空格，五行信息仍然能对应。若目标是方便阅读这种空格变化未必需要返工。若目标是逐字保留原始文本就不能忽略它。关键不在于替所有用户决定哪种更好，而是在开始前约定这些变化怎样记录。可接受的差异也需要明确名称，不适合统统写成"基本没问题"。
我会先保留原始提取文本，再复制一份用于整理。这样对方要的是方便阅读的结果时可以直接用整理版，后续需要追踪某处变化也能回到原始结果。在当前核对结束前保留原始结果有助于追踪变化，长期留存则由具体项目决定。
人工修正也需要对应到依据。直接照原页改一个明确错字与凭上下文猜一个模糊字并不是同一件事。前者已有核对依据。后者仍需确认来源。本次"假"变"真"有明确原页和生成基线，可以据此判断错误。缺少基线时会把疑问保留在记录中，语句顺畅本身不能代替校对依据。
3 怎样给一份PDF建立接收记录
文件版本决定后续比较对象
同名文件容易拿错。本次正常、缺映射和错映射通知看着一样，内容状态却不同。实验记录利用文件名和文件摘要区分输入，防止不同文件的检查结果相互混用。交付流程不一定需要向使用者展示长串技术标识，但内部至少应知道每份结果由哪个版本生成。
接收时可以先记录文件名称、页数、接收时间以及提供者标明的版本。对方补发的文件应关联新一轮处理结果，旧结果则保持原来源不变。这样做并不复杂。它能回答"你检查的是我刚发的版本吗"，也能避免明明换过输入却还拿昨天的截图证明今天的结果。
页数和文件大小只是识别线索。正常通知为 29,878 字节，删映射版为 28,423 字节。后者体积变小无法说明内容优化成功。不同文件重写过程产生的体积差不能直接归为某个单一对象的大小。对交付有用的是它们确实不同，以及每次检查使用哪一份；大小本身不能批准内容通过。
接收记录还需注明原始编辑文件是否可得、是否允许图像识别及模糊内容的确认人。这些可以提前问清楚。本次通知不涉及权限问题。真实材料是否允许上传或修改仍需按实际授权确定。
样段需要覆盖实际要用的内容
样段不是随便截一行看着顺的文字。只抽查缺映射通知中仍然可读的年份、日期数字和英文会漏掉中文损坏。我会选择所需中文内容以及数字与文字相连的位置进行对照。这个选择来自本次结果，而不是某个万能抽样比例。不同文件需要使用的关键内容变化后，对应检查样段也应调整。
一份两页的混合样本进一步说明了这个问题。第一页使用正常通知，第二页使用缺映射通知。两页外观相同，但只有第一页能够正常提取文字。只看首页就会通过整份文件。把全文合起来搜索标题也会因为第一页命中而通过。样段需要带页码，否则它可能只证明文档某处有正确文字。
较长文件先由提供者标出急用页面，再从其余部分选择来源或格式不同的位置试做。这里提出的是安排方法，不是在承诺某几个样段能代表所有页面。若最终要保证全文可用检查范围就不能在交付时悄悄缩成首页。用于判断处理路线的试做不能替代后续针对全文的内容验收。
样段还可以注明选择理由。比如本次标题包含容易发现的中文变化，返岗句把日期和动作放在一起，英文句用于观察混合语言输出。理由写明后后续换文件的人可以理解检查意图。固定照搬上份文档的抽查位置，可能漏掉新文件真正需要使用的内容。
4 首轮试做怎样看出真实差别
正常通知先建立检查基线
我跑了一次图映的 PDF 内容提取，先用正常通知建立对照。结果区的标题、放假时间、返岗提醒、报销说明与英文能与输入五行逐项对应。正常样本这一步很有用：它说明当前入口、操作方式和测试材料可以得到预期结果。后面再换缺映射版时才不至于把整个操作流程的问题与输入差异混在一起。
图中保留了完整操作界面。左侧是导入通知的预览，中间是实际处理结果，右侧显示处理完成和保存选项。右侧 DONE 仅代表处理状态，内容核对应当查看结果中的五行文字。截图里的可用保存按钮也不等于本轮已经验完系统下载流程。此次核查以结果预览和读取出的文本为准，没有把未拿到的下载事件写成保存成功。
我用的是图映 ImgIng，测试输入为保留正常映射的自造通知。工具名称用于记录条件。更换工具不会取消内容核对，正常通知通过也不代表另一份文件一定能通过。对使用者来说最值得复制的是对照方法，而不是某次点击的顺序。
接着把缺映射版放进相同入口，打开与关闭"识别图片内文字"后得到的文本逐字相同，中文仍然损坏。这个结果说明按钮状态本身不能当作修复证据。没有内部日志就无法判断模型究竟走过哪条路径，我只保留可以观察的结论：这次切换选项没有改变交付给用户的文字。
换工具需要带着具体问题
为排除某一个工具的特殊表现我又看了三个独立提取器的结果。三个实现都能正确读取正常通知，面对缺映射版本却只产生形式不同的乱码。PyMuPDF 和 pypdf 仍输出 152 个字符，PDF.js 拼接后为 137 个字符。字符总数不同并不自动说明哪个更好，三份结果都没有满足这份通知的中文交付目标。
对于独立开发者这组结果最实用的地方是帮助决定下一步。继续无目的地轮换工具只会增加结果文件的数量。更换实现可以用于核查异常是否限于某个入口，或尝试取得与原页相符的文字。结果依旧损坏时就记录为未解决当前问题，格式整齐不会改变这项结论。
错映射通知更能说明这一点。三个提取器都把"假"读成"真"，结果并不需要进一步排版就能阅读。它们的一致性没有修复内容。此时我会把原页上的目标字与提取文字放在一起确认，而不会继续数支持这个答案的工具有几个。交付时需要从原文找到内容依据，工具结果一致本身无法提供这项证据。
使用 Helvetica 和标准编码生成的英文数字文件没有 ToUnicode，却被三个提取器正确读取。缺少这个字段因此不能直接判定交付失败。接收者无需记住所有字体规则，只需知道结构检查是排查线索。最后仍需用实际需要的内容判断结果能不能用。
5 PDF转图失败后还能怎么办
页面图先通过可读性检查
本次缺映射样本走图映 PDF 转图片时没有成功。我选择单页、PNG 和 216 DPI，界面给出 SVG render failed。这一步应当如实记为失败，不能因为理论上能转图就把它从路线记录里删掉。对交付而言中间文件有没有真正产生决定下一步是不是具备执行条件。
截图保留了右侧处理失败信息及左侧所选的页、格式和清晰度。中间名为"原 PDF"的窗格实际上标记了 HTML，里面也出现乱码。这不是原生阅读器显示的证据，不能据这张图断言源 PDF 本来就看不清。已确认独立 MuPDF 能正确显示原通知，因而两个入口的预览需要分别判断。
若已有能正确显示该文件的阅读器可以评估通过它取得所需页面图。取得图片后再检查标题、正文、小字和页面边缘是否完整。OCR 将会读取这张中间图片，所以识别之前先检查图像内容。如果图里的字已经缺失、裁掉或无法辨认就不能指望后续识别替我们找回没有交给它的内容。
本次补救用的是此前通过外部渲染器生成的清晰单页 PNG，不是刚才失败入口生成的图。这一点必须写在交付记录里。否则流程汇总后就会变成"图映转图片成功再 OCR"，与实际操作不符。对于只有一个人维护的小项目记住每一步来源比记住工具名更有价值，下一次重跑才能知道从哪里接上。
图片OCR恢复了五行信息
拿到清晰页面图以后我在独立的图片文字识别入口用专业默认档处理，扫描增强关闭。结果恢复了通知的五行信息，界面显示 134 字。标题、放假范围、返岗提醒、报销说明和英文都能对应。中文里的空格与原 PDF 有差别，因此这次可以说内容信息恢复，不能说所有空白也完全保留。
图中间的识别框对应五行页面内容，可以与右侧识别文字逐行查看。看这张图时我先对照标题和两处日期，再看其余说明。界面显示的 134 字只是产品计数，并没有表达当前结果的正确率。用时也只是某一次处理记录，不宜拿它估计整个文档库的工期。图片来源仍是外部正确渲染结果，截图没有证明产品内部转图路线通过。
这条路线对本次通知有效，并不意味着拿到任何 PDF 都先转图片最好。正常通知直接提取已经得到可用文字，再进行 OCR 会增加一轮识别与核对。对坏映射通知清晰图片提供了另一种读取途径。两种输入需要分别判断。我会先试原生提取，再根据结果决定是否需要图像路线。
交付时我会把这份结果标成"由页面图识别后核对的文本"，而不是"原 PDF 已修复"。如果接收者继续复制原 PDF原先的字符映射问题依然可能出现。识别出的新文字可以满足当前用途，但它和原文件的状态应分别记录。这样接收者才能知道该使用哪个产物，不会拿错文件后以为我们没有处理。
6 怎样把样段变成验收依据
页面与文本需要成对交付
验收样段最有用的形态是一边有原页位置，一边有对应文本，再写明检查范围。只发一段粘贴出来的文字，接收者还得重新找到它的来源。只发截图又无法确认文字文件里存的是否相同。两者成对之后讨论才能落在同一个位置，修订时也容易重跑相同检查。
本次通知可以选标题和返岗句作为首轮样段。标题用于核对"放假"两个字，返岗句用于核对"10 月 8 日"与"返岗"有没有保持关系。再核对放假时间一行中的 10 月 1 日至 10 月 7 日及共 7 天，最后检查报销句和英文，才覆盖五行信息。这些检查对象覆盖了当前小样本的全部内容，尚不能推广成通用抽样比例。
长文件的首轮样段先用于确认接收者是否认可结果的段落、空白及页面关联方式。接受样段并不等于自动接受整份文件。后续交付说明需要区分"处理范围"和"人工核对范围"，例如哪些页已经处理、哪些页逐字核对、哪些只做过异常检查。这些名称清楚之后就不必用模糊的"验收通过"概括不同工作量。
关键内容还需明确依据。本次受控通知可以直接依据生成时写下的原文精确核对。真实文件没有这种基线时则以可见页面或提供者确认的来源为准。字形模糊处保留待确认状态，依据上下文作出的猜测不算已核对内容。这样做可能会让异常清单多一行，却能避免接收者把猜测当成原文。
空格和错字分开记录
这次差异的性质各不相同。缺映射版的中文无法正常读取，属于内容损坏；错映射版有两处合法汉字替换，属于内容错误；图片 OCR 的空白变化则需要结合用途判断。统称"格式问题"会打乱修订顺序。我会先恢复错误内容，再讨论版式整理的具体范围。
空格也不能一概随手清除。中文句子里数字两侧的空格对阅读影响可能不大；某些代码、编号或固定格式字段中的空格则可能有意义。目前没有覆盖所有文档，交付时可以先记录变化再按用途确认。比起提前宣布"自动清理都没问题"给差异一个明确类别更容易形成共同判断。
原生文本与 OCR 文本也可以采用不同的验收关注点。原生提取这次遇到了映射缺失与错误，OCR 路线则需要核对识别文字、标点和布局整理。两者都可能产生可读结果，但不能因此省掉检查。记录处理来源以后接收者看到异常时知道该回到原页、提取器输出还是识别结果去查。
我会把本次可用结果写成这样：五行信息已对照，中文与数字之间的部分空格被合并，原 PDF 未修改。这个描述没有承诺整份文件已经获得新的搜索能力，也没有把界面的 134 字翻译成百分比。它让接收者知道现在拿到什么、还保留什么差异，以及继续使用哪份文件。
7 什么时候该向对方要源文件
多次重试需要带来新信息
本次坏样本先后经过原生提取、开关对照、HTML 转换和独立提取器比较。几条路线都没有得到正确中文。到这里继续换容器或反复点同一个按钮已经不能回答新的问题。我会把已有结果整理出来，再决定是否需要其他输入。转而索要源文件并不是放弃处理，而是尝试拿到更直接的文字来源。
要源文件时可以说清楚已经确认的差别：页面可以正确显示，但提取文本不一致；当前几个提取入口没有恢复所需中文；若有生成这份 PDF 的编辑文件，可以用它核对或重新导出。比起只说"文件坏了"这种说明更容易让提供者理解为什么要补材料。它也避免把所有失败都归给对方，毕竟本次已经看到工具路径本身会有不同表现。
源文件可以是提供者仍然保留的编辑版本，也可以是已经确认的原文材料。实际能够取得的补充材料应由文件提供者确认。不能默认他们一定有，也不能自行找一份看起来相似的网络内容替代。自造样本有原始字符串可作依据。真实交付缺少这种条件时仍需保留不确定范围。
我不会给"重试三次就索要源文件"这样的固定次数。次数不说明信息增量。同一个失败流程重复多次可能什么也没发现，一次原页对照却可能直接确认问题。比较实用的停止条件是已经没有新证据可采、现有路线无法满足约定用途，这时继续尝试的范围需要重新商量。
源文件也要重新检查
补到源文件不意味着检查结束。它可能是更早版本，也可能与收到的 PDF 有部分内容差异。重新导出后先核对内容版本，再检查原先约定的验收样段。来源看着可靠也不能省略原先认定重要的日期、标题和关键字段检查。目标始终是这次交付可用，而不是证明某个文件格式更好。
如果只要少量段落有时直接从可信源文档取得文字更省事。若需要继续使用 PDF 的原始分页则还得核对重新导出后的页码关系。两种需求的处理范围不同。索要源文件以后仍需回到既定交付目标。重新导出的成本尚未实测。
源文件没有时清晰页面图加 OCR 可能让工作继续；拿得到源文件时重新取得文字可能减少猜测。对个人项目我会先看现有条件能不能给出可核对的结果，再决定值得走到哪一步。所有尝试都停在具体样本上，不借本次成功宣称某条路线适用于所有资料。
若提供者暂时无法确认模糊内容交付可以保留待确认项。比如明确标出某页某行尚未核实，其他已确认部分可以按约定先交。是否接受这种分段结果取决于需求，但至少接收者知道剩余工作在哪里。把疑问隐藏掉只会把确认成本转移到更晚的阶段。
8 一份文字交付包应包含什么
结果与异常清单一起到达
我会把交付包做得尽量轻：实际要使用的文本、一份来源与检查说明，以及尚未解决的问题清单。若有整理版就注明对应的原始提取版本。交付说明附上对应样段即可，不必向接收者发送全部中间截图。关键是他们打开后知道该用哪个文件，并能追溯到输入版本和检查范围。
这次通知的说明可写为：输入是一页受控 PDF。原生中文提取失败后改用外部页面图做 OCR。五行信息已对照，空格有变化，原 PDF 保持不变。这样的记录能把路线说清楚。交付记录无需列举模型原理或使用容易误解的"智能修复完成"名称。
异常清单的价值在于告诉接收者哪些地方还要留意。能具体到页和片段就具体到那里，不只写一句"可能有误差"。本次缺映射样本的原生提取应当列为未满足文字用途，图像路线的空格变化则应按约定记录。两项状态并列存在，不必因为最终找到可用文字就删除前面的失败。
交付包里也应区分结果预览与真正导出。工具界面能显示内容，说明当前页存在一个可读取结果；它不直接证明保存出来的 TXT、Markdown 或其他文件都已经检查。本次自动化仅取得结果预览证据，尚未完成系统下载事件的核验。我不会拿一个可见按钮替代最终文件的回读检查，实际交付时这一项仍需要补齐。
这个区别看着琐碎，却能避免"我这里能看见"和"你那里打不开"的争论。接收者使用的是交出去的产物不是我们操作时的浏览器状态。实际导出文件需要重新打开并核对编码、内容及约定样段，之后才记录保存验收完成。未执行的动作继续保留在待办里，计划和实际结果分别记录。
修订记录帮助限定返工范围
后续发现错字时最先需要确认的是影响哪份结果、哪一页和哪段内容。这个定位成立之后才知道是单个文字修改、某页重新识别，还是整批输出都需要重跑。输入版本和处理来源保留下来，返工就能围绕已经发现的问题展开。没有这些关系哪怕只错一个字也可能得把所有步骤重新梳理一遍。
我会把人工改动与重新提取分开记录。人工对照原页改了一个字，可以写明位置和依据；更换提取器生成了新版本，则保留工具和处理时间。两种修改各有对应核对范围，文件名加上"最终版"并不能代替实际检查。对只有一个维护者的项目这份记录也方便过几天回来看，避免靠记忆辨认哪份才是确认过的。
如果接收者补了新输入旧问题是否消失要在新文件上重查。新版仍要重查样段。反过来新版修复也不意味着旧文件可以继续作为可用资料分发。交付说明里写明替换关系可以让对方把已经下载的旧结果更新掉。这里讨论的是文件使用关系，没有暗示本文已经搭建了版本管理平台。
不必为此先做一个复杂后台。文件命名、检查记录和一张异常清单都能承担早期工作。字段是否进系统取决于真实文档数量和协作需要。我更在意能否回答一次具体修订的问题，不愿为了记录本身增加一堆没人看的表。字段如果不能帮助定位、复核或交接就暂时不加。
9 小团队怎样安排人工复核
复核投入跟着用途走
如果只需要通知的放假范围复核可以先集中在日期、起止关系和对应说明。若准备全文公开发布标题、其他通知事项和英文都需要纳入。这里不能用一份固定检查表替所有用途做决定。有限人手应优先核对实际要使用的内容，避免检查无关部分却漏掉即将引用的段落。
其余内容也不能任意忽略。处理和核对范围分别说明。收到全文文本的人可能默认所有内容都可靠。局部核对需要标出范围。若对方需要全文级别的确认就把相应工作列出来。事先说明范围更容易形成共同预期，避免事后才解释"我只看了前两行"。
人工核对可分别安排关键样段逐字对照、每页缺失检查和异常项目确认。每项回答的问题不同。逐字对照能确认局部准确，逐页浏览容易发现大片缺失，异常清单让已知问题不至于遗忘。各项动作的耗时尚未测量，因此暂不计算整体效率。
对本次五行通知内容很短，全部对照比设计抽样方案更直接。长文档则需要依据真实用途商量范围。这个取舍是我更看重的：检查本身应当帮助完成交付，而不是为了显得专业不断增加步骤。若一个新增字段没有改变接受、返工或索要材料的决定它暂时可以留在内部实验记录里。
试做通过后再决定扩大范围
试做失败也有价值。它也可能证明当前文件需要额外处理，原先设想的批量路线不能直接使用。本次缺映射通知就经历了这种情况：原生文本不可用，产品内部转图片又失败，最后依赖已有的正确页面图。若把这种文件混进批量任务而没有异常出口，处理完成数量可能增加，可交付内容却没有同步增加。
我会等试做确定了可用路线以后再考虑扩大处理量。少量材料足以先观察直接提取、异常转图、失败停止位置和来源确认等处理分支。目前这仍是未经过大批文件验证的处理顺序建议。它的依据是本次一个文件就能走出不同结果，扩大数量之前值得先了解这些分支。
通过试做后仍要给后续文件保留异常标记。相似外观不代表相同结构，本次三份通知已经说明这一点。新增文件如果出现不同症状，就回到它自身的检查记录，不因为先前某个样本成功而强行归入同一路线。这样批量处理才不会把不确定性藏在统一的完成状态后面。
也不需要在第一次试做时承诺处理所有异常。可以先说明当前能支持的结果，以及什么情况需要暂停并索取材料。对于独立开发者明确停止位置同样是工作的一部分。停止条件让精力回到可继续推进的部分，也能避免对没有新信息的失败反复尝试。
10 适用边界与风险提示
样本成功不能升级成通用承诺
本文有三份外观相同的通知、两页混合版本和英文编码对照，也读取了已有公开论文的前两页。公开对照来自 RAG-Safety-Bench，三个提取器得到可读英文，抽查标题、摘要开头和第二页小标题相符。它是真实电子文档的正常对照。缺映射故障仍来自人工构造，不能换个说法就把它称为真实客户文件。
那份公开论文的字体资源均有 ToUnicode。它与故障通知并不构成某种成功率统计，只是帮助区分真实来源对照与受控实验。论文只做过指定样段核对。真实乱码 PDF 仍需继续收集。若据此给所有电子文档承诺可恢复程度证据显然不够。交付时保持样本范围，就是把这个限制留在接收者能看到的位置。
版本和输入会影响结果。本文线上截图来自具体日期的桌面环境，换一个文档或更新后的入口需要重新试做。清晰图片 OCR 这次恢复了五行，并不说明复杂背景、模糊小字或其他语言有相同表现。凡是没有测试过的输入条件我会直接留作未知，不借一个成功样本替它们签字。
这篇也没有比较各平台费用、处理配额或商业方案。这类会随平台调整而变化的数字，不影响本文关于可交付结果的判断。小团队可以先确认产物用途，再按实际处理范围评估工作。拿一个虚构成本去说明某条路线更划算只会让原本清楚的实验失去可信度。
文本可用不等于原PDF修复
交付文字与交付一份被修好的 PDF需要不同验收。本次图片 OCR 产物是一份识别结果，原输入的文字映射没有因此自动改变。若接收者想继续复制、搜索原 PDF单独拿到 TXT 不会自然满足这个目标。开始前明确目标很重要，结束时还要把它再对一遍，防止用另一种成果替代原需求。
如果后来决定生成新的可搜索 PDF还需要验收新的文字层和页面关系。OCRmyPDF 官方文档就区分跳过现有文字、重做识别层和强制栅格化等处理方式。这些路线对既有内容的处理不同，不能统称为"一键修复"。这里只借官方模式解释交付类型的区别，未运行 OCRmyPDF。
原文件涉及签名、表单或其他特殊内容时是否可以重写要结合实际要求判断。本文没有测试这些情况，因而不把纯文本通知的流程扩展成它们的处理保证。当前可以交付的是已核对范围内的新文字；原件是否保持原用途属于另一项需要明确说明的结果。
我会在最终说明里用普通语言写清楚：这是提取文字、整理文字，还是一份新生成的 PDF。名称不宜统称"修复版"。名称能帮助接收者做正确动作，也方便后来的人追溯来源。若只有一项结果完成就只确认那一项，把剩下的工作留在记录里继续处理。
11 测量方法自身的坑
工具计数需要保留原口径
不同工具显示的"字数"并不天然可比。本次正常通知在 PyMuPDF 和 pypdf 里都是 152 个字符，PDF.js 拼接后为 151，差别包括末尾换行。图片 OCR 界面显示 134 字，采用的是产品自己的计数字段。把这些数直接排序无法得出文字准确率或丢失内容的数量。
较可靠的做法是先看实际文本差异，再解释计数。本文能够确认缺映射版没有恢复中文是因为有原始通知和原页对照。能确认错映射版有两处字变了也是因为直接比过内容。字符数量只适合作为辅助证据，不能省略对应的文字内容核对。逐字符对齐完成前只记录计数来源，暂不把差值认定为丢字数量。
这张为本次独立实验整理的字段对照报告不代表产品界面。它把正常、缺映射和错映射版本的关键文字与统计并排展示。阅读时先核对标题和日期片段，再结合汉字数量与替换符等信号判断。正常版与错映射版都保留 56 个汉字。相同统计无法保证交付内容相同。
图像检查的数字也有边界。独立 MuPDF 在同一设置下将三份通知渲染为 893×1263 像素，原始像素摘要完全相同。该条件下的外观一致无法代替其他阅读器验证或文字内容核对。对于接收检查它的价值是提醒我们不要仅靠页面外观决定结果可用。
抽查结果需要带上范围
"检查过了"应该带着对象。核对标题只是标题通过，查看第一页只是第一页通过。两页混合样本已经展示首页正常、尾页损坏的情况。若记录省略范围局部结果很容易在交接里变成全文结论。检查说明保留页码与片段即可帮助状态对应到具体证据。
本次五行通知可以全部对照，公开论文则只抽查了特定位置。核对深度不同的两个结果不适合被合成为一个准确率数字。对于真实项目同样如此：自动异常检查、人工抽查和逐字核对分别记录，接收者才知道每项结果承担多大范围。是否需要扩大检查应该由用途与已发现的问题共同决定。
截图也有自己的局限。它展示某一次界面状态，不能代替所有导出格式的回读；截图里的文件名能帮助识别输入，不能单独证明后来交出的文件与它相同。本文保留原始结果和检查条件是为了让截图有对应数据。实际交付同样可让界面截图关联原始数据，避免只凭视觉状态判断全部结果。
还有个小坑是用处理耗时推算总工期。某次图片识别的耗时没有包含索取材料、选择路线和人工核对，也不能代表所有页面。本次没有批量耗时数据，不能将单次用时直接乘以页数。独立开发者可以根据已记录的实际工作环节安排后续，而不急于给出依据不足的总时长。
12 下次接到文件可以怎样开始
下次遇到"这份 PDF 帮我转成文字"我会先请提供者指出结果要用在哪里，再确定需要保留的内容和允许的整理。先记录接收版本与页数并选择真正需要使用的样段试做。拿到结果后把文字与原页并排核对，分别记录正确内容、可接受的空白差异和仍未解决的问题。这个起点不依赖某个工具，也不需要先搭一套系统。
如果原生提取满足目标就沿已确认路线继续；若出现坏映射这类问题再评估能否得到正确页面图，或是否应索取源文件。每次更换路线都针对具体问题进行判断，避免只追求界面的完成状态。本文的通知最后通过清晰页面图恢复了五行信息，但产品内转图失败也仍然保留在记录里，两件事并不冲突。
交付前最后回读真正准备交出去的文件，再对一次约定样段，并把来源、核对范围和剩余问题随结果一起交代。只有结果预览时就写结果预览已验证，未完成导出回读时也照实标出。对小团队而言可交付文本的价值就在这里：接收者知道拿到的内容能怎样用，维护者也知道出现问题后从哪里接着查。
参考资料
- RAG-Safety-Bench 论文来源：Adithiyan Rajan Indira Saravanan、Kathleen C. Fraser，arXiv 2609.11758v1，2026 年 9 月 10 日，CC BY 4.0。本文只使用此前留存的前两页作正常对照，未改写论文内容。
- OCRmyPDF 官方高级文档：参考现有文字与不同识别模式的处理边界。本次未运行该工具。
- 本次受控核验2026 年 9 月 30 日：正常通知、缺映射通知、错误映射通知、两页混合文件、标准编码英文对照，以及线上内容提取、转 HTML、转图片和独立图片 OCR 的记录。自造通知不是实际业务来件，数据仅用于本次样本内判断。