LLM Wiki - 让 AI 整理出来的知识持续沉淀
这个想法来自 Andrej Karpathy 的 LLM Wiki gist。它更像一条精炼的提案，距离完整产品还很远：让 AI agent 根据原始资料持续维护一个 Markdown Wiki，让知识工作可以积累下来，避免每次用完就散。
一种让 AI agent 持续维护 Markdown Wiki 的模式：把有价值的理解沉淀下来，避免每次都从原始资料重新开始。
LLM Wiki 把知识库看作一个可以被 AI agent 持续更新的对象。原始资料保留为可追溯的证据，Markdown Wiki 层则承载不断积累的综合理解。
真正有用的转变，是把已经理解过的东西维护起来。
可复用的知识
有价值的输出应该超出一次回答，沉淀成之后可以继续复用的知识层。
筛选和判断
人负责选择资料、提出更好的问题、检查重点，并判断哪些内容值得留下。
维护结构
AI agent 更新摘要、概念页、链接、矛盾、索引和相关笔记。
持续增长的主题
当一个主题会持续积累资料和关系时，这个模式才有价值。一次性的小记录，保持简单就好。
这个模式靠三个层次运转。
它把证据、综合后的知识，以及约束 AI agent 的规则分开，让维护工作更稳定。
原始资料保持不变
文章、论文、转录文本、数据集、网页存档、截图等资料都保持可追溯。
Wiki 成为持续维护的综合层
Markdown Wiki
指令决定更新方式
Schema 和 agent 指令规定内容放在哪里、链接怎么处理、来源如何记录，以及什么时候更新已有笔记。
源文件保留为可审计的证据。Wiki 负责总结和连接它们，但不替代它们。
可复用的理解进入互相链接的笔记，让未来的问题从已维护的上下文开始。
Schema 告诉 agent 什么时候创建、更新、引用、链接、记录，什么时候保持不动。
Wiki 通过一次次维护产生复利。
这个循环的重点不在捕捉、总结之后就结束。每一次有价值的处理，都应该让知识库更容易查询、浏览、审计和继续维护。
吸收资料
新资料进入时，agent 要判断它改变了什么：概念、实体、链接、比较，还是来源记录。
回应问题
有价值的回答可以沉淀成持久笔记，不要留在聊天记录里就结束。
维护结构
定期检查过时的说法、互相矛盾的笔记、缺失的链接、孤立笔记和薄弱导航。
每一次处理都会让 Wiki 更容易查询、浏览、审计和维护。输出应该超出一个回答，变成一个更好的知识库。
适合文章、论文、剪藏、转录文本，或其他会影响多个笔记的长期研究资料。
好的比较、框架、看板或项目笔记，最好写回 Wiki，不要只留在聊天记录里。
当笔记和来源越来越多时，健康检查可以让整个知识图谱保持可用。
当每一层都有清楚的位置时，这个模式才会变得具体。
这是我自己笔记系统里那张映射的公共版本：把证据、综合理解、实体、入口、指令和日志分成不同职责。
来源层
可长期保存的来源包、PDF、剪藏、存档和文件，供之后的笔记引用。
知识层
可复用的概念、框架、项目和综合笔记，会逐渐变成工作知识。
entities
人物、组织、产品，以及反复出现的引用对象。
maps
给人浏览、也给 agent 定位的入口页。
system
归档规则、YAML、模板和任务指令。
logs
有意义的 AI 修改按时间记录下来。
这里真正有用的单位，往往是一整次有纪律的处理：一份有意义的资料，可以同时更新来源包、库笔记、实体页、地图和变更日志。
RAG 和 LLM Wiki 解决的是知识问题里的不同部分。
提问时检索
持续维护的综合理解
要有意识地使用它，不要拿它处理每一条小记录。
- 一个主题会在几周或几个月里持续积累资料。
- 每次都从头综合会很浪费。
- 概念、实体和比较需要保持连接。
- 未来的 AI agent 需要继承已经维护好的上下文。
- 这只是一条一次性的小记录。
- 快速回答已经够用。
- 没有必要保留来源追溯。
- 这个主题不需要持续维护。
把握意义
选择资料、提出问题、检查重点，并判断什么值得变成长期知识。
执行维护
阅读资料、更新笔记、创建链接、处理矛盾、刷新索引，并为有意义的改动留下简洁记录。
约束流程
文件夹职责、YAML、模板、任务指令和安全规则，让更新足够一致，能够积累，也能避免慢慢漂移。
我觉得这个想法有意思，是因为它让 AI 知识工作可以积累。
我喜欢 LLM Wiki 的地方，是它让 AI 从一个“回答机器”，变成一种知识维护层。重要的问题变成：处理完这份资料或这次对话之后，知识库有没有比之前更好？
这对不断扩展的主题尤其有用。好的回答如果澄清了概念、比较了想法，或者更新了理解，最好能沉淀成之后还能复用的东西。