昨天在文章里顺嘴提了一句我自己搭建个人知识库的事情，今天索性就跟大家好好唠唠这套东西。

过去几年，我收藏了大量文章，公众号自己也写了不少内容。

但真正遇到问题时，我还是习惯性地重新搜索。

以前写过什么、做过什么判断、哪些观点之间有关联，脑子里经常断片，完全想不起来。

这让我意识到：收藏资料不等于拥有知识。真正有价值的知识库，应该帮助我找回信息、形成判断，并推动下一步行动。

于是，我开始尝试搭建自己的 AI 个人知识库。

目前已经纳入近 300 条原始材料和原子笔记，并逐渐形成了一套从收集、整理到问答和复盘的完整流程。

1. 个人知识库究竟有什么用？

1.1 集中管理分散的信息

过去的内容可能散落在公众号文章、网页收藏、PDF 文档、临时想法、项目文档、聊天记录以及不同的笔记软件里。

个人知识库首先解决的是“信息放在哪里”的问题。

所有内容进入统一目录，并区分为：

raw：未经修改的原始材料
notes：从单条材料中提炼出的原子笔记
wiki：由多条笔记编译形成的主题结论
briefs：选题、周报和复盘报告
logs：处理过程和错误记录

这样既保留了原文，又能逐步形成结构化知识。

1.2 帮助自己找回曾经的思考

搜索只能告诉我“哪些内容包含这个关键词”。

而知识库更应该回答：

我以前如何看待这个问题？
我的观点发生过什么变化？
哪些文章能够支持这个判断？
我在哪些地方存在矛盾？
当前证据还缺少什么？

它不仅是资料搜索工具，也是一面观察自己的镜子。

1.3 基于自己的材料向 AI 提问

普通 AI 回答依赖模型已有的通用知识。

个人知识库问答则优先使用我自己的文章、笔记和判断，并要求回答必须提供引用来源。

例如我可以问：

基于我过去写过的内容，我最关注的长期问题是什么？
我对 AI 产品的判断发生过哪些变化？
我有哪些反复出现，却一直没有解决的问题？

如果材料不足，系统应明确告诉我“证据不足”，而不是用模型常识补出一个看似合理的答案。

1.4 把零散材料编译成稳定结论

一篇文章通常只解决一个局部问题。

当同一主题积累了多条材料后，可以把它们编译成 Wiki 主题页，例如：

我的 AI 产品方法论
个人知识管理体系
内容创作原则
当前职业判断
某个产品或公司的长期观察

原子笔记负责保留事实和局部判断，Wiki 负责形成阶段性认知。

1.5 为写作和决策提供素材

知识库还可以根据已有内容生成：

写作选题
观点冲突
证据缺口
周度总结
可继续研究的问题
下一步行动建议

这样，知识库就不只是“存放过去”，还能够参与未来的创作和决策。

2. 我是怎样搭建这套知识库的？

整个过程可以分成四个阶段。

第一阶段：先建立最小骨架

一开始不要急着接入向量数据库、复杂 Agent 或云服务。

先确定三个最基本的问题：

什么内容需要进入知识库？
内容以什么格式保存？
将来如何迁移和备份？

我的选择是以 Markdown、JSON 和原始文件作为事实源。

这样做的好处是：

不依赖某个笔记软件
文件可以直接打开
可以使用 Git 管理代码和公开内容
可以复制到其他磁盘进行备份
即使以后更换 AI 模型，原始数据仍然存在

Web UI 只是操作界面，文件系统才是最终的数据事实源。

第二阶段：打通内容入库

系统需要支持最常见的输入：

一句话想法
普通网页
微信公众号文章
GitHub 仓库
PDF 和扫描版 PDF
本地文件夹批量导入

每次入库都会经历：保存原文 → 生成原子笔记 → 提取标题与标签 → 建立关联 → 更新索引。

同时还需要处理重复内容和版本变化。

同一个网页重复提交时，不应该不断生成副本；网页内容更新后，也不应该直接覆盖旧版本，而应保留历史。

第三阶段：建立索引、关联和问答

有了内容之后，下一步才是“怎样取出来”。

当前系统会：

对笔记和 Wiki 进行分块
建立可重复生成的本地索引
根据标签和标题关键词建立关系
检索与问题最相关的材料
将这些材料交给 AI
校验回答中的引用是否真实存在

AI 可以通过本地 CLI 或 HTTP Provider 接入，例如 Codex、ZCode 或其他兼容模型。

其中最重要的原则是：每个结论都必须能够回到具体来源，如果只有漂亮的总结却没有证据，那它仍然是不可靠的。

第四阶段：接入日常使用

知识库最终是否有价值，不取决于功能数量，而取决于是否真正进入日常流程。

我给自己设计的最小使用方式是：

看到有价值的内容，立即入库
遇到问题时，先询问自己的知识库
同一主题积累两三条材料后，编译 Wiki
每周生成一次周报和选题
对重要回答显式保存为决策记录
连续记录 14 天真实使用情况

Web UI 将入库、问答、搜索、关系图、Wiki、报告和诊断集中在一个本地工作台中，从而减少记忆命令的成本。

3. 搭建过程中最需要避开哪些坑？

3.1 不要把知识库做成资料仓库

收集越多，不代表知识越多。如果内容再也没有被用于决策，它只是换了个地方躺尸。

因此，比“收集数量”更重要的是：

问过多少真实问题
回答是否真的有用
引用是否准确
是否形成新的判断
是否减少了重复搜索

3.2 原文、AI 总结和个人判断必须分开

原文是事实来源，AI 总结是加工结果，个人判断才是最终需要沉淀的内容。

三者混在一起，时间久了就很难分辨一句话究竟是谁说的。

3.3 AI 回答必须带引用

没有引用的知识库问答，很容易退化成普通聊天机器人。

引用不仅用于证明答案，也方便发现检索是否找对了材料、AI 是否误解了原文、当前结论是否只有单一来源、以及哪些问题仍然缺少证据。

3.4 先用简单检索验证需求

在资料规模不大时，关键词检索、标签和关系扩展已经能解决大量问题。

只有当真实评测证明现有召回效果不足时，再考虑 Embedding、向量数据库或混合检索。

不要因为技术听起来先进，就提前增加系统复杂度。

3.5 必须考虑隐私和数据边界

调用外部 AI 时，被选中的正文和上下文可能发送给模型服务。

因此需要明确：

哪些材料允许发送
API Key 只放在运行时环境变量中
日志中不记录密钥和完整正文
私密运行数据不提交到公开仓库
备份目录也按照私密数据保护

3.6 失败不能破坏已有内容

知识库属于长期积累的数据资产。

写入过程中即使程序中断，也不能导致原文、笔记、索引和问答历史互相矛盾。因此需要原子写入、错误日志、完整性诊断和本地备份。

3.7 用真实使用验证，而不是继续堆功能

我目前采用的是 14 天验证法：

至少入库 20 条真实材料
至少提出 10 个真实问题
至少 8 个回答有用且引用正确
主动使用不少于 10 天
没有长期退回原来的搜索方式

如果没有达到目标，先找出最高频的阻力，而不是马上增加新功能。

4. 我现在对个人知识库的理解

个人知识库不是另一个收藏夹，也不是简单给文件接上 AI。

个人知识库真正应该完成的是这样一个循环：收集信息 → 提炼观点 → 建立关联 → 提出问题 → 核对证据 → 形成判断 → 推动行动。

最终重要的不是知识库里保存了多少内容，而是它能否在我需要的时候，帮助我找回过去的自己，并让我做出比过去更好的判断。

这才是我继续完善这套个人知识库的真正原因。