企业官网建设流程全解析

库存本体 AI 问答 CI 配置清单

摘要

截至 2026 年 9 月，公开资料能够支持的结论是：华为 MetaERP 采用云原生、元数据多租和实时智能等架构方向，将业务对象、实体、逻辑等元数据资产标准化，并以 8,767 个分钟级流水线、3 周验证 1.5 万个测试场景支撑全球切换；但公开资料没有证明华为 MetaERP 已经存在名为“库存本体”的产品、服务或 AI 问答实现，也没有公开其本体语言、规则引擎、内部 CI 平台或灰度工具。[1][2] 因此，本报告不将其写成华为内部事实，而是给出一套“待评审、待接入”的工程方案：库存领域语义、公理、映射与契约统一进入 Git，每次合并形成不可变ontology bundle；CI 依次执行解析、静态/语义校验、公理单测、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.0@sha256:...。查询服务、提示模板、向量化管道和 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 报告、安全扫描、回滚版本和应急联系人。

建议阈值必须先作为红线，再按生产基线校准。​ 图中红线不是华为公开实测，而是内部库存问答治理的起始建议。数值与金额以业务单位同口径比较：数量绝对误差为 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）。删除字段、收紧允许值、改变单位换算或把“可查”改为“不可查”均应视为破坏性变更；新增只读字段且不改变既有消费方解释时，才可归为兼容增强。

数据快照只保存脱敏输入、计算上下文和授权引用。​ 原始库存表不得进入 Git；CI 从受控数据服务拉取带 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_type（fact/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.scale=3" 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_type=unknown或answer_type=ambiguous，并断言必须出现的原因与授权范围。

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。

模型输出应评分，但不能以单点“相似度”替代规则。​ 每例保存expected_elements、forbidden_elements、numeric_assertions、source_assertions和safety_assertions。总分仅用于排序和趋势；只要任一 P0 断言失败，总分再高也不得通过。这样可以防止模型通过流畅语言掩盖数量错误、错误引用或权限越界。

六类库存 Golden Case

ATS 可用量要验证“量从哪里来、扣掉什么、属于哪个时点”。​ 用例 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 --abbrev=0) \ --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 --tags=p0 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/checkout@v6 - 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/checkout@v6 - run: qa-eval run --suite tests/golden --report build/report.json - run: qa-safety auth --matrix tests/permission/matrix.yaml - uses: actions/upload-artifact@v6 with: name: qa-report path: build/report.json

指标定义、门禁表与运营看板

指标必须先定义分子和分母，才能成为合并门禁。​ 关键规则通过率只统计标记为 P0 的 Gherkin/规则用例；Golden 通过率按全部执行用例计算，但必须同时单列核心 P0 场景。敏感信息泄漏率不能只按回答命中数计算，而应按“涉及脱敏快照的请求数”计算，因为未发现不等于没有泄漏。多模型一致率只比较可规范化断言结果，不比较自然语言措辞。

运营看板应同时显示“质量、影响、成本、风险”，避免只看模型准确率。​ 推荐首页显示：当前生产 bundle 与兼容基线、过去 24 小时 P0/P1 失败、关键 Golden 通过率、模型一致率、敏感告警、延迟分位数、权限失败、回滚次数、未消费本体弃用项。每条失败必须能下钻到 commit、规则 ID、快照、租户范围、模型、输入策略、断言差异和批准记录。月度看板还应展示存量用例的概念覆盖、公理覆盖、映射漂移、契约弃用、人工纠错和过期快照。

落地组织与 P0—P4 路线图

三方职责应按“领域定真理、平台定闸门、算法定解释”划分。​ 库存领域负责对象、状态、计算、口径和例外；平台负责 Git、CI、制品、依赖图、权限、可观测性与回滚；算法负责查询理解、检索、提示、模型评测和错误归因。任何单方面都不能修改生产真理源：领域提交语义，平台执行门禁，算法不得用提示词覆盖已发布公理。所有 P0/P1 变更必须由领域负责人、平台负责人和安全/隐私代表共同评审。

P0 不应追求覆盖全部库存知识，而应验证“真理源能否真的卡住错误”。​ 第一批只选择可机器验证、业务后果高、口径争议小的概念，先证明 bundle 不可变、CI 可复现、模型不能绕过规则。P1 再引入单位、成本、所有权等复杂口径；P2 从文件差异升级为服务影响图；P3 的灰度只针对低写风险场景，写操作仍应置于独立工具链和显式审批之后。P4 的核心不是继续堆积问答，而是建立业务变化的可持续运营：新增概念必须配公理、映射、契约、测试、权限策略和退役计划。

结论

库存本体要成为 AI 问答的真理源，关键是把它变成与代码同等严格、可版本化和可回滚的工程资产。​ 对华为 MetaERP 而言，公开资料足以支持元数据多租、业务对象标准化、AI 与大规模自动化测试能力，却不足以证明“库存本体”这一具体组件已经存在。因此，最合适的交付不是声称复刻华为，而是在其公开架构方向上构建一个可由三方共同评审的受控语义层。

本方案能否落地，取决于三条边界是否守住。​ 第一，本体只定义业务真理，不把模型猜测当作业务事实；第二，模型只能消费经过发布的 bundle、受控快照和最小权限上下文，不能直接写库存；第三，所有发布均以 P0 规则、快照一致性、权限和脱敏为绝对门禁。建议的阈值适合作为起点，但生产 SLO、单位精度、成本口径和租户切片必须来自真实业务基线；若未经校准就直接宣称“满足华为标准”，会超出当前公开证据。