Jev 们不缺判断力，缺的是你的标准 - AI闲人

最近 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.8（"88"经别名规则映射成 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相关的高质量内容。你也可以GitHub找到zhuzhaoyun/Molio，star一下随时了解我们的实践之路。