联邦知识库不是为了让 AI 更自由，而是为了让 AI 更有边界。

这套系统如果没有边界，很快会变危险：私有项目材料可能被写进公开文章，过期文档可能被当成事实，站点生成物可能反过来覆盖知识真源，项目 AI 可能把中央理论误用到当前代码。

所以边界不是附加功能，而是核心设计。

隐私边界：默认不公开

任何进入知识系统的材料，都不应该默认可以公开。

项目文档、家庭资料、客户素材、私有仓库、截图、日志、调试路径和聊天记录，都可能包含不适合公开的信息。AI 在整理这些材料时，不能因为文字已经被总结，就默认风险消失。

一个实用规则是：

raw detail stays private
generalized lesson may be promoted
public draft needs review

也就是说，原始细节留在本地项目或私有仓库；可复用经验可以晋升到中央库；公开稿必须经过 publication review。

项目真相源：代码和本地事实优先

中央知识库可以保存方法论，但不能替代项目真相源。

对软件项目来说，代码、测试、配置和当前产品文档通常比中央总结更接近事实。对研究项目来说，当前 sources 和 package manifest 比后来的概念页更接近原始证据。对发布节点来说，路由和组件实现要以站点代码为准。

所以当 AI 判断一个项目时，必须先问：这个项目的事实源在哪里？

如果中央库说一件事，项目代码说另一件事，不能直接选中央库。应该回到项目目录确认，再决定是否更新中央知识。

发布审计：公开不是复制粘贴

公开内容必须有审计链路。

最危险的做法是：在项目里讨论出一个结论，直接复制到站点文章里。这样很快会丢失来源、隐私检查、双语一致性和后续更新能力。

更稳的方式是 publication record：

  • source draft 保存公开表达的来源。
  • manifest 保存目标 collection、语言、slug、series 和 source hash。
  • review 保存隐私和 schema 检查。
  • sync-log 保存写入站点的记录。
  • site artifact 只负责渲染。

这样即使半年后要更新文章，也能回到知识源头，而不是在站点里猜当时为什么这么写。

失败模式零：过早全自动化

AI-native PKM 很容易走向一个诱人的方向：让 agent 自动监听、自动总结、自动写入 wiki、自动发布。

这在 demo 里会显得很强，但在真实知识库里风险很高。因为系统还没有足够证据判断哪些材料稳定、哪些只是临时讨论、哪些包含隐私、哪些应该公开。自动化越强，错误传播越快。

所以我的原则是 review-first，而不是 automation-first。

可以自动化的是检查、生成候选、汇总差异和提示下一步；不应该太早自动化的是静默改长期 wiki、静默复制项目文档、静默发布公开内容。

失败模式一：全局知识污染项目判断

如果项目 AI 默认读取完整中央库，它可能把其他项目的原则套到当前项目。

例如，一个项目适合“产品事实留在代码仓库”，另一个项目可能是“工作区是控制层，子仓库是产品真相源”。如果 AI 把前者套到后者，就会整理错目录，甚至改错文档。

解决办法不是让 AI 少读，而是让 AI 先识别当前目录模式，再通过窄接口查询中央知识。

失败模式二：站点霸占内容真相

一旦公开文章只存在站点里，站点就会变成事实来源。

这会破坏知识库到 publication 的数据流。后续如果知识库修正了概念，站点文章不会自动知道；如果站点里手改了 generated 内容，中央 record 也不会知道。

所以 generated content 可以进入 Git，但不应该成为 source。

失败模式三：把 AI 生成内容当成证据

AI 可以总结证据，但 AI 的总结本身不是原始证据。

如果知识库里只有“AI 说某产品如何如何”，却没有来源、代码、文档或测试支撑，那这不是知识沉淀，只是一个更正式的幻觉。

联邦知识库必须区分：

  • source evidence
  • compiled knowledge
  • public argument
  • site artifact

这四者可以连接，但不能混为一谈。

边界让系统能扩展

一个本地知识系统最终会接入越来越多目录：研究目录、产品仓库、开源项目、家庭资料、个人站点、社交输出。

如果没有边界，规模越大越危险。边界清楚，规模越大越有价值。

联邦知识库的目标不是让 AI 获得无限上下文，而是让 AI 在正确的上下文里做正确的事，并让每一次跨边界动作都能被追踪、审查和回滚。