> 译文仅供阅读便利。具有规范效力的是英文原文。 # 良好实践 **元宇宙规范** **文档编号：** MU-V2-GUIDE-006 **标题：** 良好实践 **文档类别：** 说明性 **版本：** 2.0（草案） **状态：** 工作草案 **规范性引用：** MUC、MMAS、MUFP **说明性引用：** Design-Recommendations、Create-a-New-Meta-Model、Federation-Guide **版权：** © Orkestron.AI **许可：** Apache-2.0 --- # 1. 目的 这份指南把设计、发布并演进合乎元宇宙的元模型时所建议的做法归拢到一处。 这些建议出自 MUC、MMAS 与 MUFP 的诸原则，属经过验证的架构指点，而非强制的要求。 --- # 1a. 知识的三个层次 元宇宙的知识存在于**三个层次**，而这份指南占的是第三层。把它们分清，便知何者有约束力、何者只是建议、何者不过是经验之下的判断： - **规范层** - *必须遵从的东西*。也就是那些标准本身：MUC、MMAS 与 MUFP。合规是强制的，也是可核验的。 - **参考层** - *所建议的架构*。参考架构与各份参考领域元模型，示出一条已知可行的施用之路。 - **良好实践层** - *老练的架构师实际上如何取舍*。当标准留出判断余地时，经验丰富的从业者所用的那些积累下来的心法与习惯。 可拿万维网的文档方式作比。**HTTP 的 RFC** 定的是协议（规范层）；**架构指南**示出在其上建造的建议方式（参考层）；而**实用建议**记的则是老练的工程师实际怎样设计真实系统（良好实践层）。三者缺一不可：协议担保互操作，架构示出一个验证过的形状，而实践传递的是任何规范都无法完全编码下来的经验。本文档属第三层 - 它绝不凌驾于第一层之上。 --- # 2. 用语义去想，不要用技术去想 永远先为业务上的现实建模。 DO: - 认出概念； - 认出意义； - 定下关系。 不要去为这些建模： - 数据库的表； - REST 端点； - 编程语言里的类； - 存储结构。 技术变得比语义快。 --- # 3. 宁取小的领域模型 造那些各守其题的领域元模型。 好的例子： - 员工 - 组织 - 产品 - 客户 不要去造那种想把每个领域都描述一遍的庞大通用模型。 论建模，联邦胜过整块。 --- # 4. 先复用，再创造 在引入一个新概念之前： - 到已登记的元模型里找一找； - 翻一翻导入过的标准； - 查一查语义包； - 掂量各种联邦配置。 凡有可能，就复用已有的语义。 --- # 5. 让身份成为正典的 把这几样分开： - 正典身份； - 本地身份； - 身份绑定。 正典身份在整个生命周期中始终稳定。 --- # 6. 把关系设计得明明白白 关系最好这样设计： - 名字清楚； - 表达业务上的含义； - 自身可独立追溯； - 避开实现方面的术语。 关系立得好，AI 的推理就更顺。 --- # 7. 把事件明写地建出来 把事件当作一等的语义产物。 要紧的业务变动，都会生出事件。 不要单凭当下的状态去重建历史。 --- # 8. 用投影，不用副本 绝不要把内部模型直接露出去。 造出与下列各项相称的投影配置： - 受众； - 目的； - 披露政策； - 语境。 以投影相分享，语义上的漂移最小。 --- # 9. 语境总要定下来 每一份投影、每一次来往，都要定下： - 目的； - 受众； - 假设； - 可见性。 意义，取决于语境。 --- # 10. 保全出处 每一件有分量的产物，都要保全： - 来处； - 所有者； - 发布它的权威； - 版本； - 相关的事件。 信任，落在出处之上。 --- # 11. 为联邦而设计 就当每一份元模型早晚都可能参与联邦。 备好： - 语义映射； - 身份绑定； - 合约； - 同步的策略。 联邦的就绪，不该是事后才想起的事。 --- # 12. 版本要走得稳 用语义化版本。 避开不必要的破坏性改动。 凡切实可行处，都把兼容守住。 演进，保全的是语义上的连续。 --- # 13. 持续地校验 校验所核实的是： - 是否合乎 MUC； - 是否合乎 MMAS； - 命名； - 可追溯性； - 语境； - 投影的设计； - 兼容性。 凡切实可行处，就把校验交给自动化。 --- # 14. 把历史留住 绝不要重写语义上的历史。 宁可： - 用不可变的事件； - 把版本归档； - 只追加地演进。 历史越全，越讲得清。 --- # 15. 写文档，既给人也给 AI 文档最好保持： - 简洁； - 有结构； - 凡切实可行处让机器读得懂； - 语义上前后一致。 仓库的消费者，既有人，也有 AI 智能体。 --- # 16. 把元数据发布齐全 发布： - 所支持的标准； - 版本； - 兼容性； - 合规； - 治理； - 许可。 元数据齐备，发现与复用都更顺。 --- # 17. 定期复核 隔一段时日就复核一次： - 术语； - 映射； - 合约； - 投影； - 校验结果； - 兼容性声明。 不断改进，长远的互操作才立得住。 --- # 18. 设计检查清单 发布之前问一问： - 领域是否界限分明？ - 身份是正典的吗？ - 语境是明写的吗？ - 投影是否已定下？ - 事件是否齐全？ - 出处是否保全？ - 联邦是否可行？ - AI 能读懂这份模型吗？ - 这份模型能稳妥地演进吗？ --- # 19. 未来方向 随着实践经验渐渐积厚，良好实践这一层可以凝成一部**元宇宙架构手册** - 一份经过甄选、与规范性标准相伴的读物，把验证过的模式、反模式、走通的例子与取舍的心法收在一处。这样一部手册会稳稳地留在知识的第三层：它讲的是*老练的架构师如何取舍*，会与参考架构和[设计建议](Design-Recommendations.md)相互援引，且绝不凌驾于 MUC、MMAS 或 MUFP 之上。它会是社群积累下来的判断被写下来、并且一直保持新鲜的那个地方。 --- # 结语 成功的元模型，是围着稳定的语义概念设计出来的，而不是围着一时的实现细节。 把这些良好实践一以贯之地用起来，组织便造出可复用、可解释、可互操作的语义模型：它们能跨数十年演进，能参与联邦，能同时托住人的协作与 AI 原生的知识系统，而身份、信任与治理都不打折扣。