# 包、层与记录

*构建元模型 · 第 2 课，共 6 课 · 约 15 分钟*

## 你将学到

模型内容实际上如何组织与书写：包 → 层 → 记录的层级、承载含义的命名，以及什么样的记录才算好。

## 层级

- **包**是一项语义责任："产品为何存在"、"系统设计"、"质量与风险"。包是有序的：基础在前，这样单次顺序阅读就能先遇到定义再遇到用法。
- **层**是包内部的一个问题："相关方有哪些？"、"有哪些 API？"。层目录里有一份 `README.md`，写明这一层所回答的问题：这份 README *就是*该层的含义声明。
- **记录**是一条可独立路由的陈述：一条需求、一项决策、一份 API 契约、一个风险。一条记录，一个文件。

旗舰领域元模型 AISMM 为"软件产品"这一领域固定了十三个包（从 b0 产品核心到 b12 经济性），约 90 个层。你的领域会有自己的包；机制完全相同。

## 机器能读的名字

记录遵循一套把分类写进文件名的命名约定：

```text
{record_kind}-{YYMMDDNNNNN}-{memo}.md
   req-26071800001-minor-parental-consent.md
   decision-26061500001-concept-decisions.md
   i18n-26060300001-languages-roster.md
```

前缀是记录的种类（需求、决策、api、风险……），数字是可排序的、基于日期的标识，备注给人看。因为种类就在名字里，清单中一条声明的规则就能分类成千上万个文件（下一课）。两个来之不易的细节：前缀可以包含数字（`i18n`），而标识一经诞生便永不更改，哪怕备注或内容变了：引用的稳定性胜过好看。

## 记录内部是什么

一条记录有两部分：机器块与人类正文。机器块（front matter）承载身份（文档标识、层、产品）、分类（`kind_class`：这对产品而言是*规范性*的、是对它的*描述*，还是别的东西的*投影*？），以及关键的**推导**：如果这条记录是智能体从来源生成的，机器块会说明来自什么、由谁、如何转换、以及是否有所有者校验过。正文则是普通的、写得不错的散文与结构化数据：标准对你的文风没有意见，只对你的可追溯性有意见。

正是 `kind_class` + `derivation` + `validation_status` 这三件套，让人机混合团队能够信任一个模型：你总能分清哪条是所有者已校验的规范性陈述，哪条是智能体对某个 wiki 页面未经校验的概括。

## 什么样的记录才算好

- **只谈一件事。** 如果不用"和"就没法给它起标题，那就拆开。
- **可路由。** 被指派"处理 req-26071800001"的人，无需别的东西就能找到自己的活。
- **引用，而非重复。** 记录引用正典、引用 `raw/` 中的证据，也彼此引用；同一个事实说两遍，最终只会有一遍是真的。
- **对状态诚实。** 草稿、未校验、已被取代：状态是元数据，不是秘密。

## 要点

- 包 = 责任，层 = 问题，记录 = 一条可路由的陈述。
- 文件名承载种类；front matter 承载身份、分类与推导。
- 可追溯性（谁从什么推出了它、谁校验了它）正是让智能体所写内容可用的关键。

## 深入阅读

- [MMAS 核心架构](/spec/#02-architecture/MMAS-Core.md) · [命名约定](/spec/#02-architecture/Naming-Conventions.md)
- [创建新的元模型](/spec/#07-guides/Create-a-New-Meta-Model.md)
- AISMM，旗舰领域元模型：[github.com/orkestron-ai/software-meta-model](https://github.com/orkestron-ai/software-meta-model)

下一课：[无损遍历](03-walk.md)