一篇公开文章不应该直接从聊天记录里复制出来。

如果这篇文章来自长期知识库，它至少应该经过三个阶段：证据层、wiki 层、publication 层。

这不是为了形式感，而是为了避免三个问题：来源丢失、项目事实被误读、公开内容泄露私有信息。

第一阶段：保留证据

知识形成的第一步不是总结，而是保留证据。

证据可以是网页、论文、项目文档、代码审计结果、产品调研、会议记录或本地复盘。它们不一定适合公开，也不一定已经稳定，但它们是后续判断的来源。

这个阶段最重要的是：

  • 不急着美化。
  • 不覆盖原始语境。
  • 记录来源和日期。
  • 区分事实、推理和观点。

AI 可以帮忙整理证据，但不应该把整理后的版本伪装成原始事实。

第二阶段：编译成 wiki

证据层回答“材料是什么”，wiki 层回答“我们从材料里稳定学到了什么”。

Codex 在这里的作用是编译：把多个来源里的重复模式、概念、方法和判断整理成可链接的知识对象。

例如，一个项目复盘可能会沉淀出一个概念；多个产品调研可能会形成一个评价框架；一次发布流程问题可能会形成一个 publication boundary。

wiki 层应该追求：

  • 概念清晰
  • 来源可追踪
  • 与其他页面有链接
  • 不复制项目局部材料
  • 不把临时判断写成长期原则

这一层可以被 Obsidian 浏览，也可以被 Codex 后续查询和增量更新。

第三阶段：变成 publication source

wiki 不是公开文章。

wiki 面向自己，publication source 面向读者。两者的写法不同，隐私要求不同，结构也不同。

publication source 要先回答：

  • 读者是谁？
  • 读者要完成什么理解或行动？
  • 这篇内容应该进入 writing、tutorials、notes、projects 还是 playgrounds？
  • 是否需要中英文 sibling？
  • 哪些来源可以公开，哪些只能作为内部证据？
  • 是否属于某个 series？

这一步不是简单改标题，而是把知识重新组织成读者能理解的文章。

让 AI 提议，但不要让 AI 静默写入长期层

公开工具里也有类似的 review queue 思路。例如 Tracekeeper 这类 Obsidian 插件强调：AI 可以提出修改和维护建议，但在进入 durable knowledge 之前，应该保留可审阅的 trace，由人决定是否接受。

这个原则对 publication 更重要。

AI 可以把 evidence 编译成 wiki，也可以把 wiki 改写成 publication source。但从“建议”到“长期知识”，从“长期知识”到“公开文章”，中间应该有明确状态，而不是静默覆盖。

所以我的流水线里至少有两个闸门：

project evidence -> central review/promote -> wiki/source draft
publication source -> prepare/review -> site artifact

这两个闸门不是为了拖慢流程，而是为了保留责任链。

第四阶段：prepare 和 review

publication source 还不能直接进入站点。

需要先生成 publication candidate：

kb publish prepare <source>

prepare 负责创建候选记录、公开稿、source snapshot、manifest 和初始 review 文件。对双语站点来说，中英文 adaptation 也应该在 prepare 阶段完成。

然后 review：

kb publish review <candidate-id>

review 要检查：

  • 是否有本机路径
  • 是否泄露私有材料
  • 是否缺少双语 sibling
  • metadata 是否对齐
  • source hash 是否有效
  • collection 和 series 是否合理

这一步很关键。因为 AI 写得顺，不代表它可以公开。

第五阶段：sync 到站点

review 通过后，才 sync 到发布节点：

kb publish sync <candidate-id>

sync 不负责翻译，也不负责补事实。它只是把已审查的候选内容序列化成站点能渲染的 generated artifact。

站点负责构建、路由、样式、语言切换和部署。知识真源仍然保留在中央知识库。

如果站点页面显示不对，先判断问题属于哪一层：

  • 内容事实错了，回中央知识库修 source 或 candidate。
  • 路由、样式、构建错了，去站点项目修。
  • 项目事实不清楚，回项目目录确认。

一篇文章的生命周期应该可追踪

一个健康的 publication pipeline 应该能回答这些问题：

  • 公开文章来自哪个 source draft？
  • source draft 来自哪些 wiki 概念或项目证据？
  • candidate 什么时候生成？
  • review 检查了什么？
  • sync 写到了哪里？
  • site status 是 draft 还是 published？

这就是为什么我不把公开文章直接写进站点。

站点是发布节点，不是知识真源。真正的知识系统需要保留从证据、编译、公开稿到站点 artifact 的整条链路。