LLM Wiki 的工作原理

返回专题首页

这个方法受到 Andrej Karpathy 提出的 LLM Wiki pattern 启发：让 Agent 把来源逐步编译成一组持久、结构化、彼此连接的 Markdown 页面。公开 Skill 是对这一思路的独立实现，具体指令与模板以 GitHub 仓库 为准。

Raw / Wiki / Schema

• Raw 保存来源和出处。它回答“这个判断来自哪里”，不承担最终解释。
• Wiki 保存机制页、概念页、实体页与 Hub。它回答“我们已经理解了什么”。
• Schema 规定页面类型、元数据、命名、链接和维护规则。它回答“知识应如何保持一致”。

每次采集都先确认目的和结构，再把新证据合并到已有机制页；只有出现独立、可复用的概念时才创建新页。Hub 负责导航，双向链接说明概念之间的关系，索引和维护日志提供稳定入口。

为什么会产生知识复利

传统收藏通常按来源增长：读十篇文章，就得到十份摘要。LLM Wiki 按知识增长：新来源可以补强同一个机制、增加约束、暴露冲突，并连接到其他概念。后续查询读取的是已经整理过的知识网络，而不是每次从原文重新开始。

人负责确定范围、判断质量和处理关键取舍；Agent 负责结构化、搜索已有页面、维护互链与执行一致性检查。

与其他方法的边界

• 临时搜索适合寻找最新事实或一次性答案；结果不会自动变成可维护知识。
• 长上下文适合一次会话内联合阅读少量材料；上下文结束后，结构和判断不会自然沉淀。
• RAG适合从大规模语料中按查询召回片段；它降低检索成本，但召回片段不等于已经消解重复与冲突的知识。
• LLM Wiki适合规模可控、需要持续理解和人工治理的领域；它要付出采集和维护成本，也不替代原始来源或实时检索。

实践中可以组合使用：先搜索或 RAG 找到材料，再把真正值得复用的部分编译进 Wiki。

下一步：从零构建知识库