OCR 标签核对：原生工作流与精确匹配

目的与适用边界

把文字检测、识别和业务字段验证分开处理，并保留不确定的文本，而不是用预期批号去替换它。

本教程定义的是一项工程评估，而不是可直接运行的产品认证。当前 Deyi Vision 公开的 PC 示例涵盖在已确认样本图像上运行的 EAN-13 工作流。工程代码中的原生 OCR 与检测部分，使用前必须对照已安装的运行环境、已绑定的模型和作业进行核查。浏览器模板并不能证明可在浏览器中执行：规划中的 OpenCV.js 后端需要另行验证。云端识别必须明确批准所涉及的图像范围、服务商、模型和费用。评审存档不是可执行的发布包。相机、固件和驱动的兼容性需要单独核查。下列记录表中的所有数值均为假设，不是 Deyi Vision 的测量结果，也不是客户结果。

准备证据

绑定经确认的 OCR 包、语言词典和预处理版本。要检查实际已安装的功能，不要把可编辑的 OCR 模板当作可执行的。解读最终标志之前，先对照输出约定检查中间输出。区域缺失、文本字段格式错误、坐标无效或数值非有限，都必须作为明确的失败保留，而不是默认判为合格。记录该次运行实际使用的执行后端和依赖项；不要把另一个模板同名的后端上的验收结论沿用过来。如果选用了新的模型或预处理版本，要保留之前的版本并重跑固定的对比，而不是把不同标识下的结果混在一起。要给出尝试的案例总数、其中返回可用证据的数量，以及对其余案例所作的处置。这些数量既说明识别质量，也说明覆盖范围和失败处理情况。OCR 标签核对是一项数据完整性任务，而不是在找看似合理的词。定义每个字段、字段位置、预期字符集、精确比对规则，以及预期值的可信来源。批号字段、日期字段和产品名称可能需要不同的规则。在规范化空格或大小写之前，先保留文字检测多边形和识别器的输出。不要悄悄地把 I 替换成 1，或把 O 替换成 0：这会让错误的标签看起来正确。原始工程证据中有一个范围很窄的 OCR 边界案例，其结果为 NoResult 或 Review；增大裁剪范围并不能证明识别已普遍可用。可读的字段仍可能是错误的批号；而预期值本身正确，也不能成为把它填进不可读字段的理由。把工作流看作一连串类型明确的判定，而不是模型给出的单一答案。运行实验之前，先绑定输入标识、区域变换、节点版本、预处理和模型包。在开发图像上选择参数，与在冻结集上做评估要分开；冻结集的答案不得用于调参。每个案例的基线结果和候选结果都要保留，执行失败的也不例外。AI 的建议可以提出修改方案，但不能确认参考答案、授予数据上传权限或批准投入生产。如果服务商调用的回执状态不确定，要保留请求标识，先查清该回执，再考虑是否重发。运行环境可用性、识别质量和发布批准是相互独立的检查。

操作步骤

1. 只把与源图像关联的字段送入检测，并在识别之前保留返回的多边形。
2. 保留原始识别文本，再只套用书面规定的规范化规则；两个版本和所用规则都要记录。
3. 与可信的批号字段做精确比对，并区分可读但不匹配的情形与 NoResult 或 Review。
4. 在开发数据上选择模型或阈值的变更，然后重跑冻结的对比，其中要包含易混淆字符。

解读试验

LOT123 是假设的预期字段内容。LOTI23 是可读但不匹配的结果，尽管两者都是 6 个字符。模型的置信度并不构成把 I 替换成 1 的许可。缺少检测器/识别器依赖项会阻止执行；仅凭公开的 PC 示例，并不能证明这条原生 OCR 链路已就绪。

记录表

两种工程视角

故障诊断

• 文本值本身正确，却关联到了错误的字段多边形，必须判定为绑定复核不通过。
• 缺少所要求的来源/请求标识的服务商应答，不得成为被接受的本地 OCR 回执。

验收与交接

只验收实际评估过的已绑定运行环境。保存多边形、原始文本、规范化文本、预期值来源、版本，以及每个失败字段的处置结果。

将源图像、预期判定、确切版本和完整的结果记录放在一起保存。在选定最终参数之前，先冻结评估集。如果这些答案之后被用来调整工作流，就要把该集合标记为开发数据，并另取一套独立的验收集。Review、NoResult、执行错误和缺失的采集都要保留在分母中；不要通过过滤数据行把它们变成合格。可复现的失败案例要与成功样品一并保存。交接内容应写明：谁可以修改配方，如何恢复先前获批的版本，以及在验收之前哪些设备输出保持禁止。仅凭软件结果，并不能证明运动中的实物工件到达了正确的去向。