> 译文仅供阅读便利。具有规范效力的是英文原文。 # 从 v1 迁移 **元宇宙规范** **文档编号：** MU-V2-GUIDE-005 **标题：** 从元宇宙 v1.x 迁移到 v2 的指南 **文档类别：** 说明性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** MUC、MMAS、MUFP **说明性引用：** Repository-Structure、Create-a-New-Meta-Model、Federation-Guide **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 这份指南讲的是，如何把既有的元宇宙 v1.x 仓库与元模型迁到元宇宙 v2 的架构上。 迁移既保全历史上的知识，也让仓库与 v2 所引入的宪章、架构与联邦诸原则对齐。 迁移是演进式的，不是掀桌式的。 --- # 1a. 迁移的三个层面 迁移并非一次性的一件事。它发生在**三个各自分明的层面**上，各层可以按各自的快慢推进，也可以分开来想： - **结构迁移** - *仓库与文档的结构*：目录布局、文件的组织、文档编号与文首信息。这一层最显眼，也最容易自动化。 - **语义迁移** - *术语、概念、关系与规则*：星系如何变成命名空间，对象如何变成元对象，名字换了而意义如何得以保全。迁移的实质在此。 - **联邦迁移** - *模型如何与别的宇宙打交道*：采纳信任、身份绑定、语义映射、合约与投影同步，好让迁过来的模型能参与更广的生态。 结构迁移搬的是文件；语义迁移保全的是文件里的意义；联邦迁移恢复的是这份模型与其他模型的关系。一次完整的迁移，三者都要照应到。 ## 1a.1 迁移的不变量 无论在哪一层，迁移都： - 是**可追溯的** - 每一处改动都能从来源一路跟到结果； - 是**可逆地讲得清的** - 缘由与先前状态都被记下，于是一处改动既能被弄懂，必要时也能被退回； - **保全历史的连续** - 过往的版本与事件仍然可得； - **不破正典身份** - 身份原封不动地熬过这场搬迁； - **不悄悄改动意义** - 意义上的任何改变，都记成一次明写的迁移事件，绝不作为重构未加声明的副作用。 最后这一条最要紧：结构上的改动可以是无声的，语义上的不可以。意义只经由一次声明过的迁移事件而改变。 --- # 2. 迁移的立场 对迁移的期望是： - 保全历史的可追溯； - 避开语义上的损失； - 把破坏性的改动压到最少； - 一步一步地引入新概念； - 保全那些正典身份。 历史仍是仓库的一部分。 --- # 3. v2 的主要变化 版本 2 引入： - 元宇宙宪章（MUC）； - 元模型架构标准（MMAS）； - 元宇宙联邦协议（MUFP）； - 参考架构； - 生态各规范； - 标准化的仓库组织方式。 这些添加是对先前概念的扩充，而不是取代。 --- # 4. 仓库的迁移 建议的迁移步骤： 1. 把既有的 v1 仓库结构归档。 2. 建起 v2 的目录布局。 3. 把历史文档挪进 `archive/v1/`。 4. 引入新的基础文档。 5. 加上宪章类规范。 6. 加上架构类规范。 7. 加上联邦类规范。 8. 校验仓库的自洽。 历史上的各次发布仍然可得。 --- # 5. 概念的对应 概念演进的典型样子： - 星系 → 命名空间 - 元宇宙 → 宇宙 - 既有的对象 → 元对象 - 既有的投影 → 投影（不变） - 既有的身份 → 正典身份 概念的演进，保全的是语义上的本意。 --- # 6. 命名空间的迁移 命名空间成了一等的架构元素。 既有的标识符，凡兼容者可以原样留着。 命名空间的所有权变得明写。 --- # 7. 仓库结构的迁移 既有的文档被重新理进： - 00-foundation - 01-constitution - 02-architecture - 03-federation - 04-core-concepts - 05-reference-architecture - 06-ecosystem - 07-guides 重新整理，保全的是文档的历史。 --- # 8. 联邦的迁移 仓库采纳 MUFP 的诸概念，包括： - 信任模型； - 身份绑定； - 语义映射； - 联邦合约； - 投影同步。 联邦可以一点一点地引入。 --- # 9. 校验 迁完之后核实： - 仓库的组织； - 文档编号； - 术语是否前后一致； - 命名约定； - 文档之间的交叉引用； - 版本元数据。 凡切实可行处，校验都交给自动化。 --- # 10. 向后兼容 元宇宙 v2 的设计，是要在切实可行处保全与 v1 概念的兼容。 历史上的术语，可以留在归档的文档之内。 当前的文档用 v2 的术语。 --- # 11. 建议的迁移流程 建议的次序： 1. 归档 2. 重新整理 3. 概念改名 4. 引入 MUC 5. 引入 MMAS 6. 引入 MUFP 7. 加上参考架构 8. 加上生态 9. 校验 10. 发布 每一步都仍然可追溯。 --- # 12. 迁移中常遇的难处 典型的问题有： - 术语重复； - 身份前后不一； - 缺了可追溯性； - 面向技术来写的描述； - 领域边界混在一起。 迁移把语义上的一致，看得比文档的布局更重。 --- # 13. 迁移检查清单 发布之前核实： - 归档是齐全的； - 仓库遵循 v2 的结构； - 术语已更新； - 凡适用之处，命名空间已取代星系； - 各处引用有效； - 校验通过； - 历史得以保全。 --- # 14. 往后的演进 迁到 v2 的仓库，已经准备好去做： - 在登记册上发布； - 生成兼容性矩阵； - 认证； - 联邦配置； - 由 AI 协助的校验。 迁移，是为仓库长久参与这片生态做准备。 --- # 15. 未来方向 迁移的语义层面，会因一部专门的**语义迁移标准（SMS）**而受益。SMS 会把意义如何跨版本传承这件事形式化：一套迁移事件的词汇、旧概念到新概念的机器可读映射、可追溯与可逆的保证，以及确保没有哪份意义会在没有明写、留档的迁移事件之下改变的合规规则。有了 SMS，结构迁移与语义迁移便可被校验，甚至部分自动化，同时让正典身份与历史的连续在整个宇宙范围内毫发无损。 --- # 结语 迁到元宇宙 v2，是一次架构上的演进，而不是一次重写。 既保全历史上的知识，又采纳宪章式的治理、标准化的架构与语义联邦，组织便能以最小的动荡把既有仓库现代化，并把它们摆到一个位置上：在这片渐长的元宇宙生态里长久地互操作。