卡帕西Karpathy 预测了“LLM Wiki”的威力。谷歌刚刚将其正式化。
认识一下开放知识格式（OKF）：一个供应商中立的规范，用于为基础模型提供它们所需的精选上下文。
我真心觉得这能取代 Notion、Obsidian 或传统 wiki，用于开发者团队，而原因归结于记账工作。
传统 wiki 失败是因为人类不可避免地会放弃更新它们的繁琐工作，但是正如 Andrej Karpathy 最近指出的，LLM 不会感到无聊。它们不会忘记更新交叉引用，而且它们可以在一次通过中触及 15 个文件。
OKF 标准化了互操作层，这样代理就能真正自主地完成那些繁重工作。
因为该格式的观点最小化，它不规定你写什么，它只规定如何结构化。你会得到：
→ 可读性强的文档，直接与你的代码一起存放在版本控制中
→ 交叉链接，能够映射出复杂实体关系，而无需图数据库
→ 一个能在不同工具和组织之间迁移时存活下来的系统
没有复杂的压缩方案。
没有中央注册表。
如果你能 cat 一个文件，你就能读取它。
如果你能 git clone 一个仓库，你就能部署它。
这就是我们如何停止每次新模型发布时从头重建上下文管道的方式。
信息之所以没用，是因为它散得像你口袋里的钢镚，想用的时候永远凑不齐
你早上出门买早餐，口袋里揣了十个钢镚。但它们不在一个地方。一个在牛仔裤屁股兜里，两个在昨天穿的外套里，三个掉在书包夹层，还有四个，你记得是放在鞋柜上了，但出门太急，忘了拿。最后你到了包子铺，发现自己只从裤兜里摸出了一个钢镚，买了个馒头。那些剩下的钱，它们存在，但它们没用。
这就是现在所有公司里信息的状态。
一个AI想知道某个业务指标怎么算，它得自己去翻好几个地方。
它得去一个叫“元数据目录”的系统里查，这个系统有自己的规矩和入口。然后它得去公司的内部维基百科翻帖子，那个网站可能还得单独登录。接着它要去读代码库里的注释，那些注释可能是一年前写的，早就不准了。最后，它可能还得去问那个唯一懂行的工程师，但那个人正在写周报，没空理它。
每一个做AI助手的人，都在重复解决同一个问题：怎么把散落在各个角落的信息碎片，给拼到一块儿去。每个卖数据管理软件的厂商，都在重新发明轮子，搞自己那一套存储信息的方式。结果就是，信息被锁死在了它最初被创建的那个工具里。你用A工具写的文档，想拿到B工具里去让AI用，门儿都没有。
这就好比你用微信记的账，想导到支付宝里自动算你的花呗额度。或者你在网易云音乐建的歌单，想拿到QQ音乐里去让AI帮你推荐相似歌曲。能行吗？不行。每个App都是一个孤岛，信息就只能在那一个岛上待着。谷歌这个OKF格式想做的，就是给你造一艘船，或者至少，给你一个所有岛都承认的通用货币。
你可能已经见过最好的解决办法，但每次都得重新搭台子
AI大神安德烈·卡帕西Andrej Karpathy，他提过一个想法：既然AI干那些重复的、需要细心整理的活特别在行，那我们干脆把所有知识整理成一个维基百科那样的东西，让AI自己去维护它。你想啊，AI不会觉得更新一个链接烦，也不会忘了在十五个文件里同时修改同一个术语的定义。让它干这个，比让人类干可省心多了。
这个想法就跟病毒一样传开了。很多团队都开始这么干。他们用笔记软件（比如Obsidian）记东西，然后让写代码的AI助手能读这些笔记。他们在项目文件夹里放一个叫AGENTS.md或者CLAUDE.md的文件，里面写清楚这个项目的各种规矩，AI干活之前得先读这个文件。数据团队会在代码仓库里放一堆markdown文件，专门记录哪个指标是什么意思，哪个表和哪个表怎么关联。
每个这么干的团队，都觉得自己的办法很聪明。确实聪明。但问题来了，每一个团队的聪明办法都是自成一派，互相不认。卡帕西的维基和你团队的维基，表面上看起来都是markdown文件，都有个文件头，都有超链接。但两者没有一个通用的规矩。没有规定说每个文档必须标明自己是“一张表”还是“一个业务指标”，也没有规定文件名里带什么字符代表什么含义。
这就导致了，你们辛辛苦苦记下来的知识，依然只对你们自己团队有用。隔壁团队想用，或者你换了个AI工具，没法直接读。一切又得从头适配。等于每个团队都自己造了个轮子，但轮子的形状、大小、螺丝孔位置都不一样。你想把A团队的轮子装到B团队的车上去？不行，你得重造一个。
所以，缺的不是一个新软件、新服务，不是让你再去注册一个“万能知识管理平台”。缺的是一个格式，一个所有人和所有AI都认的格式。这个格式得像TXT文本文件一样，谁都能打开，谁都能写。换电脑、换系统、发邮件给朋友、传给另一个AI，它都不会坏。
这个格式简单到离谱：就是个装满文件的文件夹，每个文件前面带个说明书
一个OKF的知识包，就是一个普普通通的文件夹。文件夹里面，全是.markdown结尾的文件。每一个文件，代表一个知识点。这个知识点可以是一张数据表格、一个业务指标（比如“月活跃用户”）、一份事故处理手册、一个API接口说明，什么都行。
一个文件，就是一个知识点。这个文件在文件夹里的路径，就是它的身份证。比如，一个叫做“财务”的文件夹里，有个叫“营收”的文件，它的身份就是“财务/营收”。
每个文件分成两部分。第一部分是文件最开头的“说明书”，用YAML格式写的，就是几行键值对。第二部分是正文，随便你写什么，用markdown语法就行。
说明书长这样：
type: metric |
看到了吗？type字段是唯一强制要写的，说明这个文件是个“指标”。其他都是建议，你想写啥就写啥。这就像你给每个文件贴了个标签，AI一眼就能看出这个文件是干什么用的，不需要把整篇文章读完。
正文部分，你就可以用人话写详细解释了。比如“这个指标为什么重要？”“计算的时候要排除哪些测试用户？”“如果遇到数据缺失怎么办？”等等。而且最关键的是，文件之间可以用标准的markdown链接互相指来指去。比如在“每周活跃用户”的正文里，你可以写“用户登录日志表”，这样就形成了一个知识网络。
整个文件夹里，还可以有一些约定俗成的特殊文件，比如每个子文件夹里可以放一个index.md，当目录用，告诉AI这个文件夹里主要有什么。还可以放log.md，像航海日志一样，记录下每次重要修改。
没有复杂的压缩算法，不需要装什么运行环境，不用申请什么开发工具包。任何一个能显示文本的编辑器都能打开。上传到GitHub上，它能直接渲染。任何搜索引擎都能索引它。你可以把它打包成tar文件发邮件，也可以放在任何Git仓库里，还可以挂载到任何文件系统上。
为什么这个土办法，比那些花里胡哨的系统都管用
你可能会说，这不就是个文件夹吗？我们公司共享硬盘上有一百万个这样的文件夹。关键不在于“文件夹”本身，而在于它背后的三条原则。
第一，规矩极少。你不需要学习一套庞大的数据模型，也不需要遵守几十条规则。OKF只规定了一件事：每个文件必须有一个type字段。至于type里能写什么值，别的字段叫什么，正文分几个小节，随便你。这就像是交通规则只规定了“靠右行驶”，至于你开什么车、穿什么衣服、车里放什么音乐，随便你。这样带来的好处是，任何一个人，不管他用什么工具，都可以立刻开始生产OKF格式的知识。因为门槛太低了。
第二，生产和消费完全分开。写知识的人和读知识的人，互相不需要知道对方是谁。一个人类手写的笔记，可以被AI直接读。一个数据库自动导出的元数据文件，可以被一个网页可视化工具直接展示。一个大模型自己总结出来的知识包，可以被另一个大模型直接拿来查询。大家只认这个格式，而不在乎对方是用什么工具、什么流程造出来的。这就好比你和一位只说法语的朋友通信，你们约定好用英文写信。你不需要学法语，他不需要学中文，只要你们都用英文，就行了。OKF就是那个“英文”。
第三，它是个格式，不是个平台。这句话是灵魂。你不需要注册任何账号，不需要登录任何云服务，不需要购买任何许可证，不需要每年续费。它不会跟你说“请下载我们的专用阅读器”。它永远不会被某个公司收购然后关闭服务器。它就是一个死板的、公开的规矩。你把它打印出来贴在墙上都行。之所以要把它做成开放的、与供应商无关的标准，就是因为一个知识格式的价值，完全在于有多少人在用它，而不在于它归谁所有。
谷歌不光动嘴，他们还给你送了几个能直接用的玩具
光说理论你可能还是觉得虚。谷歌这次很实在，跟这个格式一起，他们还放出了几个参考实现。就是你不用自己从头琢磨怎么用，可以直接拿来玩。
第一个是一个“知识补充机器人”。你给它一个谷歌BigQuery数据集的地址，它就会自动走进去，为里面的每一张表和视图，草稿一份OKF格式的文档。然后它会跑第二遍，去爬取官方的文档，把这些文档里的引用、表的详细结构、表与表之间的关联路径，全都自动补充到刚才的草稿里。你啥都不用干，它就帮你把一个数据库里的死信息，变成了一个活的知识包。
第二个是一个“静态网页展示器”。你给它任何一个OKF的知识包文件夹，它会吐出一个单独的HTML文件。你用浏览器打开这个文件，就能看到一个交互式的知识图谱。里面所有知识点都变成了一个个小圆圈，互相之间的链接就是连线。你点一个圆圈，就能看到它的说明书和正文。最重要的是，这个网页没有任何后端，不需要安装任何软件，所有数据都在这个页面里，你的数据不会上传到任何地方。
他们还提供了三个可以直接拿去玩的示例知识包。分别是关于谷歌分析GA4电商数据、Stack Overflow技术问答数据，还有比特币公开数据集的。这些都是用上面那个机器人自动生成的，你可以直接下载下来，用那个网页展示器打开看看效果。
这些东西都是“概念验证”，意思就是告诉你“看，能这么玩”。这个格式本身不规定你必须用什么AI框架，也不规定你必须用网页展示器。你可以自己写一个机器人，从你自己的数据库、你公司的文档网站、你团队的笔记里，抽取知识，生成OKF包。你也可以自己写一个消费端，比如一个搜索引擎，专门索引这些OKF包，或者一个AI代理，直接在这些文件夹里推理。谷歌希望，围绕这个格式生长的工具生态，能远远超过他们自己送的这几个小玩具。
从今天起，你可以让AI当你的档案管理员
你现在就可以开始动手了。这个格式目前是0.1版本，还是个孩子。但它一出生就是开源的，因为谷歌知道，一个知识格式要配得上它的名字，必须从一开始就在阳光下成长。
你可以做这么几件事：
第一，去读那个格式说明书。真的很短，比你读完这篇文章要短得多。
第二，为你自己的数据源写一个“生产者”。比如你公司有个MySQL数据库，你能不能写个小脚本，把每个表的结构都转成一个OKF的markdown文件？或者你们有个内部文档网站，你能不能写个爬虫，把每个页面存成一个OKF文件？你不需要一次搞定所有数据，从一个最小的点开始就行。
第三，为你自己的需求写一个“消费者”。比如你需要一个工具，能在一堆OKF文件里快速搜索某个关键词。或者你需要让你的AI助手，在回答一个问题之前，先去读当前文件夹下的index.md文件，而不是自己去瞎猜。或者你干脆就写一个命令行工具，能列出某个OKF包里有几个type是“metric”的文件。
第四，去试试谷歌提供的那个参考机器人，把它指向你自己的数据，看看它生成的OKF包怎么样。你会发现，很多你以前觉得整理起来要花三天的工作，现在AI几分钟就给你干完了。
第五，如果你发现了问题，或者你有更好的想法，去给他们的GitHub仓库提Issue，或者直接提交代码修改。因为这个格式是版本化的，并且被故意设计成可以向后兼容地成长，你的贡献很可能被全世界采纳。
最后，谷歌还做了一件事，他们把自己家的“知识目录”产品给改了，让它能直接吃掉OKF格式的文件夹，并且把这些知识喂给谷歌自己的AI代理。这意味着，如果你用OKF整理知识，你不仅可以用那些开源的小工具，你甚至可以直接跟谷歌家的商业产品对接。当然，这不是必须的。正如反复强调的，格式是自由的。
你的知识不需要被困在一个个死掉的文档和系统里。给它一个简单、开放、人类和AI都认识的形状，它就能活过来。而OKF这个格式，就是那个形状的草图。
总结
本文解释了谷歌发布的开放知识格式。该格式通过一个基于Markdown文件和YAML文件头的文件夹结构，解决信息碎片化问题。核心原则包括极少的强制规定、生产与消费分离、以及供应商中立。文章介绍了参考实现工具，并鼓励读者尝试用这种格式让AI成为知识的主动维护者。
一个比维基百科更简单的办法：用记事本和文件夹让AI懂你的业务！
别再手动整理公司文档了，谷歌这个新格式让AI替你收拾烂摊子
信息散落各处找不到？谷歌OKF格式把文件夹变成AI能读的知识网