选型指南
如何选 AI 知识库工具：8 个真正重要的检查
先分清文档问答、RAG、笔记工具与维护型知识库，再用来源、更新、审核、数据控制与实测结果选择工具。
关于这篇指南
工作流程
正在选择文档问答、RAG、本地笔记或跨 AI agent 知识系统的简体中文用户
8 分钟阅读
01
先选运行模式，再比较功能列表。
02
用来源变化与冲突测试答案是否仍可追溯、可更新。
03
用自己的小型文档集对每个候选工具执行同一套验收。
工作流比较指南
换一种工具，日常工作会怎么变？
先看哪些工作想保留，再决定哪些交给工具。以下根据公开文档整理适用情况，不是易用性实测，也不意味着每个人都该换工具。
来源核对：2026-09-07 · 根据官方文档与源代码整理，并非实机性能评测。
01
Wenlan 的配置、模型与脉络
Wenlan 栏位背后共用的配置与证据边界。
为你和 AI 共用、在工作中逐步积累的知识库。
Wenlan 把来源文档与工作中保存的决策、经验，编成有来源的 Living Wiki。 Sources、Memories、Pages 模型将决策、经验与修正保存为独立的知识记录；需要修正旧知识时，可以记录明确的替代关系，再与文档共同支撑知识页。
这个知识生命周期延伸自社群 Rohitg00 LLM Wiki v2 提案讨论的方向，但不是官方版本认证。 先连接来源、指定后台模型并建立首批页面；之后本地 daemon 同步已连接文件夹的变化，刷新符合条件的既有页面，并保留变更历史。
新主题不保证自动建页；模型不可用、来源或引用检查未通过时，更新会暂停。 你亲自编写或修改的页面先提出修订，审核通过后才修改原文；不是每一笔 AI 写入都需要批准。
人与已连接的工具可通过 plugin／CLI／MCP 共用所选 Space 的知识，不必打开桌面 App。 数据保存在本地；模型处理可按设置使用本地或云端服务。
- 文档＋独立决策
- 来源文档与独立保存的决策、经验、修正，共同支撑知识页面。
- 持续维护的 Wiki
- 机器维护的页面，能根据当前支持它的来源重建。
- 审核＋变更历史
- 你写的内容先审再改，页面版本始终可查。
- 跨 AI 工具共用
- 连接好 MCP 的工具共用本地知识，不必各留一份。
02
AI 工具＋文件
AI 能替你读写文件；Wenlan 再把来源追踪、知识页更新与修订审核整合好，让工作留下的不只是回答，而是一份持续维护的知识库。
- 开始前要做什么
- 选择文件与支持格式的 AI 工具，确认读取的版本以及能否修改原文件；不一定需要先建立完整知识库。
- 什么情况下，继续用它就好
- 文件少而稳定，现有工具已能找到并读取每次任务需要的资料。
- 什么情况下，值得加入 Wenlan
- 某份规范改了，你希望引用它的知识页也进入更新流程，而不只在下次提问时读到新版。Wenlan 已内置来源关联、过期追踪与修订审核，不必自己用脚本搭出这一层。先连接支持的来源、配置模型；符合条件的页面可在后台刷新，你编辑过的页面则先提出修订让你审核。
这里比较原生 AI 直接处理文件、尚未额外构建 Wiki 维护系统的做法，不代表每种 AI 产品。 Claude Code 有跨对话的 auto memory；官方将记忆上下文与强制执行机制分开。
hooks 可执行自定义自动化，但来源与页面的关联、过期判定及修订分流，仍需实现与验证，不是一段提示词就能提供的系统。 Wenlan 已整合这些机制；产出仍需核对依据与内容版本。
直接目录来源支持 Markdown、text（纯文本）与 text-extractable PDF；Word 与 PowerPoint 先导出为 text/Markdown 或 text-extractable PDF，scanned PDF 单独做 OCR。 新主题不保证自动建页；后台刷新需要已配置且可用的模型。
03
LLM Wiki · nashsu
两者都有文件夹监控，也不只处理文档。Wenlan 还跟踪每条知识与引用它的页面；LLM Wiki 则以来源与 Wiki 页面的整理为主。
- 开始前要做什么
- nashsu/llm_wiki 需要先安装 App、创建项目、配置模型并添加来源；之后可以通过文件夹监控自动整理，MCP 则单独连接。
- 什么情况下，继续用它就好
- 你希望把文档与有用的回答编成 Markdown Wiki，而且它的 App、项目结构和 MCP 流程已经合用。它已有产品界面与自动化，不只是研究配方。
- 什么情况下，值得加入 Wenlan
- 例如，已保存的交付日期从九月改为十月，你希望系统找出受影响的知识页，而不只多存一条笔记。Wenlan 接受替代修订后，会把页面依据连到新记忆并标记待更新；后台刷新仍需可用模型，你改过的页面则先提出修订供你审核。
这里比较 nashsu/llm_wiki，不是 Karpathy 的方法或整个 LLM Wiki 类别。 它支持引用、Review、MCP 和 skills。
配置导入模型后，把回答「存回 Wiki」也能自动整理；DeepResearch 直接写入附引用的问答页，不再进入来源导入流程。 删除来源时，也会清理受影响的页面与链接。
Business 模板则在决策页记录状态与 supersedes。 Wenlan 把决策保存为独立记录：修改、删除或接受替代修订后，标记引用该记录的页面待更新；接受修订时，也把页面的依据连到新记忆。
新记录还可补入匹配的既有页面。 后台刷新需要可用模型与符合条件的页面；人改过的页面先提出修订，批准后才修改原文。
nashsu 的导入则先写入页面，再列出 Review 待办。 这些是实现差异，不等于易用性或内容正确性的保证。
04
Obsidian
你可以继续用 Obsidian 写笔记，让 Wenlan 读取原文，另外维护一份给你和 AI 共用的 Wiki。
- 开始前要做什么
- 打开 vault、撰写笔记即可开始。AI 是可选项：选择插件或外部工具，再确认模型、文件权限和备份需求。
- 什么情况下，继续用它就好
- 自己撰写和整理笔记，就是你思考的一部分；现有搜索、链接与插件也已经够用。
- 什么情况下，值得加入 Wenlan
- 你想保留原来的 vault 不动，另外维护一份有来源、供后续 AI 工作使用的 Wiki。Wenlan 仍需连接来源与配置模型，不会省掉所有初始设置，也不取代你的笔记编辑器。
适合想自己撰写、整理与连接笔记的人，Markdown 文件保存在自己的设备上。 需要 AI 搜索、摘要或改写时，可以另外安装插件或连接 AI 工具。
插件与同步服务可能将数据传到其他服务；笔记保存在本地，不代表所有 AI 处理都在本地。
05
Notion
Notion 让你为工作区任务配置 Agent；Wenlan 把来源跟踪、知识页维护和修改审核做成内置流程。两者都能自动运行。
- 开始前要做什么
- 先安排工作区页面与权限。如果需要 Custom Agent 无人值守执行，再确认方案，配置指示、触发条件和访问范围。
- 什么情况下，继续用它就好
- 共享页面、团队协作、数据库和工作区权限是主要需求；Notion 的 Agent 也能自动处理工作区任务。
- 什么情况下，值得加入 Wenlan
- 你需要一份独立于工作区的本地知识库，让已连接的 AI 工具使用，并有内置的来源跟踪和页面审核流程。Wenlan 不取代 Notion 的团队工作区或项目管理功能。
Notion 是个人与团队共用的云端工作区，不只是数据库或被动笔记。 Notion Agent 可以搜索、创建和编辑；Custom Agents 还能按事件或计划在后台运行，包括知识维护。
你可以使用模板或自行设置指示、触发条件和访问权限，再查看活动日志，使用 Notion 的历史与还原功能。 官方文档列出 Custom Agents 需要 Business 或 Enterprise 方案。
云端内容可以下载离线使用或导出备份。 差别在于通用工作区自动化与 Wenlan 内置的知识维护流程，而不是 Notion 没有自动化或不能连接外部工具。
06
NotebookLM
NotebookLM 帮你理解一组来源；Wenlan 把资料与工作决策积累成 Wiki，让已连接的 AI 工具在后续工作中使用。
- 开始前要做什么
- 创建笔记本、选择来源。支持的 Google Drive 导入会在打开笔记本时同步，上传文件则保留导入副本；先确认格式和分享设置。
- 什么情况下，继续用它就好
- 主要任务是理解一组材料，根据来源提问、摘要或制作学习材料，也会在 Gemini 使用这些来源。
- 什么情况下，值得加入 Wenlan
- 阅读结论需要接回后续工作：保存新的决策、维护相关 Wiki 页面，再从已连接的 AI 工具中找回。这和制作学习材料是不同任务，不是说 NotebookLM 不能复用来源。
NotebookLM 是大家熟悉的产品；Google 官方文档现在将它标为 Gemini Notebook。 它提供基于来源的问答、摘要和学习材料，笔记本也能用于 Gemini 对话，不能说只能停留在一个独立 App 中。
支持的 Google Drive 来源会在打开笔记本时同步；本地上传文件是导入副本。 你选择提问引用的来源与云端分享权限，它不会改写原始 Drive 文档。
来源同步不等于保证先前生成的每份学习材料都会重新生成。
01
先分清你需要哪一种 AI 知识库
不要先问哪个工具最好。先判断需要的是当次会话的文档上传、针对一组文档的 RAG 问答、让 AI 直接读取笔记或 Markdown vault，还是跨会话与多个 agent 维护有来源的当前答案。
这四种模式可以组合，但解决的问题不同。把它们放在同一张功能表比较，通常会选到不符合实际工作方式的产品。
02
8 个真正重要的检查
用一小组有代表性的文档，先写下预期答案，再对每个候选工具做相同测试。
- 来源可追溯：重要答案能否打开支持它的确切来源或引用？
- 更新状态：来源变化后，哪些答案过期、哪些需要刷新是否看得见？
- 冲突与审核：矛盾证据会进入明确审核，还是被模型静默改写？
- 数据所有权与导出：能否保留或导出可读文件与历史，不被单一服务绑定？
- 隐私边界：哪些文件、提示、检索片段与模型调用会离开电脑？
- Agent 互通：同一份知识能否供实际使用的 Claude Code、Codex、Cursor 或 ChatGPT 读取？
- 输入限制：真正支持哪些格式、扫描文档、文件夹、vault 与文件大小？
- 可重复验收：工具能否处理可回答、不可回答、跨来源三种问题，并在来源修改后得到正确结果？
03
一组能暴露问题的验收资料
不要一开始导入整个资料库。准备一份干净来源、一份过期版本、一组互相矛盾的说法，以及一个资料中没有答案的问题。好的工具应该暴露不确定性和冲突，而不是只生成流畅文字。
修改其中一份来源后重跑相同问题。如果答案不会显示过期、引用仍指向旧内容，或无法判断哪些页面需要更新，这套系统就还不适合承担长期知识。
04
Wenlan 适合哪一种模式
Wenlan 对应维护型、有来源的本地知识层。Sources、原子知识与 Pages 分开保存；Claude Code、Codex、Cursor、ChatGPT 等客户端通过 plugin 或 MCP 使用同一套知识；引用、过期状态、修订与人工审核保持可见。
完成平台与客户端设置后，可以用一个小型来源集验证，而不是只相信产品描述。
Wenlan 验证流程
wenlan status
wenlan sources add ~/Knowledge/evaluation-set
/distill <测试主题>
/pages <测试主题>
/lint
/curate05
什么时候不该增加另一套知识库
如果只是阅读一份短文档、现有 wiki 已由团队稳定维护，或 AI 不需要跨会话复用答案，直接文档阅读或当前笔记工具可能已经足够。
选择标准不是功能最多，而是以最低维护成本通过你的来源、更新、冲突、隐私与可重复验收。
用同一套 8 项检查测试 Wenlan
从一组小型来源开始，验证引用、更新与审核，再判断维护型本地知识层是否适合你的工作流。
常见问题