Appearance
知识库怎么搭？
导读
知识库是放知识与经验的唯一入口，里面是一个收件箱加 PARA 四格。读完你能给自己搭一套 AI 能直接读的库，也知道哪些东西不该放进去。
总图：并列的四件，和知识库里面的五格
这套体系分两层看。
第一层是并列的四件：知识库，加上三个与它平齐的配套——代码仓库、凭证保险库、AI 沙箱。
第二层是知识库里面的五个格子：一个收件箱，加上 PARA 四格。
text
第一层 · 并列四件（同一个父目录下平级摆放，互不嵌套）
知识库 代码仓库 凭证保险库 AI 沙箱
知识与经验 代码、脚本 密码、密钥、凭证 AI 的缓存、草稿、
唯一入口：收件箱 可上传 GitHub 与代码、知识分离 还没做完的东西
四件之间靠「卡片 ＋ 卡片里的链接」相连；链接优先用相对链接
第二层 · 知识库里面（五格）
00_收件箱 ───清空────▶ 01_项目 · 02_领域 · 03_资源 · 04_归档
（只存不整） （PARA 四格）两层的分工一句话说清：并列的四件解决“东西存哪儿分开”，知识库里的五格解决“同一种东西在自己家里怎么走”。
四件之间不搬东西，只连链接：知识库的卡片里写“这个项目的代码在代码仓库的哪儿”“钥匙在保险库里”，写的是位置，不是把代码和密码抄一份进知识库。相对链接是这套连接的默认选择——文档挪了位置、改了文件夹名，只要卡片里的相对关系没变，链接就不断。
知识库：一个收件箱，加 PARA 四格
知识库是一个根目录，里面就五个格子：
text
知识库/ ← 根目录
├── 00_收件箱/ ← 唯一入口，只存不整
├── 01_项目/ ← 正在做的事
├── 02_领域/ ← 长期要管、会一直更新的事
├── 03_资源/ ← 参考与沉淀（踩过的坑放这里）
└── 04_归档/ ← 做完的、不再维护的为什么要用“序号 ＋ 下划线”。 两个原因：一是外来户一眼认得出来——带 00_～04_ 编号的，是规则里自带的格子；你或 AI 随手新建的、名字没编号的，就是外来户，一眼能认出来。二是沟通方便——“放进 03”比“放进那个参考资源的文件夹”省事，也不会说岔。
收件箱——唯一入口，只存不整。
所有东西先丢这里：网上刷到的链接、一句好句子、忽然冒出来的念头、视频和语音转写出来的文字、图片里的内容。存的时候不做任何判断——不选文件夹、不起名字、不打标签。做了任何一样，就是在“整”，收件箱就不成立了。
收件箱里也可以有文件夹（比如按来源分几个兜子），但这不是分类，只是别让所有东西堆在一层。真正的分类从“清空”那一步才开始。任何东西都先进这里，不直接塞进四格——跳过了收件箱，就等于跳过了“先让它存在”这一步。
收件箱里住着三种不同命的东西，清空时先分堆：
| 分堆 | 怎么认 | 它的终点 |
|---|---|---|
| 要看的 | 链接、摘录、转写——是“料” | 进四格里的某一格 |
| 要做的 | 你忽然想起来的一件事 | 做完，或者挂到某个项目下等它做——它没有“归到哪格”的终点 |
| 要验的 | AI 交回来的半成品 | 当场验：验过了才算数，验不过退回沙箱 |
清空——把收件箱里的资料变成一个个话题，放进 PARA 四格。
清空是这套体系的固定动作。攒够了就清，清的方式只有一件事：把手里的东西变成一个能说清主题的话题，再放进下面四格里。
| 格 | 装什么 | 判据 |
|---|---|---|
| 01_项目 | 正在做的事：需求、路线、进度、卡片 | 有明确的“做完”那一刻 |
| 02_领域 | 长期要管、会一直更新的事（没有截止日期） | 交出去你会不放心 |
| 03_资源 | 以后做别的事会用到的参考与沉淀（踩过的坑放这里） | 下次做别的事，你会回来找它 |
| 04_归档 | 做完的、不再维护的 | 跟手头的事无关了 |
清空要由人做，而且要有节律。 分拣这一步必须由人——可以设置路由机制让机器分拣，但不建议：人的知识是动态的，需求是多变的，不适合用固定的 SOP 流程去决定东西该去哪儿。“有了时间就整理”等于永远不整理，所以给清空定一个固定时段——像开例会一样占进你的日程（比如每周日晚上半小时）。
判据只一句：上次清空是哪天？超过两周没清，收件箱就正在变成第二个收藏夹。 补一条：当你在库里翻来翻去找不到东西时，先回去把收件箱清了——找不到东西常常不是库的问题，是收件箱在堵车。
四格的关系是流动的：项目做完了，整份挪进归档；项目里沉淀出来的踩坑与经验，抄进资源。 归档不是删除，它还在库里、还搜得到，只是不再占你眼前的注意力。
为什么收件箱必须清。 不清空，东西永远停在“收到”那一步，PARA 四格永远长不大，这套体系最重要的产出——越用越厚的知识与经验——就不会发生。
与知识库平齐的三个根
代码仓库。 放代码、脚本。它自己也是一个根目录：里面就是一个一个单独的文件夹，文件夹名就是代码的名字。
text
代码仓库/ ← 根目录
├── kb/ ← 一个文件夹就是一个代码项目
├── photo-tools/ ← 文件夹名就是你给这份代码起的名字
└── …它是独立的一份，可以上传 GitHub：云端仓库与你本地的代码仓库保持一致，换哪台电脑都跟着走。它和知识库是两回事——知识库里只放“这个项目是什么、代码在哪儿”的卡片，代码本体不进知识库。
凭证保险库。 放密码、密钥、各类凭证。它必须单独住：密码、代码、知识，这三者必须分离。知识库的卡片里只写“钥匙在保险库的哪个位置”，不抄密码原文；代码里也不写死密钥。
AI 沙箱就是缓存文档。 跟 Agent 合作时，AI 需要一个单独的工作目录，按项目划分——这一块就是你的缓存文档区。里面放的是 AI 工作产生的缓存、草稿、还没正式做完的东西：这些默认不定稿，做完就结论，有价值的才沉淀。
这三个配套为什么必须与知识库分开，理由各一句话：
- 代码与知识分开：代码是要被执行、要版本管理的东西，知识是给人看的东西，混在一起两边都不好用；
- 凭证与一切分开：密码泄露是不可逆的，它不能和任何会外发、会上传、会被 AI 大段读写的东西住在一起；
- 沙箱与知识库分开：跟 AI 合作会持续产生半成品，半成品如果直接混进知识库，你就分不清哪份是真的、哪份是草稿——AI 也会分不清。
四件怎么连：卡片、地图、名字
四件之间只连链接，不搬东西。连法由三样东西组成，缺一样，链接就开始断。
第一样：卡片 ＋ 卡片里的链接。 每份文档都是一张卡片；卡片里写指向别处的相对链接——相对链接优先，是因为绝对路径换台电脑、换个盘符就断。链接指向的是“位置”，不是内容：卡片里不抄代码、不抄密码。
第二样：名字。 一套命名规则，管住“改一个名字牵动一片”的问题：
- 一个项目一个唯一名——从卡片到代码文件夹到沙箱目录，全用同一个名字；
- 通用件不往任何项目里塞——它是所有项目共用的，就放在公共位置；
- 名字里不带版本号和日期——版本和日期会变，名字一变，指向它的卡片全断。
第三样：一张整体地图。 全库一张地图，规范每一个文档是干什么用的。地图上每个条目固定四列：它是什么、在哪、被谁引用、谁维护。
“被谁引用”这一列是防“改了它不知道通知谁”的：通用件被两个以上项目引用时，这一列必须填；改它之前先查这一行，一次查出全部受影响的项目。代价是这张表要人维护——项目不到十个的时候，直接在库里搜它的名字也一样管用；等你开始“因为怕麻烦而跳过这一步”了，才值得正式上表。
每个项目再配一份 readme，固定四行。 本项目叫什么、唯一真相源在哪儿、代码存放在哪儿、密码存放在哪儿。换一个 AI、换一台电脑，读这四行就能接手。它答的是“东西在哪”，不是“做到哪了”——位置几乎不变，进度天天变，两件事得两份文档，别用一份兼。
各份文件各写各的那一层——一个事实只写一份。 同一个项目，知识库里有卡片、沙箱里有需求草稿、代码仓库里有源码，这不是重复，是几件不同的东西，彼此不是“同步”关系，只是“指向”关系。真正要一致的只有一句：唯一真相源是哪一份，它写在 readme 里，只写一处。各份各写各的：
- 项目卡片写“为什么做、去哪找”——几乎不改；
- 需求文档写“要什么、定了什么”——只往后追加；
- 沙箱草稿写“现在做到哪了”——它是唯一频繁变的那份；
- 踩坑记录写“这次踩了什么”。
判据：这段话要改的时候，有几个地方要同时改？超过一个，就已经错了。
知识库也要跟着你走。 代码有 GitHub，换哪台电脑都跟着你；知识库没有，所以给它定一份主副本（放在哪台机器由你定），其他机器只读——所有改动只在主副本这一处发生。这样“库里只有一份真相”这句话才真的成立。想在两台机器上同时改，就要处理“两边各改了一半、谁听谁”的问题，本版不推荐。
一条信息走完全程
以“刷到一篇好文章，最后变成项目里能直接用的东西”为例。
第 1 步 · 进来
所有信息都从收件箱这一个口进来。采集的手是自己做的那个飞书工具：视频、语音、图片丢给它，统一转成 MD 文档落进收件箱；网上看到的链接、临时念头，也全部往这里放。不整理、不分类，先让它存在。
第 2 步 · 清空
按前面说的节律，先分堆（要看的、要做的、要验的），再把“要看的”变成一个个话题：这篇讲什么、这条想说什么。这一步必须由人做，AI 只辅助拆解。
第 3 步 · 混装的东西按性质分家
一份转写或摘录里常常混着好几样东西，靠人机协作拆开：先把内容交给 AI，让它说清这里头都是什么；你看着它，确认拆到多细，再决定每一份的去处。
| 拆出来的部分 | 去哪儿 |
|---|---|
| 知识、经验、踩过的坑 | 知识库的 PARA 四格 |
| 需求、方案 | 做成需求文档放 AI 沙箱，给 AI 接着做项目 |
| 代码、脚本 | 代码仓库 |
| 密码、密钥 | 凭证保险库 |
第 4 步 · 用起来
做项目的时候，让 AI 打开相关的文件夹、顺着卡片里的内部链接把知识串起来；也可以自己在 Obsidian 里把这一片打开看一看、做头脑风暴。卡片里的相对链接让“串起来”这件事随时做得到。
第 5 步 · 沉淀——不定生死，只往前压层
项目做完，把项目级的文档回流进知识库——尤其是“踩过的坑”：踩得越多、记得越多，知识库就越大。这是这套体系里知识增长的主要来源。
别把“这东西值不值得沉淀”交给一次判断，那判断做不出来。用压层：第一次碰上它，原样存着，不做加工；第二次又碰上、并且用上了，给它加一句提要——“这条是什么、什么时候该看”；第三次再碰上，把它提炼成一句能直接用的规则或提示词，把原来的长文压到下面当依据。每用一次，压薄一层——库里的好条目，都是被用出来的，不是被写出来的。
第 6 步 · 归档
做完的项目、不再维护的东西，从项目格挪进归档格，原位留一张卡片说明“去哪找”。
让 Agent 用得起来，也守得住
知识库攒起来之后，真正的用法是：随时让 Agent 去扫描你的知识库，把里面的东西倒出来用。
Agent 找东西靠三样：一张整体地图（先读地图，知道这类事情该找哪几片）；卡片里的相对链接（顺着链接一层层打开，而不是把整个库倒给它）；项目的 readme 四行（接手一个新项目先读它）。Obsidian 在这里的角色是可视化端口——把一张张卡片连成一张网，让你对全局有把握；它是看的窗口，不是体系本身。
库大了怎么办。 两个动作：地图分层——总地图只写到“每个格子管什么”这一级，某一类涨厚了，就在它自己脚下再放一张小地图，总地图上那一行不用变；定期下架——没有人链接它、很久没有用过、里面的说法已经被新的取代了，这三样占了两样，就把它挤到 04_归档。库的健康不靠“什么都留着”，靠“留下来的都还活着”。
AI 能碰什么，三档定死。
| 档 | 位置 | 规矩 |
|---|---|---|
| 随便写 | AI 沙箱、公示板 | 沙箱是草稿层，公示板是记录层，写坏了不心疼 |
| 可以写，四类先请示 | 知识库、代码仓库 | 删除、批量改（三份以上）、挪目录、往外发——这四类先把要动的文件列成清单给你看 |
| 只读 | 凭证保险库 | AI 要用的钥匙，用环境变量递进去，不把钥匙文件拷进任何干活的地方；这一条没有商量余地 |
AI 每动一次手，留一行记录：改了什么、改在哪份里。记录是给你查的，不是给它看的。
两套记录对不上怎么办。 手改文件本身允许，也应该——知识库本来就是给人直接改的；要补的是改完之后那一个动作：说一句“我改了 X”，让 AI 知道去哪对齐。
剩下的靠定期对账兜底：定时跑一个 Skill，拿“库里实际有什么”和“公示板上记了什么”对一遍，只报两类——库里新出现、登记里没有的；登记里写了、库里已经不在的。只报告，不自动改；两边打架时，以磁盘上真实存在的那一份为准，登记向实际看齐——记录错了改记录，别改磁盘去迁就记录。
一件事变了，全库怎么跟上
改名、搬家、改主意——这类动作会牵动别处，所以走固定顺序。
先判这次改的是“地图”还是“内容”。 地图是“什么东西叫什么、干什么用、在哪儿”；内容是具体的说法与细节。改地图，要通知一圈——它会牵动所有指向它的卡片；改内容，自己改就行，顺手补一句登记。
再从上层往下改。 顺序固定：先改地图与命名，再改卡片链接，最后改内容本体。 反过来改，中间任何一步都会让别的卡片指空。
动手之前先查影响。 让 AI 先把引用它的地方列出来，列不出就先别改——“列出所有指向这份文件的位置，先别动手。”改动本身用这条工作流：主 Agent 负责改，Subagent 负责查，Subagent 对照规则检查，不合格就打回重改；每一步的动作记进公示板。人只在两个地方出现：开头定“改哪一份”，最后核查结果。
以后很难反悔的决定，写一页短语留档：决定了什么、为什么、否了哪些备选。几个月后你自己、或者换一个 AI 来接手，读这一页就能对齐，不用对着一堆笔记猜。
你在这套体系里的位置。 去留由你定，维护交给 AI——这是全篇最后一条，也是最要紧的一条：分拣、去留、颗粒度、先做哪个，全是你的判断；改名、搬运、更新索引、更新地图、对账，全是它的活。两边各有一份规则，缺哪边，这套体系都会烂。