知识工程化：用 LLM-wiki + 谷歌 OKF，把"资料黑洞"变成活的智库

先拆掉你脑子里的"知识库"

一提知识库，大家脑子里浮现的，是一个能搜文档的系统。

错了。那不是知识库，那是"资料黑洞"——东西吸进去，就再没人动过，连它自己都忘了里面有什么。

真正值钱的知识，从来不是"堆"出来的，是"长"出来的。

是点和点之间，自己连上了线。是"这个故障"和"三年前那次停工"之间，被人一眼看出了同一根因。

野中郁次郎早就说过：企业里能被写下来的显性知识，只占10% 到20%。剩下那八成，在老师傅的脑子里、在会议里的随口一句、在跨部门协作的潜规则里。

数据孤岛的本质，从来不是"没数据"。是"有数据，但没连起来"。

你以为建个大库就通了？库越大，反而越像个巨大的、安静的黑洞。

RAG 为什么救不了数据孤岛

RAG 是个好东西。它像开卷考试：模型不用背下所有知识，现查现答。

但问题就在这三个字——"现查"。

每次有人提问，RAG都从零开始翻书、拼碎片。它不累积。上次你问过什么、得出过什么结论，它转头就忘。

更致命的是，它不连接。

它给你返回"相关的几段文字"，但不告诉你这几段背后，其实是同一件事的不同切面。

有个被广泛引用的观察：企业知识库里超过40%的文档，建好两年后就过时了。而 RAG 还在一本正经地引用它们。

所以 RAG 是"检索"，不是"工程"。

它解决了"找得到"，没解决"连得起来、长得出来、保得了鲜"。

这恰恰是企业数据孤岛真正的病根。

LLM-wiki：让 AI 当"编译者"

LLM-wiki 这个思路，最早是 Karpathy（前特斯拉 AI 负责人、OpenAI 创始成员）公开出来的。一句话讲透：别让AI每次现查，让AI把你的资料"编译"成一座活的 wiki。

类比很妙——

C 源码 (.c)  →  编译器  →  可执行文件 (.exe)
散乱资料 (raw/)  →  LLM  →  结构化 Wiki (wiki/)

它的三层架构极简：

raw/      ← 原始资料（PDF、会议纪要、手册），只读
wiki/     ← LLM 生成的结构化 Markdown，带交叉引用
Schema    ← 一份规则文件（比如 CLAUDE.md），约定知识长什么样

跑起来是四个阶段：摄入 → 编译 → 查询增强 → 校验。

关键是这几件事，传统知识库做不到：

• 一次编译，持续保鲜。新资料进来，LLM 增量更新，不是推倒重来。一篇新论文，可能同时改写"GPU 架构""内存瓶颈""训练效率"十几个页面。
• 交叉引用+矛盾标注。新知识撞上旧结论，AI 会标出来："这条和你三个月前记的冲突了，看哪条对？"
• 越用越厚。好的回答，AI 帮你存回wiki变成新页面。探索本身在复利累积。

Karpathy 自己实践下来，一个领域约 100 篇概念文章、40 万字，全带反向链接。在这个规模内，连向量数据库都不用——一个index.md就是"穷人版搜索引擎"。

人干嘛？人负责筛选资料、定方向、提好问题、做判断。记账的苦活，交给不会累的 AI。

谷歌 OKF：给活 wiki 一把通用尺

光有活 wiki 还不够。问题来了：这座 wiki，换个系统还能用吗？能被别的 AI 直接吃吗？

6月，谷歌开源了一个东西，叫OKF（Open Knowledge Format，开放知识格式）。就是为了解决这个。

它简单到让人意外。就是Markdown+YAML头，只强制一个字段type。预留 index.md、log.md有特殊含义。没了。

但设计理念极狠：生产者和消费者彻底解耦。

人写的 wiki，能被 AI agent 直接消费。一个大模型合成的知识包，能被另一个大模型查询。格式是唯一的契约，两端工具随便换。

不绑云、不绑数据库、不绑框架。你cat得动一个文件，就能读 OKF；git clone 一个仓库，就能分发OKF。

这就是为什么它和 LLM-wiki 是绝配——

LLM-wiki 负责把知识"养活"，OKF 负责把活知识"标准化、可搬运、可推理"。

一个管生长，一个管流通。合起来，才是真正能破解数据孤岛的知识工程。

数据主权：为什么这事最关键

说到这，得把这套方法最被低估的一面挑明：它顺手解决了相当一部分的数据主权问题。

什么意思？今天大多企业上知识库，最后知识都住进了某个SaaS平台、某个云厂商的肚子里。模型一换，数据导不出来；厂商一涨价，你被绑死；更麻烦的是，敏感知识一旦进了别人的云，域就出了你的境。对码头公司这种国企、生物医药公司这种手握核心实验数据的公司来说，"数据不出域"从来不是可选项。

LLM-wiki+OKF这套，从根上就避开了这个坑：

知识是纯Markdown，躺在你自己git仓库里。不绑云、不绑数据库、不绑框架。

OKF 的设计目标之一，就是当"主权 AI 栈的基石"。因为它是纯文件格式、无厂商绑定，你的知识文件留在你的“仓库”、你的服务器、你的管辖权。

更妙的是provenance（溯源）。OKF 每个概念都带来源和引用，AI 每句话都能指回"它从哪来的"。对受监管、重风险的组织，"AI 这话从哪来的"不是可选项，是必答题。

所以知识工程化不只是一套效率工具。它让你把最核心的知识资产，留在自己手里、自己能读、自己能搬。

模型会换代，厂商会洗牌，唯一该一直属于你的，是让任何模型变得有用的那层"知识语境"。

两个真实战场

光说概念没意思。说说我亲历的两个场子。

码头公司。港口作业的知识，散在 SOP 手册、工单系统、还有老师傅二十年攒下的手感里。以前新员工想搞懂一个故障，得挨个问人。

我们用 LLM-wiki 的思路，把会议纪要、故障处理记录、操作手册喂进去，编译成带交叉引用的活 wiki——"桥吊急停"点一下，能牵出三年前同型号设备的那次停工。再用 OKF 给不同系统的知识发统一"身份证"，原本各说各话的术语，第一次有了通用坐标。对码头公司这种国企，知识全程自托管、数据不出域，本就是硬约束——这套方法正好踩中。

生物医药公司。科研知识迭代快、版本多、方法新旧并存。最怕的就是"用了过时 protocol 还不知道"。

LLM-wiki 自动标注新方法旧方法的矛盾；OKF 让这些知识包能被研究员自己的 AI agent 直接调用，查一个参数，不用再翻五篇 PDF。知识从"存在那"变成"随时能问"。对这家生物医药公司，实验数据和客户项目高度敏感，知识包必须留在自己环境里——OKF 的自托管特性，正好对上。

两个场子的共同点：不是建库，是养库。不是IT交一个项目，是业务日常持续喂料。

反转认知：知识工程化，不是"建库"，是"养库"

写到这，该翻一个个认知了。

最大的误区，是把知识工程化当成一次性的IT工程，验收完就完事。

真相是：它是一头持续喂养的活体，越用越值钱。你停喂，它就又变回资料黑洞。

第二个误区：这是技术部门的事。

错了。最懂知识的，永远是一线干活的人。AI不会无聊、不会忘更新交叉引用、一次能改 15 个文件——但它不知道什么重要、什么该信。这个判断，得人来做。

所以人和AI的分工很清晰：

你负责筛选、提问、拍板；

AI负责记账——交叉引用、去重、标矛盾、维护索引。

把这套跑起来，知识才真正"工程化"：可累积、可连接、可保鲜、可搬运。

你明天就能做的三件事

不用等完美，先转起来：

1. 挑一个你最常被问的领域，建个raw/文件夹，往里丢资料。别贪多，先装一个月的会议纪要就够。
2. 写一份Schema（一份CLAUDE.md之类的规则文件），告诉AI你的知识长什么样、怎么命名、怎么交叉引用。
3. 让 AI 帮你编译出第一版 wiki，然后每周 lint 一次——扫矛盾、找过时、补缺口。

知识工程化最难的，从来不是工具。是有人陪你从"建"走到"养"，把这套飞轮真正转起来。

这也是我带 AI 陪跑时在干的事：不是教你几个 prompt，是盯着你做完第一轮，改完，再陪你转下一圈。

今天，就从整理你那个"资料黑洞"开始。