AI 时代，别只囤笔记：我是怎么把知识库做成一部活的 Wiki

这两年我越来越明显地感到一件事：AI 很聪明，笔记很多，可人还是常常卡住。

为什么？

因为 AI 知道的是公共世界，咱们真正要用的，往往是自己的那点"私房货"：上周为什么推翻方案 A，三个月前哪个坑已经踩过，某个老项目里那句"这里千万别这么改" 到底写在哪个文件里。

这几年我写博客、做笔记、留工作文档，存了不少东西。平时看着都在，真到要找时，经常像在阁楼里翻纸箱。Obsidian 一份，飞书一份，公司 wiki 一份，本地 Markdown 还有一份。东西没丢，人先烦了。

所以我后来慢慢想明白了，AI 时代最值得花力气搭的，不是一个"更花哨的笔记软件"，而是一套属于自己的知识底座。它得让人能读，AI 也能读；得能持续吸收新材料，也得经得起回头审计；得能回答问题，更得能支持写作、决策和协作。

我最近折腾的一套私人原型，表面上是个 file-based wiki，骨子里其实在回答一个更土、也更真切的问题：

在 AI 发达的今天，怎么建立自己的知识库，才能让它不只是一个知识仓库？

这篇就结合这个项目，聊聊我现在的答案。

先说结论：知识库不是"硬盘"，而是"生产线"

很多人做知识管理，第一步就走偏了。

看到好文章，存一下。开会有纪要，存一下。灵光一闪，赶紧记一下。时间一长，Notion、Obsidian、飞书、邮件、微信收藏、本地 Markdown，到处都是"资料"。看上去挺勤奋，实际上像家里囤了一仓库纸箱，箱子外面还写着差不多的标签。真要找东西时，还是靠运气。

我现在的看法很简单，一句话：

知识库真正的价值，不在"存了多少"，而在"能不能持续吸收、整理、校验、连接，再反过来服务行动"。

换句话说，知识库不是仓库，更像车间。原材料进来，先分拣，再加工，再质检，再编目，最后变成能直接拿来用的东西。你要的是"随时可取"，不是"堆着不丢"。

我在这套原型里，故意把这条线做得很明确：

init -> import/ingest -> verify -> build -> serve

这几个动词比"写笔记"更重要。因为它们说明一件事：知识不是静态摆放，而是动态生产。

为什么我没有把知识库做成"黑箱数据库"

我做这个项目时，最先定下来的一个原则是：文件系统才是 source of truth。

所以这套原型里的页面就是 Markdown 文件，元数据放 YAML frontmatter，目录就是分类，Git 直接记录历史。这样做不花哨，但很踏实。

1. 人能直接读，AI 也能直接读

Markdown 是少数同时对人类和 AI 都友好的格式。

• 人类可以直接打开看，不需要专门客户端。
• AI 可以直接解析，不需要复杂转换。
• Git 可以对比 diff，不会像数据库那样一黑到底。

这一点在 AI 时代尤其重要。因为将来不只是你自己在用这些知识，AI agent 也会参与进来。它要读，要写，要补充，要总结。如果底层格式不透明，最后你得到的很可能只是一个"看起来很聪明，谁也说不清里面装了什么"的黑箱。

2. 页面必须是"显性知识"，不是隐形向量

向量检索当然有用，我并不反对。

但如果一个知识库里，最核心的内容只存在于 embedding 里，那它更像一个"召回系统"，不是一个真正的知识系统。因为你看不到它形成了什么判断，也看不到它到底依据了什么内容。

所以我更偏向"编译式知识库"这个思路：先把原始材料整理成结构化页面，再让搜索、问答、AI 助手建立在这些页面之上。

这也是我现在比较认同的三层结构：

raw/        -> 原始材料、待处理输入
wiki/       -> 结构化知识页面
metadata/   -> schema、索引、日志、治理信息

有了这三层，"随手记下来的碎片" 和 "已经沉淀过的结论" 就不会搅成一锅粥。前者是毛坯房，后者才是能住人的房子。

3. Git 历史本身就是知识的一部分

很多人只把 Git 当代码工具，我越来越把它当知识工具。

为什么这个页面是今天这个样子？是谁改的？什么时候改的？是 AI 先写的，还是人后来修过？这些都不是边角料，而是"这条知识值不值得信"的重要依据。

所以在这个项目里，我特别看重这些元数据：

• created_by
• updated_by
• source
• verification_status
• updated
• commit

这些字段干的不是"装饰工作"，而是把"知识的来路和可信度"说清楚。

我是怎么搭这个知识库骨架的

如果把这套原型当成我对知识库的一次实验，那它的骨架大致有四层。说白了，就是先把门、牌照、用途和规矩都立起来。

第一层：先把入口分清楚，别让所有东西都挤在一个 inbox

做知识库最大的坑之一，就是"什么都先记下来，以后再整理"。

问题是，"以后" 通常不会来。

所以我现在会强迫自己把入口拆开：

• raw/ 放原始材料，比如剪藏、会议记录、临时草稿、外部文档
• wiki/content/ 放已经整理成页面的知识
• wiki/metadata/ 放治理文件、索引和日志

这样分的好处是，你永远知道一条信息现在处于哪个阶段：

• 只是收集了
• 已经分类了
• 已经沉淀为可复用知识了
• 已经被验证过了

这听起来有点流程味，实际上是在帮自己对抗信息过载。否则三个月后你回头一看，根本分不清哪些是随手一记，哪些是你真正认可的结论。

第二层：给每一页加"身份证"，别让 AI 胡乱冒充权威

项目里我给页面定义了比较完整的 frontmatter，核心类似这样：

---
title: "Page Title"
tags: [tag1, tag2]
summary: "Brief description"
created_by: ai
updated_by: human+ai
doc_type: explanation
verification_status: unreviewed
source:
  type: git_repo
  uri: "https://github.com/example/repo"
  path: "docs/design.md"
  ref: "main"
---

我越来越不相信"没有上下文的知识"。

一句话写得再漂亮，如果你不知道它从哪里来，由谁写下，有没有复核，适合什么场景，那它就很容易变成一种危险的"伪确定性"。AI 特别擅长把这种伪确定性说得一本正经，气势很足，心里没底。

所以我宁可让知识库多一点"啰嗦的元数据"，也不愿意让页面看起来像百科全书，其实来源不明。

尤其是 verification_status 这个设计，我很喜欢。AI 写的内容默认可以是 unreviewed，人确认过的再变成 supported。这样一来，AI 就不是在偷偷替你发言，而是在老老实实交作业，等你批改。

第三层：别只按主题分类，要按"文档职责"分类

我在这套原型里引入了 Diátaxis 的四种文档类型：

• tutorial
• how-to
• reference
• explanation

这件事看着文绉绉，其实非常实用。

很多知识库之所以越写越乱，不是因为内容不够多，而是因为文章都写成了一个样子。教程里掺了一半原理解释，参考文档里又夹了操作步骤，最后每篇都像一锅乱炖。写的人累，看的人也累。

我后来才慢慢意识到：分类不仅是为了"放在哪"，更是为了"怎么写" 和 "怎么用"。

比如：

• 我 onboarding 新同事时，更需要 tutorial
• 我线上排障时，更需要 how-to
• 我查参数和接口时，更需要 reference
• 我做技术判断时，更需要 explanation

如果知识库不区分这些职责，搜索结果再多也很难真正帮上忙。你明明是来查参数的，结果先被教育了半天人生道理，这谁受得了。

第四层：给知识库配治理文件，而不是只配目录

这是我这次做项目时感受最深的一点。

以前我们搭知识库，通常只会关心目录结构，比如 programming/、devops/、project-a/。现在我觉得这还不够，还得有"治理层"。

在这套原型里，至少有这么几类治理文件很关键：

• 一个 schema 文件：告诉人和 AI，这个知识库接受什么命名、什么 frontmatter、什么链接规则
• 一个总索引页：给出总入口，避免内容写着写着散掉
• 一个变更日志页：记录操作轨迹，知道最近发生过什么变化

而在后续演进里，我又特别想补上一块"目的说明"。

为什么？因为 schema 解决的是"怎么写"，解决不了"为什么写"。没有目的约束，AI 很容易把知识库越写越像一锅资料汇编，什么都沾一点，最后什么都不聚焦。

所以如果今天让我给任何一个人提建议，我会说：

别只给知识库设计目录，也给它设计"宪法" 和 "北极星"。

前者约束格式，后者约束方向。

怎样让它不只是一个知识仓库

这才是最关键的问题。

如果只把资料放进去，知识库最多算个"电子储物柜"。要让它真正活起来，我现在主要做五件事。

1. 让它有摄入能力，而不是靠手工搬运

在这套原型里，我给自己留了几种入口：

• 单文件导入
• 目录批量导入
• URL 导入
• inbox 批处理

这意味着知识库不是一个"只能手工写页面"的地方，而是一个能够不断吸收外部材料的系统。

比如我看到一篇文章，存下一份设计文档，记了一段会议纪要，它们都可以先进入 raw/，然后再经过分类、整理和沉淀。这样你就不会被迫在"先别记" 和 "记了就永远不整理" 之间二选一。

2. 让它有校验能力，而不是只会越堆越多

我很反感一种知识管理幻觉：以为"存下来了" 就等于 "掌握了"。

其实很多知识库，最需要的不是更多输入，而是一次体面的体检。

所以这套原型里有一条专门的校验步骤，我觉得非常必要。它提醒我去看：

• 有没有失效链接
• 有没有互相矛盾的内容
• 有没有长期没更新的页面
• 有没有来源不明、状态不清的页面

AI 时代更要重视这件事。因为 AI 能帮你生产内容，但不会天然帮你控制内容腐烂。你如果没有"验证" 这道工序，最后得到的往往是一个产能很高、质量很飘的知识工厂。量上去了，心里反而更虚。

3. 让它有连接能力，而不是只有孤岛页面

我越来越觉得，知识的价值一半在内容，一半在连接。

我在这套原型里放了 wiki link、分类索引、标题索引、标签索引、最近变更、全文搜索。这些能力单看都不复杂，但加在一起，会把一堆独立页面变成一个可以漫游的网络。

这点对人和 AI 都重要：

• 对人来说，你能顺着链接找到上下文
• 对 AI 来说，它能据此判断哪些页面互相关联

没有连接的知识库，很像一本页码被撕掉的书。每一页可能都对，但你不知道它和前后文是什么关系。单页是对的，整体是散的。

4. 让它有信任分层，而不是"一律当真"

这是我很在意的一件事。

以前我们默认"写进文档的就是正式结论"，现在这个前提已经不成立了。因为越来越多内容是 AI 草拟的、协作生成的、甚至是半自动编译出来的。

所以知识库里最好天然区分几类状态：

• 这是原始材料
• 这是 AI 整理稿
• 这是人审核过的稳定结论
• 这是已经过时但保留存档的历史页面

你会发现，一旦把这层状态显式化，知识库的气质就完全不一样了。它不再假装自己"句句都像圣旨"，而是诚实地告诉你：哪部分可以直接信，哪部分要打个问号。

5. 让它有出口，能反过来服务写作、决策和协作

如果一个知识库最常见的用途只是"搜一下"，那它还没完全发挥价值。

我现在更看重它能不能反过来支持这些动作：

• 写博客时，快速调出过去的材料和观点
• 写设计文档时，复用已有术语、约束和决策背景
• 做 code review 或 onboarding 时，给新人一条可追踪的知识路径
• 问 AI 问题时，让它基于我的材料回答，而不是基于公共互联网胡猜

这其实就是从"存储系统" 走向 "工作系统"。

知识库一旦能稳定支持这些输出，它就不只是记忆体，而开始像一个"外接大脑"了。平时安安静静地躺着，用的时候又真能帮上忙。

一个最小可行做法

如果你今天也想搭一个自己的知识库，我建议别一上来就追求"大而全"，先做一个最小版本。

第一步：选一个足够朴素的底座

我建议优先考虑本地 Markdown + Git。

原因很简单：十年后它大概率还读得出来，迁移成本也低。你现在贪的那点"功能炫酷"，以后很可能都要连本带利还回去。

第二步：先把目录分成三层

raw/
wiki/content/
wiki/metadata/

就这三层，先跑起来再说。别上来就设计 27 个目录，最后自己也记不住。

第三步：为页面补齐最关键的元数据

至少有这些：

• title
• summary
• tags
• doc_type
• source
• created_by
• verification_status

少了这些，后面 AI 很难稳定帮你工作。

第四步：把"导入" 和 "校验" 做成固定动作

对应到实践里，大概就是：

初始化知识库目录
导入一篇笔记或一批材料
跑一次校验
重建索引和页面
启动本地预览

这几个命令的意义不只是跑通工具，而是帮你养成习惯：输入不是随便堆，输出之前要过一遍检查。别把知识库养成一个只进不出的仓鼠笼。

第五步：给 AI 划边界，不要让它自动发布"结论"

我的经验是：

• AI 适合做分类、摘要、初稿、链接建议
• 人适合做定性、取舍、背书、最后发布

别把这两件事反过来。否则你的知识库会越来越勤快，也越来越不靠谱。它看上去很忙，实际上在制造新的技术债。

我现在最警惕的三个坑

最后说几个我自己也在努力避免的坑。

坑一：把知识库做成信息坟场

看起来什么都没丢，实际上什么都找不到。症状通常是"收藏很多、沉淀很少、搜索全靠关键词碰运气"。

坑二：把 AI 当权威，而不是当助手

AI 可以参与知识生产，但不该偷偷代替你下结论。尤其是涉及架构、流程、组织经验的内容，最后那道责任门最好还在你手里。

坑三：只追求检索效果，不建设可读页面

这类系统通常 demo 很亮眼，长期维护却很痛苦。因为知识最后还是要给人看、给人改、给人讨论。页面不可读，知识就很难变成团队资产。能召回，不等于能传承。

结语

AI 时代，建立自己的知识库，不再是"爱记笔记的人" 的小众爱好，而越来越像一种基础能力。

它决定了你是在反复喂给 AI 一堆零散上下文，还是给它一个真正可依赖的工作底座；也决定了你手里的知识，是一堆安静躺着的文件，还是一套能不断吸收、整理、校验、连接、输出的活系统。

如果要把这篇文章收成一句话，我会这样说：

知识库最好的形态，不是仓库，而是 wiki；不只是 wiki，而是一条可信、可演化、可协作的知识生产线。

可执行清单

• 用本地 Markdown + Git 作为知识底座
• 把内容拆成 raw / wiki / metadata 三层
• 为页面补齐来源、作者、状态、文档类型
• 区分 AI 初稿和人工确认内容
• 定期跑一次校验，处理失效和陈旧信息
• 用 wiki link、索引和标签把页面连起来
• 让知识库服务真实工作流，而不只是"能搜到"

参考

• 我自己这些年积累的博客、笔记和工作文档整理经验
• file-based wiki 的一些通用设计思路
• Diátaxis 文档分类方法
• Git 作为知识历史与审计线索的实践

你现在手上的知识库，更像"收藏夹"，还是已经开始像"操作系统"了？