事实核对：本文描述的个人知识库搭建过程基于本人 2026 年 7–8 月的实际操作，目录结构、约定规范均为本机真实状态（核对日期：2026-08-27）。

先说痛点：我的"知识库"曾经只是文件堆

过去两年，我的资料散落在一堆文件夹里：项目方案在 raw/ 里按公司名堆着，会议记录和战略思考混在一起，政策法规、竞品分析、产品文档全凭记忆找。每次要做一个新东西，都得先花半小时回忆"上次那个项目材料放哪了"。

更尴尬的是：AI 帮不上忙。让 AI 助手读一遍文件夹，它每次都要重新理解上下文；问它"新银邦项目现在什么状态"，它得现翻十几个文件才能拼出个大概。知识库存在的意义是"让信息可以被调用"，而我这个库连我自己都调用不动。

所以我决定重搭一个——这次的标准只有一条：必须让 AI 能自己维护、自己回答问题。工具我选了两样：本地 Obsidian（Markdown 仓库）+ pi（终端 AI 助手）。前者管存储，后者管调用。

第一步：先定结构，再堆内容（PARA + MOC + Wiki 三层）

我参考了 Tiago Forte 的 PARA 方法论和 Andrej Karpathy 的 LLM Wiki 思路，把仓库重构成六块：

Obsidian/
├── 00-MOC/       ← 仪表盘：项目驾驶舱 + 全部待办
├── 01-Projects/  ← P：活跃项目（有截止日期、有交付物）
├── 02-Areas/     ← A：持续领域（战略、运营、长期责任）
├── 03-Resources/ ← R：参考资源（模板、政策、竞品、产品文档）
├── 04-Archives/  ← 存档（暂停项目、过期策略、旧会议）
├── 05-wiki/      ← Wiki 层：从 PARA 提炼的知识页面
└── CLAUDE.md     ← Schema：结构约定和工作流

判断放哪里的标准就一句话：这个东西"现在"还在不在动？在动就是 Project，长期关注就是 Area，以后可能用就是 Resource，不动了就是 Archive。旧的 raw/ 目录按这个规则全部迁移拆散，一劳永逸。

第二步：写一份"给 AI 看的说明书"（CLAUDE.md）

这是整个搭建里最值钱的一步。我花了一晚上，写了一份 CLAUDE.md 放在仓库根目录，它本质上是这份知识库的 schema：

• 每个目录放什么、谁写谁读（表格写清）
• 每个项目文件夹必须有一个 <文件夹名>.md 的 overview 文档
• overview 的 frontmatter 必填字段：title / type: overview / tags / status / updated
• 内容结构：一句话摘要 → 项目速览表 → 当前状态 → 详细文档链接 → 待办

为什么这么较真？因为AI 是严格按 schema 工作的。frontmatter 里有没有 status 字段，直接决定驾驶舱能不能自动聚合；type: overview 决定 Dataview 查询能不能过滤出项目。人写笔记可以随心所欲，但要让 AI 维护，就得先把"元数据规范"钉死。

第三步：搭一个自动刷新的仪表盘

有了标准化的 frontmatter，仪表盘就是水到渠成的事。我在 00-MOC/项目驾驶舱.md 里用 Obsidian 的 Dataview 插件写了一个查询：自动从 01-Projects/ 抓取所有 overview 文档，按 status 的 emoji（🔴 ⚠️ 🔄 🛠 ✅）排序，展示"项目名 / 状态 / 最近更新"。

效果是：我只需要在项目文档里维护 status 和 updated 两个字段，驾驶舱自己就更新了。不用再手动维护任何总表。另一个 全部待办.md 用 Tasks 插件把全仓库的待办按 deadline 排出来，逾期一目了然。

第四步：让 pi 进场——知识库从"能看"变成"能干"

结构搭好只是地基。真正让它活起来的是 pi——一个本地终端里的编码助手（npm 全局装一个就行，pi 直接进交互模式）。

pi 的玩法很对我的胃口：它不内置一堆花活，而是给你四个基础工具（读文件、写文件、改文件、跑命令），能力全靠"技能包"扩展。这跟我的知识库哲学完全一致——规范先行，按需生长。

日常用法是这样的：我打开终端，在知识库目录里跑 pi，然后直接说：

"你看下 01 下面 FDE 服务这个项目，了解下情况我再派任务"

pi 会先读 CLAUDE.md 拿到仓库规范，再按 overview 文档把项目状态、客户、目标、待办全部过一遍，然后给我一份结构化的项目摘要。之后我说"基于这些内容，给客户做一份方案 PPT"，它就能直接开工——因为上下文已经在对齐的那一刻建立好了。

这套组合给我带来了什么

1. 上下文不再靠人肉回忆。任何一次新会话，pi 读一遍 CLAUDE.md + 对应项目文档，五分钟内对齐全部背景。我不用再当"人肉上下文传输带"。
2. 知识库有人维护了。frontmatter 标准化、断链修复、Dataview 路径更新这些脏活，丢给 AI 干就行；它按 schema 写出来的东西比我手写的还规整。
3. 能力和边界都可控。pi 的技能包是 markdown 文件（SKILL.md），想加什么能力就放一个进去，AI 按需加载——这跟我"先定结构再长内容"的思路一模一样。
4. 一切都是本地文件。没有平台绑定、没有锁定效应，Markdown 永远可读，换个工具随时能迁移。

踩过的坑，给你避雷

• 先定 schema 再堆内容。我第一版直接开写，结果文档格式五花八门，AI 没法统一处理，后来全部返工。规范应该是最先写的那个文件。
• frontmatter 是 AI 的"眼睛"。status、updated、type 这几个字段值不值得维护，直接决定你的仪表盘和数据聚合能不能跑起来。
• 别让 AI 自己发明分类。目录层级要写死在 CLAUDE.md 里，AI 只会按规则放文件，不会自己悟出"该放哪"。
• 会话记忆要善用。pi 的会话是持久化的，跨天继续对话上下文还在。我一般一个项目开一个会话，别混着聊。

最后

个人知识库这件事，我踩了三年坑才想明白：重点不是"存了什么"，而是"能不能被调用"。把结构、规范、仪表盘都搭好，再让 AI 进场当维护者，知识库才算真正完成——它不是仓库，是生产线。

如果你也在折腾第二大脑，我的建议很简单：用 Markdown（别用私有格式），按 PARA 分类（别自创体系），写一份 AI 能读的 schema（这是核心），然后找个顺手的 AI 助手把它用起来。剩下的，交给时间。

（本文基于个人实操整理，工具版本与目录结构以核对日期为准；个人经验仅供参考。）