你公司花了几十万建的那个知识库，大概率是个"资料黑洞"。
别急着反驳。想想看：上一次你真的从那个库里，挖出过一个之前不知道、还用上了的东西，是什么时候？
如果答案是"记不清了"，那它就不是知识库。那只是个把文档吸进去、就再没吐出来过的黑洞。
我最近给一家码头公司、一家生物医药公司做知识工程化培训，开场第一件事，就是把他们脑子里那个"知识库"三个字，先敲碎了重装。
今天把这套思路拆给你看。它不新，但足够反常识——
用LLM-wiki把知识"编译"成活的 wiki，再用谷歌刚开源的OKF规范当格式标尺。这才是RAG之后，真正能破解数据孤岛的那一步
——而且，顺手把数据主权也拿回了你自己手里。
01 先拆掉你脑子里的"知识库"
一提知识库，大家脑子里浮现的，是一个能搜文档的系统。
错了。那不是知识库，那是"资料黑洞"——东西吸进去，就再没人动过，连它自己都忘了里面有什么。
真正值钱的知识，从来不是"堆"出来的，是"长"出来的。
是点和点之间，自己连上了线。是"这个故障"和"三年前那次停工"之间，被人一眼看出了同一根因。
野中郁次郎早就说过：企业里能被写下来的显性知识，只占10% 到20%。剩下那八成，在老师傅的脑子里、在会议里的随口一句、在跨部门协作的潜规则里。
数据孤岛的本质，从来不是"没数据"。是"有数据，但没连起来"。
你以为建个大库就通了？库越大，反而越像个巨大的、安静的黑洞。
02 RAG 为什么救不了数据孤岛
RAG 是个好东西。它像开卷考试：模型不用背下所有知识，现查现答。
但问题就在这三个字——"现查"。
每次有人提问，RAG都从零开始翻书、拼碎片。它不累积。上次你问过什么、得出过什么结论，它转头就忘。
更致命的是，它不连接。
它给你返回"相关的几段文字"，但不告诉你这几段背后，其实是同一件事的不同切面。
有个被广泛引用的观察：企业知识库里超过40%的文档，建好两年后就过时了。而 RAG 还在一本正经地引用它们。
所以 RAG 是"检索"，不是"工程"。
它解决了"找得到"，没解决"连得起来、长得出来、保得了鲜"。
这恰恰是企业数据孤岛真正的病根。
03 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。
04 谷歌 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 负责把活知识"标准化、可搬运、可推理"。
一个管生长，一个管流通。合起来，才是真正能破解数据孤岛的知识工程。
05 数据主权：为什么这事最关键
说到这，得把这套方法最被低估的一面挑明：它顺手解决了相当一部分的数据主权问题。
什么意思？今天大多企业上知识库，最后知识都住进了某个SaaS平台、某个云厂商的肚子里。模型一换，数据导不出来；厂商一涨价，你被绑死；更麻烦的是，敏感知识一旦进了别人的云，域就出了你的境。对码头公司这种国企、生物医药公司这种手握核心实验数据的公司来说，"数据不出域"从来不是可选项。
LLM-wiki+OKF这套，从根上就避开了这个坑：
知识是纯Markdown，躺在你自己git仓库里。不绑云、不绑数据库、不绑框架。
OKF 的设计目标之一，就是当"主权 AI 栈的基石"。因为它是纯文件格式、无厂商绑定，你的知识文件留在你的“仓库”、你的服务器、你的管辖权。
更妙的是provenance（溯源）。OKF 每个概念都带来源和引用，AI 每句话都能指回"它从哪来的"。对受监管、重风险的组织，"AI 这话从哪来的"不是可选项，是必答题。
所以知识工程化不只是一套效率工具。它让你把最核心的知识资产，留在自己手里、自己能读、自己能搬。
模型会换代，厂商会洗牌，唯一该一直属于你的，是让任何模型变得有用的那层"知识语境"。
06 两个真实战场
光说概念没意思。说说我亲历的两个场子。
码头公司。港口作业的知识，散在 SOP 手册、工单系统、还有老师傅二十年攒下的手感里。以前新员工想搞懂一个故障，得挨个问人。
我们用 LLM-wiki 的思路，把会议纪要、故障处理记录、操作手册喂进去，编译成带交叉引用的活 wiki——"桥吊急停"点一下，能牵出三年前同型号设备的那次停工。再用 OKF 给不同系统的知识发统一"身份证"，原本各说各话的术语，第一次有了通用坐标。对码头公司这种国企，知识全程自托管、数据不出域，本就是硬约束——这套方法正好踩中。
生物医药公司。科研知识迭代快、版本多、方法新旧并存。最怕的就是"用了过时 protocol 还不知道"。
LLM-wiki 自动标注新方法旧方法的矛盾；OKF 让这些知识包能被研究员自己的 AI agent 直接调用，查一个参数，不用再翻五篇 PDF。知识从"存在那"变成"随时能问"。对这家生物医药公司，实验数据和客户项目高度敏感，知识包必须留在自己环境里——OKF 的自托管特性，正好对上。
两个场子的共同点：不是建库，是养库。不是IT交一个项目，是业务日常持续喂料。
07 反转认知：知识工程化，不是"建库"，是"养库"
写到这，该翻一个个认知了。
最大的误区，是把知识工程化当成一次性的IT工程，验收完就完事。
真相是：它是一头持续喂养的活体，越用越值钱。你停喂，它就又变回资料黑洞。
第二个误区：这是技术部门的事。
错了。最懂知识的，永远是一线干活的人。AI不会无聊、不会忘更新交叉引用、一次能改 15 个文件——但它不知道什么重要、什么该信。这个判断，得人来做。
所以人和AI的分工很清晰：
你负责筛选、提问、拍板；
AI负责记账——交叉引用、去重、标矛盾、维护索引。
把这套跑起来，知识才真正"工程化"：可累积、可连接、可保鲜、可搬运。
08 你明天就能做的三件事
不用等完美，先转起来：
① 挑一个你最常被问的领域，建个raw/文件夹，往里丢资料。别贪多，先装一个月的会议纪要就够。
② 写一份Schema（一份CLAUDE.md之类的规则文件），告诉AI你的知识长什么样、怎么命名、怎么交叉引用。
③ 让 AI 帮你编译出第一版 wiki，然后每周 lint 一次——扫矛盾、找过时、补缺口。
知识工程化最难的，从来不是工具。是有人陪你从"建"走到"养"，把这套飞轮真正转起来。
这也是我带 AI 陪跑时在干的事：不是教你几个 prompt，是盯着你做完第一轮，改完，再陪你转下一圈。
今天，就从整理你那个"资料黑洞"开始。
