联邦知识库最重要的不是“多几个目录”，而是让每个目录有不同职责。

如果中央知识库、项目目录和发布节点都可以随意承担事实来源、草稿生成、公开发布和长期归档，系统很快会失控。你会不知道一个结论到底来自哪里，不知道一个页面是不是最新，不知道某个项目文档能不能公开，也不知道 AI 现在应该听哪个目录的规则。

所以这套系统先做一件事：分清职责。

为什么不是一个更好的 vault template

很多 Obsidian 模板会先定义 inbox、areas、projects、resources、archive，或者用 Zettelkasten 把原子笔记组织成网络。这些结构对个人知识很有用，但它们通常假设“所有知识都在同一个 vault 里被组织”。

我的问题不是单 vault 结构不够漂亮，而是项目事实、中央知识和公开发布本来就不是同一种东西。

一个生产项目的代码目录需要以代码、测试和当前文档为准；一个中央知识库需要沉淀跨项目概念；一个网站仓库需要关心路由、样式和构建。把它们都塞进同一个模板，短期会显得整齐，长期会让 AI 不知道谁是事实源。

所以这里的核心不是模板，而是 ownership。

中央知识库负责长期知识

中央知识库不是所有文件的垃圾桶。

它应该保存的是跨项目可复用的知识对象：概念、专题、方法、判断框架、publication source、公开候选记录和发布审计。它可以吸收项目经验，但不应该直接复制项目的所有材料。

中央知识库适合回答这些问题：

  • 这个概念是否已经存在？
  • 这个方法是否适用于多个项目？
  • 某个项目经验能否抽象成通用判断？
  • 哪些内容已经准备公开？
  • 哪些 publication record 已经生成、同步、发布？

它不应该成为每个项目的真实业务文档，也不应该成为每个产品的临时规划区。

项目目录负责项目事实

项目目录是项目事实的工作现场。

一个真实项目里会有代码、文档、任务、测试、素材、研究包、临时决策和过期文件。AI 在项目目录里工作时，最重要的是先尊重项目事实，而不是拿中央知识库里的抽象原则覆盖当前项目。

项目目录适合保存：

  • 当前产品或研究的真实材料
  • 本项目的代码和测试
  • 项目内研究包
  • 本地 AGENTS 规则
  • 项目专用 skill
  • 只在当前项目成立的判断

当某个项目经验变得稳定，并且对其他项目也有复用价值时，它才应该被晋升到中央知识库。

这里的关键词是“晋升”，不是“同步”。同步会让项目和中央库互相污染；晋升意味着有选择、有来源、有审查。

发布节点负责渲染，不负责知识真相

个人网站、文档站或其他发布项目是 publication node。

它应该负责页面结构、样式、路由、SEO、RSS、构建和部署。它不应该成为知识的真相源，也不应该在生成内容里临时补翻译、补事实、补出处。

如果公开文章来自中央知识库，那么文章源头应该留在中央库的 publication record 里。站点只消费经过 review 的生成物。

这样做有一个直接好处：当知识库里的来源更新时，后续可以重新生成站点内容，而不是让站点里的 MDX 文件变成新的孤岛。

三层之间靠窄接口连接

这三层不是完全隔离的。它们需要协作，但协作必须通过窄接口。

一个稳定的数据流应该是：

project insight -> federation inbox -> central wiki/source draft -> publication candidate -> site artifact

反过来不应该发生：

site copy -> central truth
random project note -> public article
global wiki dump -> project agent context

窄接口让每一步都有边界。项目要晋升知识，就走 promote。项目要查中央库，就走 lookup。中央库要发布，就走 prepare、review、sync。站点要显示内容，就只读取 generated artifact。

这套分工减少了 AI 的误用

AI 最容易出问题的地方，不是它不会写字，而是它不知道自己应该相信什么。

如果在项目目录里让 AI 同时读取中央理论、过期项目文档、站点生成物和临时对话，它很可能把这些材料混成一个“看似合理”的答案。

职责分层让 AI 的工作更可控：

  • 在项目目录里，它优先信项目事实。
  • 在中央知识库里，它负责抽象和编译。
  • 在发布节点里，它负责渲染和验证。

这不是限制 AI，而是让 AI 的能力落在正确位置上。

一个长期可用的知识系统，不需要每个目录都什么都能做。它需要每个目录知道自己不该做什么。