一、一个被默认的前提
最近看了几篇企业知识库选型的文章，五家产品，路线不同，但都建立在一个前提上：
"要让 AI 读你的资料，就得先把资料汇进一个服务端知识库。"
先把话说清楚：在很多场景里，这个前提是对的。 公司几十万份文档、Word/PDF/扫描件混着， 几十个部门要按权限查，还希望网页、企微、钉钉里都能问一句话就得到答案 —— 这种情况你就该上一个服务端知识库：统一解析、统一向量化、统一检索、统一鉴权。 像腾讯 WeKnora 那种把 BM25、向量检索和知识图谱混着用的路子， 或者 MaxKB 那种"接模型 → 建库 → 再往工作流和 Agent 走"的渐进路线， 对"一个组织要一起用 AI"这件事是合理答案。（顺带说一句，MaxKB 的工作流知识库在社区版里， 但单点登录（CAS/OIDC/LDAP）其实在它的付费增强包里 —— 选型时这类边界要一条条对。）
我想聊的是另一种情况：你的"资料"不是几十万份企业文档，而是你自己这几年攒下来的东西 —— 笔记、草稿、读过的 PDF、项目的表格和看板。这些东西的价值密度很高，且几乎不可重建。
对这批资料，"先把它们汇到一个服务端"就不是唯一答案了，甚至常常是错的那一步。
二、分岔点不是"云还是本地"，而是"默认边界在哪一侧"
我们平时把问题简化成"本地 vs 云"，其实真正的分歧是：谁在默认边界之内。
服务端 RAG 的默认边界是：资料要先离开你的设备，进入那个库。之后它的能力（检索、问答、多端） 都是在这条边界内长出来的。你得到的是能力，付出的是"资料的又一个副本存在别处"， 以及"这条链路必须有一个在线的服务"。
本地优先的默认边界是：资料先在你这里，AI、检索、同步都是可选地接上来的。
这两种不是"好和坏"，是默认值不同。而默认值这件事，平时不觉得，出事的时候很致命 —— 断网、服务迁移、账号异常、供应商改条款，甚至只是"我想离线在飞机上把一份旧笔记找出来"。
三、几家的做法里，有一条特别值得抄
看这几家的实现，有一个细节我认为比它们的整体架构更有价值。
字节开源的 OpenViking（火山引擎）做的是"Agent 的上下文底座"，不是知识库产品。 它把资料按三层组织：目录级的 L0 摘要（默认 256 字符，用来做向量检索和快速判断）、 目录级的 L1 概览（默认 4000 字符，用来重排和导航）、以及原文 L2（按需加载）。 （注意一个容易传错的地方：L0/L1 是目录级的 sidecar，不是每个文件一份摘要。）
这条思路的价值在于：它承认了"不可能一次把所有内容都塞进上下文"。 喂给模型的是摘要层，需要细节时再往下展开一层。
我们自己要做"AI 帮我读我的知识库"时，撞的就是同一堵墙：上下文有预算。 所以我把这条记在了自己的设计清单上 —— 先给目录/摘要，再按需展开原文， 而不是把整个库拼成一个大 prompt。这和服务端还是本地无关，两边都该这么干。
另外两家的产品判断也值得尊重：PandaWiki（长亭开源）把"AI 创作 / 问答 / 搜索"长在文档站上， 一条命令部署，导入还支持 URL、Sitemap、RSS —— 它很清楚自己服务的是"对外文档/FAQ/博客"这个场景。 MrDoc（觅思文档）更老派也更稳：Python/Django，多端齐全（Web、剪藏扩展、桌面端、Android， 甚至有 Obsidian 同步插件），文集权限细到"公开/私密/指定用户/访问码"。 如果你要的是一个跑在自己服务器上、团队都能用的文档库，它是很务实的选择 （它现在也有 AI 问答和写作辅助，别再用几年前的印象评价它）。
四、那我们这一侧，怎么把同一件事做出来
说回"资料在自己手里"这条路。它不是"不接 AI"，而是把顺序倒过来：
- 先本地：文档和附件落在本地库里，离线也能读、能搜、能编辑。这是地基，不是卖点。
- 再按需接 AI：模型端点是自己填的 —— 可以用在线服务，也可以指向自己的本地模型。 涉密或没网的场景下，"能不能用本地模型"决定的是"能不能用 AI"，不是"用得多好"。
- 检索先在本地做：全文搜索、标签与关系图这些不依赖云。
- 要跨设备就同步，但同步是选项：可以自建同步服务（数据在自己服务器上）， 也可以定期导出导入。
团队场景要更诚实一点：多人协作、权限、审计、共享检索，几乎一定要有一个服务端， 而且那个服务端会看到明文。 这不是能靠口号绕过去的取舍 —— 想要协同， 就得接受"有台机器能看到内容"；把它讲清楚，比假装零知识要负责得多。
五、说点这套路的真实代价
不能只讲好处，这条路的成本是实打实的：
- 同步得自己操心：多设备冲突合并、增量同步，比"云笔记自动同步"要多花心思；
- 本地 AI 有硬件门槛：模型体积、推理速度跟云端大模型有差距，老笔记本上尤其明显；
- 没有云端秒级协同：真实时多人编辑，本地优先目前给不了；
- 生态插件比大平台少：这是事实，得靠时间攒。
所以我不认为"本地优先"是所有人的答案。如果你的需求是"公司所有人随时问 AI"， 老老实实上服务端知识库；如果这批资料是你个人的资产、且你希望十年后还能打开， 那默认边界应该站在你这边。
六、给自己三个问题（选型时比功能清单有用）
- 断网、断服务、换供应商之后，这些资料还完整、还能打开吗？
- "AI 能读"这件事，是以"资料必须存在别处"为前提，还是可选的？
- 我买的是能力，还是租的是访问权？ —— 能力可以换工具继续用，访问权要看别人脸色。
我自己的答案是：核心资料留在本地，AI 和同步当成可插拔的选项。 ShuyoNote 把"本地优先 + 数据主权"做进了默认设计里： 本地库、可自建同步、AI 端点可自配（含本地模型），块编辑和项目管理长在同一个工作台上。
不一定要用 ShuyoNote，但先想清楚默认边界在哪一侧 —— 这件事比"哪家功能多两个"重要得多。
评论 0
还没有回复，来说两句吧。