---
title: "知识网络构建规则"
author: "Perrin Yong"
author_profile: https://www.pystone.net/profile/
published_by: "Perrin Yong"
canonical: https://www.pystone.net/notes/knowledge-network-build-rules/
type: note
content_role: guide
source_type: "guide"
visibility: public
id_stability: rename-stable
source_path: "00-总览与索引/04-知识网络构建规则.md"
content_hash: d719194fb574ff23075ec892356f9422f12e4f03a8175636c6e0c4e42c91a158
knowledge_version: 224c990773de.5fa8af6e39fa
site_commit: 224c990773de166d23a886306577dd90379529ce
notes_commit: 5fa8af6e39fa3891d1b9b4832bfa6c4e0ecaaf0a
---
# 知识网络构建规则

## 两套结构各司其职

- 文件树回答“笔记的主要角色和归档位置是什么”。一篇笔记只需要一个稳定位置。
- 双向链接回答“这条知识与哪些概念、问题和实践相关”。一篇笔记可以同时属于多个关系网络。
- MOC（Map of Content）是人工维护的认知地图，不是标签列表，也不是全文目录。
- frontmatter `note_id` 回答“这篇笔记的对外稳定身份是什么”。它是标题语义翻译成的小写英文单词加连字符（全库唯一），作为博客 URL 后缀与图节点身份；笔记移动、改名都不更换它。它不参与库内 Obsidian 双链——库内链接仍按路径与标题解析。

本库采用四级导航结构：[库级枢纽](https://www.pystone.net/notes/knowledge-network-navigation/) → 领域 MOC → 跨领域主题 MOC → 知识笔记。集合 MOC 保证可达性，主题 MOC 表达真正的知识关系。这里的导航级别不同于“知识底座—知识演化层”的两层知识架构。

## 知识演化层

- 知识底座中的既有笔记默认忠实原文，优先只做格式、资源引用、来源和语义链接维护；新的纠错、冲突、比较与综合优先通过知识演化层表达。
- “知识演化层”是第二层的正式名称，维护持续更新的综合判断、证据边界、矛盾、开放问题和跨领域关系。
- “知识编译”是定位、关联、对照、验证、综合、写回和校验这些内容的工程机制。
- “知识发酵”描述知识长期相互作用并可能形成新认识的自然过程，不作为目录名或效果承诺。
- 综合笔记分布在最合适的现有领域；库级入口只负责导航，不建立与现有知识域竞争的复制目录树。
- 除库级 `05-知识演化.md` 系统入口外，主题 MOC 和具体综合笔记必须用真实主题或问题命名；`知识演化`、`知识编译` 和 `知识发酵` 不能替代具体主题名称成为通用 Graph 枢纽。

### 第二层识别约定

- 不为知识演化层建立独立领域目录，也不使用“综合-”“演化-”等前缀污染主题名称。
- 综合笔记必须在属性中写明 `type: synthesis`、`layer: evolution`、`status: evolving`；库级工作台写明 `type: workspace` 与 `layer: evolution`。
- 第一层不批量补 `layer: foundation`；未标记 `layer: evolution` 的既有笔记默认属于知识底座。
- 综合笔记在标题后放置“知识演化层”说明块，让阅读者一眼知道本文维护的是基于多份底座材料形成的当前认识，而不是来源原文。
- 在 Obsidian 搜索中输入 `[layer:evolution] -path:"00-总览与索引/模板"` 可以列出真实第二层笔记；在 Graph 的 Groups 中使用同一查询并指定颜色，可以在整体网络中辨认第二层节点。路径排除避免携带待复制 frontmatter 的综合模板成为假知识节点；查询仍只使用 Obsidian 原生属性与路径检索，不需要标签节点或额外插件。

## 链接必须带有关系

优先使用下面六类关系来写链接：

- 上位：这篇笔记属于哪个更大的问题或主题。
- 前提：理解当前结论前必须掌握什么。
- 解释：哪个机制能够解释当前现象。
- 对照：哪个观点、方案或案例与它形成差异。
- 应用：这条知识在哪个工程、产品或决策中被使用。
- 证据：哪个来源、实验或案例支撑这个判断。

例如，“自动化测试是 [持续交付系统](https://www.pystone.net/notes/software-delivery-automation-quality/) 的反馈环节”，比单独放置一个裸链接更有信息量。

## 笔记粒度

- 原始材料可以保持完整，但要连接“来源”和“待提炼主题”。
- 稳定知识笔记尽量围绕一个可复述的核心判断，而不是机械追求篇幅短小。
- 同一结论出现于多个材料时，建立一篇综合笔记作为枢纽，让材料作为证据回链。
- 不为制造链接而拆碎上下文；项目档案、课程原文和长篇论证仍可保持整体。

## MOC 的维护方式

- MOC 文件名表示主题身份，也是 Graph 视图显示的节点名；使用 `软件工程与质量保障` 这类主题名，不使用 `00-索引`、`README` 等只有页面角色、没有主题信息的名称。
- MOC 的页面角色写入 `type: moc` 属性，集合层级写入 `scope`，不要把这些元数据塞进文件名。
- 集合 MOC 带有 `generated: true` 属性，由仓库内 `python tools/kb_moc.py --build` 刷新，使用 `--check` 只读核验；工具拒绝覆盖人工页面。
- 主题 MOC 由人工维护，只收录能解释主题结构、矛盾、路径和应用的关键节点。
- 当一个主题 MOC 超过约 30 个同层链接时，按问题或机制拆出子 MOC，而不是继续堆长列表。
- 每次完成一篇重要笔记，回到它的上位 MOC，补充一句关系说明。

## Obsidian 使用建议

- 在主题 MOC 上使用局部关系图，深度 2 通常足以看到相邻知识。
- 在知识笔记上同时查看反向链接和出链，前者显示“哪些主题需要它”，后者显示“它依赖什么”。
- 可在关系图中搜索 `[type:moc]` 聚焦枢纽页；按 `path:` 过滤某个知识域。
- 属性用于稳定元数据，正文链接用于表达可阅读、可推理的关系。

## 自动一致性校验

- 本地图片、文档、音视频和压缩包引用必须解析到仓库内真实文件；HTTP(S)、`data:`、`file:`、`obsidian:` 等外部 URI 不作为本地附件检查。
- 占位图必须是实际存在的文件，并在替代文本或正文中明确标为占位；不能仅写“占位”来绕过缺失附件。
- 确认无法恢复但必须保留的历史引用，逐条登记到 `.knowledge-base/attachment-exceptions.txt`，写明来源、目标和原因；禁止全库通配豁免，引用恢复后必须删除例外。
- 提交前运行 `python tools/validate_knowledge_base.py --check`，检查摘要、MOC、库级规则、附件、公开/私有边界和原文保真确认门禁。
- validator 同时检查综合笔记是否带有 `layer: evolution`，防止第二层再次变成无法辨认的普通文件。
- validator 检查 `note_id` 全量覆盖（生成页、模板与根级治理文件除外）、格式与全库唯一性；生成页的 `note_id` 由 `.knowledge-base/generated-note-ids.tsv` 注册表登记并由生成器写回。新笔记的 ID 由 Agent 依标题语义翻译生成，冲突时已持有 ID 的一方保留、新笔记用领域限定词具体化。
- 新增、删除或移动 Markdown 笔记后运行 `python tools/validate_knowledge_base.py --fix`，在本仓库内刷新 MOC 与派生文档并继续校验。
- 仓库通过 `.githooks/pre-commit` 执行只读校验；新环境需运行 `git config core.hooksPath .githooks` 启用仓库内 Hook。
- 自动校验只判断可机械验证的结构事实，不替代人工判断链接是否真正表达知识关系。