2026年已经过去大半，你的知识库建起来了吗？
上半年全网都在推「AI知识库搭建教程」，就好像没搭一个就不算会用AI。
用 Obsidian 管文件，用 Claude Code 等 Agent 整理资料，接上 RAG，生成摘要、双向链接和知识图谱。
每一种方法都讲得很完整：装什么、目录怎么分、Prompt 怎么写、资料怎么导入。
可是很少有人继续回答：建完以后呢？
谁来看这套知识库？谁来查？它具体进入了哪项工作？帮助谁学会了什么？又让哪个结果发生了变化？
工具当然能用，教程也不是在骗人。
知识图谱画出来了，双向链接连起来了，文件夹也分得很漂亮。面对满屏节点，我们很容易产生一种错觉：看，我已经有第二大脑了。
实际上，大脑有没有变不知道，硬盘里倒是多了一批 AI 写的 Markdown。
原本要解决学习和工作问题，最后却变成了完成一次“建库”手工课。
哪些情况根本不需要建知识库
先别急着收集。我们要分清信息、资料、知识和知识库。公开信息随时可以重新获得；资料是为某个问题保留下来的信息和证据；知识则要经过理解或验证，能够支持判断和行动。知识库可以保存资料和知识的外部表达，却不会自动把它们变成你的能力。
大模型本身已经学过大量公开知识。随着模型能力继续改善，许多公开、稳定、随时能重新获得的通用内容，单独建库的价值可能越来越低。
下面这些内容通常不值得单独建库：
- 一次性问题，答案用完就结束；
- 模型已经掌握、随时可以重新获得的通用知识；
- 没有可信来源、无法复核的 AI 长文；
- 只是觉得“以后可能有用”的批量收藏；
- 高频变化、原本应该由业务数据库管理的数据；
- 没有明确使用者和调用时机的聊天记录；
- 为了让图谱更丰富而创造的空洞关系。
建库前先回答四个问题：
- 谁用？ 人、模型，还是某条工作流？
- 什么时候用？ 学习时、决策前、执行中，还是出错后？
- 用了改变什么？ 理解、答案、动作，还是结果？
- 为什么不能临时再找？ 它是私有的、动态的、需要追溯的，还是积累成本很高？
四个问题都说不清，先不要建。
知识库到底给谁用
知识存下来还不算结束，真正的问题是谁来用。按使用者来看，知识库大致分为三类：给人、给模型，以及给工作流。
1. 给人用，帮助理解和学习
AI 生成一篇摘要，不代表你理解了；知识图谱上连着十个概念，也不代表你能解决一个新问题。
如果你要学会分析一家公司的商业模式，理解 Agent 为什么会失败，或者掌握如何与客户澄清需求，知识最终要内化到自己身上：面对具体情况时，能够判断什么重要、什么适用、接下来应该怎么做。
学习型知识库可以这样工作：
读一份材料
→ AI 帮助拆解概念
→ 人用自己的话复述
→ AI 给出新案例和反例
→ 暴露误解
→ 把误解和修正写回
→ 过一段时间再次测试有价值的页面不一定是最完整的概念百科，反而可能是“我在什么地方理解错了”。它应该保存你的误解、练习和仍然回答不了的问题，而不是只存一份正确答案。
衡量效果时，不要看生成了多少张卡片，要看你能否不用原文讲清楚，能否把它用在新案例上，能否判断一个反例，能否脱离知识库完成任务。
这时，知识库是学习工具，不是学习成果。离开它就什么都不会，它还只是拐杖。
2. 给大模型用，补充它不知道或不能乱猜的东西
还有些内容不必内化到人身上。电话号码、API 参数、一家公司过去五年的产品发布时间，需要时能准确找到就够了。
一类 AI 知识库不是给人看的，而是给模型提供外部依据。模型知道大量通用知识，却不知道项目进度、公司内部规则、昨天的客户决定和刚发布的新版本。知识库可以让它依据指定资料回答，使用统一口径，读取最新状态，并给出原始出处。
下面几类资料更适合保存在可更新的外部系统中：
- 私有知识：个人记录、企业流程、客户资料和项目决策；
- 动态知识：今天的库存、当前版本、最新政策和项目状态；
- 高风险或受约束的知识：合同条款、审核规则和操作边界；
- 需要追溯的知识：必须指出来源、时间和原文依据的结论；
- 个人与组织经验：复盘、决策，以及成功或失败的条件。
模型会继续变强，但不会仅凭参数知道你公司昨天开会做出的决定。即使能通过工具取得，也需要一个经过授权、可更新且可核验的信息源。该问的是：哪些知识交给模型，哪些留在可更新、可审计的外部系统里。
这类知识库的价值不在于页面多，而在于来源是否准确、内容是否仍然有效、事实和推导能否分开、需要时能否快速定位。知识图谱如果帮助定位关系，就有用；只是把普通链接画得复杂，就是装饰。
3. 给工作流用，让知识直接触发行动
还有一些知识不是概念或事实，而是“在什么条件下，应该做什么”。它不该等人主动搜索，也不该等模型临时想起来，而要在特定节点被调用。
比如客户连续两次无法确认成功标准，项目就暂停澄清；文章出现强比较，发布前必须补独立来源；某种 Prompt 只在特定模型和输入格式下有效。
例如做一个长期项目，知识不只是散落的会议记录，而可以被整理成：
项目目标
关键决策与依据
已尝试但放弃的方案
客户反馈与证据
风险、问题和未决项每次开会后，Agent 提取新增决策和风险，由负责人确认后写入；准备新方案前，先检查有没有重复走失败路线；新成员加入时，从项目变化而不是几百份文档开始了解。
再例如写公众号文章。
知识库不是囤积金句，而是保存可核实的事实、来源、旧判断、反证和读者反馈。新选题开始时，Agent 先检查过去写过什么、哪些结论已经变化、还缺什么证据；发布前，再根据规则检查高风险主张。
这时不是“有人偶尔去查库”，而是工作流每次都会经过它。知识库从被动容器变成了任务的一部分。
别再从“导入全部收藏”开始
想知道 AI 知识库有没有用，不必先搭一个宏大的第二大脑。
选一项每周都会发生的真实任务：跟踪一个行业、推进一个项目、写公众号文章，或者学习一项马上要用的技能。
先明确这套库给谁用。给人用，就设计复述、练习和纠错；给模型用，就准备私有、动态、可追溯的资料；给工作流用，就把规则放进任务节点，而不是等人想起来再搜索。
先跑四周，只观察三件事：
- 哪些真实任务调用了旧知识；
- 哪些内容不再需要从头查找或重新判断；
- 哪些新结果反过来修正了旧知识或改变了下次动作。
如果四周后找不到这样的记录，别急着加向量数据库、知识图谱和更多自动化。
你缺的可能不是更强的知识库，而是一个真正需要它的问题。
自动维护也不等于无人负责
2026 年 4 月，Karpathy 在一份 GitHub Gist 中提出 LLM Wiki。他没有提供一套完整程序，只分享了一种方法：把原始资料放进文件夹，让 Agent 将它们整理成互相链接的 Markdown 页面，并随着新资料和新问题持续更新。
Agent 可以承担摘要、链接、更新和检查，不是把资料扔进去就会自动长出真知的机器。错误同样会积累。
模型第一次误读了一个数字，后来几个页面继续引用；它把两篇实验条件不同的论文写成互相矛盾；它为了让页面流畅，悄悄覆盖了旧判断。几轮以后，一套结构漂亮但来源混乱的 Wiki 就出现了。
至少要守住几条边界：
- 原始资料保留原貌，Agent 不覆盖；
- 重要数字、引文和判断能够回到来源；
- 新旧资料冲突时保留口径和条件；
- 删除、合并、覆盖旧结论等修改需要人工复核；
- 用 Git 或其他方式保留修改历史；
- 聊天记录、客户资料、病历等内容进入云端模型前，先检查隐私和数据处理规则。
Agent 可以维护知识库，但责任没有因此转移给 Agent。
知识库不是成果，产生效果才是
不用羡慕别人花里胡哨的知识图谱。
AI 已经能帮助我们阅读、分类、链接、检索和维护资料。建设越容易，“建好了”这个指标越没有意义。
知识要么进入人的理解，变成能解释、能判断、能使用的能力；要么成为模型可靠的外部依据，补充它不知道、不能猜或必须追溯的内容；要么进入工作流，在正确的时间改变一次行动。
到了该用的时候，谁也没用上，它就是占硬盘的电子垃圾。
大半年过去了，你的知识库搭建好了吗，是怎么用的，评论区聊聊。
