把 AI 解析接进业务流程：OCR、结构化字段与人工确认

做 AI 业务功能时，我最先感受到的落差，是演示里的“解析成功”和工作台里的“可以继续操作”相隔很远。

上传一份文件，模型返回一段看起来合理的 JSON，演示就能继续。但真正处理询价资料的人还要知道：板厚来自哪一页？数量为什么没有识别出来？两份附件写得不一样时，应该采用哪一个？如果这些问题需要重新打开所有文件寻找答案，结构化提取只是把检查工作换了个位置。

在 AIQS 的解析工作台相关开发中，我逐渐把注意力从“字段能不能抽出来”移向“结果如何被核对、修改和接纳”。本文用合成的 PCB 询价资料说明这条链路，不包含真实客户文件，也不讨论未经测量的识别准确率。

一份资料经过四种处理

假设一份询价包含扫描说明、规格表和补充邮件。扫描说明写着板厚 1.6 mm，规格表修订为 1.2 mm，采购数量没有提供。直接输出 thickness: 1.6，会把尚未解决的冲突藏进一个整洁的数字里。

我会把处理过程拆成四层：

层次	主要职责	不能替下一层决定的事
文档解析 / OCR	获得文字、表格、页码等可用信息	哪个业务值应该最终生效
模型提取	根据字段定义整理候选值和对应证据	缺失信息是否可以自行补齐
字段映射	把解析字段接到业务字段，并完成确定性的转换	是否覆盖用户确认过的数据
人工确认	核对来源、解决冲突、补充必填项	无法确认时应保留待处理状态

OCR 服务正常，只能证明文档识别这一步可用。后面的模型提取仍可能因为配置、额度或响应格式失败。反过来，模型调用成功，也不意味着扫描表格中的每个单元格都被正确读出。排障时需要分别记录这些阶段，界面也应保留相应的失败位置。

先表达候选值，再表达结论

简单的键值对象适合提交结果，却不适合承载整个确认过程。下面是用于解释设计的 TypeScript 示例，并非现有接口的完整定义：

type Candidate<T> = {
  value: T | null;
  unit?: string;
  source?: { fileId: string; page: number; excerpt: string };
  state: 'suggested' | 'missing' | 'conflict' | 'confirmed';
};

const thickness: Candidate<number> = {
  value: 1.2,
  unit: 'mm',
  source: { fileId: 'demo-spec-v2', page: 1, excerpt: '板厚：1.2 mm' },
  state: 'conflict',
};

这里的 conflict 很关键。它允许系统推荐一个值，同时承认还有另一个来源需要处理。推荐策略可以依据文件版本、明确的修订标记或用户指定的资料优先级；没有这样的依据时，应该展示候选值，而不是让模型替业务人员猜测。

数量缺失则应该保持 null，不能为了让表单完整而填入常见数量。0、空字符串和缺失值也不能混用：是否允许零值由具体字段规则决定，不能用一次真假判断处理所有字段。

来源信息最好来自解析管线可以定位的页码、区域或文本片段。模型输出的“第几页”也需要验证，不能只因为它符合 JSON 格式就当作可靠证据。

让核对路径尽量短

我更喜欢把文档预览与字段编辑放在同一工作区。点击字段来源后，预览跳到对应文件和页码；用户修改字段时，原始候选值仍然可以查看。这样，“我为什么相信这个值”就不再依赖记忆。

状态反馈也需要具体。与其让所有附件共同显示一个旋转图标，不如分别呈现“正在识别文档”“正在提取字段”“部分结果待确认”。当第二个附件失败时，第一个附件已经获得的结果仍可保留，但必须让用户看见这次结果不完整。

在移动端，不必强行塞下左右两栏。预览和字段区可以切换，关键是保留当前字段与来源之间的联系，返回后不要丢掉编辑位置。对于键盘用户，来源按钮、错误提示和确认按钮也必须有清楚的操作顺序。

把确认作为一次明确的数据提交

比较危险的做法，是模型每返回一个字段就直接更新正式记录。后续重试、重新上传或重新解析，都可能覆盖用户刚刚完成的修改。

更容易解释的流程是：

文件快照 → 解析任务 → 候选字段
                         ↓
                  用户核对和补充
                         ↓
                 确认提交 → 业务记录

在这个流程里，解析任务拥有自己的结果，正式记录拥有自己的当前值。确认时要校验必填项、单位和允许范围，也要确认任务对应的文件版本。对于支持多人编辑的系统，还应考虑记录版本检查，避免把基于旧表单的确认覆盖到新修改上。这是进一步的设计要求，不能仅靠前端禁用按钮实现。

重新解析应该产生新的候选结果。若要同步到已有记录，先展示差异，再让用户决定哪些字段可以更新。它与“创建记录时应用一次映射配置”是不同操作，后者的边界在动态业务字段一文继续展开。

验证整条业务路径

合成资料可以构造一组有明确答案的检查场景：板厚单位不同、两份文件冲突、数量缺失、附件识别失败，以及用户确认后再次解析。检查对象既包括提取结果，也包括来源是否可定位、错误是否可恢复、人工修改是否被保留。

如果要报告准确率，需要先定义字段级口径、样本范围、缺失值和冲突如何计分，并单独统计人工修正。某次演示里几个字段正确，不能推导为整套流程可靠。

这篇复盘的重点是数据与交互边界。候选值、证据定位和版本校验的完整模型仍需要结合实际系统落地；本文示例不代表这些能力已经全部实现。对我而言，一个可用的 AI 工作台，应该让用户既能利用机器的速度，也能清楚地判断什么时候需要自己接手。