半导体设备
与一家设备厂合作：Micius 逐段核对物料编码，整改留给工程师
聊聊你的编码规范 
- 错在哪一段
- 逐条写明出错字段和原因，整批给出整改顺序
- 判定附出处
- 每条规则都注明出处，可回到规范原文核对
这家半导体设备厂物料品类多。新物料建档前，工程师要对着几张编码规范表，把清单上的编码一条条核。知满把这一步交给了 Micius 模型：它先读规范，再整批核对，写明错在哪一段；改不改、怎么改，仍由工程师定。
挑战
一条编码要查五处
这家企业做半导体设备，物料品类多。编码体系早就有了，规范写在几张表里：前缀对应哪类物料，这一类允许哪些写法，每段几位。新增物料、维护主数据，都得人对着这几张表一条条核。一条编码要查五处：类别、写法、位数、分隔符，还有和别的编码有没有重复。
品类越多，规范越长，翻得越慢，看久了会漏判、错判。漏过去的错码会流进 BOM（物料清单）、采购和库存，最后还得回头整改主数据。
规则本身也在变。品类在增加，规则在修改、新增。核对的人跟不上更新，手里拿的常常是旧版。
读规范
先把规范读成带出处的规则
Micius 要用两样东西：企业的编码规范，和每一批待核的编码清单。规范先进知识库，清单在建档时交给它。这家企业的编码分四段，用短横线连接，另有一张类别表，一张类别与材质对照表。
这批是 47 行新增物料清单。工程师的要求是：先读规范、列出规则并注明出处，再逐条核。
它读规范，把规则抽出来：哪个前缀对应哪类物料，每类允许哪些写法，各段几位、怎么分隔。每条规则都标着出处。工程师先让它把规则列一遍：Micius 列出五条，每条后面标着出处：编码结构一节、类别表，或者类别与材质对照表。它还把五个类别各自允许的材质排成一张表；对照表里没写材质的类别，它留空并标出来。
流程示意规范里的规则逐条列出，每条都能回查原文。
工程师对着原文把五条看过一遍，确认读对了，才拿去核编码。有拿不准的前缀，直接问它。Micius 部署在企业内部，规范和物料数据不出企业。
核编码
整批核完，标出错在哪一段
新增物料或主数据变更时，工程师上传编码清单，也可以把编码直接贴进对话。Micius 把每条编码拆成几段，逐段对照规则，再查同一批里有没有重复。
核完先给汇总：合规、不合规、无法判定各多少条，有没有重复。再给明细，写清每条错在哪一段、违反了哪条规则。规范里找不到依据的，只标“无法判定”，留给人看。
那批 47 条编码，结果是 41 条合规，5 条不合规，1 条无法判定。五条不合规都标出了出错的那一段：两条材质不在该类别允许的范围内，一条规格少一位，一条缺分隔符，一条流水号与前面重复。第 36 行的类别在类别表里有，但对照表没写这类允许哪些材质，Micius 把它标为“无法判定”，交给人。
看明细时，工程师可以让它逐段解释某一条：每段对照哪条规则，出处在哪。拿第 07 行来说，类别、规格、流水号都没问题，材质却不在真空件这一类允许的范围里。Micius 建议先确认这件物料到底归哪一类，再定改哪一段。它还给这一批的 5 条不合规排出整改顺序，结构错误排在前面，因为编码拆不开，后面几段都没法核。清单里已经有人工结论的，它逐行比对，标出不一致的地方。
流程示意逐段说明第 07 行为什么错，再排出整改顺序。
一条编码该归哪类、该怎么改，要看这件物料到底是什么，这个判断留给工程师。它的判定也会出错，所以每条都附出处，可以逐段展开复核；判得不对，顺着出处就能找到原因。
结果
从翻规范，变成看汇总
交给 Micius 以后，物料主数据工程师可以先看汇总和明细，精力放在不合规和无法判定的那几条上。按知满的估算，物料主数据工程师的事务性工作可以减少 55% 以上。
知满给出的校验准确率在 98% 以上。编码规范还会继续改。规则修改或新增之后，只要规范文件跟着更新，核对用的就是现行规则。这一步不需要为此做大量开发。
下一步，双方计划把校验挪到 PLM 和 ERP 的建档环节。PLM（产品生命周期系统）和 ERP（企业资源计划系统）里，新编码一提交就先过一遍校验，不合规的在进入 BOM、采购和库存之前就拦下。
留给人的，是只有人能定的两件事：这件物料到底归哪一类，规范里哪一块还没写到、该怎么补。
这套做法也适用于
-
供应商编码与主数据
供应商建档时，按企业规范核对编码和必填信息，指出缺漏、写法不一致的地方，交给采购或主数据工程师确认。
-
图号与文件编号
图纸和工艺文件归档前，按编号规则逐段核对图号、文件号，标出不合规的那一段，说明依据哪条规则。
-
BOM 发放前的编码核对
BOM 发放前，逐行核对引用的物料编码是否合规、是否已停用，把有问题的行和原因列给工程师。
-
零部件与封测企业
物料品类多、编码规范常调整的零部件和封测企业，同样可以先让 Micius 读懂规范，再整批核对。
