摘要

随着企业数字化建设持续深入，企业架构管理对象已经从相对稳定的业务流程、应用系统、数据实体和技术组件，扩展到模型服务、智能体、知识库、向量数据、推理端点和模型训练流水线等新型架构资产。架构制品的数量、类型和关联关系快速增加，传统依赖人工阅读、经验判断和会议会审的评审方式，逐渐暴露出效率不高、标准执行不一致、跨域关系难以核验以及问题发现滞后等不足。尤其是在大型企业中，一项架构变更往往同时影响业务、应用、数据、技术和安全等多个架构域，仅检查单份表格是否填写完整，已经难以识别跨制品冲突、概念混用和潜在影响。

本文提出一种基于企业架构本体的智能评审方法。该方法首先建立覆盖业务架构、应用架构、数据架构、技术架构和安全架构的统一元模型，将分散在图表、清单和说明文档中的架构元素转化为具有明确语义的实体、属性和关系；其次，将管理制度、设计原则和评审经验拆解为可维护的规则体系；在此基础上，构建由规则引擎层、语义理解层和智能推理层组成的智能评审模型，分别承担结构化校验、自然语言理解和跨域关系推理任务。模型输出通过项、警告项、不通过项、问题依据和修复建议，并将人工复核结果反馈至术语库、规则库和案例库，形成持续优化闭环。

本文重点讨论方法框架和实施路径，不将大模型视为替代架构师的自动决策者，而是将其定位为受规则约束、过程可追溯、结论可复核的辅助工具。该方法有助于提高评审效率和标准一致性，也为架构资产的持续治理、影响分析和知识复用提供基础。

关键词：企业架构；本体；架构制品；智能评审；规则引擎；语义理解；知识图谱

一、 企业架构评审面临的新问题

（一 ）架构管理对象正在快速扩展

传统企业架构主要围绕业务、应用、数据和技术四个方面展开。业务架构描述战略目标、业务能力、价值流、业务流程、组织和角色；应用架构描述应用模块、功能项、应用服务、接口和集成关系；数据架构描述数据域、数据主题、概念实体、逻辑实体、物理实体和数据标准；技术架构描述技术分类、技术组件、技术服务、技术平台和部署节点。对于安全要求较高的企业，还需要将安全域、安全组件、安全服务、安全控制和合规要求纳入整体架构。

人工智能进入企业级应用后，架构管理对象进一步增加。模型不再只是应用系统内部的一段算法，而可能以独立服务的方式被多个应用调用；智能体也不只是一个页面功能，而是具有感知数据源、任务目标、工具权限、协作关系和执行动作范围的运行主体。与此同时，训练数据集、验证数据集、非结构化文档、向量集合、知识图谱、提示模板、模型推理端点和模型训练流水线逐步成为需要登记、评估和持续维护的架构资产。

如果仍然沿用“一个项目提交若干表格、架构师逐份查看”的方式，评审人员很容易只看到局部信息。例如，应用清单中登记了一个智能问答功能，但模型服务目录没有相应记录；数据架构中新增了向量集合，却没有说明其来源数据、更新周期和访问权限；技术架构中部署了推理服务，却没有关联具体业务能力和应用模块。这些问题通常不是单张表格中的明显错误，而是多个制品之间关系不完整或语义不一致造成的。

（二） 传统人工评审存在四类局限

第一，评审标准难以稳定执行。同一项要求在制度文件中可能使用原则性语言，在模板说明中可能表现为字段要求，在评审会议中又可能转化为经验判断。不同评审人员对规则的理解存在差异，容易出现相同问题采用不同尺度、同类项目得到不同结论的情况。

第二，跨域关系核验成本较高。业务能力、应用功能、数据实体和技术组件分别记录在不同制品中，人工需要不断在清单、图形和文字说明之间切换。制品数量较多时，确认“业务需求是否被应用功能承接”“功能是否使用了已登记的数据实体”“应用是否部署在合规技术环境”等关系，需要大量重复比对。

第三，文本类问题不易通过传统程序识别。必填字段、数据类型和枚举值可以通过简单程序检查，但概念使用是否准确、功能描述是否过于宽泛、同一术语是否具有多种含义，往往隐藏在自然语言中。单纯依靠固定关键词既容易漏报，也容易将正常表述误判为问题。

第四，评审知识没有形成可积累资产。许多有价值的判断依据保存在专家个人经验、会议纪要和历史意见中。项目结束后，这些知识未必转化为新的规则，导致相同问题重复出现。新架构师也难以快速掌握评审尺度，组织对少数专家的依赖长期存在。

因此，智能评审建设的核心并不是把纸面评审搬到线上，也不是让大模型直接给出“通过或不通过”的答案，而是建立一套可表达架构语义、可执行管理规则、可追溯判断过程的评审基础。

二、总体思路与建设原则

（一）从文档检查转向架构知识校验

智能评审的对象表面上是架构制品，实质上是制品所承载的架构事实。应用模块清单中的一行数据，代表一个应用模块及其属性；数据实体清单中的一行数据，代表一个数据对象及其所属数据域；应用集成图中的一条连线，代表两个应用之间的调用或数据交换关系。只有将这些内容还原为实体、属性和关系，系统才能理解不同制品是否在描述同一个对象，也才能判断多份制品之间是否相互支持。

基于这一认识，本文将总体方法概括为“统一语义、结构化表达、分层评审、人机协同、闭环演进”。统一语义是通过元模型、本体和术语库明确每个概念的含义；结构化表达是把图表和文本中的架构信息转化为机器可处理的数据；分层评审是按照问题性质调用规则、语义或推理能力；人机协同是将高风险和低置信度问题交由架构师确认；闭环演进是把复核结论沉淀为规则和案例，使模型随实际使用持续改进。

（二）建设原则

一是标准先行。智能评审不能建立在口径不清的规则之上。应先统一模板、字段、术语、关系和评审尺度，再开展自动化建设。对于仍存在争议的管理要求，应保留人工评审，不宜过早固化为阻断规则。

二是确定性能力优先。字段是否为空、值域是否合法、编号是否重复、关系是否存在等问题，适合交由规则引擎处理。能够用确定性逻辑解决的问题，不应全部交给大模型，以避免结果波动并降低运行成本。

三是语义能力受控。大模型适合处理术语对齐、描述完整性、相似问题检索和修复建议生成，但其输出必须受到术语库、规则库、知识图谱和提示模板约束，并保留引用依据、置信度和版本信息。

四是结论可解释。每项问题都应能够回答“检查了什么、违反了哪条标准、涉及哪些架构对象、为何形成该等级、建议如何修复”。不能只输出一个分数或笼统结论。

五是人工保留最终责任。智能评审的定位是提高发现问题和准备证据的效率，不能替代授权架构师完成重大事项审批。对于跨域影响大、规则冲突明显或模型置信度不足的情况，应自动转入人工复核。

（三） 建设范围与能力边界

智能评审的建设范围应覆盖“标准、数据、知识、模型、流程、运营”六个方面。标准层明确制品模板、字段口径、术语定义、关系类型和评审要求；数据层负责制品接入、解析、清洗、版本管理和质量控制；知识层承载企业架构本体、知识图谱、规则依据和历史案例；模型层提供规则执行、语义识别和关系推理能力；流程层连接提交、评审、复核、整改和发布；运营层持续分析规则有效性、模型准确性和问题变化趋势。六个方面缺一不可，不能仅建设一个大模型问答入口就视为完成智能评审。

能力边界也需要在建设初期明确。系统可以自动确认字段缺失、取值越界、编码重复和关系断裂等确定性问题，可以对术语不统一、描述不完整和概念粒度异常等情况提出判断建议，也可以基于图谱关系识别跨域冲突和影响范围。但涉及战略优先级、投资合理性、组织权责调整以及多种可行方案之间的取舍，仍需由架构师和业务负责人结合实际情况决策。

为了使能力能够逐步扩展，应为每类评审任务设置清晰的输入和输出。输入不仅包括待评审文件，还包括适用的项目阶段、制品版本、评审范围、架构基线、规则版本和本体版本；输出不仅包括问题结论，还包括证据位置、判断依据、影响对象、置信度、修复建议和复核状态。统一任务口径后，不同技术组件才能在同一流程中协同工作。

图1  企业架构智能评审总体方法框架

三 、企业架构本体的构建

（一）本体与企业架构元模型的关系

元模型规定企业架构中“可以有哪些元素，以及元素之间可以建立哪些关系”。例如，业务能力由应用模块支撑，应用模块包含功能项，功能项使用数据实体，应用模块部署于技术节点。元模型为架构设计提供结构骨架，但在实际管理中，仅有元素类型还不够，还需要统一概念定义、同义词、约束条件和推理关系。

本体是在元模型基础上的语义扩展。它不仅描述类、属性和关系，还可以表达概念层级、等价关系、互斥关系、属性限制和逻辑公理，使系统能够判断不同名称是否指向同一概念，并依据既有事实推导出新的关系。W3C对OWL 2的说明将本体概括为面向特定领域、由共同用户群体共享的形式化词汇体系，术语的含义通过其与其他术语的关系得到界定。对于企业架构而言，本体可以看作连接制度语言、架构语言和系统数据的语义中间层。[2]

（二）本体的核心概念设计

企业架构本体可以按照五个架构域组织核心类。

业务域包括战略目标、业务能力、价值流、业务流程、业务活动、业务对象、组织和角色。应用域包括应用系统、应用模块、功能项、应用服务、接口、集成关系、模型服务和智能体。数据域包括数据域、数据主题、概念实体、逻辑实体、物理实体、数据属性、数据标准、数据源、非结构化数据集、向量集合、知识图谱和样本集。技术域包括技术分类、技术组件、技术能力、技术服务、技术平台、部署节点、算力资源、推理端点和模型训练流水线。安全域包括安全区域、安全角色、安全控制措施、安全策略、安全标准和合规要求。

在核心类之外，还应定义能够支持治理的通用属性，包括唯一标识、名称、定义、责任部门、负责人、生命周期状态、版本、生效时间、失效时间、保密等级和来源制品等。对于模型服务和智能体，还应增加模型类型、服务等级、输入输出、调用范围、工具权限、数据来源、部署形态、运行状态和可观测性要求。

图2  企业架构本体的领域与关系结构

（三）关系设计与图数据表达

本体价值主要体现在关系上。关系设计至少包括层级关系、组成关系、支撑关系、使用关系、产生关系、部署关系、约束关系和依赖关系。例如，“客户服务能力由营销应用模块支撑”“营销应用模块包含客户查询功能项”“客户查询功能项使用客户概念实体”“营销应用模块部署于企业云节点”“安全策略约束客户数据实体”。

RDF将信息表达为主语、谓语和宾语组成的三元组，多条三元组共同形成图结构。[1] 采用这种表达方式后，一个架构事实可写为“应用模块A—支撑—业务能力B”，另一个事实可写为“功能项C—属于—应用模块A”。系统既可以沿关系向下查找能力由哪些功能承接，也可以反向追溯某个功能最终服务于哪些业务目标。

对于跨域评审，应特别关注关系的方向、基数和适用条件。一个已发布应用模块至少应包含一个有效功能项；一个功能项原则上只能有一个直接归属模块，但可以支撑多个业务活动；一个物理实体应能追溯到逻辑实体；一个生产环境中的应用应关联有效部署节点和安全域。关系定义越明确，后续规则越容易转化为可执行逻辑。

（四）语义公理与约束

本体中的逻辑公理用于表达不能仅靠字段值说明的知识。等价类公理可以描述不同架构域或历史系统中语义相同但名称不同的概念，例如“客户主数据”和“客户基础档案”经确认后可建立等价或映射关系。不相交类公理用于声明两个类别不能同时成立，例如“生产环境节点”和“测试环境节点”在同一版本、同一管理口径下不应交叉归属。

属性约束用于限定取值范围和数量。例如，发布状态的应用模块必须具有负责人；生产部署关系必须指向状态有效的部署节点；涉及敏感数据的模型服务必须关联安全控制措施。关系属性还可以设置传递、对称或逆向特征。部署关系的传递性有助于从功能项追溯应用、容器和基础设施形成的部署链路；“支撑”与“被支撑”作为逆关系，可以从应用功能反向追溯其支撑的业务能力。

需要注意，本体推理遵循形式逻辑，其结论取决于前提事实和公理质量。如果源数据不完整，系统可能无法推出应有关系；如果公理设计过强，也可能产生大量冲突。因此，本体设计应从高价值、低争议的核心关系开始，通过试点逐步扩展，不宜一次性追求覆盖所有制度内容。

四、架构制品的结构化处理

（一）建立结构化制品清单

企业首先需要形成统一的架构制品目录，对每类制品记录核心用途、适用阶段、更新频率、责任主体、存储形式、依赖关系和版本关联。业务架构制品可以包括业务能力地图、价值流图、流程图、业务对象清单和组织角色清单；应用架构制品可以包括应用模块清单、功能项清单、应用服务目录、接口清单和应用集成图；数据架构制品可以包括数据实体清单、数据流图、数据标准和数据服务目录；技术与安全架构制品可以包括技术组件清单、部署架构图、安全域划分图和安全控制清单。

制品目录的作用不是增加填报材料，而是明确每类信息应由哪份制品承担，减少重复记录和口径冲突。当同一属性需要在多份制品中出现时，应明确主数据来源和同步关系。例如，应用模块名称以应用模块清单为主，其他制品通过唯一标识关联，不允许各自维护不同名称。

（二）信息抽取与实体对齐

对于表格类制品，可以通过字段映射直接转化为架构实体和属性；对于图形制品，需要识别节点、连线、方向和关系类型；对于文字说明，需要提取对象名称、动作、依赖条件和约束要求。抽取过程应保留来源文件、页码或段落位置，确保问题能够回溯到原始材料。

同一架构对象可能以全称、简称、历史名称或项目内部名称出现，因此需要进行实体对齐。系统可以先通过唯一编码、标准名称和同义词词典完成确定性匹配，再利用语义相似度识别候选项，最终由人工确认是否合并。未经确认的高风险映射不应直接写入正式知识图谱。

（三）图谱存储与查询

结构化结果可按照RDF图或属性图方式存储。采用RDF时，可以利用SPARQL对图中的实体和关系进行查询，例如查找“没有任何应用模块支撑的业务能力”“使用敏感数据但未关联安全控制的模型服务”或“部署节点失效但仍承载生产应用的记录”。SPARQL支持图模式匹配、可选关系、属性路径、聚合和子查询，适合对跨制品关系开展追溯分析。[4]

对于数据质量约束，可以引入SHACL描述节点形状和属性形状。SHACL能够对RDF图执行类、数据类型、数量、取值范围、字符串格式、逻辑组合和关系等方面的验证，并生成结构化验证报告。[3] 这意味着“必填字段检查”“每个应用模块至少包含一个功能项”“字段取值必须属于指定枚举”等规则，可以用统一方式表达和执行。

（四）语义标准化与质量门禁

制品结构化并不只是把文件转换成表格或图数据，更重要的是建立统一的语义标准化规范。针对各类制品的填报场景，应明确字段定义、填报口径、关系描述规则、术语使用标准和允许取值，重点规范容易产生歧义的对象名称、状态含义、版本标识和上下游关系。通过标准模板、填报校验和术语提示，可以从源头减少人工填写的随意性，为后续AI语义识别和信息抽取提供稳定输入。

结构化处理过程可以设置四道质量门禁。第一道是文件门禁，检查文件类型、模板版本、命名和完整性；第二道是字段门禁，检查必填、格式、值域、主键和重复记录；第三道是语义门禁，检查名称映射、概念类型和描述要素；第四道是关系门禁，检查跨制品引用、方向、基数和生命周期状态。只有通过基础门禁的数据才能进入正式知识图谱，存在疑问的数据进入待确认区，避免错误事实直接参与后续推理。

每一次解析和对齐都应生成可追溯记录，包括源文件版本、抽取时间、抽取方式、字段映射规则、实体匹配结果和人工确认状态。当模板或抽取模型升级后，系统可以比较新旧结果，判断差异来自原始制品变化还是处理逻辑变化。这种可追溯机制既服务于问题复核，也为后续改进解析准确率提供样本。

图3  架构制品结构化处理流程

五、智能评审规则体系

（一）规则分类

评审规则应按照检查对象和判断方式分类管理。系统首先扫描架构制品的全部字段和关联关系，从规范性、一致性、合规性三个维度开展基础检查，再结合具体场景判断设计合理性。第一类是规范性规则，主要检查字段完整性、数据类型、编码格式、值域范围、命名规则和版本信息。第二类是一致性规则，主要检查同一对象在不同制品中的名称、状态和属性是否一致，以及关联关系是否相互印证。第三类是合规性规则，主要检查设计是否符合企业标准、安全要求、技术路线和管控流程。第四类是合理性规则，主要结合行业经验和历史案例判断功能拆分、能力复用、组件选型和部署方案是否合理。

从自动化程度看，规范性规则最适合直接执行；一致性规则通常需要跨表或跨图查询；合规性规则可能同时涉及结构化条件和文本要求；合理性规则具有较强场景性，宜由模型提出风险提示，再由架构师确认。规则分类能够防止把所有问题都交给同一种技术处理。

在实际执行中，系统应扫描架构制品的全部字段和关联关系，从规范性、一致性、合规性三个维度开展评审。规范性解决“有没有按要求填写”的问题，一致性解决“不同制品是否在表达同一事实”的问题，合规性解决“设计是否满足制度和技术管控要求”的问题。三个维度既可以分别形成问题，也可以组合判断。例如，接口清单中缺少数据分类属于规范性问题，接口清单与数据流图中的传输方向不同属于一致性问题，敏感数据通过未批准通道传输则属于合规性问题。

（二）规则的标准结构

每条规则应至少包括规则编号、规则名称、适用架构域、适用制品、适用阶段、触发条件、检查逻辑、问题等级、依据来源、修复建议、责任角色、启停状态和版本信息。例如，“应用模块必含功能项”规则的触发对象是状态为已发布的应用模块，检查逻辑是其包含关系数量不得小于一，未满足时形成阻断级问题，修复建议是补充功能项或将模块状态调整为草稿。

将规则写成标准结构后，管理人员可以看到规则的业务含义，开发人员可以据此实现执行逻辑，审计人员也可以追溯规则来源。规则变更应经过提出、评估、测试、审批、发布和回滚等流程，不能由模型自动修改正式规则。

规则应形成完整生命周期。规则提出阶段记录制度依据和业务目标；规则设计阶段明确适用对象、触发条件和例外情形；规则测试阶段使用正确样例、错误样例和边界样例验证结果；规则发布阶段确定生效时间、适用项目和优先级；运行阶段持续记录命中率、确认率和误报情况；规则退出阶段保留历史版本和替代关系。这样可以避免同一要求在不同时间被重复配置，也能在制度调整后准确定位受影响的评审任务。

对于规则冲突，应按照强制性、适用范围、发布时间和对象层级确定优先级。国家和行业强制要求优先于企业建议性规则，特定架构域的专用规则优先于通用提示，新版本规则在生效范围内替代旧版本规则。如果冲突无法自动消解，系统应同时展示两条依据并转交人工确认，而不是任意选择其中一条执行。

（三）问题等级

建议将评审结果分为通过项、警告项和不通过项。通过项表示检查对象满足当前规则；警告项表示存在信息不足、潜在风险或合理性疑问，但不必立即阻断；不通过项表示违反明确的强制要求，需要整改后才能进入下一阶段。每个等级还可以结合影响范围分为一般、重要和重大，以便确定处理时限和审批层级。

等级设置应与规则性质相匹配。标记为必填的字段是否已填写，未填写则触发阻断级错误；术语可能存在歧义但尚未造成关系冲突时，可形成警告；涉及生产安全、敏感数据或强制技术标准的问题，应直接转入重点复核。避免为了追求问题数量而普遍使用高等级，也避免将明确违规事项弱化为一般提示。

六、三层智能评审模型

 （一）总体结构

智能评审模型涵盖规则引擎层、语义理解层和智能推理层三个层次。三层并不是彼此割裂的三个系统，而是面向不同问题类型的能力组合。规则引擎层负责处理确定性强、可直接编码的结构化规则；语义理解层负责识别自然语言中的概念、意图和表述差异；智能推理层负责结合本体关系、规则和上下文开展跨域分析。模型采用分层可扩展架构，各层之间通过标准化接口交互，支持规则库的动态更新和AI模型的持续迭代。

从完整能力描述看，模型构建涵盖规则引擎层、语义理解层和智能推理层三个层次。规则引擎层负责字段必填性、值域合法性、格式规范性和跨制品一致性等结构化规则的自动检查，将评审标准转化为机器可执行的逻辑规则。语义理解层利用AI的语义理解能力，对制品中的术语一致性、概念准确性进行智能识别，通过自然语言处理技术判断制品描述是否与架构核心概念清单保持一致，并进一步分析描述要素是否完整、概念粒度是否合理。智能推理层则结合企业架构本体和跨制品关系，对单一规则无法直接判断的问题进行验证。三层共同形成由确定性检查向语义判断、再向跨域推理逐步递进的能力体系。

在具体执行时，应优先运行成本较低、结论稳定的规则检查。只有当问题涉及文本含义、概念映射或复杂关系时，才调用语义理解和智能推理能力。这样既可以提高效率，也能降低不必要的模型调用和判断波动。

图4 规则、语义与推理协同的三层评审模型

（二）规则引擎层

规则引擎层负责字段必填性、值域合法性、格式规范性和跨制品一致性等结构化规则的自动检查，将评审标准转化为机器可执行的逻辑规则。其输入是经过结构化处理的架构实体、属性、关系和制品元数据，输出是规则命中结果、问题对象和证据位置。

字段级规则包括非空、长度、类型、格式和枚举检查。例如，应用模块必须填写责任部门，接口编号必须符合编码规范，模型服务状态必须属于已登记枚举。对象级规则包括唯一性、完整性和生命周期检查，例如同一版本内应用模块编码不得重复，已停用组件不得作为新项目选型，已发布对象必须具备完整责任信息。

必填性检查应直接对应模板和管理要求。系统逐项判断标记为必填的字段是否已填写，未填写则触发阻断级错误。对于有条件必填的字段，需要同时保存触发条件，例如“部署环境为生产时，安全域和容灾等级必填”“数据分类为敏感时，访问控制措施必填”。系统不仅要指出字段为空，还要说明该字段为何必填、依据哪项规则以及补充后如何重新验证。

关系级规则用于检查跨对象和跨制品一致性。例如，功能项清单中的应用模块编码必须能够在应用模块清单中找到；数据流图涉及的数据实体必须已纳入数据实体目录；部署架构中的应用节点必须与技术组件和运行环境建立关系。对于多条件规则，可以使用规则编排或图查询方式实现。

规则引擎应支持全量评审和增量评审。全量评审适用于基线建立和阶段性检查，增量评审则只分析本次变更对象及其关联范围。对于频繁更新的架构资产，增量方式可以显著减少重复计算，同时便于快速判断一次变更影响了哪些业务能力、应用、数据和技术资源。

（三）语义理解层

语义理解层利用自然语言处理和大模型能力，对制品中的术语一致性、概念准确性、描述完整性和表达歧义进行识别。它重点解决传统规则难以覆盖的文本问题，但不直接替代确定性规则。

术语一致性检查用于判断同一概念是否采用不同名称，或同一名称是否被用于不同概念。系统可以将制品文本与标准术语库、本体定义和历史映射进行比较，给出“标准术语”“疑似同义词”和“需人工确认”三类结果。概念准确性检查用于判断描述是否符合该类对象的定义，例如一个所谓“应用模块”实际只描述了单一操作按钮，可能存在粒度过细问题；一个“功能项”同时包含多个相互独立的业务目标，可能存在粒度过粗问题。

描述完整性检查关注文本是否说明对象、动作、结果和边界。例如，功能描述只有“提供智能分析能力”，没有说明分析对象、输入数据、输出结果和使用角色，系统可以提示补充必要要素。表达歧义检查则识别“及时处理”“高效支撑”“相关系统”等无法直接核验的模糊表述，并建议替换为可验证内容。

语义层输出必须附带证据，包括命中的原文、匹配的标准概念、相似度或置信度、使用的模型版本和提示模板版本。对于重要结论，应采用检索增强方式，把企业术语库、制度条款和优秀案例作为上下文，减少模型脱离企业口径自由生成的风险。

语义判断还应区分“明确不一致”和“疑似不一致”。当制品使用的术语能够映射到标准词，但名称不规范时，可以直接提示替换；当一个名称可能对应多个概念时，应列出候选概念、差异依据和置信度，交由人员确认；当制品描述缺少判断所需信息时，应明确提示补充材料，不能在证据不足的情况下推断为不通过。通过这种分级处理，AI能够参与审核，又不会把概率性判断包装成确定事实。

（四）智能推理层

智能推理层基于企业架构本体、知识图谱、规则结果和语义识别结果，对架构元素之间的逻辑关系进行推理验证，重点识别单一制品无法暴露的跨域问题。例如，业务能力发生调整后，系统可以沿“业务能力—应用模块—功能项—数据实体—技术组件”关系链分析影响范围；应用模块准备停用时，可以反向查找仍在调用其服务的系统和仍由其支撑的业务能力。

在应用与数据架构联合评审中，应对架构元素之间的逻辑关系进行推理验证，识别功能项与应用模块归属、应用集成关系与数据流图之间的潜在冲突和不一致。比如，功能项清单显示“客户画像查询”属于客户服务模块，但应用集成图却将相关接口登记在营销分析模块下，系统需要沿功能归属、接口提供和应用调用关系核对真实承载边界；又如，应用集成图显示系统A向系统B发送客户数据，而数据流图记录的流向相反，推理层应定位两张制品中的对应节点和连线，形成可复核的冲突证据。

跨域推理还可以覆盖业务与应用、数据与安全、应用与技术等关系。业务能力没有任何有效应用模块支撑，可能意味着需求未落实或架构资产登记不完整；模型服务使用敏感数据却未关联访问控制和脱敏措施，可能形成安全风险；生产应用仍依赖已退出技术组件，可能影响后续升级和运维。系统应将发现的问题按关系路径展示，避免只给出“存在不一致”的笼统结论。

推理可以分为三种方式。第一种是基于本体公理的演绎推理，根据等价关系、逆关系、传递关系和属性限制推出新事实或发现矛盾。第二种是基于规则的条件推理，将制度要求转化为“如果—那么”逻辑。第三种是基于案例的类比推理，从历史评审案例中检索与当前问题相似的情形，为架构师提供参考。

例如，图谱中存在“功能项A属于应用模块B”“应用模块B部署于节点C”“节点C位于测试环境”三条事实，而功能项A所属版本已标记为生产发布。推理层可以结合环境约束识别生产功能与测试部署之间的冲突。又如，两个应用模块调用同一模型服务，但其中一个模块记录的模型版本与服务目录中的生效版本不一致，系统可以通过模型调用矩阵与版本关系形成一致性问题。

大模型可以参与复杂关系解释和建议生成，但不能绕过事实验证。推荐采用“图谱检索—规则筛选—模型解释—人工确认”的路径：先从图谱中获取确定事实，再运行适用规则缩小问题范围，然后由模型组织问题说明和修复方案。模型生成的任何新关系都应标记为候选事实，经过确认后才能进入正式知识图谱。

（五）三层协同机制

三层协同的关键是建立统一任务对象和结果格式。每个评审任务都应携带项目、版本、架构域、制品、对象范围和评审模式等信息。各层返回统一的问题编号、对象标识、规则或模型依据、证据位置、问题等级、置信度和建议动作，便于汇总和追踪。

当规则引擎发现必填项缺失时，无需再调用语义模型；当规则检查通过但文本含义仍不明确时，转入语义层；当语义层发现多个对象可能等价或存在跨域影响时，再触发推理层。对于多层同时发现的问题，应进行归并，避免同一根因生成多条重复意见。

（六）标准化接口与模型迭代

各层之间可以通过统一任务接口交互。任务输入包括对象标识、制品位置、结构化属性、关联关系、适用规则和上下文材料；任务输出包括状态、问题等级、判断依据、证据、置信度和建议动作。规则引擎输出的确定事实可以作为语义层和推理层的前置条件，语义层确认的候选映射可以触发图谱查询，推理层形成的关系路径又可以回填评审报告。标准化接口可以减少各能力之间的直接耦合，便于后续替换模型或扩充规则。

规则库动态更新和AI模型持续迭代应采用不同治理方式。正式规则只有经过审批、测试和发布后才能生效；AI模型可以通过术语库更新、检索知识更新、提示模板优化或模型版本升级提高效果，但每次变更均需在固定测试集上验证。测试集应覆盖常见正确样例、典型错误、边界情况和历史误报，重点比较问题发现率、确认率、结果稳定性和解释完整性，未达到门槛的模型不能直接替换生产版本。

七、智能评审业务流程

（一）评审准备

项目提交架构制品后，系统首先校验文件格式、模板版本和提交范围，确认是否使用当前有效模板。随后解析表格、图形和文档，形成结构化数据，并将抽取结果与现有架构资产进行实体对齐。对无法识别的对象、缺失编码和疑似重复实体，系统先生成数据准备问题，不直接进入复杂推理。

评审范围可以根据项目阶段和变更类型自动确定。新建系统通常需要覆盖业务、应用、数据、技术和安全多个架构域；局部功能优化可以采用增量评审，重点检查变更功能及其上下游关系；技术组件替换则应加强部署、接口、数据流和安全影响检查。

（二）自动评审

准备完成后，系统按照规则适用条件生成评审任务清单。规则引擎先执行格式、完整性、唯一性和值域检查，再执行对象和关系一致性检查。语义理解层对名称、定义和说明文字进行分析，智能推理层对跨域关系、影响范围和潜在冲突进行验证。

自动评审过程中应保存输入快照、规则版本、模型版本和执行日志，确保同一版本制品能够复现相同评审过程。对于外部模型服务，还应控制输入范围，避免将敏感架构信息发送到未经批准的环境。

（三）问题归并与分级

多个规则可能指向同一问题。例如，应用模块编码缺失会同时导致模块自身完整性问题、功能项归属无法匹配和部署关系断裂。如果系统逐条输出，评审人员会看到大量重复意见。问题归并模块应识别共同根因，将衍生问题作为影响范围附在主问题下。

问题等级由规则等级、对象重要性、影响范围和置信度共同决定。明确违反强制标准且证据充分的问题可判定为不通过；存在潜在影响但需要更多材料的问题判定为警告；系统自动修复或补齐后通过复核的事项记录为通过。对于重大架构变更，最终等级仍应由授权架构师确认。

（四）人工复核与结果发布

人工复核界面应同时展示问题描述、涉及对象、来源制品、违反规则、关系路径和修复建议。架构师可以选择确认、驳回、调整等级或要求补充材料，并说明处理理由。系统不应只记录最终状态，还应保存人工修改前后的差异，为后续分析规则准确率和模型偏差提供数据。

评审报告应包含通过项、警告项、不通过项及具体原因，并给出修复建议。报告既要提供面向管理人员的总体结论，也要提供面向设计人员的问题明细。总体部分可以展示问题数量、架构域分布、重大风险和整改状态；明细部分应支持定位至具体制品、字段、实体或关系。

报告中的每一条问题建议采用统一结构：先说明评审对象和结论，再列出违反的规则或标准依据，随后展示原始制品证据和跨制品关系路径，最后给出可执行的修复建议。修复建议应与问题类型匹配，例如字段缺失类问题明确需要补充的字段，术语类问题给出推荐标准词，关系冲突类问题提示需要核对的两份制品和责任主体。对于无法自动确定修复方式的问题，应明确标注“需人工确认”，避免生成看似具体但缺少依据的方案。

评审结果还应支持按项目、架构域、制品类型、问题等级和责任部门进行汇总。管理人员关注整体风险、阻断事项和整改进度，设计人员关注问题定位和修改要求，架构师关注规则依据和跨域影响，平台运营人员关注规则命中、模型效果和异常情况。通过同一数据生成不同视角，可以减少重复编制报告，同时保持结论口径一致。

（五）整改与复评

问题确认后，系统生成整改任务并关联责任人、完成时限和验证方式。设计人员修改制品后，可以仅对受影响对象及其关系重新评审。若问题通过复评，系统记录修复版本和关闭依据；若多次出现同类问题，应进一步分析是模板说明不清、人员能力不足、规则设置不当，还是上游数据质量长期存在缺陷。

图5  智能评审与整改复评闭环

八、结果解释与持续优化

（一）建立可解释的评审证据链

智能评审的可信度来自证据链，而不是模型语言是否流畅。完整证据链应包括原始制品片段、结构化结果、匹配的本体概念、触发规则、关系推理路径、模型提示信息、输出结论和人工复核意见。任何人查看问题时，都能够理解结论如何产生。

对于规则问题，重点展示字段值、期望值和规则条件；对于语义问题，展示原文、标准定义和差异点；对于推理问题，展示实体之间的关系链。涉及模型生成的修复建议时，还应标明建议仅供参考，避免设计人员将其误认为正式标准。

（二）用反馈改进规则和模型

人工复核结果是持续优化的重要数据。可以统计规则命中后被确认、驳回和调整等级的比例，识别误报率较高的规则；分析语义问题的确认率和典型误判场景，优化术语库、提示模板和检索内容；对反复出现的问题建立专题案例，补充到培训材料和设计指南中。

规则库与模型应分别管理。规则库修改需要正式审批和版本控制，模型可以通过提示优化、检索库更新或重新训练持续迭代，但模型变化不能自动改变强制规则。每次升级都应使用固定测试集开展回归验证，确保旧问题仍能识别，新能力不会显著增加误报。

九、平台架构与安全控制

（一）平台能力组成

智能评审平台可以由制品接入、解析转换、本体与知识图谱、规则管理、模型服务、任务编排、评审报告和运营分析等模块组成。制品接入模块负责文件、接口和架构工具数据导入；解析模块完成表格、图形和文本抽取；本体与图谱模块管理概念、关系和实例；规则模块负责规则配置、测试、发布和执行；模型服务模块提供语义理解与建议生成；任务编排模块按照问题类型组织三层能力调用。

平台不必替换现有架构管理工具，可以通过标准接口接收制品和回写结果。对于已有架构资产库的企业，应优先复用现有唯一标识、版本管理和权限体系，避免形成新的数据孤岛。

从技术部署看，平台可以划分为接入层、知识与规则层、智能能力层、流程服务层和展示运营层。接入层连接文件库、架构设计工具、资产管理平台和项目管理系统；知识与规则层统一管理本体、图谱、术语、规则和案例；智能能力层封装解析模型、语义模型、图推理和报告生成能力；流程服务层负责任务编排、状态流转、权限校验和消息通知；展示运营层提供评审工作台、问题明细、关系追溯和运营分析。各层通过服务接口传递结构化对象，避免模型直接访问不受控的数据源。

平台应同时支持批量评审和交互式评审。批量评审用于项目集中提交、阶段门检查和存量资产巡检，强调稳定性、吞吐量和结果汇总；交互式评审用于架构师在设计过程中查询概念、验证关系和预检查制品，强调响应速度和上下文解释。两类模式共享同一规则、本体和证据体系，避免设计阶段与正式评审阶段采用不同口径。

图6  企业架构智能评审平台能力分层

（二）权限和数据安全

企业架构资料可能包含核心业务流程、系统接口、数据分布和技术部署信息，应实施分级授权。用户只能查看其职责范围内的制品和问题；模型调用应遵循最小必要原则，对敏感字段进行脱敏或屏蔽；日志中不得记录未经处理的敏感输入。

智能评审自身也需要纳入模型风险管理。NIST人工智能风险管理框架强调在AI系统设计、开发、使用和评价过程中考虑可信性，并通过治理、识别、度量和管理等职能开展风险管理。[5] 对应到架构评审场景，应建立模型用途边界、输出复核机制、数据来源记录、性能监测、异常处置和版本退出机制。

十、实施路径

第一阶段统一标准和数据基础

首先梳理现有架构制度、制品模板、术语和评审意见，建立最小可用的制品目录、元模型和术语库。选择结构相对稳定的应用模块清单、功能项清单、数据实体清单和部署清单开展标准化，明确唯一标识和跨表关联方式。同时清理历史数据中的重复编码、空值和名称冲突，为后续图谱构建奠定基础。

第二阶段建设规则引擎

优先选择高频、明确、争议小的规则，包括必填、值域、唯一性、版本、状态和基础关系完整性检查。建立规则编制和审批流程，形成测试样例和预期结果。此阶段的目标不是覆盖所有评审要求，而是让一批确定性问题能够稳定自动发现，并验证制品结构化质量。

第三阶段引入本体和语义能力

在规则运行稳定后，将核心架构对象和关系导入知识图谱，逐步增加跨域一致性和影响分析。同步建设标准术语、同义词和典型案例库，引入语义理解能力处理名称不一致、描述不完整和概念粒度等问题。所有语义结果先作为建议，由架构师复核并积累标注数据。

第四阶段形成智能推理和运营闭环

在事实数据、规则和复核案例达到一定规模后，建设跨域推理、问题归并、修复建议和增量评审能力。将评审结果与整改任务、架构资产更新和运营分析连接起来，形成从制品提交、自动评审、人工复核、整改复评到知识沉淀的闭环。

十一、评价指标与实施风险

（一）评价指标

评价智能评审效果不宜只看发现问题数量。建议从效率、质量、稳定性和应用四个方面设置指标。效率指标包括平均评审时长、自动检查覆盖率和人工工作量变化；质量指标包括问题确认率、重大问题召回率、误报率和重复问题下降率；稳定性指标包括相同输入结果一致率、规则执行成功率和模型异常率；应用指标包括项目覆盖率、整改闭环率和架构师使用满意度。

指标应结合问题等级分析。低风险规则可以追求较高自动化率，高风险事项则更重视准确性和可解释性。对于语义判断，应持续观察不同架构域、不同文本长度和不同项目类型下的表现，避免总体平均指标掩盖局部失效。

（二）主要风险及应对

一是标准基础薄弱。如果模板、术语和关系本身不统一，智能评审只会放大已有混乱。应将标准治理作为前置工作。二是规则数量过多且相互冲突。应建立规则优先级、适用范围和冲突处理机制，并定期清理失效规则。三是模型输出不稳定。应通过检索增强、固定提示、结构化输出、置信度阈值和人工复核控制风险。

四是数据更新不及时。知识图谱中的架构状态如果落后于实际系统，推理结论将失去可信度。应明确各类资产的更新责任和时限。五是过度依赖自动化。平台能够发现形式和逻辑问题，但无法代替架构师判断复杂的战略取舍、组织影响和实施可行性。智能评审应始终服务于专业决策，而不是弱化责任边界。

结语

基于企业架构本体的智能评审，本质上是将架构知识、管理标准和评审经验转化为可计算的组织能力。本体解决“系统如何理解架构对象及其关系”的问题，规则体系解决“依据什么标准进行检查”的问题，规则引擎、语义理解和智能推理三层模型解决“不同类型的问题如何被发现和解释”的问题。三者共同作用，才能形成机器可执行、AI可审核的标准化体系。同时，对高风险事项保留人员复核和最终决策环节，确保自动化能力不改变既有责任边界。

推进过程中，应坚持从标准化和确定性规则起步，以真实评审场景验证本体和模型，逐步扩展跨域推理和智能建议能力。最终目标不是追求完全无人化评审，而是让架构师从大量重复比对中释放出来，将更多精力投入业务价值、整体协同和重大技术决策，实现企业架构由静态成果管理向持续、主动、可度量的治理方式转变。

参考资料

[1] World Wide Web Consortium. RDF 1.1 Concepts and Abstract Syntax. https://www.w3.org/TR/rdf11-concepts/

[2] World Wide Web Consortium. OWL 2 Web Ontology Language Document Overview Second Edition. https://www.w3.org/TR/owl2-overview/

[3] World Wide Web Consortium. Shapes Constraint Language SHACL. https://www.w3.org/TR/shacl/

[4] World Wide Web Consortium. SPARQL 1.1 Query Language. https://www.w3.org/TR/sparql11-query/

[5] National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework AI RMF 1.0. NIST AI 100-1, January 2023. https://doi.org/10.6028/NIST.AI.100-1