知识网络构建规则

两套结构各司其职

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

本库采用四级导航结构：库级枢纽 → 领域 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 原生属性与路径检索，不需要标签节点或额外插件。

链接必须带有关系

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

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

例如，“自动化测试是 持续交付系统 的反馈环节”，比单独放置一个裸链接更有信息量。

笔记粒度

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

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。
• 自动校验只判断可机械验证的结构事实，不替代人工判断链接是否真正表达知识关系。