实操：从运输单据提取到异常任务创建的完整流程

本文目录

运输单据适合作为物流 AI 的第一个实操项目，因为团队可以拿已完成订单回放：系统读到了哪些字段，哪里出现冲突，人工最后采用了什么结果，都有材料可核对。

本次试点只完成一条小链路：读取一组运输单据，提取候选字段，用规则检查完整性与跨文件差异，然后创建待人工确认的异常任务。它不自动修改订单状态，不发送客户通知，也不判断合同或监管责任。

第一步：限定单据与业务范围

试点贵在窄，不在全。先选一种运输方式、一条相对稳定的业务线，以及少数常见文件，例如运单、提单、装箱单和签收证明。不同国家、运输方式和合同可能对文件有不同要求，试点字段应由企业业务、法务或合规人员按实际情境确认。

用已结束订单建立样本集，覆盖清晰电子文件、扫描件、多页表格、版本更新、手写补充、字段缺失和跨文件冲突。删除不参与验证的个人信息，并按现有制度限制访问。

第二步：建立单据与字段字典

先定义清楚每份文件该有什么。每种文件先定义允许提取的字段、格式和证据位置。常见候选包括：

• 订单号、运单号、提单号或箱号；
• 托运人、收货人、承运人和通知方；
• 起运地、目的地、装运与签收时间；
• 品名、件数、毛重、体积及相应单位；
• 文件版本、签发信息和原文位置。

同一名称在不同系统中的含义可能不同。字段字典要写清业务定义，不能只列一个英文标签。UNECE 多式联运参考数据模型可以帮助团队理解跨运输方式的数据对象，但企业仍需结合自己的合同、系统和监管要求落地。

第三步：保存原件，再做识别与提取

原件是唯一的证据，先锁住。原文件只读保存，记录来源、收到时间、文件哈希或版本标识。OCR 或版式识别产生的中间文本也要能关联回原件。

AI 输出候选字段、原文片段和页码或区域位置，同时给出“未找到”“无法辨认”“多处冲突”等状态。系统不得因为某字段在其他订单中常见，就为当前文件补出值。

第四步：用确定性规则做第一轮校验

模型输出之后，规则来把关。在模型输出之后运行规则：

• 编号是否符合企业已知格式；
• 日期顺序是否合理；
• 数值是否带单位，单位换算是否可复现；
• 必填字段是否缺失；
• 同一字段在不同文件中是否一致；
• 文件与订单能否唯一关联。

规则保存原值和标准化值。AI 可以提示“这里可能是重量”，单位换算与阈值判断必须由程序完成。

第五步：把差异转换成异常任务

有差异不可怕，没人处理才可怕。为每类差异预先定义任务模板。例如，订单号无法匹配交给单证人员，件数冲突交给运营核查，签收要素缺失进入签收材料队列，敏感或高风险事项按制度升级。

任务中包含订单、异常类型、冲突字段、各来源原值、证据链接和建议核查的问题。AI 可以把技术字段整理成易读说明，不能选择“更可信”的文件并覆盖另一个值。

第六步：人工确认并记录修改原因

人要做决定，系统要留下记录。处理人员查看原件与差异，选择正确值、要求补充材料或标记源数据问题。每次修改记录原值、修改值、人员、时间和理由。若业务定义本身不清楚，应更新字段或规则。反复要求模型猜得更准，治标不治本。

确认后的数据先写入测试表或待提交记录。正式系统写回需要权限、幂等、撤回和失败重试设计，不属于第一版验证范围。

第七步：用结果完善异常流程

问题暴露出来，正是改进的机会。统计最常见的失败来源：低质量扫描、模板变化、字段别名、跨文件冲突、订单关联失败，还是上游根本没有记录。针对不同问题采取不同措施，不能把所有错误都归为“模型准确率不够”。

当字段和任务创建稳定后，可以接入异常订单协作流程，增加事件时间线、责任分派和客户通知草稿。扩展前仍应进行影子运行。

验收看五组结果

不要只看准确率，拆开看。

结果	需要检查的内容
字段	关键值漏提、错提和单位错误
证据	字段是否能回到正确原文位置
关联	文件是否挂到正确订单，歧义是否转人工
异常	重要差异是否创建了正确任务和升级
效率	人工整理、核对和返工时间是否变化

还要单独记录高后果错误，例如把一个订单的文件关联到另一个订单、把缺失值补成确定值，或漏掉需要立即处理的冲突。总体平均结果不能抵消这类问题。

何时停止，何时扩大

不是所有情况都适合自动处理。出现未覆盖文件类型、原件不可读、关键编号冲突、证据定位失败或业务规则缺失时，停止自动处理并进入人工队列。系统不可用时，团队仍能按原流程处理必要单据。

只有当错误类型可解释、规则版本可管理、任务有人负责、运行能够重放时，才扩展新单据和新线路。GS1 EPCIS所体现的事件共同语言，也可以在下一阶段帮助企业把单据事实与运输状态连接起来。

这个试点的价值，不只是把文件变成表格。它先建立了一条可靠链路：每个字段有来源，每个差异有规则，每个异常有人处理。物流 AI 的后续场景，应该建立在这条链路上。一段无法追溯的摘要，再多也撑不起下一步。