AI 检索约定

本库以 Markdown、稳定元数据和显式链接为基础，便于未来建立全文检索、向量索引或 RAG。

按问题类型路由检索

AI 不应只根据关键词命中单篇笔记，而应先判断用户在问“导航、概念、操作还是故障”，再选择主要目录：

用户意图	首选目录/type	回答重点
“这一章学什么、下一步是什么”	10-Domains / moc	学习顺序、前置、主线入口
“X 是什么、为什么这样”	20-Concepts / concept	定义、机制、边界、因果关系
“怎么从头完成、给我步骤”	30-Projects / project	按顺序的可执行步骤和验证标准
“为什么报错、怎么修”	50-Labs / lab	现象、环境、根因、修复与结果

如果问题跨层，按以下顺序组织答案：先用 Concept 给出必要解释，再引用 Project 的具体步骤；发生错误时补充对应 Lab。不要用故障笔记代替正常操作主线，也不要从 Project 的命令片段反推完整概念。

沿链接扩展上下文

• 命中章节 MOC 后，继续读取其“概念导读”“主线笔记”和“故障复盘”中的相关链接。
• 命中 Concept 时，沿关联链接找到经过验证的 Project，以实际环境和结果约束理论回答。
• 命中 Project 时，读取它链接的 Concept 解释操作目的，并读取相关 Lab 了解当前环境特有的兼容问题。
• 命中 Lab 时，必须核对适用版本、工具链和状态；若 result 尚未成功或 status: growing，明确说明尚未完成验证。
• 回答“当前做到哪里”时，以 Project 的完成标准和验证结果为主，不以单条故障日志或聊天印象判断。
• 命中 Project 时先按“章节 → 小节 → 笔记”解析目录语义；章节编号和小节编号是各自层级的阅读顺序，不能按扁平全局序号解释。
• 命中带编号的小节时，同时检索该小节中的“扩展”笔记；架构或版本变体属于原小节上下文，不应根据变体推断它是一个新章节或新小节。
• 命中 Lab 时沿镜像目录返回同章节、同小节的 Project；若 Lab 位于架构子目录，还要读取同一 Project 小节中的对应扩展笔记。

为检索优化

• 每篇笔记开头写独立可理解的 摘要，避免“如上所述”等依赖上下文的表达。
• 标题层级表达语义；单节聚焦一个子问题，避免超长无标题文本。
• 事实、推断和问题分开写，使用 > [!note]、> [!warning] 等 callout 标识。
• 代码块注明语言；日志注明环境、命令、预期与实际结果。
• 来源包含 URL/书目信息、访问日期、版本或 commit；引用说明具体章节/行号。
• 敏感信息（密钥、内部地址、个人数据）不得进入库或 AI 索引。

推荐索引单位

按二级/三级标题切块，保留笔记标题、路径、YAML、标题层级和来源链接作为元数据。优先索引 status: evergreen 和 growing；默认排除 _Templates、.obsidian、二进制附件与 99-Archive。

索引时同时保存目录层级和 type，避免把 Concept、Project 与 Lab 的同名关键词混为同一种答案。代码块应与其上方的步骤标题、工作目录和说明放在同一检索块中；故障日志应与环境、根因和结果字段一起保留。

质量信号

• status: evergreen 表示结论已有可靠来源或实验验证，并不表示永远正确。
• 待验证 中的内容不得被 AI 当作确定事实。
• 冲突结论不直接删除：分别保留适用版本/条件，并建立互链。
• 对操作问题，优先采用 Project 中已经验证的主线；Lab 中失败过的命令不能脱离上下文作为推荐步骤。
• 对概念问题，优先引用 Concept；Project 中为了当前机器作出的权宜配置不能泛化为普遍原理。