很多人搭 AI 知识库时会自然想做一件事：让 AI 能看到所有资料。

这听起来很合理。资料越多，AI 不是越聪明吗？

我的经验正好相反。对项目里的 AI 来说，默认看到完整知识库通常不是优势，而是风险。

AI 可读，不等于全量暴露

公开实践里已经有不少 AI-readable wiki 或 AI-maintained vault 的探索。它们有一个共同前提：知识应该被写成 AI 能读取、检索和修改的形态。

这个前提我认同。

但“AI 能读取”不等于“每个项目 AI 都应该默认读取全部”。在中央编译场景里，AI 需要看更大的知识面；在项目执行场景里，AI 更需要局部事实、当前代码、当前任务和项目规则。把完整中央库塞进项目上下文，往往会降低可靠性，而不是提高可靠性。

所以这套系统不是反对 AI-readable vault，而是把读取权限变成按需动作。

上下文越大，边界越容易坏

一个项目 AI 的首要任务不是“知道最多”，而是“在当前项目里做对事”。

如果它正在修改一个产品仓库，它应该优先理解当前代码、测试、产品事实和本项目规则。如果它正在整理一个研究包，它应该优先看当前研究材料和来源链。如果它正在处理家庭私有资料，它更应该严格留在当前隐私边界内。

完整知识库会引入大量看似相关、实际会干扰判断的材料：

  • 其他项目的历史结论
  • 已经过时的 publication source
  • 只在另一个产品里成立的规则
  • 私有资料的泛化摘要
  • 尚未验证的讨论记录

AI 很擅长把这些材料编织成一个流畅答案。但流畅不等于可靠。

项目局部事实不应该被全局理论覆盖

中央知识库适合沉淀原则，但项目目录掌握项目事实。

比如中央库可以说“发布节点不应成为内容真相源”，但某个站点项目的实际路由和组件实现，仍然要以代码为准。中央库可以沉淀“project skill 不应复制全局知识库规则”，但某个项目是否需要特殊 skill，还得看它自己的工作模式。

如果项目 AI 默认读完整中央库，它很容易把原则当成事实，把方法论当成当前实现。

好的项目 AI 应该这样工作：

read local truth first
ask central knowledge only when needed
promote stable lessons only after review

隐私边界需要默认保守

联邦知识库里可能接入很多类型的目录：开源项目、私有仓库、产品研究、家庭资料、客户材料、个人写作、发布站点。

这些目录的风险完全不同。

如果让每个项目 AI 默认看到全局知识库，就等于把不同隐私级别的材料放进同一个上下文池。即使 AI 没有恶意，也可能在总结、改写、公开稿或代码注释里带出不该出现的细节。

隐私治理不应该依赖“希望 AI 小心”。它应该依赖默认不可见。

窄接口比全量暴露更适合长期协作

项目 AI 不是完全不能接触中央知识库。它只是不能默认全量读取。

更好的模式是窄接口：

  • 需要查重时，用 lookup 查询已有概念或专题。
  • 需要复用方法时，用 catalog 看轻量目录。
  • 有稳定结论时，用 promote 送入中央待编译入口。
  • 需要公开时，由中央 publication flow 处理。

这样 AI 仍然能利用中央知识，但不会把中央库直接塞进项目上下文。

这和软件系统里的 API 很像。你不会把整个数据库直接暴露给每个前端组件。你会设计接口、权限和返回结构。知识库也是一样。

项目 AI 应该知道中央库存在

“不默认看全库”不等于“完全不知道中央库”。

项目 AI 应该知道三件事：

  • 有一个中央知识库存在。
  • 当前项目默认只处理本地事实。
  • 需要跨边界时必须走明确命令或工具。

这就是 federated skill、AGENTS 规则和 kb 命令的价值。它们不是给 AI 更多材料，而是告诉 AI 如何处理边界。

可靠 AI 工作流靠的是选择性记忆

人类工作也不是靠同时记住所有东西。

我们会在不同场合打开不同文件，引用不同资料，遵守不同规则。一个律师不会把所有客户材料混在同一份备忘录里。一个工程师不会把另一个产品的实现当作当前仓库事实。一个研究者不会把未验证笔记直接写进论文结论。

AI 也应该这样。

完整知识库适合中央编译，不适合项目默认上下文。项目 AI 需要的是局部清晰、窄接口和可追踪晋升，而不是无限记忆。