Knowledge Audit
11-Tech-Backend & Infra 目录体检与可视化方案
2026-02-01 · 个人知识库 / 自用 · 05-Knowledge/11-Tech-Backend & Infra
面向 Obsidian 的信息架构、可视化与优化建议
从文件结构与链接/元数据覆盖率入手，给出可视化与整理路径。重点：先降噪，再建入口。
auditobsidianvisualizationbackendinfra
TL;DR
核心结论：
这个目录目前更像「历史导入桶」，不是「后端/Infra 知识库」：
Development/ 占 93.6%（743/794），主题混杂；内部链接几乎为零（[[...]] 总计 26，仅 4 个文件）；YAML 元数据覆盖极低（4 个文件）。
- 优先级 #1：把
Development/从本目录迁出或归档，让剩余 51 条后端/infra笔记可见。 - 优先级 #2：建立一个 Dashboard/MOC，用 5–8 个入口把内容“导览化”，并把“项目笔记 vs 参考笔记 vs 导入归档”分层。
- 优先级 #3：对关键笔记加轻量属性（
type/status/review），再用 Dataview/Canvas/Graph 做可视化与复盘闭环。
Inventory（现状量化）
MD Files
794
In Development
743 (93.6%)
Outside Dev
51 (6.4%)
YAML Frontmatter
4 (0.5%)
Wiki Links
26
Wiki-linked Files
4
Markdown Links
717
<=200B Notes
180 (22.7%)
Development/ 文件名年份分布（用于判断“历史沉淀 vs 近期工作”）
可解析出年份的条目：514（69.2%）；无法从文件名解析年份：229（30.8%）。峰值年份：2019（253）。
| Year | Count |
|---|---|
| 2016 | 12 |
| 2017 | 105 |
| 2018 | 81 |
| 2019 | 253 |
| 2020 | 58 |
| 2021 | 5 |
| Unknown | 229 |
Diagnosis（问题不是“写得不够多”，而是“信号被结构淹没”）
1) 信息架构混用
- 同一目录里同时存在：工作项目（
infra.md）、技术参考（Node/Kafka/OSS）、以及大量与后端无关的历史笔记（Development/）。 - 结果：搜索命中高噪声、Graph/Backlinks 几乎失效、复盘与复用成本高。
2) 可视化与检索的“抓手”不足
- 内部链接极少：知识之间没有“可走的路”。
- 统一元数据不足：很难用 Dataview 生成清单/看板（例如：待复习、待补全、已验证）。
3) 内容形态偏“导入原文/链接堆”
- 大量短笔记（≤200B：180）与“百科式定义”，对你自己的工作/决策贡献不稳定。
- 建议把“信息”升级为“可执行结论”：什么时候用/不用、坑、对比、Checklist、Runbook。
4) 迁移残留
- 存在 Notion/导入痕迹（如
Parent item:、带哈希的文件名、少量引用旧路径page-from-notion）。 - 建议“分区处理”：先把结构修好，再逐步精炼内容。
Visualization（怎么把内容变成“可看懂的地图”）
Obsidian Canvas（信息地图）
- 按 4 个区域摆放：Concepts / Systems / Runbooks / Projects。
- 每个区域只放 5–12 张“入口卡”（MOC），其余靠链接下钻。
Dataview（动态清单）
- 只给“核心 51 条”加属性：
type、status、review。 - 生成 3 张表：待补全、待复习、可复用 Runbook。
Graph（结构验证）
- 目标不是“好看”，而是：核心概念之间有路可走。
- 先让 10 条核心笔记互相链接起来，Graph 才会开始“长出来”。
Dataview 示例（复制即可用：只要你启用了 Dataview 插件）
```dataview
TABLE type, status, review
FROM "05-Knowledge/11-Tech-Backend & Infra"
WHERE type AND status
SORT review ASC
```
```dataview
LIST
FROM "05-Knowledge/11-Tech-Backend & Infra"
WHERE contains(file.name, "infra")
```
如果你不想全量加属性：也可以只在 _MOC.md 里用手工链接 + 简短注释完成 80% 的导航价值。
Expert Views（谁最懂？他们会怎么改）
Tiago Forte（PARA / Second Brain）
- Thesis：先按“可行动性”组织，而不是按学科；否则你只是在囤积信息。
- 建议：把工作项目（infra）与可复用资源分开，
Development/直接归档。 - 边界：PARA 解决“找得到”，不保证“写得深”。
Andy Matuschak（Evergreen Notes）
- Thesis：好笔记是“可组合的观点”，而不是“资料卡片”。
- 建议：把 Node/Kafka/OSS 这类笔记改成：何时使用/反例/踩坑/与你当前项目的关联。
- 边界：需要持续迭代，无法一次性“整理完”。
Google SRE（可靠性工程）
- Thesis：知识要落在“可运行的系统”上：服务目录、SLO、Runbook、事后复盘。
- 建议：围绕
infra.md建一套最小 Runbook：采集→文本化→清洗→分流（RAG/SFT/预训练）＋关键指标（例如信息损失率）。 - 边界：偏工程实践，若只是学习会觉得“太重”。
Brendan Gregg（性能与可观测性）
- Thesis：排障与性能分析需要“方法论模板”，否则每次都从头来。
- 建议：在本目录建立
Observability Playbook（USE/RED）、常用命令、与案例复盘。 - 边界：适合生产环境问题；对纯概念学习帮助有限。
Options（按投入程度给 3 档方案）
| Option | Best for | Upside | Downside | Key risk | First step |
|---|---|---|---|---|---|
| A · 最小可用 | 15–30 分钟见效 | 立刻降噪；目录变“能用” | 不解决深层内容质量 | 搬迁路径影响旧链接 | 把 Development/ 迁出或移到 Archive |
| B · 标准化 | 1–2 小时建立系统 | 可视化（Dataview/Canvas）开始工作 | 需要一点点维护习惯 | 属性不一致导致看板失真 | 给“核心 51 条”补 type/status/review |
| C · 深度重构 | 想长期把它做成“可复用知识库” | 链接网络 + 结构化模板 + Runbook | 工作量大、需分阶段 | 重命名/移动造成外部引用断裂 | 从 Obsidian 内部批量重命名（自动更新链接） |
Playbook（我建议你怎么做：三段式）
现在（15 分钟）
- 把
Development/从本目录迁出（或放入90-Archive/）。 - 新建
_MOC.md：只放 8 个入口链接。 - 把
infra.md顶部加“结论/下一步”摘要。
今天（1–2 小时）
- 把核心笔记按
Projects / Concepts / Systems / Runbooks分区（文件夹或标签都行）。 - 挑 10 条最常用笔记互相加
See also（至少 3 条内链/条）。 - 做一张 Canvas：把入口卡摆好。
本周（可选）
- 逐步把“定义型笔记”改写成“你自己的判断/经验”。
- 为 infra 项目建立：决策记录（ADR）+ Runbook + 指标口径。
- 设一个
review周期：每周清理 5 条短笔记。
Sources
- Local scan:
05-Knowledge/11-Tech-Backend & Infra（本报告基于本地文件结构与内容特征统计，不依赖联网）。 - Key files:
infra.md、Kafka.md、OSS/对象存储服务OSS.md、服务器/服务器.md。 - Methods referenced（概念层面）：PARA / Evergreen Notes / SRE / Observability（未逐条在线核验原文引用）。
先让目录“能用”，再让内容“变强”。
— Closing note