#AI OCR 为什么会重构文档处理

OCR 过去常被理解为“把图片里的字识别出来”。这当然重要，但在真实文档处理里，只拿到文字远远不够。

发票、合同、简历、报告、病例、试卷、银行流水、招标文件、扫描 PDF，它们不只是文字集合。它们有版面、层级、表格、页眉页脚、签章、图片说明、批注、阅读顺序和字段语义。

AI OCR 的变化在于：系统不再只问“图片里有哪些字”，而是开始问“这份文档是什么结构，哪些信息属于同一个字段，哪些内容需要被引用、校对、检索和进入业务流程”。

这会重构文档处理产品，也会让前端承担更多交互和工程设计。

#传统 OCR 解决了什么，没解决什么

传统 OCR 擅长把图像区域识别成文字。它通常输出文本行、坐标和置信度。

例如：

{
  "text": "合计金额：1280.00",
  "confidence": 0.98,
  "box": { "x": 120, "y": 640, "width": 260, "height": 32 }
}

这对搜索、复制和基础归档很有用。但文档处理真正困难的地方往往在后面。

系统还需要知道：

• 这个金额是含税金额、未税金额还是付款金额？
• 表格的列和行如何对应？
• 多页合同里的条款层级是什么？
• 页眉页脚是否应该进入正文？
• 扫描件里的印章、手写字和水印如何处理？
• 两栏论文的阅读顺序是什么？
• 这个字段低置信度时应该如何让用户校对？

传统 OCR 输出的是“文字碎片”，而业务需要的是“可用文档结构”。

#AI OCR 的核心变化

AI OCR 可以理解为 OCR、视觉理解、版面分析和结构化抽取的组合。

它的重点不是替代 OCR，而是把 OCR 结果变成更接近业务语义的数据。

常见能力包括：

• 保留文字和坐标之间的映射。
• 识别标题、段落、列表、表格、图片、页眉页脚。
• 推断阅读顺序。
• 把文档字段抽取成 JSON。
• 对表格做行列结构恢复。
• 给字段置信度和来源区域。
• 支持用户校对后回写。
• 为 RAG 建立页码、区块和引用关系。

这些能力组合起来，文档处理就不再是“上传文件，拿到一大段文本”，而是一个可检查、可校正、可追踪的数据生产流程。

#对前端工程师意味着什么

AI OCR 产品的前端不只是文件上传页，而是文档审阅和结构化编辑界面。

用户需要看到原文，也需要看到系统抽取出的结构。用户要能判断某个字段是否正确，错误时能快速定位来源区域并修正。

这通常需要三类视图：

• 文档视图：展示 PDF 页面、扫描图、缩放、翻页、旋转、区域高亮。
• 结构视图：展示抽取字段、表格、段落层级、JSON 结果。
• 校对视图：展示置信度、错误提示、人工修改、提交状态。

前端的价值在这里非常明确：让用户相信、检查并修正 AI OCR 的结果。

#文档处理的工程链路

一个稳定的 AI OCR 链路通常不是同步请求。

大 PDF 可能有几十页，扫描件需要渲染页面，OCR 和版面理解需要时间，字段抽取还可能需要模型调用。因此更常见的设计是任务化处理。

type DocumentJobStatus =
  | 'queued'
  | 'rendering'
  | 'ocr_running'
  | 'layout_running'
  | 'extracting'
  | 'ready_for_review'
  | 'completed'
  | 'failed';

type DocumentJob = {
  id: string;
  documentId: string;
  status: DocumentJobStatus;
  totalPages: number;
  processedPages: number;
  error?: string;
};

前端应该把这些状态展示成可理解的进度，而不是只有一个转圈。

例如：

• 已上传，等待处理。
• 正在渲染第 3/18 页。
• 正在识别文字。
• 正在恢复表格结构。
• 正在抽取合同字段。
• 需要人工校对 4 个低置信度字段。

这些阶段提示能显著降低用户焦虑，也能帮助定位失败。

#数据模型：不要丢掉坐标

文档处理系统最重要的工程原则之一是：不要只保存纯文本。

如果你只保存 OCR 后的一段字符串，后续就很难做到引用、校对、高亮和审计。

更好的结果模型应该包含页面、区块、文本、坐标、类型和置信度。

type DocumentBlock = {
  id: string;
  page: number;
  type: 'title' | 'paragraph' | 'table' | 'figure' | 'header' | 'footer';
  text: string;
  confidence?: number;
  bbox: {
    x: number;
    y: number;
    width: number;
    height: number;
  };
  children?: DocumentBlock[];
};

type ExtractedField = {
  key: string;
  label: string;
  value: string;
  confidence: number;
  sourceBlockIds: string[];
  sourceRegions: Array<{
    page: number;
    bbox: { x: number; y: number; width: number; height: number };
  }>;
  reviewedByUser: boolean;
};

这类结构让前端可以实现：

• 点击字段，高亮来源区域。
• 点击页面区域，查看对应识别文本。
• 对低置信度字段做校对。
• 在导出 JSON 时保留来源证据。
• 在文档问答中返回页码和区域引用。

坐标映射是 AI OCR 从“识别文字”走向“可信文档处理”的基础。

#结构化抽取需要 schema

AI OCR 最有业务价值的场景通常不是“给我全文”，而是“帮我抽取这些字段”。

例如发票：

type InvoiceExtraction = {
  invoiceNumber: string;
  sellerName: string;
  buyerName: string;
  issueDate: string;
  totalAmount: number;
  taxAmount?: number;
  lineItems: Array<{
    name: string;
    quantity: number;
    unitPrice: number;
    amount: number;
  }>;
};

合同可能需要抽取甲方、乙方、金额、期限、付款条件、违约条款。简历可能需要抽取姓名、联系方式、工作经历、技能和教育背景。

前端在这里要做两件事。

第一，展示 schema 对应的表单，而不是只展示模型返回的原始 JSON。用户要能编辑、清空、确认和提交。

第二，处理字段状态。每个字段可能是自动抽取、低置信度、人工修改、缺失、格式错误或等待确认。

type FieldReviewState =
  | 'auto_filled'
  | 'low_confidence'
  | 'missing'
  | 'invalid_format'
  | 'user_modified'
  | 'confirmed';

这让文档处理从一次性 AI 输出变成可控的业务流程。

#表格是最容易低估的难点

表格抽取比普通段落困难得多。

难点包括：

• 合并单元格。
• 多级表头。
• 跨页表格。
• 无边框表格。
• 扫描件倾斜。
• 手写批注覆盖。
• 数字列对齐但没有明确分隔线。
• 表格标题和脚注属于表格上下文。

前端不要假设 AI 返回的表格一定完美。更实际的设计是提供可编辑表格：

• 允许新增、删除、合并、拆分行列。
• 支持单元格来源区域高亮。
• 对数字列做格式校验。
• 对低置信度单元格标记。
• 支持导出 CSV、Excel 或业务 JSON。

对于表格密集型业务，前端表格编辑器的体验往往决定 AI OCR 是否真的能落地。

#AI OCR 与文档 RAG 的关系

文档问答不是把 PDF 全文复制进 Prompt。

稳定的文档 RAG 需要把文档解析成可检索、可引用的块。

AI OCR 在这里提供的不是单纯文本，而是带页码和区域映射的 chunks。

一个 chunk 应该知道自己来自哪一页、哪个段落、哪个表格，最好还能定位到页面坐标。这样模型回答时才能返回“第 7 页，付款条件表格第 2 行”这样的引用。

前端则要把引用变成可点击、可验证的体验。

#人工校对不是失败，而是产品能力

很多团队希望 AI OCR 一次性完全正确。但真实业务里，人工校对是不可避免的。

尤其在高价值场景中，用户不只是要“快”，还要“可确认”。

前端可以把校对体验设计得很高效：

• 默认聚焦低置信度字段。
• 键盘快捷键在字段之间切换。
• 字段获得焦点时自动高亮来源区域。
• 修改后记录 AI 原值和人工值。
• 支持批量确认高置信度字段。
• 对格式错误即时提示。
• 提交前展示未确认字段。

这类体验能让 AI OCR 成为生产力工具，而不是一个不稳定的黑箱。

#常见坑

#只保存 OCR 文本，不保存布局和坐标

这会让后续引用、校对、溯源和文档 RAG 都变得困难。文档处理要尽早保留页面、区块、坐标和置信度。

#让用户直接面对原始 JSON

模型返回 JSON 不等于产品完成。前端应该把字段映射成表单、表格和校对工作流，让用户能理解和修正。

#忽略低置信度字段

低置信度不是后端日志里的细节，而是前端交互里的重点。用户应该优先看到需要确认的内容。

#把 PDF 当成纯文本文件

PDF 可能包含扫描图、文本层、表格、图片、批注、签章和多栏布局。直接抽文本很容易丢失阅读顺序和视觉证据。

#不处理人工修改的审计

文档处理常进入财务、法务、医疗、人事等流程。谁修改了哪个字段、原始 AI 值是什么、来源区域在哪里，都可能需要记录。

#小结

AI OCR 会重构文档处理，因为它把“识别文字”推进到了“理解版面、抽取结构、保留证据、支持校对和进入业务流程”。

对前端工程师来说，这不是一个简单上传组件，而是一套文档工作台：预览、缩放、高亮、字段表单、表格编辑、低置信度校对、引用跳转和任务进度都很关键。

文档处理的可靠性不只来自模型，也来自工程上是否保留了结构、坐标、置信度和人工修正路径。AI OCR 真正的价值，是让非结构化文档可以被稳定地检查、修正、检索和自动化处理。