BOM 标准化:一个「工作台」示例
前面几篇(CRM / 库存 / 采购)是「列表 + 表单 + 详情」的标准三件套。这一篇换两个角度: 一是展示 AuraBoot 另一种页型——工作台(Workbench);二是讲透一件真正难的事: 把客户五花八门的 BOM 自动标准化。它不是「再加一张表」能解决的 CRUD,而是一个解析 + 匹配 + 人机协同的领域问题,正好需要工作台这种「看一批数据健康度、再逐条处置」的页型。
bom-standardization 插件(命名空间 bom,hybrid)声明了 31 个 model、65 条命令、56 个页面,
后端 jar 承载 Excel 解析、物料匹配、LLM 格式探索等有状态逻辑。
1. 这件事到底难在哪
一家 PCBA 工厂每天收到几十份客户 BOM(Excel),要把它们变成能下单、能齐套分析的标准数据:
- 格式千差万别:列名(
Comment/规格/描述/Value)、单位、品牌写法、表头位置、合并单元格、 多 sheet……每家客户、甚至每个版本都不一样。 - 物料要匹配到标准库:同一颗 0402 100Ω 电阻,客户可能写成十几种样子,要对到企业物料库里唯一的标准编码。
- 匹配天然有灰度:有的能精确命中,有的只能按规格模糊命中、给出多个候选让人选,有的库里压根没有。
- 关系复杂:一个内部物料对应多个制造商料号(AML)、多个供应商料号(AVL);还有多层结构 BOM。
- 必须可追溯、可审计:每一行最终对到哪个编码、是自动还是人工确认的、依据是什么,都要留痕。
把这些塞进「一个上传按钮 + 一张表」是做不出来的。AuraBoot 的做法是:用声明式模型描述整个领域, 用命令管道承载每一步处置,用工作台把「整体质量 + 逐行处置」摆在一屏。
2. 工作台:一屏看清,逐条处置
工作台是这个场景的主界面,信息密度正是它的价值:
- 指标条(metric-strip):有效行 186 / 已确认 152(绿)/ 待确认 22(黄)/ 无法识别 12(红)—— 一眼看清这批 BOM 的标准化质量。
- 归类原因分布:不只「有多少待确认」,而是为什么——多候选待选择 / IC·连接器需人工确认 / 模糊命中需复核 / 缺关键字段 / 类别无法识别,按原因钻取。
- 全部 / 仅待确认 tabs:聚焦灰色地带。逐行选标准编码 / 确认 / 排除
(
bom:confirm_candidate、bom:confirm_standard_item、bom:set_standard_line_exclusion)。 - 重新生成并下载 / 导出版本 / 变更历史:确认完出一份干净的标准 BOM,留版本与审计轨迹。
工作台入口是一张转换任务列表——每个上传的 BOM 一行,「待确认」数让你优先处理最该看的那一批:
3. 匹配策略:绿 / 黄 / 红 是怎么判出来的
工作台上每一行的颜色,来自后端匹配引擎给出的归类原因码(bom_match_reason_code)。
这是整个产品的核心智能,分三档:
| 档 | 归类原因 | 含义 |
|---|---|---|
| 🟢 绿(自动命中) | 物料编码精确命中 / MPN+品牌精确命中 / 规格+封装精确命中 / 缺次要字段已按规格命中 | 高置信,直接采用标准编码,无需人工 |
| 🟡 黄(待确认) | 多候选待选择 / 模糊命中需复核 / IC·连接器需人工确认 | 有把握但不唯一,给出候选让人选——工作台的主战场 |
| 🔴 红(无法识别) | 物料库无匹配 / 缺关键字段 / 位号数量与用量不一致 / 类别无法识别 | 数据缺失或库里没有,需补库或修数据 |
候选不是只从一个地方来。一行待确认的物料,系统会从多个来源汇总候选给人选:
扁平物料库 / 内部物料主数据 / AML / AVL / 供应商料号 / 大模型建议 / 人工输入
(bom_candidate_source)——这也是为什么同一颗料能从「客户的十几种写法」收敛到「唯一标准编码」。
4. 数据模型(31 个,按职责分组)
整个领域被拆成五组声明式模型,各司其职、边界清晰:
- 来源解析:
bom_source_artifact/bom_source_sheet/bom_source_row/bom_source_cell/bom_raw_line_pcba—— 把上传的 Excel 拆成 sheet→行→单元格,保留原始证据。 - 格式规则:
bom_source_format_profile(格式 Profile)/bom_header_alias(表头别名)/bom_field_composition_rule/bom_category_rule/bom_unit_rule/bom_package_rule/bom_validation_rule—— 把「这家客户的这种格式怎么读」沉淀成可复用规则。 - 物料主数据:
bom_material_master(扁平物料库)/bom_item_master(内部物料主数据)/bom_manufacturer_part/bom_supplier_part/bom_aml_relation(AML)/bom_avl_relation(AVL)。 - 转换与评审:
req_requirement_set_pcba_bom(项目)/bom_conversion_task_pcba(转换任务)/req_requirement_line_pcba_bom(规范行)/bom_standard_line_pcba(标准行)/bom_match_result_pcba/bom_match_evidence(匹配证据)/bom_review_decision(评审决策)。 - 结构与版本:
bom_structure/bom_structure_line(多层结构 BOM)/bom_export_revision/bom_revision(导出与版本)。
平台据此自动建表、生成接口、渲染页面——业务团队写的是声明,不是 CRUD 代码。
5. LLM 格式探索:对付没见过的格式
新客户的 BOM 格式没有对应的格式 Profile 时,转换任务会进入 format_exploration_required 状态。
这时 bom:explore_format 调用大模型,看一眼表头和前几行,推断哪一列是物料名称 / 规格 / 位号 / 用量,
产出一个候选格式 Profile。置信度足够就自动应用并重跑;不足则标记、交人工复核——
LLM 用在「读懂格式」这种结构化判断上,而不是替代确定性的物料匹配。一旦某客户的格式被确认,
就沉淀成 bom_source_format_profile,下次同格式直接复用、无需再调模型。
6. 它在平台上怎么搭出来的
- 工作台页型用平台 workbench block 家族:
metric-strip/status-banner/tabs/workbench-action-bar。在 Page Designer 里配出来,不写 tsx—— 驾驶舱 / 对账台 / 审批台 / 异常队列都用这一套。 - 每个处置是一条命令,走同一条 命令管道: 确认候选、确认标准项、排除行、重新生成、导出版本——鉴权、校验、审计、状态机内建。
- hybrid 后端承载确定性的有状态逻辑:Excel 解析、物料匹配引擎、格式探索、导出生成; 模型 / 页面 / 命令 / 字典仍是 DSL 声明。这正是 hybrid 插件的分工——声明描述「是什么」, jar 实现「怎么算」。
一句话:工作台不是一个特制页面,而是一种平台页型;BOM 标准化则是它最能打的场景之一—— 一个真正需要解析、匹配、人机协同的领域,用声明式模型 + 命令管道 + 工作台,而不是堆一堆手写代码, 就能做成可追溯、可扩展、可被 AI 驱动的产品。
下一步
- 命令管道 —— 工作台上每个处置动作走的执行契约
- Page Designer —— 工作台与普通页面都在这里配
- 插件清单 —— hybrid 插件怎么把 DSL 与后端 jar 组合起来
- 回到业务模块总览看其它行业切片