AI 时代如何构建自己的知识库
过去，大家沉淀个人知识的方式通常只有两点：一是记笔记，二是靠大脑硬记。实际上，绝大多数人都在依赖后者。比如，一名研发往往清楚自己负责的项目里哪段逻辑有坑，全凭经验和记忆在脑海里索引。也有人养成了记笔记的好习惯，但很快会遇到另一个难题：笔记记多了，检索就成了沉重的负担。
在大模型普及的今天，获取公共知识的门槛已经被彻底抹平了。过去为了搞懂一个知识点，我们需要在搜索引擎里翻阅大量网页、甄别信息；现在直接向 AI 提问，它就能高效梳理出我们想要的内容。但公共知识之外，还有一个更关键的领域：私有知识。那些我们靠记忆或笔记沉淀下来的项目细节、业务决策与技术踩坑，构成了我们最核心的私有知识库。要让 AI 真正成为专属于你的得力助手，前提就是让 AI 与你共享这个私有知识库——这也是为什么记笔记的习惯在今天变得更加重要，因为这些笔记正是喂给 AI 的绝佳原料。
因此，我们不应再过度依赖大脑记忆来沉淀知识，而应尽可能把有价值的事情都记录下来。例如：今天跟客户开会聊了什么、达成了什么结论、有哪些 TODO 项需要跟进，线上排查故障定位到了什么根本原因……全都记进笔记里。过去，笔记越多往往越难查；而在今天，只要把这些知识提供给 AI，让它帮我们检索与总结，事情就会变得极其简单。
理清了这层逻辑，具体该如何实施落地？我认为核心在于做好四个环节：方法论、工具选型、检索机制与服务化消费。
组织方法论：PARA + I
搭建知识库的第一步不是挑工具，而是建立一套属于自己的分类方法论。方法本身没有绝对好坏，关键在于是否有清晰的边界和可持续性。
我的日常实践是在经典 PARA（Project, Area, Resource, Archive）体系的基础上加入了一个 Inbox，形成“PARA + I”。我们为每一个类别建立一个根目录：
- 00-Inbox（收集箱）：还在处理中的临时文档、随手记下的灵感碎片，以及 Agent 自动生成的初稿等缓冲内容。
- 10-Project（项目）：记录具有明确起止时间与交付目标的项目笔记。比如正在跟进的一个客户、正在开发的一款 App。
- 20-Area（领域）：记录需要长期维护的专业领域经验。比如在项目研发中沉淀下来的技术方案，更具体如“如何通过 TiDB 查询当前 TSO”。
- 30-Resource（资源）：记录个人兴趣与长期参考的资料。比如摄影构图技巧、家庭养鱼心得等。
- 40-Archive（归档）：归档已经完成或不再活跃的内容。比如已经结束的项目，归档后既能备查，又不会干扰日常活跃目录。
整体的笔记目录结构大致如下：
00-Inbox
- agent
10-Project
- finance
- 效率
- ...
20-Area
- cs
- finance
- DB
- ...
30-Resource
- 摄影
- 养鱼
- ...
40-Archive
- 10-Project
- 20-Area
- 30-Resource
- ...
清晰的分类方法不仅能帮助 AI 更准确地根据目录定位上下文，更重要的是，即使在断网或 AI 不可用时，我们自己也能顺着层级迅速找到想要的内容。
工具选型：为什么必须是本地 Markdown？
有了方法论，接下来是选择笔记软件。
许多人习惯使用各类商业云笔记，但商业云笔记往往存在一个根本问题：用户无法真正完全掌控自己的数据。有些平台甚至连基本的批量导出功能都不支持，导致我们根本无法把笔记内容自由喂给 AI。笔记是个人最重要的数字资产，我们必须拥有完整的数据控制权——决定把它存放在哪里，以及如何使用程序对它进行切分与向量化（Embedding）。
因此，我强烈建议使用以本地文件为中心的笔记软件（如 Obsidian）：
- 绝对的数据控制权：笔记就是本地磁盘上的纯文本 Markdown 文件。没有私有格式锁定，你可以用任意脚本或工具去批量读取、解析和处理。
- 格式通用，天然契合 AI：Markdown 简洁易读，无论是人类阅读、程序解析还是大模型理解，都具备天然的友好性。
- 版本管理与工程化协作：本地文件可以自然结合 Git 进行版本管理，不仅能清晰回溯历史变更，还能直接接入 CI/CD 自动化流程。
- 规范的模板生态：借助生态成熟的模板工具，预先定义好会议纪要模板、项目跟进模板等。统一格式不仅能降低动笔时的心智负担，也让沉淀下来的知识更加结构化。
检索机制：从精确匹配到向量语义检索
用规范的方法在本地沉淀了大量 Markdown 笔记之后，下一步就是如何让 Agent 高效使用这些内容。
最朴素的思路是全文精确搜索（Full-Text Search）。由于 Markdown 是纯文本，Agent 做关键词匹配并不困难。但纯字符串匹配的最大痛点在于召回率低，无法处理跨语言和语义关联。
举一个真实的场景：在我的 20-Area/cs 目录下，有一篇介绍如何让 Codex 在 MacBook 休眠或合盖时继续工作的英文教程，其中包含这样一句话：
Codex can continue running while the Mac display is off.
很久之后，如果我想重新找出这篇教程，让 Agent 去检索中文关键词“休眠”，纯字符串匹配就会彻底失效——因为原文里根本没有出现过“休眠”二字。
这就需要引入 Embedding（向量化）。将笔记切分后转化为向量存入数据库，检索时通过计算向量相似度来进行语义匹配。在刚刚的场景中，即使我们搜索中文“休眠”，向量检索也能根据语义关联，准确命中包含 Mac display is off 的那篇教程。这也是为什么前面反复强调必须拥有笔记完整控制权：只有拿到原始文件，我们才能自由地切分内容、调用模型生成 Embedding，并将其存入向量数据库中。
消费端：通过 MCP 为 Agent 提供检索服务
在这一套体系中，数据流可以清晰地划分为两端：
- 数据生产者：负责读取笔记、文本切块、生成 Embedding 并写入向量数据库。
- 数据消费者：Agent 在需要参考私有知识时，去向量数据库中发起查询。
连接 Agent 与向量数据库的最佳桥梁就是 MCP（Model Context Protocol）。我们只需编写一个简单的 MCP 服务，向外暴露向量搜索接口，并将其配置给 Agent。Agent 在推理过程中如果判断需要查询私有知识，便会主动通过 MCP 调用该工具，从向量数据库中检索相关片段作为上下文。这种设计实现了存储层与 Agent 客户端的彻底解耦。
个人零成本落地架构：TiDB Cloud + Vercel + GitHub Actions
对于个人使用者来说，搭建这样一套系统完全可以做到极低成本甚至零成本。核心依赖的向量数据库、计算环境与托管平台，都可以充分利用云厂商提供的免费额度：
Obsidian 本地笔记
│ git push
▼
GitHub 仓库
│ 定时触发 (Cron)
▼
GitHub Actions Runner ──(增量切片 + 向量化)──► TiDB Cloud (Vector 存储)
▲
│ 语义检索
Agent (Codex / Claude Code 等) ──(MCP 协议)──► Vercel (MCP 服务)
- 向量数据库：TiDB Cloud。无论是国内的平凯星辰云服务还是海外的 TiDB Cloud，都提供了 Serverless / Starter Tier 的免费额度，且内置了向量检索能力（
tidb_vector），容量和性能完全能满足个人的日常知识库使用。 - MCP 服务托管：部署在 Vercel 上。利用 Vercel 提供的免费 Serverless Function 部署方案，免去自行维护服务器的成本，按需响应 Agent 的查询请求。
- 自动化同步构建：利用 GitHub Actions 定时流水线。我的方案是将笔记上传到 GitHub 私有仓库（这也是掌握完整控制权带来的灵活性）。配置一个定时运行的 GitHub Actions 工作流（例如每天凌晨 0 点），Runner 自动检出笔记仓库，增量提取变更文本，调用 Embedding 接口生成向量后写入 TiDB。
数据安全与运维底线
在享受自动化便利的同时，有两点安全防护必须做好：
- 避免构建日志泄露隐私：在 GitHub Actions 的 Embedding 脚本中，务必做好日志脱敏，严禁将笔记正文打印到控制台日志中，防止私有数据在 CI 日志中留痕。
- MCP 服务严格鉴权：部署在公网的 MCP 接口必须配置认证鉴权（如 API Key 或 Bearer Token）。Agent 接入 MCP 时必须携带授权凭据，只有鉴权通过才允许查询，杜绝个人数据在公网上无防护暴露。
总结
在 AI 时代，通用的公共知识早已垂手可得，真正能拉开差距、让 AI 成为专有助手的，正是那些沉淀着独特经验与业务背景的私有知识。
守住本地数据控制权，用清晰的体系组织笔记，再借助 GitHub Actions、TiDB Cloud 与 Vercel 的免费生态实现自动化向量化与 MCP 服务化，我们便能以极低的门槛，为自己搭建一个随叫随到、真正懂你的专属 AI 外脑。