假期的时候，Karpathy 大神发了一个llm.wiki的想法。 这条推文火爆了。
在LLM Agent时代，分享具体代码或应用的意义正在变弱，现在只需要分享想法，然后把它交给 Claude、Grok 等 Agent，它就可以根据你的需求，自动搭建一个属于你自己的个人知识库。
还有最近特别火的各种 personal skill ，同事.skill、前任.skill、自己的skill，甚至卡兹克把自己的创作skills都开源了。。。。
整体看下来我觉得它们都在做一件事情：把现实世界里原本只能“看”的东西，编译成 AI 可以持续操作的东西。
llm.wiki 在编译知识。创作 skill 编译方法论。persona skill 编译人格。
全网的博主都在分享理论。今天我们分享一下如何能跑通这种知识的编译。
llm.wiki这套理论虽然看起来就是又一次渐进式披露的实践。
但是很多人觉着，这不只是一个 AI 工具，而更像是一种元框架（meta-framework）。它并不依赖某个具体模型或技术栈，而是在尝试定义一种人类与 AI 协作管理知识的方式。随着模型不断迭代、框架持续演进，让 LLM 帮助编译并维护一个持续生长的 Wiki 这一模式，反而具备更长期的稳定性和适用性。
所以llm.wiki在干什么？
过去，大模型使用文档，都是用RAG。问一个要综合五份文档的问题，模型每次都要重新找、重新拼。没有积累。NotebookLM、ChatGPT 的文件上传，其实都是这个模式。
但是llm.wiki的模式是： 你丢一份新材料进去，模型不是索引它等着以后检索，而是立刻读它、提炼它、把关键信息编入已有的 wiki。更新实体页、修订概念页、标注新旧数据的矛盾。一份材料可能触及十几个 wiki 页面。
而且知识编译一次，然后持续维护。不是每次都从头来。
这个模式其实非常有意思，不止可以用在建个人wiki场景，还可以往很多场景拓展，比如记忆。
karpathy大佬举了一些场景case，如下图，也很实用。尤其是今天的ai发展的这么快。前脚龙虾，后脚就hermes。上个月的harness，可能这个月就要拆掉一些了。 这种知识的管理。不论是对个人，还是对自己的agent系统都非常重要。
正常情况下，如果想打通这种自动wiki工作流，很容易遇到各种奇形怪状的数据。但是llm.wiki 这些，都假设数据是干净的markdown，这还还挺不符合实际场景的。
所以，我找了一批更符合真实场景的数据，但是也没有精挑细选。主要是Anthropic、OpenAI关于harness的博客。还有新模型mythos的博客、智谱glm5.1的博客、以及智谱的招股书（本来准备下载财报的，好像下错了，不过这个500多页pdf，也有很多复杂的图表）。
然后就可以开始按照llm wiki的要求3层架构构建了。
把llm.wiki丢给agent，会自动构建好目录结构。 我用的 cursor + opus 4.6。raw 放原始材料，wiki 放 AI 维护的知识中间层，AGENTS.md 告诉 AI 这个 wiki 怎么组织。
整体的一个壳子大概长下面这个样子。
然后第一道坎就来了。
如果你的实际数据不是规整的txt，或者markdown，ai用pdfplumber转成的markdown就会变成这个样子。文字换行、缩进、表格、图片，这些都没法保留，甚至可能混乱。
不管是简单的博客，还是复杂的文档，解析成这个样子其实对模型都特别不友好。
还好我用的opus 4.6，对这些东西会鲁棒一些，如果用国产平替估计影响就比较大了。
但是。正好，我们最近有一些业务涉及到复杂的word格式文档处理，订阅了合合信息 TextIn 的 API，所以我顺手做了个对比。
比如，这是TextIn转写的博客结果，图片和格式排版这些都有保留。
TextIn对表格的表示用的是用的html形式的，所以它可以表示更复杂的无线表、合并单元格这些。
可以看下图。在招股书的解析里边，图表的结果也非常的不错。
最后，还附上TextIn api的耗时参考。目前，这套解析，在我们现在内部的一个业务上跑的还不错。可以在这里测试TextIn的解析：https://cc.co/16YSdj
搞定预编译之后，开始走 ingest 流程。这里有一个很蠢的坑，模型喜欢偷懒，一次性看一点文档，然后ingest很多的文档。
结果每份材料都是浅读，生成的 wiki 页面跟目录没什么区别。信息密度极低。
所以这里我优化了一下默认的AGENTS.md，让它一份份处理，超过的还要分段来处理。
这个小优化会带来比较明显的数据处理质量的提升。
10 份材料全部 ingest 完之后，结构是这样的：
大概的一个流程是，解析->然后模型会按照AGENTS.md 梳理每份内容的要点，文档要点示例如下：
然后会整理出实体、概念。 以下是二者的示例。都会有明确的跟其他文件的link关系。
concept之间还会自动构建起对比，comparisons示例：
最后，从结果来看，因为我已经用了最顶级的Opus4.6模型了，所以不论是不是最好的解析方式。
带来的wiki结构密度其实差异不大。但是信息密度差异比较大。用TextIn API解析的数据可以保留更多的原始信息，让整个库的信息密度更高。
所有有考虑搭建这种自动更新wiki的同学，可以考虑，尽量用最好的解析策略。
接下来就可以看出来这种关联wiki的魅力了。
比如Harness，我放了4篇博客，包含Ralph Wiggum的反对多Agent的博客，以及OpenAI、Anthropic的相关博客。
这样，在Agent Harness概念页就出现了同时容纳了正反两方的观点，还用表格对比了两种流派的差异。
这种跨文档的交叉引用和矛盾标注，RAG 是做不到的。RAG 能从单份文档里检索片段，但它不会主动发现两个人其实在用不同方式解决同一个问题。但是通过这种模式，构建的wiki 它就全都懂了。
或者需要结合多个跨文档综合的问题。比如「智谱跟 Anthropic 的商业化策略有什么不同」。
Agent就可以依据信息的链接跳转，自动的去探索需要的信息，找到最终的答案了。
而传统的利用单文档的longcontext chatbot 或者 RAG，其实很难做这些事情。但是wiki已经把他们编译好了。
写在最后
坦率的讲，跑完整个流程之后我有一个很强的感受。
llm.wiki 这个模式从理论上肯定是跑得通的。你在里面能看到 GraphRAG 的影子，能看到 Skills 的影子，能看到 Context Engineering 的影子。这些东西换了不同的名字，但做的事情有很大的重叠。
而在 Harness Engineering 爆火的今天，llm.wiki 其实又是在强调，过去那些手动维护知识库的包袱，可以扔了。一整套编译工作，交给模型就行。
但一个东西没变。
garbage in, garbage out。今天依然成立。
解析，仍然是很多项目真正的卡点。如果你现在还在被这个问题困扰，可以试试 TextIn，地址在这里：https://cc.co/16YSdj
