最近 Jev 这种专门做结构化判断的模型引起了不少关注。它不生成文本只返回类型化的判断结果毫秒级输出还不收费。这种决策模型让我想起之前做过的一个项目建筑构件的标准化匹配与业务挂接。这个项目背后其实藏着一个跨行业的共同问题。在制造业企业需要把不同来源的物料映射到统一的标准体系在金融领域系统需要识别不同业务口径下的数据与风险信号在医药领域药品、疾病和临床术语需要建立准确的对应关系在财会领域不同系统的科目、凭证和业务数据需要按照统一口径归集在法律领域合同条款、法规要求与具体业务场景之间也需要建立可靠的关联。这些场景看起来差异很大但都面临着一个相似的挑战如何把不同来源、不同表达方式、不同业务口径的信息转化为能够被系统准确识别和处理的标准化对象再据此完成判断与业务操作这正是我在建筑构件项目中遇到的问题。当时我们需要从不同来源的 BIM 模型里识别建筑构件把它们的属性匹配成标准构件再根据匹配结果关联成本清单、施工工序这些业务逻辑。做法不复杂读取构件属性根据预置的判断条件命中后挂接标准构件和业务规则。条件明确的时候整个过程由程序确定性完成结果稳定也方便追溯。从技术实现看这套方案没什么大问题。真正让项目难以规模化的不是最后这一步。不同设计院有各自的设计标准不同业态的项目用不同的建模软件。要让一套匹配机制适用于更多项目得先梳理各家标准建立统一的构件分类和属性体系再逐一搞清楚各种来源的构件怎么映射到标准构件。这活高度依赖专业人员耗时而且很难一次做完。更麻烦的是匹配还依赖设计阶段有没有录入足够准确的属性。源头信息不完整后面就没有可靠依据。回头看这个项目的瓶颈从来就不是怎么判断两个构件匹不匹配而是怎么以可承受的成本建立并持续维护一套能支撑匹配的标准体系。我之前写过一篇说 AI 真正缺的不是企业知识而是企业的业务模型。构件标准化大概就是那个业务模型最具体、最硬的一个样子不是文档不是图谱是一整套这个对象算什么、按什么算、谁来确认的判断结构。这篇文章想说的就是这件事——语义层、判断机制和规则引擎能不能结合起来改变业务标准化的实施方式以及 Jev 这类模型在里面扮演什么角色。一、匹配之前还有一项更难的工作传统软件系统里业务匹配是一套确定性流程先定义匹配条件再读取数据、执行判断、输出结果。条件明确、数据规范的时候这套机制稳定、可验证也方便批量处理。问题是真实业务的数据并不总是按预先定义的标准产生的。想把一套匹配机制推广到更多项目、更多系统首先要解决的不是多写判断条件而是这些条件依赖的标准从哪里来。这就把问题分成了两层。第一层是标准建设。定义什么是标准构件它的业务含义、分类方式、必要属性和适用范围。这不是整理一张清单就完事的。分类过粗撑不住精确的算量和施工规则过细标准维护和模型映射的成本又会上去。标准化不只定义对象还要定义对象之间的关系以及它们在不同业务里的适用条件。第二层是标准应用。把来自不同系统、不同项目的数据映射到统一标准再依据业务规则完成后续处理。这个过程并不总是确定的。有的构件信息完整直接匹配有的缺关键属性得从别的信息里找证据有的同时符合多个候选必须进一步判断甚至交给设计师确认。两层互相依赖。没有标准体系匹配没有可靠的目标没有有效的匹配机制标准体系也没法低成本地用到大量现实模型上。传统方法往往把精力花在第二层的规则编写和执行上第一层反倒容易被忽视。可规则只能执行已经明确的判断逻辑保证不了标准本身完整合理。标准建设要是高度依赖人工业务匹配的规模化就免谈。于是出现了一个很别扭的局面匹配执行已经自动化了前面的标准化工作还是纯人工。这事其实有个著名的先例。Palantir 的 Ontology 之所以存在就是因为前线部署工程师在每个客户现场做的方案不抽象成通用业务本体换个客户就带不走。而这两年我从三个互不相干的方向听到了同一句话的不同版本。做业务 Agent 的团队说AI 听得懂人话不是模型能力问题是知识库结构化程度问题。做数据治理的人说AI 看不懂数据的根因不在模型在元数据。我在工地上遇到的版本是构件匹配不准问题不在匹配算法在标准体系没建起来。三个域同一堵墙。这不是哪个行业的特殊麻烦是企业数字化的普遍瓶颈。二、制造业物料标准化为什么有了编码问题还在制造业有个更容易理解的例子。一家企业的研发、采购、生产、仓储系统各自沿用不同的分类和编码规则企业想建统一的物料主数据。这看起来像数据清洗实际比名称去重复杂得多。国家标准 GB/T 45309—2025《企业采购物资分类编码指南》把采购物资分类编码列为一项专门的标准化工作因为企业需要的不是一张编码表是一套能统一描述和识别物料的标准体系。拿螺栓来说。两条记录名称不同可能实际是同一种规格名称几乎一样又可能因为公称直径、长度、螺纹规格、材料、强度等级或表面处理不同必须归入不同的标准物料。光凭名称相似度没法可靠判断。企业得先定义螺栓的分类方式和必要属性搞清楚哪些属性决定物料之间的区别然后才能把历史记录映射到标准类别。某条记录缺了关键规格或者设计、采购环节没录入必要信息后面任何系统都没法凭空恢复这些事实。ISO 8000-100 讲主数据质量说的也是同一件事编码统一了属性不准确、不完整业务照样跑不起来。所以物料标准化至少包括三件互相依赖的持续性工作。建立标准体系也就是分类、编码规则、属性模板、业务约束。把历史数据映射到标准包括识别重复、处理分类差异、审核歧义记录。持续维护处理新物料、规格变更、属性缺失和例外。没有标准映射缺依据没有源头属性映射做不可靠没有持续维护标准又会慢慢脱离真实业务。真正贵的往往不是执行一次匹配而是建一套能长期稳定完成匹配的标准体系。这就是 AI 有机会插上手的地方。三、Jev 式判断机制能改变什么Jev 是这条路线上最有代表性的一个。它基于 Transformer但刻意不做成通用大语言模型不输出完整句子只返回强类型的判断结果。三种输出形态Choice从预定义候选列表里选一上限 255 项Score在划定的尺度上打分Noul是非判断返回为真的概率。每次回答都带完整的概率分布和置信度。端到端延迟 70 到 500 毫秒输出不收费。把三种形态放进业务匹配几乎是一一对位的。这个来源构件最可能对应哪个标准构件——Choice候选集就是标准构件库的一个子集。这两条物料记录是不是同一个标准物料——Noul返回概率用不用由业务阈值决定。几个候选哪个更可信这条记录缺的属性对分类影响多大——Score。越想越觉得这层关系比表面上深。对 Jev 式模型来说标准体系直接构成了模型的输出空间。没有标准构件库就没有 Choice 的候选集没有属性定义Noul 就没有判断依据。所以这类模型没有降低对标准化的要求反而是标准定义得越清楚判断接口就越好用。先结构化问题再让模型在结构里作答是这类模型的共同前提。官方的使用建议也是这个意思把复杂判断拆成几个明确的问题由代码来组合别一股脑丢给模型。还有两个特性决定了它的用法。一个是成本结构。毫秒级延迟加免费输出意味着判断可以插进流水线里批量地、反复地跑。Jev 这个名字就取自杰文斯悖论智力判断的成本降下来之后它会被用到大量原本不值得动用的地方。逐个构件判断这个缺失属性能不能推断以前只能抽样做或者干脆不做成本降下来就可以持续做。另一个是边界清楚。模型不会跳出预设选项乱答但选项范围内答错照样会发生这一点在宣传里经常被含糊过去。所以它天生要跟审核机制配合置信度过阈值走自动通道不过阈值转人工附上候选和依据。不过这条路上有几个边界得说准不然很容易变成新的迷信。第一选项空间要有人生成。Choice 的选项是预先枚举的而且有上限。标准构件动辄上千个不可能全塞进去得先用检索、几何相似度、空间关系把候选压到几十个再交给判断模型。选项从哪来是个工程问题模型不解决它。第二专门调校和跨场景泛化是取舍。这类模型针对具体任务调校每上一个新场景可能都要重训跟大模型的 zero-shot 泛化是两条路。换来的是速度和成本判断一次高到几分钱、低到几厘钱的量级。第三阈值是责任划分不是技术参数。模型给的是校准概率用不用、怎么用业务定。50% 或许可以忽略95% 就可以利用。但涉及结构安全的属性阈值定多高、谁来定、定完谁负责这是组织问题别写进配置文件就算完。除了执行判断判断机制还有一件事更能干发现标准的缺口。大量构件匹配失败的时候系统不该只回一句匹配失败应该把失败原因归纳成结构化的几类——缺属性、标准定义不完整、现有分类覆盖不了、证据互相冲突、必须人来确认。这样原本要人工逐项排查的事就变成了可以聚类、可以排优先级的事。一个设计院接入之后最有价值的产出可能不是匹配率是这份缺口清单。它直接告诉你标准体系该往哪补。当然判断模型不会天然知道一套标准该怎么建。它能帮着整理资料、比较差异、提候选方案但标准合不合理、关键属性够不够还是得靠专业知识和验证机制。所以值得试的不是拿模型替代规则是把判断机制嵌进标准建设和应用的全过程。四、语义层、判断机制、规则引擎从架构上看这里需要三种能力。语义层定义业务对象是什么分类、属性、关系、约束还有定义来自什么标准、适用什么范围。判断机制处理不同来源之间的语义差异提候选映射识别冲突和不确定性说明判断依据。规则引擎执行明确且验证过的业务逻辑稳定、可重复没必要每次让模型重新判断一遍。语义层别选一个分类粒度做一个对象核加几个投影语义层最难的还是第一节说的粒度问题。粗了不能用细了养不起不同业务想要的粒度还不一样。我现在的看法是这个问题无解是因为问法错了。别问标准构件应该分多细问哪个粒度是稳定的。答案是拿业务上可辨识的最小稳定单元做对象核其他粒度都是投影。┌── 设计管理投影关注构造做法、审批状态 │ 构件对象核 ─────────┼── 算量投影聚合到计量项关注几何材质厚度 稳定身份、别名、 │ 属性、关系、状态 ├── 采购投影拆到 SKU关注品牌、规格、供货周期 │ └── 施工投影聚合到施工段关注工艺、工序、验收对象核存最细的那一层因为它最稳定。一面墙就是一面墙不会因为换了个业务场景就不是墙了。粗粒度不另立一套分类是投影里的一条聚合映射要更细也是投影里的拆分映射。这么做有三个直接好处。一是粒度争论消失了。算量要粗、采购要细过去这是要吵架的现在是两个投影各自的映射规则。二是缺什么属性变成了投影相关的问题。同一份模型对算量投影够用对采购投影缺品牌和规格。这不是数据质量问题是需求声明问题而需求声明是可以写下来的。三是属性可信度能被单独管理。每个属性值带上来源和信任等级模型直读的、设计师录入的、系统推断的、人工确认过的。投影声明自己的最低信任线涉及工程计算和安全约束的属性只许消费确认过的等级推断值不够格。这里要给自己泼盆冷水。本体边界还没稳的时候别急着立完整分类树。我自己踩过的坑是图建起来了半年没人维护概念边界一直在变最后没人敢信它。腐烂的图比没有图更糟因为它还带着一副权威的样子。现实的起步方式是弱结构先把别名、标签、引用关系连起来让系统能定位对象、能顺着边走等接入三五个项目、构件聚类稳定了再把分类固化下来。先能跑再好看。一次螺栓匹配走完三层假设企业 ERP 里有两条历史螺栓记录。记录 A六角螺栓 M10×50 8.8级 镀锌记录 B六角头螺栓 M10*50 Zn 达克罗 88语义层里螺栓标准物料模板定义了八个必要属性头型、公称直径、长度、螺纹规格、材料、强度等级、表面处理、产品等级还明确了哪些属性决定物料之间的区别——直径、强度等级、表面处理任何一项不同就是不同的标准物料。匹配会走出三条路。路径一规则引擎直接命中。A 和 B 都能解析出直径 10、长度 50、头型六角、强度 8.888经别名规则映射成 8.8。别名表里如果已经收了Zn → 镀锌两条记录全部属性对齐规则引擎确定性判归同一个标准物料。这一步不需要模型也不该用模型更不用为了显得智能多加一次调用。路径二有歧义交给判断机制。B 的表面处理写着达克罗别名表里没这条。系统先用检索和属性相似度把候选压小这就是第三节说的选项空间要有人生成再调 Choice 在镀锌、锌铝涂层、锌铬涂层三个候选里挑同时调 Noul 问A 和 B 是不是同一个标准物料返回为真概率 0.62低于业务定的 0.95 阈值。系统不自动归并转人工审核附上判断依据达克罗是锌铬涂层属于涂覆工艺不是电镀锌跟镀锌不是同一种表面处理。专业人员确认后B 归入锌铬涂层类物料。路径三关键属性缺失报缺口别猜。假设 B 压根没写强度等级。这时候名称再像也不能归并进 8.8 级8.8 级和 10.9 级是两个不同的标准物料用错了有装配风险。系统该输出一个明确的信息缺口缺必要属性强度等级影响采购投影的 SKU 判定建议查采购合同或图号 XXXX由业务人员补充。而不是凭名称猜一个。反馈沉淀。专业人员确认达克罗 锌铬涂层之后这条映射写回别名表。下次再遇到达克罗规则引擎直接命中不再动用模型。判断机制处理头一回见的新词规则引擎处理确认过的旧词确认过的判断一点点变成确定性规则。沉淀的方式存碎片不存规则包沉淀这一步要是存储方式搞错了前面省下的成本会换个形式还回来。最常见的错法是按来源打包给每家设计院做一套规则包。三个问题马上出现。数量爆炸还互相干扰一个构件同时命中两三家来源的规则是常态判断会打架。维护成本线性上涨同一条属性约束变了所有含它的规则包都得改一遍。执行期约束失效自然语言描述的判断边界不清证据不足的时候容易接着往下推。最后就是你抱怨每接入一家设计院就要重梳理一遍然后给每家发了一套规则包这个问题换了个位置复现。换个存法。存碎片不存包。我看至少要四类。属性约束碎片某属性在某业态某来源下的取值域以及它对区分哪些标准构件有判别力。决策路由什么证据下判成什么。拒绝路由哪条路看起来对、实际走不通还有为什么——这类最容易被省掉但它恰恰是专家经验里最值钱的部分专家的价值常常就体现在知道什么不能做。黄金案例带完整证据、确认人、标准版本号的真实案例用来回归验证后面的修订会不会弄坏原来的判断。每条碎片带三样东西适用范围标签业态、来源体系、软件版本、生效版本号、出处哪个项目、哪次确认。执行的时候按当前任务当场组装来源体系 X、业态 Y、投影 Z筛出适用碎片跑判定。这样接入一家新设计院就不是写一套新规则包是复用已有碎片只补差异碎片。一条规则修订只改一处所有组合自动生效。这才是真正把标准化成本降下来的机制。还有一道闸门不能省。模型的产物一律是提案不直接进库。写回流程应该是触发人工修正了一次匹配、一批构件失败聚类、新来源接入取证读现有本体和适用碎片生成提案标明是新增、修订还是冲突机器校验语法、跟既有碎片的冲突检测、在黄金案例和历史模型上跑覆盖率和误匹配率业务 Owner 评审入库带版本号。两个地方容易走样。一个是评审的人规则的业务正确性必须由业务 Owner 确认不能软件团队代劳——数据治理领域有个说法我很认同治理是 30% 技术加 70% 组织。另一个是最后一步之后还有一步谁在什么证据下批准了这条规则本身也要记成一条决策记录。不然三个月后审计一次匹配你只看得到当前版本的规则看不到当时用的是哪一版。判停条件什么时候必须停下来等人还有件事得显式写出来。证据槽填不满的时候停。两条路由都命中、置信度又接近的时候停。命中已知拒绝路由的时候停。关键属性信任等级不够的时候停。这些都必须是明确条件不能靠模型觉得可以。我见过太多自动化流程最后卡住的不是能力不够是没人定义过什么情况该停。一个不会停的系统比一个偶尔要人介入的系统危险得多。判断依据要记下来事前约束和事后审计是两件事判断机制解决的是怎么作判断记录解决的是判断事后怎么被解释。这两件事经常被混在一起但失败模式完全不同。事前约束失效你会得到一个错误的匹配事后审计失效你会得到一个没法解释的正确匹配。在受监管的场景里第二种一样不能接受。开源项目 Semantica 给后一件事提供了一个我觉得对的立场决策是节点依据是边每条边带时间戳和权重解释的时候不生成只遍历。按这个立场一次构件匹配除了记下用了哪版标准定义、哪些证据支持匹配、哪些候选被排除以及为什么至少还要加三条。结论的证明范围。这个匹配是在住宅业态、这家设计院的建模深度下成立还是普遍成立两者差别巨大但系统里通常都不写于是下游拿着一个局部结论当通用结论用。推断链里最薄弱的一环。一个属性值要是靠三跳推断出来的每跳都有自己的置信度整条链的置信度是逐跳相乘的。记录里要能指出最低的那一跳审计的人应该能指着某一跳说问题出在这儿而不是面对一个笼统的可信度 0.6。决策发生的时间点。三月做的匹配依据的是三月掌握的情况。六月设计师补录了属性图更新了。九月你去审计三月的决策要是直接在当前状态上回溯就会拿六月的信息解释三月的行为。这不叫解释叫污染。所以要能按时间点回溯只走那个时刻之前已经记录的边。走到这一步语义层就不只是个存知识的结构了它成了把标准定义、判断执行和持续改进连起来的那层东西。这不是给现有系统简单加一个大模型是把业务知识、判断能力和确定性执行之间的关系重新搭了一遍。五、让标准化从一次性项目变成持续运行的过程标准化不该只是一次性的数据治理项目。建筑领域新项目不断设计标准和建模习惯在变制造业新物料持续产生供应商规格在调采购和生产要求在演进。每来一个新情况都要专业人员从头分析、重写规则系统就规模化不了。上一节其实已经勾勒出循环了。系统分析新业务数据找出无法映射、属性缺失或者存在冲突的对象。判断机制基于已有标准和证据提出候选映射或者规则修订建议。专业人员审核关键结果确认有证据的判断拒绝没证据的。确认结果以碎片形式沉淀后续业务里复用。新问题被发现进入下一轮。这个循环里属性缺失是最常见的一类值得单说。系统要先判断缺的信息能不能靠已有证据补上——结合几何信息、空间位置、材料、相邻构件和设计文档提出候选值——然后分三种情况。能靠可靠证据推断的推断值要标成推断信任等级低于人工确认值安全相关的计算不许消费它。需要设计师补录的明确指出缺哪个字段、影响什么判断别简单返回匹配失败。这里还有个附带的好处能反过来改善上游建模质量设计师长期不知道自己少填的那个属性会导致什么后果现在系统可以告诉他。现有信息不足以确定的进缺口清单等标准或者数据补齐。这套机制不是要让 AI 定标准是让标准的建设和维护不再完全靠人工逐条梳理。说穿了就是个飞轮业务使用暴露知识缺口缺口被补充、修正、验证、发布系统变得更好用产生业务价值带来更多使用。项目可以验收知识不能验收它只会过期。标准体系也一样它不是交付物是一项持续运行的业务能力。飞轮转不转得起来就看有没有反馈回流那一环。没有它系统永远停在第一次尝试的水平。六、跨行业可复用的是机制顺序不能反建筑构件和制造物料分属不同领域问题结构却像得出奇。都是先定义统一的业务对象把不同来源的数据映射到标准对象依据属性和约束完成判断最后把结果关联到规则和流程。供应链也一样要判断不同供应商的产品是不是对应同一种标准商品、满不满足替代条件名称和型号只是线索真正的判断得看规格、认证和采购约束。设备维护也一样统一设备台账的分类把故障记录、维修方案和备件关联到同一台设备或者同一类问题。合同与合规还是一样把不同文本里的条款映射到统一分类再关联审查要求模型可以帮着识别条款含义但适用范围和合规结论仍然要明确的规则和审核。我之前写过一篇说做了这么多企业知识库我越来越不相信知识中台。知识属于业务不属于平台。客服的知识、研发的知识、法务的知识不只是内容不同连什么算一条正确的知识答案都不一样。真正值得平台化的是知识建设的能力不是知识本身。这个立场在这里同样成立。我不认为存在一套跨行业的标准构件体系存在的是相同的五个环节建立业务对象和标准定义把现实数据映射到标准对象根据语义、证据和规则作判断把确认后的对象关联到业务规则用执行结果和人工反馈不断修正标准。具体知识完全不同五个环节的形状是一样的。但顺序必须是先业务后平台先建设后抽象。先在建筑构件这一个场景把机制跑通、方法稳定下来再谈第二个行业。没有哪个成熟的基础设施是一开始就把所有可能场景设计完的可复用的平台能力几乎都是从某一个具体业务里长出来的。要验证这条路线我会选制造业物料标准化当第二个场景它和建筑构件在对象识别、标准映射、属性约束、业务挂接上的结构相似性最强。不过得说清楚这一节现在是假设不是结论。我手上没有制造业的一手材料上面的类比是推出来的不是跑出来的。验证方法倒是可以照抄一个现成的。淘天商家财务团队把业务知识建模成图谱把专家判断固化成可执行的判定程序他们押这一层而不是押模型层的依据是同一套知识和决策函数在几个不同的 agent 平台、几个不同的大模型上跑过真实需求平台和模型全换了一遍输出稳定性没变。我的对应实验是同一套机制换到制造业物料上跑一个真实项目只替换领域语义、标准定义和业务规则。稳定性要还是不变可复用的是机制才算被证明而不只是被断言。七、未来的竞争力可能在于降低标准化的成本回头看构件标准化的问题很具体但它指向一个普遍瓶颈。很多企业已经有大量业务数据也部署了规则引擎和各种自动化系统却仍然需要大量人工去梳理标准、确认对象、维护映射关系、处理例外。真正难的是这个怎么把分散在专业人员经验里的标准化知识变成可以表达、可以执行、可以验证、可以持续改进的系统能力。这句话在业务域、数据域、工程域都成立。我在构件上撞到的和做业务 Agent 的人、做数据治理的人撞到的是同一堵墙只是各自的说法不同。几种能力各管一段。传统规则引擎擅长执行明确的条件但建立这些条件本身往往很贵。大模型能帮着理解复杂材料、比较不同定义、提出候选规则但替代不了业务标准的确认。判断模型能把单个决策变得可校准、可设阈值但它不解决选项从哪来也不解决谁为阈值负责。语义层提供统一的业务表达决策记录让判断可追溯反馈回流让标准自己长大。这几样凑齐了业务标准化的成本结构才有可能被改变。AI 时代业务匹配真正值得自动化的不只是最后那一步匹配而是从建立标准、补全信息、形成规则到验证结果的整个过程。这条路线要是成立最后建出来的就不只是一个建筑构件匹配工具而是一套能在不同产业里复用的标准化与判断能力。它不要求所有行业共享同一套知识而是让不同领域用自己的标准和规则建在同一个技术内核上。只是这个内核大概不会是先设计出来的。它得从第一个场景里长出来。如果你对AI相关的资讯、落地实践感兴趣欢迎关注我们我们会持续输出AI相关的高质量内容。
