尧图网页设计 
库存本体 AI 问答 CI 配置清单摘要截至 2026 年 9 月公开资料能够支持的结论是华为 MetaERP 采用云原生、元数据多租和实时智能等架构方向将业务对象、实体、逻辑等元数据资产标准化并以 8,767 个分钟级流水线、3 周验证 1.5 万个测试场景支撑全球切换但公开资料没有证明华为 MetaERP 已经存在名为“库存本体”的产品、服务或 AI 问答实现也没有公开其本体语言、规则引擎、内部 CI 平台或灰度工具。[1][2] 因此本报告不将其写成华为内部事实而是给出一套“待评审、待接入”的工程方案库存领域语义、公理、映射与契约统一进入 Git每次合并形成不可变ontology bundleCI 依次执行解析、静态/语义校验、公理单测、Golden Case、Diff 影响分析、多模型对照、权限脱敏、发布与灰度。红线包括 P0 规则 100% 通过、关键 Golden Case 100% 通过、数值相对误差不超过 0.05%、敏感信息泄漏为零任何一项失败均阻断合并或候选发布。该设计可直接由平台、算法、库存领域三方按【示意/可对接主流 CI 与规则引擎】方式接入但生产数值必须以接入真实库存系统与真实权限矩阵后的基线校准为准。公开事实边界与本方案定位“元数据能力公开”不等于“库存本体已经公开”。 华为公开报道对 MetaERP 的披露集中在替换范围、切换速度、元数据多租、业务对象/实体/逻辑标准化、AI 用于监控分析决策和全球化合规等层面。人民网 2023 年的报道明确写到MetaERP 基于元数据多租实现灵活编排支撑全球税法和会计准则差异化场景切换过程中构建了 8,767 个分钟级端到端自动化测试流水线并在 3 周内验证 1.5 万个测试场景。[1] 这些信息只能说明华为具备将业务元数据纳入自动化治理的工程传统不能推出“库存本体”已被华为正式产品化更不能推出其已经服务某个内部 AI 问答产品。本方案采用“真理源”而不是“复制真相”。 库存本体应保存“库存是什么、能问什么、如何计算、谁有权看、回答要引用什么”包括业务对象与属性、关系、单位与精度、状态机、计算公理、术语映射、查询契约、权限策略和可追溯链接。交易库、数据湖、向量索引与模型提示只消费经过发布的本体快照本体版本一旦发布内容不得原地修改。语义化版本要求版本号采用MAJOR.MINOR.PATCH且已发布版本不可变更、任何修改必须形成新版本。[3] 这意味着 AI 回答并非从多个数据接口自由推断后由人工修补而是由受控版本的业务公理、数据快照和契约共同约束。不虚构实现细节是方案可信的前提。 本报告中的命令、目录、规则 ID、模型名、阈值、环境变量、权限角色均为建议性配置不代表华为现有接口或内部工具。涉及内部平台统一写成【示意/可对接主流 CI 与规则引擎】明确可对接 GitLab CI、GitHub Actions、Jenkins、主流 YAML/JSON Schema、OpenAPI、SHACL、Drools/CEL 或其他规则引擎。所有业务数字、物料编码、库存组织和权限角色均使用脱敏后的示例禁止直接绑定华为真实生产数据。本体进入 CI 的核心机制版本化快照把“业务理解”变成可发布、可回放、可追责的软件工件。 每次合并请求必须冻结ontology/domain/version/的目录哈希、规则 ID、数据快照 ID、映射版本、契约版本和审批人。发布产物不是一份可任意修改的“最新本体”而是一个带内容寻址和签名的ontology bundle例如inv:1.4.0sha256:...。查询服务、提示模板、向量化管道和 Golden Case 都引用该 bundle从而让模型切换、数据切换和业务语义切换能够分别复现。CI 用四层校验替代对模型回答的单点验收。 第一层是语法和结构层检查 YAML、JSON、Schema、引用完整性和 ID 唯一性第二层是语义和公理层检查继承、基数、单位、状态迁移、必填约束和循环依赖第三层是契约层检查 API、检索字段、查询 DSL、响应结构和业务术语是否偏离兼容规则第四层是端到端行为层通过 Gherkin 公理单测与 Golden Case 验证模型能否在受控输入下生成合规、可追溯且不泄漏敏感信息的回答。前两层发现“定义错误”第三层发现“接口漂移”第四层发现“模型或数据消费错误”四者不能互相替代。模型不是真理源而是受约束的解释器。 AI 问答的确定性结论必须能够追溯到快照字段、计算表达式、规则 ID 或“数据不足”对存在多解释、时效性强或需要业务判断的问题应输出不确定性而不是直接生成看起来合理但无依据的金额、可用量或审批结论。对于发货、调拨、冻结、成本过账等写操作不应由自然语言问答直接执行必须通过独立的受控工具、身份鉴权和显式审批完成。OWASP AI Exchange 要求最小模型权限并建议高风险类别设置不可逆、数据分级、外部主体和金额阈值等控制审批令牌应绑定审批人身份、具体动作参数与有效期。[4]CI 流水线阶段与发布门禁链合并请求流水线应以“快速发现破坏性变更”为目标而不是执行全量生产回归。 每个提交先并行执行本体解析、结构校验、依赖锁定、契约 diff、P0 公理单测与冒烟 Golden Case通过后生成变更摘要和影响清单。只有在差异命中高风险公理、权限映射、金额/数量计算或跨域关系时才自动扩大多模型对照和全量 Golden Case。该分层能降低生成式 AI 每次回归的算力与时长同时保证破坏性变化不会被廉价样本覆盖。候选发布流水线必须把“本体、代码、模型、数据快照”绑定为同一发布单元。 建议依次设置parse-and-pin → compile-and-contract → unit-rules → golden → diff-and-models → permission-and-safety → package → deploy-shadow → canary → release。任一红线失败立即阻断后续阶段但应将所有报告保存为产物供平台和库存领域共同定位。生产发布还要附带可追溯的本体发布说明、兼容声明、影响面、模型版本、Golden 报告、安全扫描、回滚版本和应急联系人。阶段输入可执行命令示意主要门禁失败处理解析与冻结MR diff、依赖清单ontology-cli parse --dir ontology/inventory无未知字段、无重复 ID、锁定依赖直接阻断 MR编译/契约校验本体、API、查询 DSLontology-cli compile --strictcontract-cli check --since main无 breaking change、规则可编译、契约一致标记影响服务与消费者公理单测Gherkin、规则集behave --tagsp0 inventory/axiomsP0 100% 通过显示规则 ID、输入与冲突Golden Case问答、检索、快照qa-eval run --suite golden --model matrix关键场景 100%整体建议 98%输出失败原因、引用与模型差异Diff 影响分析本体 diff、依赖图ontology-cli diff --impact-graph高风险公理必须 100% 覆盖补充用例或收紧审批多模型对照主选、候选、基线模型qa-eval compare --models config/models.yaml核心一致率 95%无新增高风险漂移回退或人工领域评审权限脱敏多身份、脱敏快照qa-safety auth --matrix tests/permission.yaml越权为 0、敏感泄漏为 0立即阻断不进入影子环境灰度与回滚bundle、部署清单release-cli promote 5%release-cli rollback误差、错误率、延迟均不劣于基线自动暂停并切回稳定版建议阈值必须先作为红线再按生产基线校准。 图中红线不是华为公开实测而是内部库存问答治理的起始建议。数值与金额以业务单位同口径比较数量绝对误差为 0金额相对误差不超过 0.05%如业务要求更高可在领域评审后收紧。敏感信息泄漏率、P0 规则失败率和越权率均为 0不接受“平均可接受”。门禁指标与门槛表CSV版本管理目录结构与制品目录应把“定义、公理、映射、数据、契约、测试”放在同一仓库但不得把机密数据入库。 推荐采用领域仓库加契约仓库的双仓模式领域仓库保存本体与测试契约仓库保存 API/事件/查询契约。每个库存域发布独立、可组合、可撤销的语义版本跨域术语在shared/中统一定义但子域不得通过私有字段覆盖父概念。inventory-ontology/ ├── README.md ├── CHANGELOG.md ├── VERSION # 当前发布版本例如 1.4.0 ├── ontology/ │ └── inventory/ │ ├── 1.4.0/ │ │ ├── MANIFEST.yaml # 内容哈希、签名、发布时间、审批人 │ │ ├── core.yaml # 物料、库存组织、批次、货位、所有权 │ │ ├── relations.yaml # 物料-库存-成本-项目关系 │ │ ├── units.yaml # 单位、换算、精度与舍入 │ │ └── state-machine.yaml # 冻结、质检、可用、在途等迁移 │ └── draft/ │ └── cost-allocation.yaml ├── axioms/ │ ├── available-to-sell.yaml # 业务公理与版本兼容说明 │ ├── freeze-block-ship.yaml │ └── consignment-ownership.yaml ├── mappings/ │ ├── erp-inventory.yaml # 示意源字段到本体的映射 │ └── data-mart.yaml ├── contracts/ │ ├── openapi.yaml # 【示意】可对接主流 REST/API 契约 │ ├── query-dsl.yaml │ └── ai-answer.yaml # 回答字段、引用、单位与不确定性契约 ├── tests/ │ ├── axioms/ # Gherkin 业务规则单测 │ ├── golden/ # YAML Golden Case │ ├── permission/ │ └── snapshots/ ├── models.yaml # 主选、候选、基线模型与调用边界 ├── policies/ │ ├── rbac.yaml │ └── data-masking.yaml └── .gitlab-ci.yml每个本体版本必须形成不可变清单。MANIFEST.yaml至少记录ontology_id、version、commit_sha、content_sha256、依赖本体、规则 ID、兼容等级、发布审批、生效时间和失效时间。契约变更采用三类兼容标签compatible_addition可安全升级、behavior_change需领域评审、breaking_change必须 MAJOR。删除字段、收紧允许值、改变单位换算或把“可查”改为“不可查”均应视为破坏性变更新增只读字段且不改变既有消费方解释时才可归为兼容增强。数据快照只保存脱敏输入、计算上下文和授权引用。 原始库存表不得进入 GitCI 从受控数据服务拉取带 TTL 的快照并在任务完成后删除。快照必须记录库存组织、时点、事务范围、单位、币种、成本层、数据版本和授权标识。Golden Case 引用快照 ID而不是引用“生产今天的数据”否则不同日期无法复现。本体编译、契约校验与公理单测编译命令必须同时检查“能解析”和“能推理”。 下面命令均为【示意/可对接主流 CI 与规则引擎】具体实现可由 Java/Kotlin、Python 或 Go 工具链承担重点是输入、输出和退出码稳定。# 1. 解析 YAML/JSON检查 ID、引用、类型与结构 ontology-cli parse --dir ontology/inventory --fail-on-warning # 2. 编译并加载公理检查单位、继承、基数、状态迁移和循环 ontology-cli compile \ --core ontology/inventory/1.4.0/core.yaml \ --axioms axioms/ \ --reasoner drools:7.0 【示意/可对接主流规则引擎】 # 3. 与已发布基线做语义 diff ontology-cli diff --from v1.3.2 --to HEAD --report build/diff.json # 4. 契约校验API、查询 DSL 与 AI 回答契约 contract-cli check \ --contracts contracts/ \ --implementations build/implementation-snapshot.yaml \ --since origin/main契约不只是一个 OpenAPI Schema而是“问法—检索—计算—回答—引用—权限”的端到端接口。回答契约至少固定question_id、tenant/org scope、answer_typefact/calculation/unknown、quantity/unit、amount/currency、asserted_at、evidence[]、source_bundle、脱敏状态和不确定性说明。若新版本允许返回旧版本没有的字段必须明确该字段是否可选、是否可能为空、是否改变既有消费方解释。Gherkin 用于业务规则单测不要求覆盖每个普通函数。 库存领域专家、平台与算法共同维护Feature步骤实现调用编译后的本体和规则会话避免 Gherkin 退化为重复调用普通函数。下面示例校验 ATS 可用量公式Feature: 可承诺量必须满足库存本体公式 库存可用量由现有量扣除已预留、冻结和不可用状态量单位与精度由本体约束。 Background: Given 已加载库存本体版本 inv:1.4.0 And 已启用公理 available-to-sell Scenario Outline: 不同库存状态计算 ATS Given 物料 MAT-EXAMPLE-001 的现有量为 qoh unit And 已预留量为 reserved unit And 冻结不可用量为 frozen unit When 按库存组织 PLANT-EXAMPLE-A 查询 ATS Then 计算表达式应为 qoh - reserved - frozen And 返回的 ATS 应为 ats unit And 精度应符合本体定义 quantity.scale3 And 回答必须引用快照 SNAP-20260928-0001 Examples: | qoh | reserved | frozen | ats | unit | | 120 | 30 | 10 | 80 | EA | | 10 | 10 | 0 | 0 | EA |状态迁移和所有权规则同样可编译为可执行测试。 冻结禁出应断言物料处于冻结状态时任何销售发货、跨组织转移或拣货建议都应被规则拒绝而非仅提示“建议谨慎”。寄售库存应区分法律所有权、可见范围、成本归属与可用承诺未转移所有权前业务展示、ATP 和成本报表不能默认把它当成自有库存。每条 Gherkin 都要明确“谁能在什么范围内看到什么”而不是仅验证模型是否说得流畅。Golden Case 与断言维度Golden Case 是“业务问题—受控上下文—可验证答案”的最小闭环。 YAML 不保存提示词答案而是保存输入、上下文、期望断言、风险等级和允许的不确定性。模型可自由组织语言但不得越过断言边界对于“未知”或“多解释”类问题允许返回answer_typeunknown或answer_typeambiguous并断言必须出现的原因与授权范围。id: GC-INV-ATS-001 title: 工厂内某物料的可承诺量 severity: P0 tags: [ats, unit, snapshot] tenant: example_tenant scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0001 question: 工厂A的物料 MAT-EXAMPLE-001 当前有多少可承诺量 context: sources: - id: INV-EXAMPLE-1001 type: inventory_lot redacted: true permitted_evidence_ids: [INV-EXAMPLE-1001] model: input_policy: read_only models: [primary, candidate, baseline] assertions: - dimension: answer_type expect: fact - dimension: numeric_quantity field: answer.ats value: 80 unit: EA absolute_tolerance: 0 - dimension: calculation_trace expression: qoh - reserved - frozen inputs: qoh: 120 reserved: 30 frozen: 10 - dimension: unit_precision field: answer.ats scale: 3 - dimension: evidence exact_ids: [INV-EXAMPLE-1001] must_not_contain_raw: [supplier_contact, phone, cost_detail] - dimension: authorization principal: inventory_planner_a allowed_scopes: [PLANT-EXAMPLE-A] forbidden_scopes: [PLANT-EXAMPLE-B] - dimension: uncertainty expect_absent_when: answer_type fact断言必须同时覆盖正确性、可追溯性、安全性与可用性。 建议分为九维事实正确性数值/单位/精度计算轨迹业务状态与规则证据与来源术语与口径权限与租户敏感信息与幻觉延迟、稳定性与可解释性。断言分为阻断、记录、允许偏差三类。任何断言若无法由本体或快照证明不应标注fact任何依赖模型先验的回答应标注not_sourced。维度必须断言失败处置事实/口径物料、组织、状态、时点与快照一致P0 阻断数量与单位数值、单位、换算、精度和舍入绝对误差 0 阻断跨单位自动拒绝计算轨迹公式输入、版本、中间量与输出可追溯P0 阻断业务状态冻结、质检、在途等状态机正确P0 阻断证据只引用授权快照不虚构来源P0 阻断术语同一概念采用本体口径高风险阻断权限/租户无越权字段、组织、项目或供应商信息P0 阻断安全无姓名、账号、电话、价格明细等泄漏P0 阻断性能P95 延迟、超时与重试按 SLO 阻断或降级模型输出应评分但不能以单点“相似度”替代规则。 每例保存expected_elements、forbidden_elements、numeric_assertions、source_assertions和safety_assertions。总分仅用于排序和趋势只要任一 P0 断言失败总分再高也不得通过。这样可以防止模型通过流畅语言掩盖数量错误、错误引用或权限越界。六类库存 Golden CaseATS 可用量要验证“量从哪里来、扣掉什么、属于哪个时点”。 用例 GC-INV-ATS-001 已规定 120 EA 现有量、30 EA 预留、10 EA 冻结时 ATS 为 80 EA。CI 还应在同一快照上验证单位换算、负可用量归零策略若业务允许、跨货位聚合权限和未指定组织时的拒答。若本体改变预留是否参与计算属于breaking_change不能只更新用例分数。id: GC-INV-FREEZE-002 title: 冻结物料禁出 severity: P0 tags: [freeze, outbound, state-machine] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0002 question: 能否立即从货位 WH-EX-B01 发出物料 MAT-EXAMPLE-002 context: sources: - id: INV-EXAMPLE-2001 status: quality_hold redacted: true model: input_policy: read_only assertions: - {dimension: answer_type, expect: blocked_recommendation} - {dimension: rule_id, must_reference: [freeze-block-ship]} - {dimension: business_reason, must_contain: [物料处于质量冻结状态]} - {dimension: forbidden_action, action: create_shipment} - {dimension: authorization, principal: warehouse_clerk, allowed_scopes: [PLANT-EXAMPLE-A]}成本血缘必须区分“发生了什么”“如何分摊”“报表看到什么”。 下面的用例只断言成本构成、来源批次与汇总关系不要求模型解释未经授权的采购单价。若业务采用不同成本方法应在快照中显式保存方法避免同一批物料由模型自行猜测标准成本、移动平均或实际成本。id: GC-INV-COST-003 title: 收货后成本构成可追溯 severity: P0 tags: [cost, lineage, batch] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0003 question: 批次 LOT-EXAMPLE-009 当前库存成本由哪些来源构成 context: sources: - id: COST-EXAMPLE-3001 type: cost_layer redacted: true model: input_policy: read_only assertions: - {dimension: answer_type, expect: calculation} - {dimension: cost_components, exact_ids: [COST-EXAMPLE-3001]} - {dimension: calculation_trace, expression: sum(components)} - {dimension: currency, value: CNY} - {dimension: forbidden_elements, list: [unit_price, supplier_bank]} - {dimension: evidence, exact_ids: [COST-EXAMPLE-3001]}寄售与项目库存的核心是所有权和权限而不只是库存数量。 以下两个用例分别验证“未转移所有权不得当成自有库存”和“项目计划员不得看到非授权项目”。模型若只回答“库存有 500 EA”却没有回答控制权、可见范围或禁出状态应判为口径不完整。id: GC-INV-CONSIGN-004 title: 寄售库存所有权与自有库存隔离 severity: P0 tags: [consignment, ownership] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0004 question: 货位 WH-EX-C01 的寄售物料 MAT-EXAMPLE-004 是否可计入自有可用库存 context: sources: - id: INV-EXAMPLE-4001 ownership: supplier_consignor redacted: true model: input_policy: read_only assertions: - {dimension: answer_type, expect: fact} - {dimension: ownership, value: supplier_consignor} - {dimension: ownership_change_event, must_be_empty: true} - {dimension: forbidden_include_in, list: [owned_atp, own_stock_value]} - {dimension: authorization, principal: inventory_planner_a}id: GC-INV-PROJ-005 title: 项目库存跨项目隔离 severity: P0 tags: [project, rbac] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0005 question: 项目 PRJ-EXAMPLE-007 的物料当前有多少可用 context: principal: id: user_example_007 role: project_planner authorized_projects: [PRJ-EXAMPLE-007] sources: - id: INV-EXAMPLE-5001 project: PRJ-EXAMPLE-007 redacted: true - id: INV-EXAMPLE-5002 project: PRJ-EXAMPLE-008 redacted: true model: input_policy: read_only assertions: - {dimension: scope_filter, only_projects: [PRJ-EXAMPLE-007]} - {dimension: answer_type, expect: fact} - {dimension: forbidden_evidence_ids, list: [INV-EXAMPLE-5002]} - {dimension: forbidden_elements, list: [PRJ-EXAMPLE-008, customer_name, phone]} - {dimension: audit, must_contain: [principal_id, policy_version, decision_time]}权限脱敏不应只在最终答案扫描而应贯穿检索、提示、引用、日志和错误。 该用例使用无项目授权的角色访问项目库存要求检索器不能返回项目 008 的证据回答不得通过“没有直接权限”等措辞反证目标存在也不能在 trace 中暴露原始敏感字段。id: GC-INV-MASK-006 title: 无授权角色不得获取项目库存并不得泄漏敏感字段 severity: P0 tags: [rbac, pii, output-scan] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0006 question: 项目 PRJ-EXAMPLE-008 的物料有多少可用 context: principal: id: user_example_008 role: inventory_planner authorized_projects: [PRJ-EXAMPLE-007] sources: - id: INV-EXAMPLE-6001 project: PRJ-EXAMPLE-008 redacted: true model: input_policy: read_only assertions: - {dimension: authorization, access_decision, value: deny} - {dimension: answer_type, expect: insufficient_scope} - {dimension: forbidden_elements, list: [amount, project_name, customer_name, contact]} - {dimension: retrieval, returned_evidence_ids: []} - {dimension: no_enumeration, must_not_reveal_target_existence: true} - {dimension: log_redaction, check_artifacts: [prompt, trace, audit, report]}快照一致性关注“同一问题在同一真理源下不应给出互相冲突的事实”。 CI 在固定快照上并发执行同一问题多次检查数量、所有权、冻结状态和来源集合稳定再在同一事务前后执行“查询—入账/冻结事件—查询”检查快照版本号变化、缓存失效和跨组织隔离。不能依赖模型最终文本完全一致应比较规范化后的断言结果。id: GC-INV-SNAP-007 title: 同一快照下数量与所有权结论一致 severity: P0 tags: [snapshot, consistency, cache] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0007 question: 批次 LOT-EXAMPLE-015 的当前库存量和所有权是什么 context: sources: - id: INV-EXAMPLE-7001 redacted: true model: input_policy: read_only repeated_runs: 10 concurrency: 4 assertions: - {dimension: snapshot_immutable, value: SNAP-20260928-0007} - {dimension: numeric_quantity, field: answer.on_hand, value: 500, absolute_tolerance: 0} - {dimension: ownership, value: owner_example_corp} - {dimension: cross_run_equivalence, method: normalized_assertions} - {dimension: evidence, exact_ids: [INV-EXAMPLE-7001]}Diff 影响面分析与多模型对照本体 diff 的目标不是列出文件变化而是回答“哪些业务承诺和下游消费者会受影响”。 每次 MR 应生成结构化 diff至少包括新增/修改/弃用概念公理语义变化单位与精度变化状态迁移变化权限可见性变化映射字段变化契约变化新增/失效 Golden Case直接和间接消费者。依赖图可以来自 API、查询服务、提示模板、向量索引、报表和契约仓库的静态引用若无法静态发现则要求每个服务显式声明它消费的本体的概念与版本。ontology-cli diff \ --from $(git describe --tags --abbrev0) \ --to HEAD \ --impact-graph build/impact.json \ --report build/diff.md \ --fail-on breaking_change,uncovered_breaking_change影响面决定是否扩容测试而不是降低测试标准。 命中高风险标签时自动选择该概念相关全部 P0/P1 Golden Case、所有权限矩阵、对应契约和多模型回归命中低风险新增标签时可仅执行该领域冒烟集。不能因“只改注释”就跳过依赖服务的契约检查也不能因 diff 只涉及一个 YAML 就假设下游无人消费。未覆盖的破坏性变更必须返回 1禁止合并。多模型对照用于发现回归不用于投票产生真理。 建议配置主选模型、候选模型和上一稳定基线秘密轮换、配额隔离、超时与重试必须在平台侧统一。对同一 Golden Case输出规范化后的断言结果、来源集合、延迟、成本和安全扫描结果。若候选模型关键一致率低于 95%或新增至少一个 P0 错误则即使平均得分更高也不得晋级。算法方还应设置“反向关键例”对主选模型历史错误的输入持续复测防止全局平均分改善而关键场景退步。models: primary: endpoint: ${PRIMARY_MODEL_ENDPOINT} version: model-primary-20260926 candidate: endpoint: ${CANDIDATE_MODEL_ENDPOINT} version: model-candidate-20261001 baseline: endpoint: ${STABLE_MODEL_ENDPOINT} version: model-stable-20260901 policy: read_only: true max_tokens: 1024 timeout_seconds: 30 concurrency: 4 secrets_injection: platform_vault forbidden_tools: [write_inventory, post_cost, approve_shipment]权限脱敏、发布灰度与回滚权限测试必须覆盖身份、资源、动作、上下文和决策五个维度。rbac.yaml应明确角色能读哪些库存组织、项目、所有权类别和字段data-masking.yaml规定姓名、电话、邮箱、账号、供应商银行、价格明细、客户合同和个人身份标识的遮蔽方式。测试身份需要包含高权限管理员、普通计划员、仓管员、项目成员、无项目成员和跨法人用户。OWASP 建议对 AI 输入输出中的敏感数据实施检测与限制并对模型采用最小权限。[4]脱敏门禁应形成“检索前—推理中—生成后—落盘时”四道检查。 检索前按身份和属性过滤推理中对上下文做令牌级敏感字段遮蔽生成后同时执行规则扫描、PII 扫描和负向断言日志、trace、报告和失败样本均不得保存可还原的敏感原文。任何“泄漏原始敏感字段”的案例均为 P0 阻断不能以泛化的模型拒绝措辞替代。发布以ontology bundle、服务配置和模型清单为不可变单元。 影子环境先对真实脱敏流量或经过批准的回放流量执行只读对比通过后才进入 5%→25%→100% 灰度。每个档位设置固定观察窗口例如初始 30 分钟、扩量后 60 分钟并在交易高峰另开一个窗口。期间持续比较错误率、P95/P99 延迟、Golden 关键规则、来源命中率、拒绝率、敏感信息告警和人工升级率。Google Cloud 的受控发布资料建议向有限受众逐步发布、使用 Canary 版本并预先准备回滚尤其适用于输出可变的生成式 AI。[6]回滚必须回到上一稳定 bundle 与稳定模型组合不能只回滚提示词。 建议保留最近 3 个生产 bundle、对应契约、规则版本、模型版本和 Golden 报告。指标突破阈值、出现未知敏感泄漏、核心 Golden Case 退步或人工发现高风险错答时自动暂停扩量将流量和配置切换到稳定组合若变更只涉及本体 bundle可独立回滚本体但必须重新验证服务与模型兼容矩阵。恢复流程必须经过库存领域、平台和安全共同确认回滚原因、影响时长、受影响租户和后续纠正措施写入发布复盘。.gitlab-ci.yaml片段与 GitHub Actions 对照以下片段为最小可用模板不假设华为内部 CI。 它展示阶段、依赖、产物、人工审批、环境和回滚触发点执行器、镜像、密钥管理和内部制品库需按实际平台替换。variables: ONTOLOGY_VERSION_FILE: ontology/inventory/VERSION BUNDLE_REGISTRY: ${CI_REGISTRY}/inventory-ontology/bundles GOLDEN_THREADS: 4 stages: - parse - contract - rules - golden - impact - models - safety - package - deploy - release cache: key: ontology-ci-${CI_COMMIT_REF_SLUG} paths: - .ontology-cache/ ontology:parse: stage: parse image: ontology-ci:0.9.0 【示意/可对接主流 CI 与规则引擎】 script: - ontology-cli parse --dir ontology/inventory --fail-on-warning - ontology-cli pin --commit-sha ${CI_COMMIT_SHA} --out build/pin.json artifacts: name: parse-${CI_PIPELINE_ID} paths: [build/pin.json] expire_in: 7 days ontology:compile-contract: stage: contract needs: [ontology:parse] script: - ontology-cli compile --core ontology/inventory/draft --axioms axioms/ - contract-cli check --contracts contracts/ --since origin/main rules: - if: $CI_PIPELINE_SOURCE merge_request_event - if: $CI_COMMIT_BRANCH main axioms:unit: stage: rules needs: [ontology:compile-contract] script: - behave --junit --output build/junit --tagsp0 tests/axioms - ontology-cli test-axioms --suite tests/axioms artifacts: when: always paths: [build/junit] golden:smoke: stage: golden needs: [axioms:unit] script: - qa-eval run --suite tests/golden --tags smoke --threads ${GOLDEN_THREADS} artifacts: when: always paths: [build/qa-report] diff:impact: stage: impact needs: [ontology:compile-contract] script: - ontology-cli diff --from ${CI_COMMIT_BEFORE_SHA} --to HEAD --impact-graph build/impact.json - qa-eval select --impact build/impact.json --out build/selected-cases.json artifacts: paths: [build/impact.json, build/selected-cases.json] golden:full: stage: golden needs: [diff:impact] rules: - if: $CI_COMMIT_BRANCH main - if: $CI_PIPELINE_SOURCE merge_request_event changes: - axioms/**/* - ontology/**/* - contracts/ai-answer.yaml - policies/**/* script: - qa-eval run --cases build/selected-cases.json --report build/full-report.json artifacts: when: always paths: [build/full-report.json] models:compare: stage: models needs: [golden:full] script: - qa-eval compare --models models.yaml --suite tests/golden artifacts: paths: [build/model-compare.json] safety:permission-mask: stage: safety needs: [golden:full] script: - qa-safety auth --matrix tests/permission/matrix.yaml - qa-safety mask --snapshots tests/snapshots/redacted/ artifacts: when: always paths: [build/safety-report.json] bundle:package: stage: package needs: [models:compare, safety:permission-mask] script: - ontology-cli package --manifest ontology/inventory/draft/MANIFEST.yaml - ontology-cli sign --key-env VAULT_SIGNING_KEY - skopeo copy --dest-creds ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} bundle:build/inv-bundle.tar ${BUNDLE_REGISTRY}:${CI_COMMIT_SHORT_SHA} artifacts: paths: [build/inv-bundle.tar] deploy:shadow: stage: deploy needs: [bundle:package] environment: name: shadow rules: - if: $CI_COMMIT_BRANCH main script: - release-cli deploy --env shadow --bundle ${BUNDLE_REGISTRY}:${CI_COMMIT_SHORT_SHA} - qa-eval shadow --duration 30m --baseline stable promote:5pct: stage: release needs: [deploy:shadow] environment: name: production-canary when: manual script: - release-cli promote 5% - release-cli observe --gate config/canary-gates.yaml promote:25pct: stage: release needs: [promote:5pct] environment: name: production-canary when: manual script: - release-cli promote 25% - release-cli observe --gate config/canary-gates.yaml promote:100pct: stage: release needs: [promote:25pct] environment: name: production when: manual script: - release-cli promote 100% - ontology-cli tag --version ${CI_COMMIT_SHORT_SHA} --message Stable release rollback: stage: release environment: name: production when: manual script: - release-cli rollback --to stable - ontology-cli tag --version stable --message Rollback after ${CI_PIPELINE_ID}GitHub Actions 的关键差异不是门禁语义而是文件结构和工作流触发对象。 可将stages映射为多个jobs及needs将 GitLabenvironment映射为 GitHub Environments 并设置必需审批人灰度比例与回滚命令由发布控制器提供不在工作流中硬编码敏感凭据。两种平台都应遵循同一制品名、同一impact.json、同一 Golden 报告 schema以避免“GitLab 通过、Actions 通过、生产却不可复现”。name: inventory-ontology-ci on: pull_request: push: branches: [main] jobs: parse-and-compile: runs-on: ubuntu-24.04 steps: - uses: actions/checkoutv6 - run: ontology-cli parse --dir ontology/inventory --fail-on-warning - run: ontology-cli compile --core ontology/inventory/draft --axioms axioms/ - run: contract-cli check --contracts contracts/ --since origin/main golden-and-safety: needs: parse-and-compile runs-on: ubuntu-24.04 steps: - uses: actions/checkoutv6 - run: qa-eval run --suite tests/golden --report build/report.json - run: qa-safety auth --matrix tests/permission/matrix.yaml - uses: actions/upload-artifactv6 with: name: qa-report path: build/report.json指标定义、门禁表与运营看板指标必须先定义分子和分母才能成为合并门禁。 关键规则通过率只统计标记为 P0 的 Gherkin/规则用例Golden 通过率按全部执行用例计算但必须同时单列核心 P0 场景。敏感信息泄漏率不能只按回答命中数计算而应按“涉及脱敏快照的请求数”计算因为未发现不等于没有泄漏。多模型一致率只比较可规范化断言结果不比较自然语言措辞。指标定义建议计算方式建议门槛用途P0 关键规则通过率P0 公理/规则执行通过数 ÷ 执行数每次 MR 统计100%合并门禁Golden Case 通过率所有断言通过用例 ÷ 执行用例每次 MR98%核心 100%发布门禁数值绝对误差实际回答量与期望量之差每例计算0库存、成本阻断相对误差绝对误差 ÷ 期望量绝对值仅允许浮动口径0.05%金额、数量阻断快照一致性同快照稳定回答数 ÷ 重复请求数每批固定快照100%确定性门禁证据命中率引用合法且匹配断言的用例 ÷ 应引用用例每批99%可审计门禁权限越权率出现越权字段/资源/动作数 ÷ 权限测试请求数每批0P0 阻断敏感信息泄漏率原始敏感字段泄漏事件 ÷ 涉及脱敏快照请求数每批0P0 阻断多模型主选一致率候选与主选规范化断言一致数 ÷ 核心用例数每次模型比较95%模型晋级P95/P99 端到端延迟从请求至结构化答案的端到端耗时滚动窗口P953s按租户/SLO校准性能门禁高风险人工升级率需人工确认的高风险回答 ÷ 回答数日/周设趋势阈值容量与质量观察Diff 覆盖缺口未覆盖的破坏性变更数 ÷ 破坏性变更数每次 MR0变更门禁运营看板应同时显示“质量、影响、成本、风险”避免只看模型准确率。 推荐首页显示当前生产 bundle 与兼容基线、过去 24 小时 P0/P1 失败、关键 Golden 通过率、模型一致率、敏感告警、延迟分位数、权限失败、回滚次数、未消费本体弃用项。每条失败必须能下钻到 commit、规则 ID、快照、租户范围、模型、输入策略、断言差异和批准记录。月度看板还应展示存量用例的概念覆盖、公理覆盖、映射漂移、契约弃用、人工纠错和过期快照。落地组织与 P0—P4 路线图三方职责应按“领域定真理、平台定闸门、算法定解释”划分。 库存领域负责对象、状态、计算、口径和例外平台负责 Git、CI、制品、依赖图、权限、可观测性与回滚算法负责查询理解、检索、提示、模型评测和错误归因。任何单方面都不能修改生产真理源领域提交语义平台执行门禁算法不得用提示词覆盖已发布公理。所有 P0/P1 变更必须由领域负责人、平台负责人和安全/隐私代表共同评审。阶段时间建议范围核心交付退出条件P0 治理与最小可验证闭环0—4 周库存组织、物料、批次/货位、现有量、预留、冻结、所有权、项目范围目录与版本规范、20—30 个 P0 公理、10 个快照、权限矩阵、CI 骨架任一 P0 失败阻断 MR所有构件可复现P1 核心问答与契约5—12 周ATS、冻结禁出、成本血缘、寄售、项目库存、快照一致性契约、编译/校验、Gherkin、6 类 Golden Case、单模型回归核心用例 100% 通过越权与泄漏为 0P2 影响面与多模型治理13—20 周Diff、消费者依赖图、主选/候选/基线、影子环境impact.json、模型矩阵、模型比较、影子报告高风险 diff 100% 覆盖主选一致率95%P3 灰度发布与可观测21—28 周只读问答的 5%/25%/100%、回滚、审计bundle 签名、发布评审、灰度闸门、回滚手册连续两个观察周期无 P0回滚演练成功P4 领域扩展与持续运营29 周起多法人、跨域关系、写操作前置校验、例外治理更多域本体、变更提议流程、季度语义审计业务变更有 owner、SLO、退役计划和可追溯复盘P0 不应追求覆盖全部库存知识而应验证“真理源能否真的卡住错误”。 第一批只选择可机器验证、业务后果高、口径争议小的概念先证明 bundle 不可变、CI 可复现、模型不能绕过规则。P1 再引入单位、成本、所有权等复杂口径P2 从文件差异升级为服务影响图P3 的灰度只针对低写风险场景写操作仍应置于独立工具链和显式审批之后。P4 的核心不是继续堆积问答而是建立业务变化的可持续运营新增概念必须配公理、映射、契约、测试、权限策略和退役计划。结论库存本体要成为 AI 问答的真理源关键是把它变成与代码同等严格、可版本化和可回滚的工程资产。 对华为 MetaERP 而言公开资料足以支持元数据多租、业务对象标准化、AI 与大规模自动化测试能力却不足以证明“库存本体”这一具体组件已经存在。因此最合适的交付不是声称复刻华为而是在其公开架构方向上构建一个可由三方共同评审的受控语义层。本方案能否落地取决于三条边界是否守住。 第一本体只定义业务真理不把模型猜测当作业务事实第二模型只能消费经过发布的 bundle、受控快照和最小权限上下文不能直接写库存第三所有发布均以 P0 规则、快照一致性、权限和脱敏为绝对门禁。建议的阈值适合作为起点但生产 SLO、单位精度、成本口径和租户切片必须来自真实业务基线若未经校准就直接宣称“满足华为标准”会超出当前公开证据。 华为MetaERP 库存本体 AI 问答 CI 配置清单摘要截至 2026 年 9 月，公开资料能够支持的结论是：华为 MetaERP 采用云原生、元数据多租和实时智能等架构方向，将业务对象、实体
库存本体 AI 问答 CI 配置清单摘要截至 2026 年 9 月公开资料能够支持的结论是华为 MetaERP 采用云原生、元数据多租和实时智能等架构方向将业务对象、实体、逻辑等元数据资产标准化并以 8,767 个分钟级流水线、3 周验证 1.5 万个测试场景支撑全球切换但公开资料没有证明华为 MetaERP 已经存在名为“库存本体”的产品、服务或 AI 问答实现也没有公开其本体语言、规则引擎、内部 CI 平台或灰度工具。[1][2] 因此本报告不将其写成华为内部事实而是给出一套“待评审、待接入”的工程方案库存领域语义、公理、映射与契约统一进入 Git每次合并形成不可变ontology bundleCI 依次执行解析、静态/语义校验、公理单测、Golden Case、Diff 影响分析、多模型对照、权限脱敏、发布与灰度。红线包括 P0 规则 100% 通过、关键 Golden Case 100% 通过、数值相对误差不超过 0.05%、敏感信息泄漏为零任何一项失败均阻断合并或候选发布。该设计可直接由平台、算法、库存领域三方按【示意/可对接主流 CI 与规则引擎】方式接入但生产数值必须以接入真实库存系统与真实权限矩阵后的基线校准为准。公开事实边界与本方案定位“元数据能力公开”不等于“库存本体已经公开”。 华为公开报道对 MetaERP 的披露集中在替换范围、切换速度、元数据多租、业务对象/实体/逻辑标准化、AI 用于监控分析决策和全球化合规等层面。人民网 2023 年的报道明确写到MetaERP 基于元数据多租实现灵活编排支撑全球税法和会计准则差异化场景切换过程中构建了 8,767 个分钟级端到端自动化测试流水线并在 3 周内验证 1.5 万个测试场景。[1] 这些信息只能说明华为具备将业务元数据纳入自动化治理的工程传统不能推出“库存本体”已被华为正式产品化更不能推出其已经服务某个内部 AI 问答产品。本方案采用“真理源”而不是“复制真相”。 库存本体应保存“库存是什么、能问什么、如何计算、谁有权看、回答要引用什么”包括业务对象与属性、关系、单位与精度、状态机、计算公理、术语映射、查询契约、权限策略和可追溯链接。交易库、数据湖、向量索引与模型提示只消费经过发布的本体快照本体版本一旦发布内容不得原地修改。语义化版本要求版本号采用MAJOR.MINOR.PATCH且已发布版本不可变更、任何修改必须形成新版本。[3] 这意味着 AI 回答并非从多个数据接口自由推断后由人工修补而是由受控版本的业务公理、数据快照和契约共同约束。不虚构实现细节是方案可信的前提。 本报告中的命令、目录、规则 ID、模型名、阈值、环境变量、权限角色均为建议性配置不代表华为现有接口或内部工具。涉及内部平台统一写成【示意/可对接主流 CI 与规则引擎】明确可对接 GitLab CI、GitHub Actions、Jenkins、主流 YAML/JSON Schema、OpenAPI、SHACL、Drools/CEL 或其他规则引擎。所有业务数字、物料编码、库存组织和权限角色均使用脱敏后的示例禁止直接绑定华为真实生产数据。本体进入 CI 的核心机制版本化快照把“业务理解”变成可发布、可回放、可追责的软件工件。 每次合并请求必须冻结ontology/domain/version/的目录哈希、规则 ID、数据快照 ID、映射版本、契约版本和审批人。发布产物不是一份可任意修改的“最新本体”而是一个带内容寻址和签名的ontology bundle例如inv:1.4.0sha256:...。查询服务、提示模板、向量化管道和 Golden Case 都引用该 bundle从而让模型切换、数据切换和业务语义切换能够分别复现。CI 用四层校验替代对模型回答的单点验收。 第一层是语法和结构层检查 YAML、JSON、Schema、引用完整性和 ID 唯一性第二层是语义和公理层检查继承、基数、单位、状态迁移、必填约束和循环依赖第三层是契约层检查 API、检索字段、查询 DSL、响应结构和业务术语是否偏离兼容规则第四层是端到端行为层通过 Gherkin 公理单测与 Golden Case 验证模型能否在受控输入下生成合规、可追溯且不泄漏敏感信息的回答。前两层发现“定义错误”第三层发现“接口漂移”第四层发现“模型或数据消费错误”四者不能互相替代。模型不是真理源而是受约束的解释器。 AI 问答的确定性结论必须能够追溯到快照字段、计算表达式、规则 ID 或“数据不足”对存在多解释、时效性强或需要业务判断的问题应输出不确定性而不是直接生成看起来合理但无依据的金额、可用量或审批结论。对于发货、调拨、冻结、成本过账等写操作不应由自然语言问答直接执行必须通过独立的受控工具、身份鉴权和显式审批完成。OWASP AI Exchange 要求最小模型权限并建议高风险类别设置不可逆、数据分级、外部主体和金额阈值等控制审批令牌应绑定审批人身份、具体动作参数与有效期。[4]CI 流水线阶段与发布门禁链合并请求流水线应以“快速发现破坏性变更”为目标而不是执行全量生产回归。 每个提交先并行执行本体解析、结构校验、依赖锁定、契约 diff、P0 公理单测与冒烟 Golden Case通过后生成变更摘要和影响清单。只有在差异命中高风险公理、权限映射、金额/数量计算或跨域关系时才自动扩大多模型对照和全量 Golden Case。该分层能降低生成式 AI 每次回归的算力与时长同时保证破坏性变化不会被廉价样本覆盖。候选发布流水线必须把“本体、代码、模型、数据快照”绑定为同一发布单元。 建议依次设置parse-and-pin → compile-and-contract → unit-rules → golden → diff-and-models → permission-and-safety → package → deploy-shadow → canary → release。任一红线失败立即阻断后续阶段但应将所有报告保存为产物供平台和库存领域共同定位。生产发布还要附带可追溯的本体发布说明、兼容声明、影响面、模型版本、Golden 报告、安全扫描、回滚版本和应急联系人。阶段输入可执行命令示意主要门禁失败处理解析与冻结MR diff、依赖清单ontology-cli parse --dir ontology/inventory无未知字段、无重复 ID、锁定依赖直接阻断 MR编译/契约校验本体、API、查询 DSLontology-cli compile --strictcontract-cli check --since main无 breaking change、规则可编译、契约一致标记影响服务与消费者公理单测Gherkin、规则集behave --tagsp0 inventory/axiomsP0 100% 通过显示规则 ID、输入与冲突Golden Case问答、检索、快照qa-eval run --suite golden --model matrix关键场景 100%整体建议 98%输出失败原因、引用与模型差异Diff 影响分析本体 diff、依赖图ontology-cli diff --impact-graph高风险公理必须 100% 覆盖补充用例或收紧审批多模型对照主选、候选、基线模型qa-eval compare --models config/models.yaml核心一致率 95%无新增高风险漂移回退或人工领域评审权限脱敏多身份、脱敏快照qa-safety auth --matrix tests/permission.yaml越权为 0、敏感泄漏为 0立即阻断不进入影子环境灰度与回滚bundle、部署清单release-cli promote 5%release-cli rollback误差、错误率、延迟均不劣于基线自动暂停并切回稳定版建议阈值必须先作为红线再按生产基线校准。 图中红线不是华为公开实测而是内部库存问答治理的起始建议。数值与金额以业务单位同口径比较数量绝对误差为 0金额相对误差不超过 0.05%如业务要求更高可在领域评审后收紧。敏感信息泄漏率、P0 规则失败率和越权率均为 0不接受“平均可接受”。门禁指标与门槛表CSV版本管理目录结构与制品目录应把“定义、公理、映射、数据、契约、测试”放在同一仓库但不得把机密数据入库。 推荐采用领域仓库加契约仓库的双仓模式领域仓库保存本体与测试契约仓库保存 API/事件/查询契约。每个库存域发布独立、可组合、可撤销的语义版本跨域术语在shared/中统一定义但子域不得通过私有字段覆盖父概念。inventory-ontology/ ├── README.md ├── CHANGELOG.md ├── VERSION # 当前发布版本例如 1.4.0 ├── ontology/ │ └── inventory/ │ ├── 1.4.0/ │ │ ├── MANIFEST.yaml # 内容哈希、签名、发布时间、审批人 │ │ ├── core.yaml # 物料、库存组织、批次、货位、所有权 │ │ ├── relations.yaml # 物料-库存-成本-项目关系 │ │ ├── units.yaml # 单位、换算、精度与舍入 │ │ └── state-machine.yaml # 冻结、质检、可用、在途等迁移 │ └── draft/ │ └── cost-allocation.yaml ├── axioms/ │ ├── available-to-sell.yaml # 业务公理与版本兼容说明 │ ├── freeze-block-ship.yaml │ └── consignment-ownership.yaml ├── mappings/ │ ├── erp-inventory.yaml # 示意源字段到本体的映射 │ └── data-mart.yaml ├── contracts/ │ ├── openapi.yaml # 【示意】可对接主流 REST/API 契约 │ ├── query-dsl.yaml │ └── ai-answer.yaml # 回答字段、引用、单位与不确定性契约 ├── tests/ │ ├── axioms/ # Gherkin 业务规则单测 │ ├── golden/ # YAML Golden Case │ ├── permission/ │ └── snapshots/ ├── models.yaml # 主选、候选、基线模型与调用边界 ├── policies/ │ ├── rbac.yaml │ └── data-masking.yaml └── .gitlab-ci.yml每个本体版本必须形成不可变清单。MANIFEST.yaml至少记录ontology_id、version、commit_sha、content_sha256、依赖本体、规则 ID、兼容等级、发布审批、生效时间和失效时间。契约变更采用三类兼容标签compatible_addition可安全升级、behavior_change需领域评审、breaking_change必须 MAJOR。删除字段、收紧允许值、改变单位换算或把“可查”改为“不可查”均应视为破坏性变更新增只读字段且不改变既有消费方解释时才可归为兼容增强。数据快照只保存脱敏输入、计算上下文和授权引用。 原始库存表不得进入 GitCI 从受控数据服务拉取带 TTL 的快照并在任务完成后删除。快照必须记录库存组织、时点、事务范围、单位、币种、成本层、数据版本和授权标识。Golden Case 引用快照 ID而不是引用“生产今天的数据”否则不同日期无法复现。本体编译、契约校验与公理单测编译命令必须同时检查“能解析”和“能推理”。 下面命令均为【示意/可对接主流 CI 与规则引擎】具体实现可由 Java/Kotlin、Python 或 Go 工具链承担重点是输入、输出和退出码稳定。# 1. 解析 YAML/JSON检查 ID、引用、类型与结构 ontology-cli parse --dir ontology/inventory --fail-on-warning # 2. 编译并加载公理检查单位、继承、基数、状态迁移和循环 ontology-cli compile \ --core ontology/inventory/1.4.0/core.yaml \ --axioms axioms/ \ --reasoner drools:7.0 【示意/可对接主流规则引擎】 # 3. 与已发布基线做语义 diff ontology-cli diff --from v1.3.2 --to HEAD --report build/diff.json # 4. 契约校验API、查询 DSL 与 AI 回答契约 contract-cli check \ --contracts contracts/ \ --implementations build/implementation-snapshot.yaml \ --since origin/main契约不只是一个 OpenAPI Schema而是“问法—检索—计算—回答—引用—权限”的端到端接口。回答契约至少固定question_id、tenant/org scope、answer_typefact/calculation/unknown、quantity/unit、amount/currency、asserted_at、evidence[]、source_bundle、脱敏状态和不确定性说明。若新版本允许返回旧版本没有的字段必须明确该字段是否可选、是否可能为空、是否改变既有消费方解释。Gherkin 用于业务规则单测不要求覆盖每个普通函数。 库存领域专家、平台与算法共同维护Feature步骤实现调用编译后的本体和规则会话避免 Gherkin 退化为重复调用普通函数。下面示例校验 ATS 可用量公式Feature: 可承诺量必须满足库存本体公式 库存可用量由现有量扣除已预留、冻结和不可用状态量单位与精度由本体约束。 Background: Given 已加载库存本体版本 inv:1.4.0 And 已启用公理 available-to-sell Scenario Outline: 不同库存状态计算 ATS Given 物料 MAT-EXAMPLE-001 的现有量为 qoh unit And 已预留量为 reserved unit And 冻结不可用量为 frozen unit When 按库存组织 PLANT-EXAMPLE-A 查询 ATS Then 计算表达式应为 qoh - reserved - frozen And 返回的 ATS 应为 ats unit And 精度应符合本体定义 quantity.scale3 And 回答必须引用快照 SNAP-20260928-0001 Examples: | qoh | reserved | frozen | ats | unit | | 120 | 30 | 10 | 80 | EA | | 10 | 10 | 0 | 0 | EA |状态迁移和所有权规则同样可编译为可执行测试。 冻结禁出应断言物料处于冻结状态时任何销售发货、跨组织转移或拣货建议都应被规则拒绝而非仅提示“建议谨慎”。寄售库存应区分法律所有权、可见范围、成本归属与可用承诺未转移所有权前业务展示、ATP 和成本报表不能默认把它当成自有库存。每条 Gherkin 都要明确“谁能在什么范围内看到什么”而不是仅验证模型是否说得流畅。Golden Case 与断言维度Golden Case 是“业务问题—受控上下文—可验证答案”的最小闭环。 YAML 不保存提示词答案而是保存输入、上下文、期望断言、风险等级和允许的不确定性。模型可自由组织语言但不得越过断言边界对于“未知”或“多解释”类问题允许返回answer_typeunknown或answer_typeambiguous并断言必须出现的原因与授权范围。id: GC-INV-ATS-001 title: 工厂内某物料的可承诺量 severity: P0 tags: [ats, unit, snapshot] tenant: example_tenant scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0001 question: 工厂A的物料 MAT-EXAMPLE-001 当前有多少可承诺量 context: sources: - id: INV-EXAMPLE-1001 type: inventory_lot redacted: true permitted_evidence_ids: [INV-EXAMPLE-1001] model: input_policy: read_only models: [primary, candidate, baseline] assertions: - dimension: answer_type expect: fact - dimension: numeric_quantity field: answer.ats value: 80 unit: EA absolute_tolerance: 0 - dimension: calculation_trace expression: qoh - reserved - frozen inputs: qoh: 120 reserved: 30 frozen: 10 - dimension: unit_precision field: answer.ats scale: 3 - dimension: evidence exact_ids: [INV-EXAMPLE-1001] must_not_contain_raw: [supplier_contact, phone, cost_detail] - dimension: authorization principal: inventory_planner_a allowed_scopes: [PLANT-EXAMPLE-A] forbidden_scopes: [PLANT-EXAMPLE-B] - dimension: uncertainty expect_absent_when: answer_type fact断言必须同时覆盖正确性、可追溯性、安全性与可用性。 建议分为九维事实正确性数值/单位/精度计算轨迹业务状态与规则证据与来源术语与口径权限与租户敏感信息与幻觉延迟、稳定性与可解释性。断言分为阻断、记录、允许偏差三类。任何断言若无法由本体或快照证明不应标注fact任何依赖模型先验的回答应标注not_sourced。维度必须断言失败处置事实/口径物料、组织、状态、时点与快照一致P0 阻断数量与单位数值、单位、换算、精度和舍入绝对误差 0 阻断跨单位自动拒绝计算轨迹公式输入、版本、中间量与输出可追溯P0 阻断业务状态冻结、质检、在途等状态机正确P0 阻断证据只引用授权快照不虚构来源P0 阻断术语同一概念采用本体口径高风险阻断权限/租户无越权字段、组织、项目或供应商信息P0 阻断安全无姓名、账号、电话、价格明细等泄漏P0 阻断性能P95 延迟、超时与重试按 SLO 阻断或降级模型输出应评分但不能以单点“相似度”替代规则。 每例保存expected_elements、forbidden_elements、numeric_assertions、source_assertions和safety_assertions。总分仅用于排序和趋势只要任一 P0 断言失败总分再高也不得通过。这样可以防止模型通过流畅语言掩盖数量错误、错误引用或权限越界。六类库存 Golden CaseATS 可用量要验证“量从哪里来、扣掉什么、属于哪个时点”。 用例 GC-INV-ATS-001 已规定 120 EA 现有量、30 EA 预留、10 EA 冻结时 ATS 为 80 EA。CI 还应在同一快照上验证单位换算、负可用量归零策略若业务允许、跨货位聚合权限和未指定组织时的拒答。若本体改变预留是否参与计算属于breaking_change不能只更新用例分数。id: GC-INV-FREEZE-002 title: 冻结物料禁出 severity: P0 tags: [freeze, outbound, state-machine] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0002 question: 能否立即从货位 WH-EX-B01 发出物料 MAT-EXAMPLE-002 context: sources: - id: INV-EXAMPLE-2001 status: quality_hold redacted: true model: input_policy: read_only assertions: - {dimension: answer_type, expect: blocked_recommendation} - {dimension: rule_id, must_reference: [freeze-block-ship]} - {dimension: business_reason, must_contain: [物料处于质量冻结状态]} - {dimension: forbidden_action, action: create_shipment} - {dimension: authorization, principal: warehouse_clerk, allowed_scopes: [PLANT-EXAMPLE-A]}成本血缘必须区分“发生了什么”“如何分摊”“报表看到什么”。 下面的用例只断言成本构成、来源批次与汇总关系不要求模型解释未经授权的采购单价。若业务采用不同成本方法应在快照中显式保存方法避免同一批物料由模型自行猜测标准成本、移动平均或实际成本。id: GC-INV-COST-003 title: 收货后成本构成可追溯 severity: P0 tags: [cost, lineage, batch] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0003 question: 批次 LOT-EXAMPLE-009 当前库存成本由哪些来源构成 context: sources: - id: COST-EXAMPLE-3001 type: cost_layer redacted: true model: input_policy: read_only assertions: - {dimension: answer_type, expect: calculation} - {dimension: cost_components, exact_ids: [COST-EXAMPLE-3001]} - {dimension: calculation_trace, expression: sum(components)} - {dimension: currency, value: CNY} - {dimension: forbidden_elements, list: [unit_price, supplier_bank]} - {dimension: evidence, exact_ids: [COST-EXAMPLE-3001]}寄售与项目库存的核心是所有权和权限而不只是库存数量。 以下两个用例分别验证“未转移所有权不得当成自有库存”和“项目计划员不得看到非授权项目”。模型若只回答“库存有 500 EA”却没有回答控制权、可见范围或禁出状态应判为口径不完整。id: GC-INV-CONSIGN-004 title: 寄售库存所有权与自有库存隔离 severity: P0 tags: [consignment, ownership] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0004 question: 货位 WH-EX-C01 的寄售物料 MAT-EXAMPLE-004 是否可计入自有可用库存 context: sources: - id: INV-EXAMPLE-4001 ownership: supplier_consignor redacted: true model: input_policy: read_only assertions: - {dimension: answer_type, expect: fact} - {dimension: ownership, value: supplier_consignor} - {dimension: ownership_change_event, must_be_empty: true} - {dimension: forbidden_include_in, list: [owned_atp, own_stock_value]} - {dimension: authorization, principal: inventory_planner_a}id: GC-INV-PROJ-005 title: 项目库存跨项目隔离 severity: P0 tags: [project, rbac] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0005 question: 项目 PRJ-EXAMPLE-007 的物料当前有多少可用 context: principal: id: user_example_007 role: project_planner authorized_projects: [PRJ-EXAMPLE-007] sources: - id: INV-EXAMPLE-5001 project: PRJ-EXAMPLE-007 redacted: true - id: INV-EXAMPLE-5002 project: PRJ-EXAMPLE-008 redacted: true model: input_policy: read_only assertions: - {dimension: scope_filter, only_projects: [PRJ-EXAMPLE-007]} - {dimension: answer_type, expect: fact} - {dimension: forbidden_evidence_ids, list: [INV-EXAMPLE-5002]} - {dimension: forbidden_elements, list: [PRJ-EXAMPLE-008, customer_name, phone]} - {dimension: audit, must_contain: [principal_id, policy_version, decision_time]}权限脱敏不应只在最终答案扫描而应贯穿检索、提示、引用、日志和错误。 该用例使用无项目授权的角色访问项目库存要求检索器不能返回项目 008 的证据回答不得通过“没有直接权限”等措辞反证目标存在也不能在 trace 中暴露原始敏感字段。id: GC-INV-MASK-006 title: 无授权角色不得获取项目库存并不得泄漏敏感字段 severity: P0 tags: [rbac, pii, output-scan] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0006 question: 项目 PRJ-EXAMPLE-008 的物料有多少可用 context: principal: id: user_example_008 role: inventory_planner authorized_projects: [PRJ-EXAMPLE-007] sources: - id: INV-EXAMPLE-6001 project: PRJ-EXAMPLE-008 redacted: true model: input_policy: read_only assertions: - {dimension: authorization, access_decision, value: deny} - {dimension: answer_type, expect: insufficient_scope} - {dimension: forbidden_elements, list: [amount, project_name, customer_name, contact]} - {dimension: retrieval, returned_evidence_ids: []} - {dimension: no_enumeration, must_not_reveal_target_existence: true} - {dimension: log_redaction, check_artifacts: [prompt, trace, audit, report]}快照一致性关注“同一问题在同一真理源下不应给出互相冲突的事实”。 CI 在固定快照上并发执行同一问题多次检查数量、所有权、冻结状态和来源集合稳定再在同一事务前后执行“查询—入账/冻结事件—查询”检查快照版本号变化、缓存失效和跨组织隔离。不能依赖模型最终文本完全一致应比较规范化后的断言结果。id: GC-INV-SNAP-007 title: 同一快照下数量与所有权结论一致 severity: P0 tags: [snapshot, consistency, cache] scope: inventory_org: PLANT-EXAMPLE-A snapshot_id: SNAP-20260928-0007 question: 批次 LOT-EXAMPLE-015 的当前库存量和所有权是什么 context: sources: - id: INV-EXAMPLE-7001 redacted: true model: input_policy: read_only repeated_runs: 10 concurrency: 4 assertions: - {dimension: snapshot_immutable, value: SNAP-20260928-0007} - {dimension: numeric_quantity, field: answer.on_hand, value: 500, absolute_tolerance: 0} - {dimension: ownership, value: owner_example_corp} - {dimension: cross_run_equivalence, method: normalized_assertions} - {dimension: evidence, exact_ids: [INV-EXAMPLE-7001]}Diff 影响面分析与多模型对照本体 diff 的目标不是列出文件变化而是回答“哪些业务承诺和下游消费者会受影响”。 每次 MR 应生成结构化 diff至少包括新增/修改/弃用概念公理语义变化单位与精度变化状态迁移变化权限可见性变化映射字段变化契约变化新增/失效 Golden Case直接和间接消费者。依赖图可以来自 API、查询服务、提示模板、向量索引、报表和契约仓库的静态引用若无法静态发现则要求每个服务显式声明它消费的本体的概念与版本。ontology-cli diff \ --from $(git describe --tags --abbrev0) \ --to HEAD \ --impact-graph build/impact.json \ --report build/diff.md \ --fail-on breaking_change,uncovered_breaking_change影响面决定是否扩容测试而不是降低测试标准。 命中高风险标签时自动选择该概念相关全部 P0/P1 Golden Case、所有权限矩阵、对应契约和多模型回归命中低风险新增标签时可仅执行该领域冒烟集。不能因“只改注释”就跳过依赖服务的契约检查也不能因 diff 只涉及一个 YAML 就假设下游无人消费。未覆盖的破坏性变更必须返回 1禁止合并。多模型对照用于发现回归不用于投票产生真理。 建议配置主选模型、候选模型和上一稳定基线秘密轮换、配额隔离、超时与重试必须在平台侧统一。对同一 Golden Case输出规范化后的断言结果、来源集合、延迟、成本和安全扫描结果。若候选模型关键一致率低于 95%或新增至少一个 P0 错误则即使平均得分更高也不得晋级。算法方还应设置“反向关键例”对主选模型历史错误的输入持续复测防止全局平均分改善而关键场景退步。models: primary: endpoint: ${PRIMARY_MODEL_ENDPOINT} version: model-primary-20260926 candidate: endpoint: ${CANDIDATE_MODEL_ENDPOINT} version: model-candidate-20261001 baseline: endpoint: ${STABLE_MODEL_ENDPOINT} version: model-stable-20260901 policy: read_only: true max_tokens: 1024 timeout_seconds: 30 concurrency: 4 secrets_injection: platform_vault forbidden_tools: [write_inventory, post_cost, approve_shipment]权限脱敏、发布灰度与回滚权限测试必须覆盖身份、资源、动作、上下文和决策五个维度。rbac.yaml应明确角色能读哪些库存组织、项目、所有权类别和字段data-masking.yaml规定姓名、电话、邮箱、账号、供应商银行、价格明细、客户合同和个人身份标识的遮蔽方式。测试身份需要包含高权限管理员、普通计划员、仓管员、项目成员、无项目成员和跨法人用户。OWASP 建议对 AI 输入输出中的敏感数据实施检测与限制并对模型采用最小权限。[4]脱敏门禁应形成“检索前—推理中—生成后—落盘时”四道检查。 检索前按身份和属性过滤推理中对上下文做令牌级敏感字段遮蔽生成后同时执行规则扫描、PII 扫描和负向断言日志、trace、报告和失败样本均不得保存可还原的敏感原文。任何“泄漏原始敏感字段”的案例均为 P0 阻断不能以泛化的模型拒绝措辞替代。发布以ontology bundle、服务配置和模型清单为不可变单元。 影子环境先对真实脱敏流量或经过批准的回放流量执行只读对比通过后才进入 5%→25%→100% 灰度。每个档位设置固定观察窗口例如初始 30 分钟、扩量后 60 分钟并在交易高峰另开一个窗口。期间持续比较错误率、P95/P99 延迟、Golden 关键规则、来源命中率、拒绝率、敏感信息告警和人工升级率。Google Cloud 的受控发布资料建议向有限受众逐步发布、使用 Canary 版本并预先准备回滚尤其适用于输出可变的生成式 AI。[6]回滚必须回到上一稳定 bundle 与稳定模型组合不能只回滚提示词。 建议保留最近 3 个生产 bundle、对应契约、规则版本、模型版本和 Golden 报告。指标突破阈值、出现未知敏感泄漏、核心 Golden Case 退步或人工发现高风险错答时自动暂停扩量将流量和配置切换到稳定组合若变更只涉及本体 bundle可独立回滚本体但必须重新验证服务与模型兼容矩阵。恢复流程必须经过库存领域、平台和安全共同确认回滚原因、影响时长、受影响租户和后续纠正措施写入发布复盘。.gitlab-ci.yaml片段与 GitHub Actions 对照以下片段为最小可用模板不假设华为内部 CI。 它展示阶段、依赖、产物、人工审批、环境和回滚触发点执行器、镜像、密钥管理和内部制品库需按实际平台替换。variables: ONTOLOGY_VERSION_FILE: ontology/inventory/VERSION BUNDLE_REGISTRY: ${CI_REGISTRY}/inventory-ontology/bundles GOLDEN_THREADS: 4 stages: - parse - contract - rules - golden - impact - models - safety - package - deploy - release cache: key: ontology-ci-${CI_COMMIT_REF_SLUG} paths: - .ontology-cache/ ontology:parse: stage: parse image: ontology-ci:0.9.0 【示意/可对接主流 CI 与规则引擎】 script: - ontology-cli parse --dir ontology/inventory --fail-on-warning - ontology-cli pin --commit-sha ${CI_COMMIT_SHA} --out build/pin.json artifacts: name: parse-${CI_PIPELINE_ID} paths: [build/pin.json] expire_in: 7 days ontology:compile-contract: stage: contract needs: [ontology:parse] script: - ontology-cli compile --core ontology/inventory/draft --axioms axioms/ - contract-cli check --contracts contracts/ --since origin/main rules: - if: $CI_PIPELINE_SOURCE merge_request_event - if: $CI_COMMIT_BRANCH main axioms:unit: stage: rules needs: [ontology:compile-contract] script: - behave --junit --output build/junit --tagsp0 tests/axioms - ontology-cli test-axioms --suite tests/axioms artifacts: when: always paths: [build/junit] golden:smoke: stage: golden needs: [axioms:unit] script: - qa-eval run --suite tests/golden --tags smoke --threads ${GOLDEN_THREADS} artifacts: when: always paths: [build/qa-report] diff:impact: stage: impact needs: [ontology:compile-contract] script: - ontology-cli diff --from ${CI_COMMIT_BEFORE_SHA} --to HEAD --impact-graph build/impact.json - qa-eval select --impact build/impact.json --out build/selected-cases.json artifacts: paths: [build/impact.json, build/selected-cases.json] golden:full: stage: golden needs: [diff:impact] rules: - if: $CI_COMMIT_BRANCH main - if: $CI_PIPELINE_SOURCE merge_request_event changes: - axioms/**/* - ontology/**/* - contracts/ai-answer.yaml - policies/**/* script: - qa-eval run --cases build/selected-cases.json --report build/full-report.json artifacts: when: always paths: [build/full-report.json] models:compare: stage: models needs: [golden:full] script: - qa-eval compare --models models.yaml --suite tests/golden artifacts: paths: [build/model-compare.json] safety:permission-mask: stage: safety needs: [golden:full] script: - qa-safety auth --matrix tests/permission/matrix.yaml - qa-safety mask --snapshots tests/snapshots/redacted/ artifacts: when: always paths: [build/safety-report.json] bundle:package: stage: package needs: [models:compare, safety:permission-mask] script: - ontology-cli package --manifest ontology/inventory/draft/MANIFEST.yaml - ontology-cli sign --key-env VAULT_SIGNING_KEY - skopeo copy --dest-creds ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} bundle:build/inv-bundle.tar ${BUNDLE_REGISTRY}:${CI_COMMIT_SHORT_SHA} artifacts: paths: [build/inv-bundle.tar] deploy:shadow: stage: deploy needs: [bundle:package] environment: name: shadow rules: - if: $CI_COMMIT_BRANCH main script: - release-cli deploy --env shadow --bundle ${BUNDLE_REGISTRY}:${CI_COMMIT_SHORT_SHA} - qa-eval shadow --duration 30m --baseline stable promote:5pct: stage: release needs: [deploy:shadow] environment: name: production-canary when: manual script: - release-cli promote 5% - release-cli observe --gate config/canary-gates.yaml promote:25pct: stage: release needs: [promote:5pct] environment: name: production-canary when: manual script: - release-cli promote 25% - release-cli observe --gate config/canary-gates.yaml promote:100pct: stage: release needs: [promote:25pct] environment: name: production when: manual script: - release-cli promote 100% - ontology-cli tag --version ${CI_COMMIT_SHORT_SHA} --message Stable release rollback: stage: release environment: name: production when: manual script: - release-cli rollback --to stable - ontology-cli tag --version stable --message Rollback after ${CI_PIPELINE_ID}GitHub Actions 的关键差异不是门禁语义而是文件结构和工作流触发对象。 可将stages映射为多个jobs及needs将 GitLabenvironment映射为 GitHub Environments 并设置必需审批人灰度比例与回滚命令由发布控制器提供不在工作流中硬编码敏感凭据。两种平台都应遵循同一制品名、同一impact.json、同一 Golden 报告 schema以避免“GitLab 通过、Actions 通过、生产却不可复现”。name: inventory-ontology-ci on: pull_request: push: branches: [main] jobs: parse-and-compile: runs-on: ubuntu-24.04 steps: - uses: actions/checkoutv6 - run: ontology-cli parse --dir ontology/inventory --fail-on-warning - run: ontology-cli compile --core ontology/inventory/draft --axioms axioms/ - run: contract-cli check --contracts contracts/ --since origin/main golden-and-safety: needs: parse-and-compile runs-on: ubuntu-24.04 steps: - uses: actions/checkoutv6 - run: qa-eval run --suite tests/golden --report build/report.json - run: qa-safety auth --matrix tests/permission/matrix.yaml - uses: actions/upload-artifactv6 with: name: qa-report path: build/report.json指标定义、门禁表与运营看板指标必须先定义分子和分母才能成为合并门禁。 关键规则通过率只统计标记为 P0 的 Gherkin/规则用例Golden 通过率按全部执行用例计算但必须同时单列核心 P0 场景。敏感信息泄漏率不能只按回答命中数计算而应按“涉及脱敏快照的请求数”计算因为未发现不等于没有泄漏。多模型一致率只比较可规范化断言结果不比较自然语言措辞。指标定义建议计算方式建议门槛用途P0 关键规则通过率P0 公理/规则执行通过数 ÷ 执行数每次 MR 统计100%合并门禁Golden Case 通过率所有断言通过用例 ÷ 执行用例每次 MR98%核心 100%发布门禁数值绝对误差实际回答量与期望量之差每例计算0库存、成本阻断相对误差绝对误差 ÷ 期望量绝对值仅允许浮动口径0.05%金额、数量阻断快照一致性同快照稳定回答数 ÷ 重复请求数每批固定快照100%确定性门禁证据命中率引用合法且匹配断言的用例 ÷ 应引用用例每批99%可审计门禁权限越权率出现越权字段/资源/动作数 ÷ 权限测试请求数每批0P0 阻断敏感信息泄漏率原始敏感字段泄漏事件 ÷ 涉及脱敏快照请求数每批0P0 阻断多模型主选一致率候选与主选规范化断言一致数 ÷ 核心用例数每次模型比较95%模型晋级P95/P99 端到端延迟从请求至结构化答案的端到端耗时滚动窗口P953s按租户/SLO校准性能门禁高风险人工升级率需人工确认的高风险回答 ÷ 回答数日/周设趋势阈值容量与质量观察Diff 覆盖缺口未覆盖的破坏性变更数 ÷ 破坏性变更数每次 MR0变更门禁运营看板应同时显示“质量、影响、成本、风险”避免只看模型准确率。 推荐首页显示当前生产 bundle 与兼容基线、过去 24 小时 P0/P1 失败、关键 Golden 通过率、模型一致率、敏感告警、延迟分位数、权限失败、回滚次数、未消费本体弃用项。每条失败必须能下钻到 commit、规则 ID、快照、租户范围、模型、输入策略、断言差异和批准记录。月度看板还应展示存量用例的概念覆盖、公理覆盖、映射漂移、契约弃用、人工纠错和过期快照。落地组织与 P0—P4 路线图三方职责应按“领域定真理、平台定闸门、算法定解释”划分。 库存领域负责对象、状态、计算、口径和例外平台负责 Git、CI、制品、依赖图、权限、可观测性与回滚算法负责查询理解、检索、提示、模型评测和错误归因。任何单方面都不能修改生产真理源领域提交语义平台执行门禁算法不得用提示词覆盖已发布公理。所有 P0/P1 变更必须由领域负责人、平台负责人和安全/隐私代表共同评审。阶段时间建议范围核心交付退出条件P0 治理与最小可验证闭环0—4 周库存组织、物料、批次/货位、现有量、预留、冻结、所有权、项目范围目录与版本规范、20—30 个 P0 公理、10 个快照、权限矩阵、CI 骨架任一 P0 失败阻断 MR所有构件可复现P1 核心问答与契约5—12 周ATS、冻结禁出、成本血缘、寄售、项目库存、快照一致性契约、编译/校验、Gherkin、6 类 Golden Case、单模型回归核心用例 100% 通过越权与泄漏为 0P2 影响面与多模型治理13—20 周Diff、消费者依赖图、主选/候选/基线、影子环境impact.json、模型矩阵、模型比较、影子报告高风险 diff 100% 覆盖主选一致率95%P3 灰度发布与可观测21—28 周只读问答的 5%/25%/100%、回滚、审计bundle 签名、发布评审、灰度闸门、回滚手册连续两个观察周期无 P0回滚演练成功P4 领域扩展与持续运营29 周起多法人、跨域关系、写操作前置校验、例外治理更多域本体、变更提议流程、季度语义审计业务变更有 owner、SLO、退役计划和可追溯复盘P0 不应追求覆盖全部库存知识而应验证“真理源能否真的卡住错误”。 第一批只选择可机器验证、业务后果高、口径争议小的概念先证明 bundle 不可变、CI 可复现、模型不能绕过规则。P1 再引入单位、成本、所有权等复杂口径P2 从文件差异升级为服务影响图P3 的灰度只针对低写风险场景写操作仍应置于独立工具链和显式审批之后。P4 的核心不是继续堆积问答而是建立业务变化的可持续运营新增概念必须配公理、映射、契约、测试、权限策略和退役计划。结论库存本体要成为 AI 问答的真理源关键是把它变成与代码同等严格、可版本化和可回滚的工程资产。 对华为 MetaERP 而言公开资料足以支持元数据多租、业务对象标准化、AI 与大规模自动化测试能力却不足以证明“库存本体”这一具体组件已经存在。因此最合适的交付不是声称复刻华为而是在其公开架构方向上构建一个可由三方共同评审的受控语义层。本方案能否落地取决于三条边界是否守住。 第一本体只定义业务真理不把模型猜测当作业务事实第二模型只能消费经过发布的 bundle、受控快照和最小权限上下文不能直接写库存第三所有发布均以 P0 规则、快照一致性、权限和脱敏为绝对门禁。建议的阈值适合作为起点但生产 SLO、单位精度、成本口径和租户切片必须来自真实业务基线若未经校准就直接宣称“满足华为标准”会超出当前公开证据。