---
title: 13-coffee-b2b-order-intake-solution
description: 文本抽取：AI研讨会/13-coffee-b2b-order-intake-solution
updated: 2026-11-04
tags: [原始文档, 抽取, AI研讨会]
source: AI研讨会/13-coffee-b2b-order-intake-solution
source_type: txt
source_hash: 970a650b3667
extracted_at: 2026-11-04
quality: ok
---

---
source: AI研讨会/13-coffee-b2b-order-intake-solution.html
type: html
size_kb: 54
category: AI研讨会
quality: ok
---

B2B 智能录单流水线方案｜ShopeX AI FDE 样例
ShopeXAI
← 返回总览
00 需求还原
01 总体架构
02 端到端流程
03 解析与校验
04 确认与推送
05 数据边界
06 价值指标
07 实施分期
导出 PDF
ShopeX · AI FDE 样例（客户匿名版）
某国际咖啡品牌 B2B 智能录单流水线
把采购单接入，从手艺活变成工业化流程
客户在需求清单里写明：用 ShopeX 的 AI 能力支撑 B2B 业务扩张，缩短下单 AHT、提高准确率。本方案把这句话翻译成一条可验收的流水线：邮件里的非标准采购单自动变成结构化订单草案，规则库完成金额与运费校验，人只做确认，B2B 平台负责建单与留痕。PoC 已在客户真实单据上跑通全链路。
50 / 19单日样本采购单数 / 客户家数（PoC 实测）
38 / 12自动解析成功 / 需视觉识别或人工补录
6 类已沉淀模板族解析器，含 5 类特殊模板
3 态待确认 → 已确认 → 已推送，全程可追溯
00 / 需求还原
客户要的不是一个 AI 功能，是录单产能不再卡住 B2B 扩张
需求来自客户的一封邮件清单，原文三条：用 ShopeX AI 支撑 2B 业务扩张；缩短订单处理 AHT、提高准确率；以更快的录单效率改善客户体验。关联系统写明 2B Porter / OMS / PowerBI。把这三条放回客户的日常作业里，痛点非常具体。
压力 01 · 格式
几十种采购单格式，没有一种是标准的
同一天进来的 50 张单子里，有万豪系 VAT13 税码格式、凯悦的 SKU 锚定行、希尔顿的 BOX/50EA 单位、中文采购单网页、Excel 送货单，还有整页是图片的扫描件。每一种都要人眼读、人手录。
压力 02 · 校验
录完不算完，还要逐项核对金额与运费
数量乘单价是否等于行总价、明细合计是否等于订单金额、运费是否符合区域规则（例如海南不满 300 粒应收 15 元运费）、发票抬头与收货信息是否缺失——这些核对今天全靠老员工的经验和细心。
压力 03 · 产能
B2B 盘子要扩，录单人头扩不动
客户原文把 AI 录单直接挂在 "support 2B business expansion" 下面。扩张意味着单子更多、客户更多、格式更杂；如果每多一个客户就多一份人工录单，增长就被产能锁死。
压力 04 · 体验
录单慢和录单错，最终都由客户体验买单
下单 AHT 长、差错要来回对账补单，客户感受到的是"下单之后迟迟没动静"。客户把"更快录单"写进客户体验改善，说明这条线在他们的考核里挂的是体验指标，不只是内部效率。
"Implement SHOPEX AI tech to support 2B business expansion. Shorten order process AHT and improve accuracy. Drive customer experience improvement via faster order placement efficiency."—— 客户需求清单原文 · B2B Order placement with AI support（关联系统：2B Porter / OMS / PowerBI）
PoC 已经回答了"能不能做"。在客户真实单据上跑过一轮完整验证：50 张采购单、19 家客户，38 张自动解析出明细行，12 张因图片型或乱码需视觉识别补录；自动恢复 5 类特殊模板；金额不平的 3 张单被校验规则拦下并标红。本方案要解决的是"怎么变成每天都能跑、能验收、能扩展的生产流程"。
01 / 总体架构
五层流水线：接入、理解、校验、确认、建单，各管一段
整条流水线不新建订单主数据，也不替换客户既有系统。它做的是把"邮件里的非标准单据"翻译成"B2B 平台能接收的结构化订单"，中间每一步都有明确的责任者和留痕点。
图 1 · B2B 智能录单流水线总体架构：五个通道层自上而下，治理与留痕贯穿右侧
1
接入层 · 邮件与文件入口
IMAP 定时收取采购单附件 · 按 Message-ID 去重 · 落入带日期的收件目录 · 支持邮箱过滤规则
凭证隔离
邮箱授权码存私有目录
不随方案与技能包流转
2
理解层 · 模板族解析与视觉识别
文本型走坐标匹配与模板族解析器 · 图片型/乱码型渲染成图后视觉识别 · 统一映射为标准订单结构
模板族库
6 类已沉淀
新模板按族归档
3
校验层 · 规则库自动核对
金额自校验（行总价/小计/合计）· 运费区域规则 · 缺失字段提示 · 不平与缺失一律标红不静默放过
规则可配置
运费/阈值/必填项
客户业务方维护
4
确认层 · 人掌握建单权
结构化草案生成可视化预览 · 运营逐单或批量确认 · 异常单转人工补录队列 · 确认动作本身留痕
确认门
未确认不推送
推送幂等可重跑
5
建单层 · 对接客户 B2B 平台
结构化订单推送 2B Porter / OMS · 回执与平台单号归档 · 经营看板按统一口径出数（PowerBI）
接口适配
一期 mock 已验证
二期换真实端点
虚线回路：建单回执与异常单回到接入层台账，形成每日处理闭环
接入与建单（系统对接）
理解（AI 解析）
校验（规则库）
确认（人工闸门）
回执回路
为什么是五层，而不是"一个 AI 把单子录进去"
设计 01 · 解析与校验分离
AI 负责读懂，规则负责判对
解析是概率性的，校验是确定性的。金额对不对、运费该不该收，用规则库判，不用模型猜。两层分离后，解析模型可以换、可以升级，校验口径始终由客户业务方说了算。
设计 02 · 确认与推送分离
人确认的是"这张单能不能进系统"
确认层给出可视化预览和标红项，人做的是业务判断；推送层只做机械动作且幂等可重跑。两者分离后，确认可以在工作时间内做，推送可以在任何时间扫，互不阻塞。
设计 03 · 每层独立验收
哪一层不达标，就补哪一层
接入看收取与去重成功率，理解看模板族覆盖率与解析成功率，校验看拦截准确率，确认看平均确认时长，建单看推送成功率与回执完整性。五层各自有指标，项目验收不靠感觉。
02 / 端到端流程
一张采购单从邮箱到 B2B 平台的十二个节点
流程分三条泳道：自动线（接入、解析、校验、登记）、人工线（预览、确认、补录）、系统线（推送、建单、回执、看板）。编号即执行顺序，09 的确认门是自动线与系统线之间唯一的闸口。
图 2 · 端到端流程：三泳道 × 十二节点，确认门为唯一人工闸口
自动线
定时任务驱动
人工线
运营 / 客服
系统线
B2B / OMS / 看板
节点说明
左列编号与泳道节点一一对应
01收取邮件附件IMAP · 去重
02文本/表格提取坐标匹配
03图片型视觉识别渲染后读图
04映射标准结构统一字段名
05规则校验标红金额/运费/缺失
06登记待确认
07可视化预览先看后确认
08确认门确认/退回/补录
09异常补录队列图片/乱码/不平
10推送 B2B 平台幂等扫描
11建单与回执平台单号归档
12经营看板出数统一口径
补录后
回确认门
01 定时收取采购单邮件附件，按 Message-ID 去重，重复运行不重处理。
02–03 有文本层的走坐标匹配与模板族解析；图片型、乱码型渲染成图后视觉识别。
04 所有来源统一映射为标准订单结构：订单头六项、明细行六项，字段名全局统一。
05 规则库校验：行总价=数量×单价、明细合计=小计、小计+税=总额、运费区域规则、必填项缺失提示；不平与缺失标红。
06 校验通过的草案登记为待确认，进入台账，状态可查。
07–08 预览先于确认：运营看到可视化单据与标红项之后才点确认；确认动作留痕。
09 解析失败或金额不平的单进补录队列，人工或视觉识别补录后回到确认门。
10 推送只作用于已确认单据，扫描幂等，重复执行不会重复建单。
11 平台回执与单号归档，与原始邮件、解析结果、确认记录同单可追溯。
12 看板按统一口径出数：单量、客户数、自动解析率、补录率、平均确认时长。
关键设计：确认门之前的一切都可以重跑，确认门之后的一切都有回执。
系统对接节点
AI 解析节点
校验与推送节点
人工节点
补录回路
流程里刻意保留了两处"慢"。预览先于确认、补录先于推送，都是故意让人停下来看一眼的环节。录单流水线的价值不在于全程无人，而在于人只在该判断的地方判断，其余环节机器跑完并留痕。
03 / 解析与校验
模板族解析器加规则库，是这条流水线真正的资产
PoC 里最有价值的产出不是"AI 能读 PDF"，而是六类模板族解析器和一套可配置的校验规则。前者决定覆盖率，后者决定可信度，两者都以文件形式沉淀，可复用、可验收、可扩展。
3.1 模板族解析器 · 已沉淀六类，新格式按族归档
模板族识别特征解析策略PoC 状态
| 通用文本型 PDF | 有文本层，标签-值同行、表格列对齐 | 坐标匹配：同 y 为标签值对，按表头 x 范围归列；多行描述按同 x 合并 | 已验证
| 万豪系 VAT13 格式 | 税码写作 VAT13 而非通用 V6 | 修正税码正则，其余沿用通用管线 | 已验证
| 凯悦 SKU 锚定行 | 行首为 SKU 编码，金额与单位混排 | 以 SKU 为锚点切行，行合计与订单金额互校验 | 已验证
| 希尔顿 BOX/50EA 单位 | 单位字段为组合单位 | 组合单位拆解，数量与包装换算后入明细 | 已验证
| 中文采购单网页 | htm 表格，含税率与未税/税额列 | 按"数量 单位 货号 描述 单价 税率 未税 税额"列序解析，含税行总价=金额+税额 | 已验证
| Excel 送货单 | xlsx 表头列定位 | 按表头列名映射品项编号/名称/单位/数量/单价/金额 | 已验证
| 图片型 / 乱码型 | 无文本层、CID 乱码、整页截图 | 渲染高分辨率图后视觉识别，结果回标准结构；识别置信度低的转补录队列 | PoC 12 单待补录，方案内闭环
3.2 校验规则库 · 判对不用模型猜
规则 A · 金额自校验
三级金额恒等式
行总价 = 数量 × 单价；明细合计 = 小计；小计 + 税额 = 订单总额。任一级不平即标红并给差额，PoC 中拦下 3 张金额不平的单（差额从数百到上万元不等）。
配置项 容差阈值（默认 0.01）、不平处置（标红待人工 / 直接退补录）line.amount == qty × unit_price → subtotal == Σ amount → grand == subtotal + tax
规则 B · 运费区域规则
区域 × 数量档的运费矩阵
示例规则：非免运费区域、商用胶囊不满 300 粒应收 15 元运费。PoC 中一张 250 粒的单运费记 0 且与文件名标注矛盾，被规则拦下。运费矩阵由客户业务方维护，规则引擎只负责执行。
配置项 免运费区域清单、数量档与对应运费、促销豁免名单region ∉ free_list ∧ qty < 300 → freight = 15，否则按矩阵取值
规则 C · 缺失字段提示
缺什么、缺在哪，一次说清
发票抬头、收货地址、收货人、电话、预计到货时间等必填项缺失时，逐字段提示并标注"原文未标注"或"仅能从文件名推断"，避免下游建单后才发现信息不全。
配置项 必填项清单、可推断项白名单（如文件名含客户名）missing(field) → mark(field, source_hint) → 预览标红
规则 D · 促销与赠送识别
备注里的业务语义不丢
备注中"实发数量含赠送"这类语义单独提示确认，避免把赠送量当销售量入看板。规则不自动改数，只把疑点摆到人面前。
配置项 赠送/促销关键词表、提示级别note ∋ keywords(gift, promo) → flag → 确认门可见
规则库的归属要一开始就写清。解析器是商派的资产，随项目交付并持续维护；校验规则的口径（运费矩阵、必填项、容差）归客户业务方所有，商派提供配置界面与执行引擎。口径变更不需要改代码，改配置即生效，并留变更痕迹。
04 / 确认与推送
三态状态机：人掌握建单权，机器保证不重不漏
每张单在台账里只有三个状态：待确认、已确认、已推送。状态只允许向前流转，推送扫描幂等。这套状态机在 PoC 中已跑通，包括确认在对话内完成、推送回执归档。
图 3 · 单据状态机与确认门：三态流转，失败可重试，全程留痕
待确认
解析+校验完成，预览已生成
已确认
人工确认，确认人与时间留痕
已推送
平台回执与单号归档
确认（对话内按钮或指令）
推送扫描（幂等）
推送失败
记录原因，下轮重试，不丢单
退回补录
解析失败/金额不平/信息缺失
补录完成回确认门
闸门 01 · 预览先于确认
不允许"盲确认"
确认请求必须附带可视化预览与标红项，人看到完整单据之后才做确认。同一张单的预览、确认指令、确认人、时间戳在同一台账条目里可查。
闸门 02 · 推送幂等
重复扫描不会重复建单
推送只作用于已确认且未推送的单据；已推送的跳过，失败的记下原因等下轮。定时任务可以每小时跑，不需要担心重跑造成重复订单。
闸门 03 · 同单可追溯
从邮件到回执一条链
原始邮件与附件、解析结果、校验标红、预览快照、确认记录、推送请求与平台回执，按单号串成一条链。任何一张单出争议，十分钟内能还原全过程。
"Agent 负责处理，人负责确认，系统负责留痕与执行。"—— 本方案对人机分工的一句话定义，与 PoC 实际运行方式一致
05 / 数据边界
四类数据各走各的管道，凭证与主数据都不越界
这条流水线碰四类数据：单据原文、解析结果、校验规则、平台回执。边界写清楚，客户的安全与合规审查才有得谈。
数据类别存放位置谁可以碰保留与销毁
| 邮箱凭证 | 客户私有目录或环境变量，权限 600；不随方案文档、技能包、代码仓库流转 | 仅客户 IT 配置的运行账号 | 轮换授权码即失效；方案交付物中只含占位模板
| 单据原文与附件 | 客户指定的收件目录（本地或客户内网存储） | 流水线运行账号 + 授权运营 | 按客户档案留存策略；解析结果不反向覆盖原文
| 解析结果与校验标红 | 与原文同目录的结构化文件 + 台账 | 运营（确认）、IT（审计） | 随单归档；看板只消费聚合指标，不消费原文
| 校验规则口径 | 规则配置文件，版本化管理 | 客户业务方维护，商派提供引擎 | 变更留痕，可回滚到任一历史版本
| 平台回执 | B2B 平台返回，归档于台账 | 运营、IT、审计 | 与订单同生命周期
边界 01 · 不新建订单主数据
订单的真源仍在客户 B2B 平台
流水线产出的是"订单草案"，建单动作发生在客户平台。避免"系统一套数、流水线一套数"的双账本问题，对账永远以平台回执为准。
边界 02 · 模型不碰凭证
AI 读的是单据，不是邮箱密码
邮件收取由独立脚本用凭证完成，模型只接收已落盘的单据文件。凭证不出私有目录，也不进入任何提示词或日志。
边界 03 · 部署形态可选
本地工作台或客户内网，二选一
流水线全部组件可跑在客户本地工作台或内网环境；单据与解析结果是否出内网，由客户安全策略决定，方案不预设默认值。
06 / 价值指标
对照客户原文的三条诉求，逐条给出度量口径
客户要的是 AHT、准确率、客户体验。方案把这三条拆成可采集的指标，基线用 PoC 实测数据，目标值在试点期与客户共同标定，不在方案里承诺未验证的倍数。
客户诉求（原文）现状基线方案落地后度量口径
| Shorten order process AHT | 人工读单+录单+核对，单张耗时以十分钟计，峰值积压 | 自动线完成解析与校验，人只做确认；确认单张耗时以分钟计 | 单张端到端时长、日均处理单量、积压单数
| Improve accuracy | 差错靠下游对账发现，发现时已建单 | 三级金额恒等式+运费规则在建单前拦截，标红可见 | 校验拦截数、建单后更正单数、金额不平流出率
| Faster order placement efficiency | 录单产能随单量线性加人 | 产能与模板族覆盖率挂钩，新增客户=新增模板族而非新增人头 | 自动解析率、补录率、模板族覆盖客户占比
| Support 2B business expansion | 新客户接入靠人工熟悉其单据格式 | 新格式按族归档复用，接入周期从"熟悉一个人"变成"沉淀一个解析器" | 新客户首单接入周期、模板族复用次数
76%PoC 自动解析率（38/50），图片型补齐后目标再议
3 张金额不平单被拦截，差额最大一张逾万元
5 类特殊模板在 PoC 中恢复，全部沉淀为解析器
0 重复去重与幂等设计下，重跑不产生重复处理与重复建单
这条流水线的商业含义：B2B 收入增长与录单人头脱钩。每多一个客户、多一种格式，增加的是一个可复用的模板族解析器和几条校验规则，而不是一名录单员。客户在需求里写的 "support 2B business expansion"，落到工程上就是这句话。
07 / 实施分期
三期推进：先把已验证的跑成日常，再换真实接口，最后扩格式扩客户
分期原则：每一期都有独立可验收的产出，上一期不验收通过不启动下一期；客户配合事项在每期开头一次性列清。
一期 · 生产化跑通
把 PoC 变成每天在跑的流程
收件、解析、校验、登记、确认、推送全链路部署到客户指定环境
图片型/乱码型 12 单的视觉识别补录闭环上线
校验规则库配置界面交付，运费矩阵与必填项由业务方录入
台账与同单追溯链上线，日报按"本次运行/累计台账"两段输出
验收 连续两周自动解析率不低于 PoC 水平、零重复建单、标红项全部有人处置客户配合：收件邮箱与目录、规则口径、确认责任人名单
二期 · 真实建单对接
mock 换成 2B Porter / OMS 真实端点
与客户 IT 联调建单接口，字段映射与回执格式双方签认
推送失败重试与告警接入客户运维通道
经营看板按统一口径出数，对接 PowerBI 数据源
验收 真实建单成功率、回执归档完整性、看板与平台数据一致客户配合：接口文档与测试环境、看板口径签认
三期 · 扩格式扩客户
把覆盖率变成扩张能力
新客户单据格式按族归档，解析器增量交付、独立验收
校验规则随业务扩展（新区域运费、新促销语义）
模板族库与规则库作为客户资产移交运维文档
验收 新客户首单接入周期、模板族复用次数、补录率下降曲线客户配合：新客户样本单据、口径变更流程
两个不在本期范围的事项，先说清楚。其一，客户清单中的发货单电子化、POS 积分支付、权益卡线下核销三项属系统集成范畴，与本 AI 录单流水线分别立项，不在本方案交付内；其二，解析准确率的上限受单据原件质量约束，扫描件模糊、原件缺字段的情况，方案以"标红+补录"兜底，不承诺百分百自动通过。
与总览页的衔接。本页是"某国际咖啡品牌"客户案例的方向一方案；同章的方向二方案（客服交互摘要与投诉预防）见《OMNI 客服智能化与合规本地化方案》。两个方向共用同一套确认门与台账设计，可分别立项、分别验收。
ShopeX 商派 · AI FDE 样例（客户匿名版）· 2026 年 9 月 14 日 · 本页数据来自客户真实单据 PoC 实测