基于 Obsidian 的知识树思维框架

这是一个极具扩展性且对 LLM（大语言模型）友好的树状知识管理框架。每一层级的目录都代表知识树的一个“树冠节点”，通过标准化的入口引导与“随取随记”的经验池，实现知识框架的自动散发与生长。

目录结构设计原则

/主题名称 (如：java)
    README.md     # 节点入口：定义本主题的核心目标、概念，以及构建下属子主题的索引 (Map of Content)
    FAQ.md        # 经验池（树干上的树脂）：收录本主题下初期的、细碎的、无法成篇的问答记录
    /子主题1 (如：基础知识)
        README.md # 子节点入口 
        FAQ.md    # 子节点经验池
        /子主题1-1 (如：语法)
            README.md
            FAQ.md 
            【知识点实体A】.md 

1. 枝干与向导 —— 关于 README.md

做什么是的？ 它是当前目录的“大纲”和“路由器”。对于 LLM 来说，这是系统理解当前目录下所有下级文件归属、前置规则的核心上下文。

应包含什么？

• 主题一句话定义：例如“本目录包含 Java 集合类框架的设计哲学与底层实现分析”。
• 目标与边界：明确要包含什么，以及该目录下绝对不包含什么。
• 动态子主题索引 (MOC)：利用双链 [[子主题名/README.md]] 将下设节点串联。系统或 AI 能够借此梳理节点层级的依存关系。

2. 查缺补漏的防护网 —— 关于 FAQ.md

参考项目中的 @[FAQ.md] 使用方式，它是极其关键的实战记录册。它不苛求结构的严密性，主要起到查缺补漏的作用。

记录什么？ 当你学习或实战时，遇到无法归类到已有重点体系，或者太过细碎不值得单独建文件的点滴经验。 写入它的触发条件是什么？

1. 反常识和易错点：“原本以为A，跑了代码发现是B”。
2. 实战踩坑记录（BugFix）：“遇到报错 Exception XYZ，解决方案是……”。
3. 未形成大体系的独立疑问：“pom.xml 中引入子模块为什么要用 <parent> 的空 <relativePath/> ”。这种细碎独立的内容不足以撑起一篇独立长文档，不必单独建 markdown 文件，当做“落叶”扫进 FAQ.md 就可以了。

3. 开枝散叶与结出果实 —— 建立新节点的时机

你不需要提前构思整个宇宙。果实和枝叶节点更多是随时根据特定主题自动规划和创建的。

• 【果实法则（直建 / 提炼）】：
  1. 直接创建（最核心方式）：当你确切地要研究一个体系完整、内容充实的具体知识点时（例如：Java的多线程源码深度解析.md），直接创建具体的 .md 文件，让它作为饱满的“果实”挂在枝头。只有该知识点实际存在时才建立，如果内容缺失，完全不需要建空壳占位。
  2. 从 FAQ 提炼（查缺补漏反哺）：如果 FAQ.md 里的某个疑问点，被你越追究越深变得足够庞大时，再将其从 FAQ 里独立出来，赋予它单独的 .md 果实文件身份。
• 【开枝法则】：当一个独立目录下的“果实”实在太多了，或者具有更深的管理需要时，建立新的子文件夹，并利用自动化工具同步为其配齐全新的 README.md 与 FAQ.md。

4. 如何做到彻底“LLM 友好 (LLM-Friendly)”？

LLM 读取知识库本质是文件语义检索。为了让模型未来可以轻松“帮我复习”、“帮我整理思路”或者“找Bug”：

1. 内容的格式和排版 在这里只需要关注内容即可，内容的格式和排版使用 obsidian-markdown skill 处理即可，无需手动过多干预排版细节。
2. 基于双向链接 (Bi-directional Links) 果实文件创建后，可以在 FAQ 或者 README 中通过 [[文件实体]] 互相引用。对于大模型来说，你就是在构建一个极其标准的领域知识图谱（Knowledge Graph）。