知识库梳理（Vault Triage）
引导用户把「越用越乱、找不到东西」的本地知识库，梳理成可持续、可检索、不靠记忆的状态。
何时使用
- 用户抱怨知识库太乱 / 文件越来越多 / 不知道放哪 / 搜不到 / 不敢删
- 用户想整理、重构、归档自己的 Obsidian 库或本地 Markdown 文件夹
- 用户感觉"整理过几次又乱了"，需要一套能长期维持的机制
- 用户新建知识库前想避免重蹈覆辙（按此流程的 S0/S2 即可）
不适用：云端笔记平台迁移（语雀/Notion 间搬家）、从零建设全新库（那是 llm-wiki 的范畴）、纯技术性的双链修复小任务。
核心立场（先讲清，贯穿全程）
- 失控是常态，不是人品问题。 知识库天然熵增，梳理的目标不是"永远整齐"，而是"乱得起、找得到、恢复快"。
- 先诊断，后动手。 大部分"整理"失败，是因为没分清自己得的是哪种病就开药。
- 先止血，再清存量。 立规矩的成本远低于事后整理，从本次对话起的新内容先走新规则。
- 归档代替删除。 用户怕丢东西是正常的，Archive 文件夹 + 全库搜索就是"心理安全网"，比"断舍离"更容易坚持。
- 导航层与存储层分离。 文件夹只做粗粒度分档，精细导航交给 MOC（地图）+ Dataview 索引 + 搜索，避免把文件夹建到十层深。
- 克制过度整理。 分类超过 3 层、维护成本高于收益的整理是新的失控。宁可少分，不可错分。
- 最小干预承诺。 不要求用户把文件夹改成 Projects/Areas 这类英文名；默认只动最常用的 20% 存量，其余保持原样；结构改不动的决定权始终在用户手里。
六步工作流
整体按顺序执行；S0-S1 每次必做，S2-S5 依据体检结果取舍。每步先读对应 references/ 文档再执行。
| 步骤 | 名称 | 解决什么 | 关键产出 | 参考文档 |
|---|---|---|---|---|
| S0 | 目标对话 | 不知道这个库到底为谁、存什么 | 「库的使命」一句话 | diagnosis.md |
| S1 | 体检诊断 | 说不清病在哪 | 体检报告 + 病型画像 + A/B/C 程度分级 | diagnosis.md + scan_vault.py |
| S2 | 止血立规 | 只进不出的口子 | 收件箱 + 命名/frontmatter 约定 + 新笔记流程 | obsidian-mechanics.md |
| S3 | 存量分批清理 | 历史欠账 | 分批行动计划与执行记录 | clean-batches.md |
| S4 | 搭导航骨架 | 靠记忆找文件 | 首页 MOC + 自动索引 | obsidian-mechanics.md + assets/templates |
| S5 | 维护机制 | 清了又乱回去 | 例行节奏表 + 防复发约定 | obsidian-mechanics.md |
S0 目标对话（10 分钟，先梳理思路）
动手前先问清楚，这些问题直接决定结构怎么搭：
- 这个库服务于什么？个人成长 / 工作项目 / 写作素材 / 学习笔记，多选可以但最多 3 个主线。
- 你最常取用的内容是什么？怎么找？（搜索 / 文件夹 / 标签 / 双链）
- 你最头疼的时刻是什么？（记了找不到 / 新笔记不知放哪 / 东西太杂不敢删 / 整完又乱）
- 每周愿意花多少时间维护？诚实回答，这决定机制要轻到什么程度。
产出：把答案凝练成一句话使命，例如「这个库服务我的 AI 编程教学：课程内容按主题归档，素材与灵感进收件箱每周五清理一次」。
> 库没有使命，任何结构都是随机结构。如果用户答不上来，帮他收敛到 1-2 个主线，并明确告知"什么都存"的库先从收件箱+归档起步。
S1 体检诊断（只读，不动任何文件）
执行顺序：
1. 先读 references/diagnosis.md，用其中的症状自检清单与用户快速对话，让用户自己描述症状。
2. 运行 scripts/scan_vault.py <库路径> 做客观扫描（只读统计：文件数、目录深度、frontmatter 缺失率、孤立笔记、重复文件名、最近修改分布）。
3. 把主观症状与客观数据合并，做双层诊断：按 diagnosis.md 的失控画像判定主病型（囤积型 / 结构洁癖型 / 散养型 / 混合型——决定"治什么"）；再按混乱程度判定 A/B/C 级（清爽 / 杂而不乱 / 失控——决定"动多大手术"）。
产出：一份体检小结（可用 assets/templates/health-report 结构），明确：
- 三个数字（总笔记数、平均深度、frontmatter 覆盖率）
- 主病型 1-2 个（治什么）
- A/B/C 程度分级（动多大手术）
- 对应路径（见下方「分级路径」）
只读原则：此阶段禁止移动、删除、重命名任何用户文件。
分级路径与授权决策点（S1 之后先对号入座）
| 程度 | 客观判据 | 走哪条路 |
|---|---|---|
| A 清爽型 | 顶层文件夹 <10、层级 ≤3、搜索基本能命中 | S2 止血 + S4 补 MOC 微调。不移动任何物理文件，S3 整段可跳过 |
| B 杂而不乱 | 文件夹多但逻辑自洽、放得下也找得到 | S2 + 元数据映射（不移动文件，用 frontmatter 打 PARA 属性）+ S4 生成看板/MOC |
| C 失控型 | 重复文件成组多、休眠占比高、经常找不到（脚本实测为准） | 完整 S2→S3→S4→S5。批次 D 重构前必须先过下方授权决策点 |
授权决策点（C 类且需动顶层结构时，强制）：
1. 先向用户说明风险与代价：「当前结构可能已失效。建议把现有顶层文件夹整体移入 !旧结构_Backup，再新建映射层；您需要投入 1-2 小时迁移高频文件。」
2. 得到用户明确同意后，才给出迁移方案并执行。
3. 用户拒绝 → 自动降级为 B 路径：不移动任何文件，改为打元数据属性 + 建 MOC 兜底。不劝用户接受重构。
> 话术基调（可直接使用）：「我不会要求您把文件夹改成 Projects/Areas 这类英文名。无论改不改，我们只动最常用的那 20% 笔记，剩下的保持原样，绝不破坏您的使用惯性。」
S2 止血立规（先让"新内容"不再添乱，约 30 分钟）
新规矩只从本次对话后生效，旧文件一律不动，等 S3。
- 建单一收件箱：库根建
00-收件箱/（或启用 Obsidian 自带"每日笔记"当天兜底）。规则：任何新东西先落收件箱，不允许"顺手放进正式文件夹"。 - 定命名约定：选一套即可（如
YYYY-MM-DD-标题或标题），旧文件不强求改。 - 定 frontmatter 最小字段：
tags+created起步（模板见 assets/templates/note-frontmatter），用 Obsidian 模板功能一键插入。 - 写"新笔记入口流程"：新笔记 → 落收件箱 → 当天/当周处理（转正式区 or 留收件箱 or 删除）。把这条规则贴到收件箱文件夹的说明文件里，也写进日记模板。
产出：收件箱目录 + 2 个模板文件 + 一段可复制的"使用说明"放进收件箱。
S3 存量分批清理（按体检结果决定做不做、做几批）
从易到难、分批执行，每批结束向用户汇报并等确认。 全部操作细节与判断标准读 references/clean-batches.md。
- 批次 A · 死档归档（决策成本最低，先做）：明确过期、已完成、不会再看的 → 移入
99-归档/。这一批通常能砍掉 20-40% 存量，立刻建立信心。 - 批次 B · 去重与近似合并：扫描重复文件名/重复标题，合并或互链，不硬删。
- 批次 C · 未消化收藏三选：针对"存了没看"的内容，逐条用 5 秒判断：转正文笔记 / 归档 / 删除。
- 批次 D · 结构重构（仅当 S1 判定为结构病且程度为 C、并通过授权决策点才做）：选型见
structure-patterns.md，用"先建新骨架目录 → 移动（重命名）→ 原路径留跳转或搜索兜底"的方式迁移，禁止复制粘贴式搬运。用户拒绝授权时降级为 B 路径（元数据 + MOC），不移动文件。
安全规则（强制）：
- 全程移动/归档优先，删除需用户逐条确认。
- 每批最多动 50 个文件以内的小批，批间停下让用户检查。
- 动手前先确认有备份（Obsidian 同步 / Git / 压缩包任一即可），没有就先做一个库级压缩包。
S4 搭导航骨架（让"找"不依赖记忆和分类）
目标：让用户以后搜得到、看得见全貌，而不是记得住放哪。
- 首页 MOC：库根放
Home.md，用链接把 2-5 个主线 + 收件箱 + 归档 + 常用 MOC 列全（首页模板见 assets/templates/home-moc，MOC 页模板见 assets/templates/moc-template）。 - 每个主线建一个 MOC 页（如
_MOC-AI编程.md），只挂该主线下的主题页与重要笔记。 - 自动索引（Obsidian）：用 Dataview 按 frontmatter 字段自动列出"最近笔记 / 收件箱待处理 / 某标签下全部笔记"，替代手维护目录。具体写法见
obsidian-mechanics.md。 - 双链卫生：只做轻量修复——给孤岛笔记补 1 个入链（从所属 MOC 挂上），不追求全库图谱完美。
S5 维护机制（防复发，机制必须轻到用户愿意长期做）
按用户在 S0 承诺的时间设计，默认给一套"最轻配置"：
- 每天 1 分钟：新笔记落收件箱（除此之外什么都不用做）
- 每周 15 分钟：清空收件箱（转正/归档/删除三选）
- 每月 30 分钟：跑一次 scan_vault.py，只看三个数字有没有恶化
- 每季度 1 小时：季度体检，重复 S1 的画像判断，重读本技能 S3 批次处理积压
把这张表写进用户的日记模板或库内 _使用说明.md。明确告诉用户：偶尔乱掉没关系，机制会在 15 分钟内把它拉回正轨，这才是可维护的状态。
对用户本地库的操作安全规则（全流程强制）
- 先只读后写入：任何改动前先完成 S1 扫描与报告。
- 可逆优先：一律移动/归档，不删除；确需删除必须逐条列清单等用户确认。
- 小批执行：单批操作 ≤50 个文件，批间停下汇报，用户确认后再继续。
- 先备份：操作前确认已有备份（Git 提交 / Obsidian 同步 / 压缩包），没有就先创建库级备份。
- 不碰系统与无关目录：只操作用户明确指出的库路径，不递归扫用户主目录。
- 全程可视：每次执行前列出将受影响的具体路径；执行后展示结果。用户要求查看任何步骤的产出文件时用 present_files 打开。
交付物清单
一次完整梳理结束后，确认以下产物都已给出并说明存放位置：
- [ ] 「库的使命」一句话（写进 Home.md）
- [ ] 体检小结（三个数字 + 主病型 + A/B/C 程度 + 路径）
- [ ] 《映射对照表》（用户习惯词 ↔ PARA 原理，模板见 assets/templates/mapping-table）
- [ ] 收件箱 + 模板 + 使用说明（S2）
- [ ] 分批清理记录（S3 每批做了什么、动了哪些文件）
- [ ] Home.md / MOC / 自动索引（S4，按需）
- [ ] 维护节奏表（S5）
所有交付内容用简体中文，结构与话术面向零基础用户，避免术语堆砌。
联系作者
微信: woyaobaofuniubi
公众号: AI共学社ALL
