收藏了很多文章真正需要时却找不到和 AI 讨论了很多问题结论又散落在聊天记录里怎么检索这类问题适合用 LLM Wiki 来改善让 AI 把资料整理成长期保存、互相关联的知识页。一、LLM Wiki 是什么Karpathy 在 LLM Wiki idea 中提出了一种个人知识库维护模式由用户选材和引导LLM Agent 持续整理 Markdown 页面。它是一份设计思路而非安装后就能使用的成品软件。具体目录、页面格式和工具需要按自己的需求确定。例如读完一篇数据库文章除了保存摘要还可以更新“索引”“事务”等概念页把新结论关联到已有知识。以后查阅时就能复用这次整理成果。二、和 RAG 有什么差别RAG检索增强生成通过检索外部资料为模型生成答案提供依据。LLM Wiki 则侧重维护持久的知识成果。维度典型文档 RAGLLM Wiki核心工作检索资料辅助生成答案整理知识维护页面与关系新资料进入更新检索索引更新摘要、概念、主题和关联查询依据相关文档或片段整理后的知识页必要时回看原文成果保存取决于系统设计明确把有价值的成果写回知识库主要挑战召回质量与答案依据综合准确性与长期一致性这不是互斥选择。RAG 可以检索 wiki 页面LLM Wiki 也可以使用关键词、向量或其他检索方式。不能把“必须向量化”或“无法积累知识”当成所有 RAG 系统的特征。三、三层结构三个操作原始 idea 将系统分成三层原始资料、整理后的 wiki以及约束 Agent 行为的 schema。schema 可以由AGENTS.md等规则文件承载。下面给出一个简化实现目录命名和归档方案是本文的落地建议。knowledge-base/ ├── AGENTS.md # Agent 工作规则 ├── raw/ # 待摄入资料 │ ├── assets/ # 图片等附件 │ └── ingested/ # 已摄入原文 └── wiki/ ├── index.md # 按主题导航 ├── log.md # 按时间记录操作 ├── sources/ # 来源总结 ├── concepts/ # 概念页 └── topics/ # 主题综合日常操作对应三个环节Ingest摄入把资料整合到知识库。Query查询基于已有知识回答问题并按需保存成果。Lint检查发现断链、遗漏、冲突和过时内容。index.md负责“有哪些知识”log.md负责“做过哪些操作”。原文需要保留以便核验模型的总结。四、如何搭建准备一个能读写本地文件的 LLM Agent以及一个 Markdown 编辑器。Obsidian 可用于阅读页面和查看关联但不是必需组件。1. 建立目录和规则按上面的结构创建目录在AGENTS.md中写入以下简化规则# 知识库工作规则 ## 来源与证据 - 原文内容不改写更新资料以新版本保存。 - 知识页注明来源区分来源陈述、模型推论和待核实内容。 - 发现冲突时列出双方依据不强行合并结论。 ## 摄入 - 默认只处理 raw 根目录源文件排除隐藏文件和子目录。 - 完整阅读后创建来源页更新相关概念和主题补交叉链接。 - 更新索引并检查成功后归档至 raw/ingested追加完成日志。 - 不覆盖同名归档核对移动前后内容及附件链接。 - 失败或部分完成留原位重试复用已有页面避免重复生成。 ## 查询与维护 - 优先读 wiki必要时回看原文回答注明依据。 - 有价值的回答按需写回 wiki优先更新同主题页面。 - 定期检查链接、索引、来源缺失、内容冲突和时效。 - 删除来源时先确认保留知识还是撤回贡献不自动连带删页。让 Agent 先读取规则再创建空的索引和日志。初期不需要急着引入数据库、插件或复杂搜索服务。2. 跑通一次摄入把一篇文章保存到raw/根目录然后发送请摄入新增资料完整阅读 raw 根目录的源文件生成来源总结提炼关键概念更新相关页面和交叉链接。检查通过后归档更新索引与日志报告完成和未完成项目。验收时看四件事原文能否找到、总结是否准确、新旧知识是否关联、失败项是否明确。不要只看生成了多少文件。对于图片和 PDF需要确认 Agent 能读取对应内容。仅读取标题或部分文本不能算完成摄入。
)
