Google 提出了 OKF，LLM Wiki 要升级了？
远舟笔记·第21篇
Google 最近提出了一套知识库标准格式，叫 OKF（Open Knowledge Format）。刚好我一直在用 LLM Wiki 做个人知识管理，就研究了一下两者的关系，看看能不能改造过去。
先说这两个概念的区别。
LLM Wiki 和 OKF 到底是什么
LLM Wiki 是一种工作流。 核心思路是：你丢素材给 AI，AI 自动整理成条目目录结构、持续更新、检测矛盾、维护索引。简单说就是让 AI 当你的图书管理员。
OKF 是一种文件格式标准。 由 Google 提出，规定知识库的 Markdown 文件应该长什么样——用什么字段、怎么命名目录、怎么组织结构。目的是让不同工具都能看懂你的知识库。
两者不是竞争关系。LLM Wiki 关心的是「怎么做」，OKF 关心的是「长什么样」。理论上，LLM Wiki 完全可以基于 OKF 格式来实现。
所以问题来了：要不要把我的 LLM Wiki 改造成 OKF 格式？
改造方案拆解：三个层面
我认真看了一遍 OKF 的规范，如果要完整改造，需要动三个地方。
第一层：文件改造
每个 Markdown 文件补上 OKF 标准 YAML 头，统一 type 字段（Concept、Source、Comparison、Archive），把现有的自定义元数据对齐到 OKF 的推荐字段。
第二层：目录改造
按 OKF Bundle 规范重新组织文件夹结构，分成 concepts/、sources/、comparisons/、archive/ 等子目录，每层加 index.md 做导航索引。现在的目录是按照主题来分的，OKF 是按文档类型分。
第三层：Obsidian Web Clipper 改造
调整 Obsidian Web Clipper 的保存路径，让新剪藏的素材直接进入 OKF 规范目录，而不是散落在各处。
评估之后，我决定先不改
原因有三。
第一，我的知识库只有一个消费者。
OKF 最大的价值是「厂商中立、跨工具通用」。但我的知识库目前只有一个 AI 在维护、也只有一个 AI 在消费。它不需要在多个工具之间流转。跨工具互通这件事，对我来说不是痛点。
第二，我已有的规范已经够用。
我的 LLM Wiki 已经有了自己的 CLAUDE.md，定义了 frontmatter 字段、目录结构、来源标注规则、交叉引用方式。OKF 能提供的结构化能力，我基本都有了。改过去相当于把一套命名换成另一套命名，作用和习惯都要重新适应，但没有实质性的新增能力。
第三，改造成本不为零。
70 多个页面要补 YAML 头、检查链接格式、更新目录索引。虽然这些工作可以交给 AI 批量处理，但总归要花时间去确认质量。做完之后没有实质收益，那我就找不到非做不可的理由。
但这不是说 OKF 不好。如果你的知识库要在多个工具之间流转、要分享给团队协作、要公开分发——OKF 的价值很大。只是我的场景目前用不上它。
所以最终决定：了解规范但不迁移，保持现有结构，等有实际需求时再改。
附：LLM Wiki 与 OKF 核心区别
| 维度 | LLM Wiki（知识管理范式） | OKF（知识表示格式） |
|---|---|---|
| 本质属性 | 一种知识管理的操作范式/工作流，描述「如何做」 | 一种知识表示的文件格式/标准，描述「长什么样」 |
| 核心关注点 | 过程与行为：如何摄入、查询、体检；人机分工 | 结构与规范：文件字段、目录组织、跨工具互操作 |
| 知识维护者 | LLM 全权负责，人类只管策源和提问 | 任何人/任何工具均可生产与消费 |
| 矛盾处理 | 主动检测并标注矛盾 | 不内置矛盾处理，消费端自行判断 |
| 索引与导航 | LLM 维护 index.md + log.md | 依赖 index.md 和目录结构，支持图谱可视化 |
| 查询方式 | LLM 基于维基问答，合成带引用的答案 | 任何兼容工具均可消费，不限定问答方式 |
| 技术依赖 | 依赖 LLM 读写能力（Markdown 为媒介） | 零依赖，纯 Markdown + YAML |
| 一句话总结 | 定义了「怎么做」的知识管理范式 | 定义了「长什么样」的知识表示格式 |
LLM Wiki 可以基于 OKF 格式来实现，但两者不是绑定关系；反过来，OKF 也可以被非 LLM Wiki 范式的工具所使用。