Knowledge Audit

Tech-Frontend 知识库体检与可视化方案

2026-02-01 · 个人 Obsidian · 结构体检 · 可视化 · 轻量治理

针对 05-Knowledge/10-Tech-Frontend：改进方向、可视化展示、可复用的信息结构

现状：981 篇笔记，其中 Design 占 82.2%。 目标：用入口页 + 标签/链接统一 + 可视化面板，把目录从“收藏夹”升级为“工作资产库”。

ObsidianFrontendDesignVisualizationImport Hygiene

TL;DR

结论：当前目录已经“内容量很大”，但还没形成可检索、可复用、可视化导航的结构。最短收益路径是：先做入口与可视化（让你能用起来），再做导入清洁（让它更干净）。

Snapshot

MD Notes
981
Design Share
82.2%
Loose Root
78
With Any Tags
103
YAML Frontmatter
40
Notion Tags Line
63
With Any Links
115
Percent-Encoding
650
Data notes
  • 统计范围：05-Knowledge/10-Tech-Frontend
  • 说明：本报告仅做本地扫描与结构性建议；未联网核验外部链接内容。

Distribution

当前目录内容分布（按顶层桶） 总计 981 篇 Markdown；最大桶 = Design（806 篇） Design 806 · 82.2% Root (loose) 78 · 8.0% 前端库 31 · 3.2% 插件 29 · 3.0% 前端框架 16 · 1.6% React 13 · 1.3% TypeScript 3 · 0.3% uni-app 3 · 0.3% CSS 1 · 0.1% 事件 1 · 0.1%
把它当作“重力中心图”：如果不先定义边界，你会在 Design 的巨大引力里迷路。

Structure

把“资料堆”变成“工作知识库”的最短路径 四步：定义边界 → 规范化 → 建入口 → 建可视化面板（持续小步迭代） 1. 边界 这是什么？ 什么不在这里？ Design 是否独立？ 2. 规范化 命名 / tags / 链接 Notion 字段 → YAML %20 链接治理 3. 入口 3 个 MOC + 10 个主题页 让搜索有路标 4. 可视化 Graph / Canvas Dashboard（Dataview） 复盘与回收站 建议先做 1→3（可立即提升检索），再做 2（更系统但更费时），最后做 4（把结构变成可看见的导航）。
结构不是为了“好看”，而是为了让你能把内容用在项目里：查得到、拼得起来、复盘得动。

Diagnosis

主要问题
  1. 命名与内容不一致：Design 占比过高；且夹杂非前端主题（如音乐等）。
  2. 入口缺失：78 篇散落在根目录的笔记缺少导航页；搜索只能靠记忆关键词。
  3. 链接与标签稀疏：多数笔记是孤岛，难以形成“从问题到答案”的路径。
  4. 导入痕迹强：Notion 字段、%20 编码、无效 index（指向 .html）降低可维护性。
直接证据（来自扫描）
  • Markdown：981 篇；Design：806 篇；根目录散件：78 篇。
  • 含 YAML frontmatter：40 篇；含 Notion “Tags:”：63 篇。
  • 含 % 编码内容（%20 / %E…）：650 篇。
  • 含图片引用：532 篇；近空笔记（<20 chars）：31 篇。

Visualization

① 入口页（MOC）
  • 目标：让“搜索”变成“浏览”。
  • 做法：3 个入口页（Frontend / Design / Tooling），每页只放：主题树 + 常用链接 + 最近更新。
  • 要求：每个主题至少 1 条“下一步动作”。
② Dashboard（Dataview/手写也行）
  • 目标：把库变成“可运营的面板”。
  • 面板最小集：Top topics / 未打标签 / 待精炼 / 最近新增。
  • 前提：统一 tag 规范（YAML tags 或 #tag 任选其一）。
③ Canvas
  • 目标：用一张图承载“前端学习/复盘路线”。
  • 结构：基础（HTML/CSS/JS/TS）→ 框架（React/umi）→ 工程化 → 性能 → 组件/设计系统。
  • 技巧：Canvas 只挂 20–50 个高价值节点，避免把 800+ Design 全塞进去。
④ Graph（局部图 + 分组）
  • 目标：用图发现“主题岛”和“桥梁”。
  • 做法：只看本目录 Local Graph；用 tags 分组（frontend/design/mobile/tooling）。
  • 用法：每周挑 3 个孤岛笔记补 2 条链接（指向问题/方案/例子）。

Roadmap

PhaseTimeWhat to doOutcome
0 · 定义边界 30–60min 确定 Design 是否拆出；确定本目录的“目标读者”（你/团队/未来的你）。 目录名与内容一致；后续治理不返工。
1 · 建入口 2–3h 写 3 个入口页（MOC）；把 78 个根目录散件先按主题挂到入口页里（不搬家也行）。 检索体验立刻提升；知道“从哪进、往哪走”。
2 · 元数据统一 半天–1天 把 Notion 的 Tags/Parent 字段转成 YAML；建立 tag taxonomy；清理 31 个近空笔记。 Dashboard/Graph 可用；噪声降低。
3 · 可视化落地 1–2h 做 1 张 Canvas + 1 个 Dashboard；每周复盘迭代。 内容可运营；学习/项目复用更快。
One-week checklist（面向新手）
  1. 在 05-Knowledge/10-Tech-Frontend 新建入口页：Frontend.MOC、Design.MOC、Tooling.MOC（名字随你习惯）。
  2. 把根目录 78 篇先做“挂靠”：每篇至少归到 1 个入口页的某个小节。
  3. 从高频主题开始补标签：React / 性能 / 组件库 / 网络 / 构建 / 小程序。
  4. 挑 10 篇最常用笔记做“精炼版”：结论 3 行 + 例子 + 反例 + 相关链接。
  5. 做一张 Canvas：只放 30 个节点（入口页 + 关键主题 + 关键清单）。

High Value

建议优先打磨的“可复用资产”：把它们从“长文/导入内容”升级为“结论 + 清单 + 场景”格式，未来会持续复用。
价值提取模板（复制即用） 
# 结论（3 行以内）
- ...

# 适用场景
- ...

# 快速清单（Checklist）
- [ ] ...

# 反例 / 坑
- ...

# 相关链接（3–7 个）
- [[...]]

Expert Views

Tiago Forte（PARA / Second Brain）
  • 把这批内容当作“资源库”，关键是让它服务于项目与复盘，而不是只做收藏。
  • 先建入口页与检索面板，再逐步做“渐进式摘要”（高频笔记先精炼）。
Andy Matuschak（Evergreen notes）
  • 价值来自“可组合的、可复用的想法单元”，而不是长篇转存。
  • 少量高质量链接（问题→结论→例子）比大量无结构文本更能形成网络效应。
Addy Osmani（Performance / Tooling）
  • 建立“检索预算”：常用主题能否在 30 秒内定位到关键笔记与下一步动作？
  • 把性能指标（FCP/LCP/TTI…）从概念条目升级为“诊断清单 + 方案库”。
Brad Frost（Design Systems）
  • 你这里的 Design 与 Frontend 其实可汇聚到“组件 / 规范 / Token”三件套上。
  • 把组件库 CSV 资源变成可浏览的矩阵（组件×场景×优缺点）。

Note

以上为基于公开方法论的观点模拟（paraphrase）；本次未联网检索原文引用。

Sources

MetricValueHow computed
Total Markdown notes981os.walk 统计
Top bucket: Design806按顶层目录聚合
Files with YAML frontmatter40首行 --- 检测
Files with Notion “Tags:” line63正则 ^Tags:
Files containing percent-encoding650检测 %20 或 %E
Files containing images532检测 ![...](...)
Empty-ish notes31strip 后 < 20 chars

Next Action

One next action：用 30 分钟写一个入口页（哪怕很粗糙），把你最常查的 10 篇笔记挂上去，并加上“下一步动作”。
把结论变成第一步。
— Closing note